Was ist Context für KI-Agenten – und warum er der eigentliche Hebel ist

Warum dieser Artikel jetzt kommt

In den bisherigen Artikeln dieser Serie habe ich über Context Engineering geschrieben – über Regel-Dateien, Memory-Systeme, Skills. Ich habe erklärt, wie man Context strukturiert, speichert und bereitstellt.

Was ich dabei übersprungen habe: Was Context überhaupt ist.

Das war ein Fehler. Denn ohne dieses Fundament bleiben die praktischen Techniken abstrakt. Man weiß, dass man .cursorrules nutzen soll, aber nicht wirklich, warum. Man hört von Context Windows, ohne zu verstehen, was sie begrenzt.

Dieser Artikel holt das nach. Er erklärt die Grundlagen – nicht als Einstieg, sondern als nachträgliche Vertiefung. Wer die vorherigen Artikel gelesen hat, wird jetzt verstehen, warum die dort beschriebenen Techniken funktionieren. Wer neu einsteigt, bekommt hier das konzeptionelle Fundament.

Wenn der Agent plötzlich nachlässt

Wer KI nur für einfache Fragen nutzt – „Was bedeutet dieser Fehler?”, „Wie geht nochmal die Syntax für X?” – wird das Problem nie bemerken. Die Antwort kommt, sie passt, fertig.

Aber sobald die Komplexität steigt, ändert sich alles.

Du arbeitest mit einem Coding-Agent an einem echten Projekt. Die erste Stunde läuft brillant – präzise Antworten, passender Code, kluge Vorschläge. Der Agent kennt deine Architektur, versteht den Kontext, liefert Code, der direkt funktioniert.

Dann kippt es.

Plötzlich:

• Der Agent vergisst, was ihr gerade besprochen habt
• Er widerspricht sich selbst
• Antworten werden generisch statt projektspezifisch
• Details verschwinden, die Arbeit wird vage

Die Vermutung: Das Modell ist schlecht. Oder es hat einen schlechten Tag. Oder man hat den falschen Prompt geschrieben.

Die Realität: Das Problem ist fast nie das Modell. Das Problem ist der Context.

Was „Context” wirklich bedeutet

Context ist nicht abstrakt. Er ist konkret und messbar.

Context = alles, was das Modell gleichzeitig sieht, wenn es eine Antwort generiert.

Das umfasst:

• Systemprompt: Die versteckten Anweisungen, die das Verhalten definieren
• Chat-Historie: Alles, was du und der Agent bisher geschrieben habt
• Eingefügte Dateien: Code, Dokumentation, Konfiguration
• Tool-Definitionen: Welche Werkzeuge verfügbar sind
• Die aktuelle Frage: Dein letzter Prompt

Und – das wird oft übersehen:

• Die Antworten des Agenten: Auch seine eigenen Outputs zählen zum Context

Jedes Wort, jede Zeile Code, jede Erklärung – alles fließt in einen gemeinsamen Pool. Diesen Pool nennt man Context Window.

Die harte Grenze: Warum Context endlich ist

Jedes Sprachmodell hat ein fixes Context Window. Das ist keine Softwarebeschränkung, die man per Update aufheben könnte. Es ist eine architektonische Realität.

Modell	Context Window
GPT-4o / GPT-4.1	128.000 Tokens
OpenAI Codex (codex-1)	192.000 Tokens
Claude Opus 4 / Haiku 3.5	200.000 Tokens
Claude Sonnet 4	1.000.000 Tokens
Gemini 2.5 Pro/Flash	1.000.000 Tokens (bis 2M für Entwickler)

Klingt nach viel?

Zur Einordnung:

• 1 Token ≈ 0,75 Wörter (im Englischen)
• 100.000 Tokens ≈ 75.000 Wörter ≈ ein mittellanges Buch
• Ein durchschnittliches TypeScript-Projekt hat schnell 50.000+ Zeilen Code

Wer eine komplette Codebase in den Context kippt, hat schnell kein Fenster mehr übrig für die eigentliche Arbeit.

Was passiert bei Überfüllung?

Wenn das Context Window voll ist:

1. Abbruch: Der Agent stoppt oder liefert unvollständige Antworten
2. Qualitätsverlust: Frühere Informationen werden faktisch ignoriert
3. Inkonsistenz: Der Agent widerspricht sich, weil er den Anfang nicht mehr „sieht”

Warum mehr Context nicht automatisch besser ist

Die Intuition sagt: Mehr Information = bessere Antworten.

Die Realität ist komplizierter.

Die Nadel im Heuhaufen

Stell dir vor, du gibst dem Agent 50 Dateien mit insgesamt 80.000 Tokens. Irgendwo in Datei 37 steht die entscheidende Information für deine Frage.

Das Problem: Das Modell muss diese Nadel im Heuhaufen finden. Je größer der Haufen, desto schwieriger wird das.

Verloren in der Mitte

Studien zeigen: Sprachmodelle haben eine Aufmerksamkeitsverteilung, die nicht gleichmäßig ist.

Sie bevorzugen:

• Den Anfang des Context (Systemprompt, erste Nachrichten)
• Das Ende des Context (aktuelle Frage, letzte Nachrichten)

Was in der Mitte steht? Wird statistisch weniger beachtet.

Das bedeutet: Wichtige Informationen in der Mitte einer langen Chat-Historie können faktisch unsichtbar werden.

Kleine, fokussierte Contexts performen oft besser

Ein präziser Context mit 5.000 Tokens schlägt regelmäßig einen überladenen Context mit 150.000 Tokens.

Warum?

• Weniger Rauschen, mehr Signal
• Keine widersprüchlichen Informationen
• Klarer Fokus auf die aktuelle Aufgabe
• Modell kann Zusammenhänge leichter erkennen

Typische Context-Fehler beim Coden

Nach Monaten täglicher Arbeit mit Coding-Agents sind das die häufigsten Fehler:

1. Endlose Chat-Historien

Die Session läuft seit 6 Stunden. 200 Nachrichten. Der Agent „weiß” theoretisch alles – praktisch hat er den Anfang längst vergessen.

Das Problem: Die ersten 50 Nachrichten sind effektiv unsichtbar.

2. Komplette Codebase einkippen

„Hier ist mein Projekt, alle 847 Dateien. Hilf mir beim Login.”

Das Problem: Der Agent ertrinkt in irrelevanter Information. Die Login-Logik (3 Dateien) geht unter.

3. Alte Entscheidungen mitschleppen

Du hast vor 2 Stunden einen Ansatz verworfen. Die Diskussion darüber ist noch im Context. Der Agent bezieht sich jetzt wieder darauf.

Das Problem: Veraltete Information vergiftet aktuelle Entscheidungen.

4. Mehrere Aufgaben in einer Session vermischen

Erst Datenbankschema, dann Frontend-Styling, dann Tests, dann Deployment. Alles in einer Session.

Das Problem: Der Agent hat keinen klaren Fokus. Jede Aufgabe leidet unter dem Ballast der anderen.

Context ≠ Projektwissen

Das ist ein kritischer Unterschied, den viele übersehen:

Projektwissen	Working Context
Tech-Stack des Projekts	Aktuelle Datei
Architekturentscheidungen	Aktuelles Problem
Coding-Standards	Letzte 5 Nachrichten
API-Struktur	Nächster Schritt
Vergangene Bugs	-

Projektwissen ist alles, was über die aktuelle Session hinaus relevant ist. Es gehört in Regel-Dateien, Dokumentation, externe Speicher.

Working Context ist das, was der Agent jetzt gerade braucht, um die aktuelle Aufgabe zu lösen.

Das Context Window ist für Working Context optimiert, nicht für Projektarchive.

Warum Agents kein „Projektgedächtnis” haben

Ein Sprachmodell speichert nichts zwischen Sessions. Wenn die Session endet, ist der Context weg. Vollständig.

Es gibt keine versteckte Datenbank, in der Claude oder GPT sich Dinge „merken”.

Die Konsequenz: Projektwissen muss explizit bereitgestellt werden – über Regel-Dateien (.cursorrules, .claude), über Memory-Systeme (ByteRover), oder über bewusste Zusammenfassungen.

Context wie Arbeitsspeicher behandeln

Die beste Analogie: Context ist wie RAM, nicht wie eine Festplatte.

RAM (Context)	Festplatte (Externes Wissen)
Begrenzte Kapazität	Praktisch unbegrenzt
Schneller Zugriff	Muss geladen werden
Für aktuelle Arbeit	Für Langzeitspeicherung
Verliert Inhalt bei Neustart	Persistent

Was gehört in den Context?

• Die aktuelle Aufgabe
• Relevante Code-Dateien (nicht alle)
• Aktuelle Entscheidungen
• Unmittelbare nächste Schritte

Was gehört ausgelagert?

• Architekturentscheidungen → Regel-Dateien
• Vergangene Diskussionen → Zusammenfassungen
• Coding-Standards → Dokumentation
• Projekt-Historie → Memory-Systeme

Warum Zusammenfassungen so effektiv sind

Statt eine 50-Nachrichten-Diskussion mitzuschleppen, fasst man zusammen:

Vorher (5.000 Tokens):

Nachricht 1: "Ich denke, wir sollten..."
Nachricht 2: "Aber was ist mit..."
Nachricht 3: "Guter Punkt, allerdings..."
[...47 weitere Nachrichten...]

Nachher (200 Tokens):

Entscheidung: PostgreSQL statt MongoDB
Grund: ACID-Transaktionen für Payments notwendig
Nächster Schritt: Prisma-Schema erstellen

Der Agent hat dieselbe Information – in 2,5% des Platzbedarfs.

Strategien für sauberen Context

Diese Praktiken sind tool-agnostisch. Sie funktionieren mit Claude, ChatGPT, Cursor, Warp oder jedem anderen System.

1. Eine Aufgabe pro Session

Starte für jede abgeschlossene Aufgabe eine neue Session. Nicht aus Faulheit weitermachen, weil „der Context ja schon da ist”.

Warum: Frischer Context = fokussierter Agent.

2. Klare Zieldefinition am Anfang

Beginne jede Session mit einer präzisen Aufgabenstellung:

Aufgabe: JWT-Refresh-Token implementieren
Stack: Node.js, Express, jsonwebtoken
Relevante Dateien: auth.service.ts, auth.middleware.ts
Constraints: RS256, Token-Rotation bei Refresh

Nicht: „Hilf mir beim Auth-System.”

3. Regelmäßige „Context-Hygiene”

Nach 10-15 Nachrichten: Zusammenfassen, was erreicht wurde. Den Rest kann der Agent vergessen.

Stand: Login-Route funktioniert, Token-Generierung steht.
Offen: Refresh-Logik, Logout-Endpoint.
Nächster Schritt: Refresh-Token-Rotation.

4. Bewusstes Neustarten statt Weiterschleppen

Wenn eine Aufgabe abgeschlossen ist: Neue Session.

Die Angst, Context zu verlieren, ist oft unbegründet. Mit einer guten Zusammenfassung startet die neue Session schneller und fokussierter.

5. Lieber kurze Recaps als lange Historien

Wenn du den Context einer alten Session brauchst, kopiere nicht alles. Schreibe stattdessen:

Letzte Session:
- Wir haben das Auth-System implementiert
- JWT mit RS256, 15min Expiry
- Refresh-Token in HttpOnly-Cookie
- Problem offen: Token-Rotation

Jetzt: Token-Rotation implementieren.

Das sind 50 Tokens statt 10.000.

Woran man erkennt, dass der Context „kippt”

Diese Warnsignale zeigen, dass das Context Window überlastet ist:

Antworten werden vage

Vorher: „Du solltest in auth.service.ts die Funktion validateToken anpassen, Zeile 47.”

Nachher: „Du könntest die Token-Validierung anpassen.”

Der Agent verliert Präzision, weil er den konkreten Code nicht mehr „sieht”.

Modell widerspricht sich

Nachricht 15: „Wir verwenden PostgreSQL.” Nachricht 87: „Für MongoDB würde ich folgendes Schema vorschlagen…”

Der Anfang der Session ist aus dem effektiven Kontext verschwunden.

Details gehen verloren

Du: „Denk dran, wir nutzen Zod für Validierung.” Agent, 30 Nachrichten später: Generiert Code mit manueller Validierung.

Die Information ist zwar im Context, aber in der „toten Zone” (Mitte).

Fokus driftet

Der Agent beantwortet plötzlich Fragen, die du nicht gestellt hast. Oder er schweift in Themen ab, die vor 50 Nachrichten relevant waren.

Das passiert, wenn zu viele unzusammenhängende Themen im Context konkurrieren.

Context-Management in der Praxis: CLI-Befehle

Die Theorie ist klar – aber wie setzt man das konkret um? Moderne Coding-Agents bieten eingebaute Befehle für Context-Management. Hier die wichtigsten für Claude Code und OpenAI Codex.

Claude Code: Slash-Commands

Befehl	Funktion
/context	Zeigt die aktuelle Token-Nutzung des Context Windows (grafisch)
/clear	Löscht die komplette Chat-Historie – harter Reset
/compact	Fasst den bisherigen Chat zusammen, behält den Sinn, macht Platz
/status	Zeigt System- und Session-Status (Token, Modell, etc.)
/model	Modell wechseln (z.B. Opus, Sonnet)
/agents	Verwaltet Sub-Agents mit eigenen Context Windows

CLI-Flags für Session-Management:

• claude --resume – Setzt eine alte Session fort
• claude --continue – Führt die letzte Session weiter

Praxis-Tipp: /compact für sanftes Aufräumen, /clear für harten Reset. Beobachte regelmäßig /context, um nicht zu überladen.

OpenAI Codex: Slash-Commands

Befehl	Funktion
/compact	Fasst die Unterhaltung zusammen, um Tokens freizugeben
/new	Startet eine neue Konversation in derselben CLI-Session
/status	Zeigt aktuellen Session-Status inkl. Token
/init	Erstellt ein AGENTS.md-Gerüst für persistenten Projektkontext
/undo	Letzten Schritt rückgängig machen
/diff	Git-Diff anzeigen

Session-Restaurierung:

• codex resume --last – Setzt die letzte Session fort

Vergleich: Context-Befehle

Funktion	Claude Code	Codex CLI
Context anzeigen	/context	/status
Context leeren	/clear	/new
Context zusammenfassen	/compact	/compact
Session fortsetzen	--resume	resume --last
Projekt-Context	CLAUDE.md	AGENTS.md

Workflow: Längere Refactor-Session

Ziel: Mehrere Stunden am selben Thema arbeiten, ohne dass der Agent „abbaut”.

Claude Code:

1. Start: Neues Terminal, Ziel klar setzen
2. Während der Arbeit: Regelmäßig /context prüfen
   • Ab 60–70% Auslastung: /compact
   • Wenn Antworten schwammig werden: sofort /compact
3. Nach Meilenstein: /clear, dann Neustart mit kurzem Status:
   • Was ist fertig
   • Was ist offen
   • Was explizit nicht anfassen

Codex:

1. Start: /new, Ziel + Scope formulieren
2. Während der Arbeit: /status im Blick behalten
   • Wenn es „zäh” wird: /compact
   • Wenn alte Annahmen durcheinander kommen: /new + Mini-Recap
3. Nach Meilenstein: Session beenden, später mit codex resume --last fortsetzen

Workflow: Feature-Bau mit Context-Isolierung

Idee: Nicht ein großer Chat, sondern mehrere kleine, saubere Contexts.

Claude Code (empfohlen):

• Haupt-Session: Architektur, API-Design, Entscheidungen
• Sub-Agents (/agents):
  • Agent A: UI / Komponenten
  • Agent B: Backend / Logik
  • Agent C: Tests

Vorteil: Jeder Agent hat eigenen Context. Kein Lost-in-the-Middle.

Codex (simuliert):

• Session 1: „Architektur & API”
• Session 2: „Implementierung”
• Session 3: „Review & Cleanup”

Zwischen Sessions: Kurztext mit Annahmen, Constraints, Entscheidungen kopieren.

Gute Ergebnisse sind Context-Arbeit

Coding-Agents sind beeindruckend leistungsfähig. Sie können komplexen Code schreiben, Bugs finden, Architekturen vorschlagen.

Aber sie sind keine Magie. Sie arbeiten mit dem, was sie sehen.

Context ist der eigentliche Hebel. Nicht das Modell. Nicht der perfekte Prompt. Sondern das, was im Context Window steht – und was nicht.

Wer Context beherrscht, holt mehr aus jedem Modell heraus. Wer Context ignoriert, kämpft irgendwann gegen unsichtbare Wände.

Die gute Nachricht: Context ist kontrollierbar. Anders als Modell-Intelligenz oder API-Limits ist es etwas, das sich direkt beeinflussen lässt. Die Werkzeuge sind da – /compact, /clear, Regel-Dateien, Session-Splitting. Ob und wie man sie nutzt, bleibt jedem selbst überlassen.