Kontext ist Infrastruktur

Ein Sprachmodell kann innerhalb weniger Minuten eine beeindruckende Menge Arbeit erzeugen. Es kann recherchieren, strukturieren, entscheiden, schreiben, prüfen und Folgeaufgaben delegieren. Doch je länger ein Projekt läuft, desto deutlicher zeigt sich eine Grenze, die mit reiner Modellintelligenz wenig zu tun hat: Ein gutes Ergebnis hängt nicht nur davon ab, was das Modell kann, sondern davon, welchen Zustand des Projekts es im richtigen Moment tatsächlich vorliegen hat.

Ein Agent kann fachlich stark sein und trotzdem falsch weiterarbeiten, wenn ihm die letzte Entscheidung fehlt. Ein Chat kann tausende Nachrichten enthalten und trotzdem einen veralteten Projektstand transportieren. Ein Projektordner kann dutzende Quellen besitzen und trotzdem keine klare Antwort darauf geben, welche davon für die aktuelle Aufgabe verbindlich sind. Und ein Team kann mehrere parallele KI-Sessions betreiben, ohne einen gemeinsamen Wissensstand zu besitzen.

Deshalb ist Kontext kein dekorativer Zusatz zu einem Prompt.

Kontext ist Infrastruktur.

Er muss geplant, geschnitten, aktualisiert, übergeben, versioniert und von Ballast befreit werden. Nicht anders als Daten, Schnittstellen oder Berechtigungen.

Das Context Window ist nicht das Projektgedächtnis

Der erste Denkfehler beginnt bereits beim Begriff „Kontext“.

Ein Context Window ist zunächst nur der Arbeitsraum, den ein Sprachmodell für die aktuelle Inferenz zur Verfügung hat. Dort landen je nach System unter anderem Systemanweisungen, die aktuelle Unterhaltung, Teile früherer Nachrichten, Dateien, Toolergebnisse, abgerufene Daten und interne Arbeitszustände.

Das ist nützlich. Aber es ist kein verlässliches Projektarchiv.

Ein langer Chat vermittelt leicht das Gefühl, die KI „wisse doch alles“. Tatsächlich steigt mit wachsendem Verlauf die Konkurrenz um Aufmerksamkeit. Frühere Informationen können zusammengefasst, komprimiert, schlechter gewichtet oder schlicht nicht in dem Detail verfügbar sein, das eine aktuelle Entscheidung verlangt.

Die praktische Konsequenz lautet:

Ein Projekt darf seinen Zustand nicht nur in der flüchtigen Arbeitsfläche eines Chats speichern.

Der Chat ist ein Arbeitsraum. Das Projekt braucht darüber hinaus dauerhafte Zustandsobjekte.

Fünf Ebenen von Kontext

Für längere KI-Projekte hilft eine klare Schichtung.

Diese Ebenen sollten nicht ungeprüft ineinanderfallen.

Wenn jede Unterhaltung das gesamte Projektarchiv enthält, entsteht Überladung. Wenn ein neuer Chat nur einen kurzen Prompt erhält, entsteht Kontextverlust. Wenn eine Wissensdatenbank alles enthält, aber niemand definiert, welche Einträge aktuell verbindlich sind, entsteht semantische Unschärfe.

Die Architektur muss deshalb beantworten: Was muss dauerhaft existieren, was muss für diese Aufgabe geladen werden, und was darf nach dem Arbeitszyklus wieder verschwinden?

Projektordner sind Kontextgrenzen, keine magischen Gedächtnisse

Ein guter Projektordner ist wertvoll, weil er Arbeit bündelt: Instruktionen, Referenzdateien, Chats und wiederkehrende Projektressourcen können an einem Ort zusammengeführt werden.

Aber auch ein Projektordner löst das Kontextproblem nicht automatisch.

Er sollte vielmehr als Context Boundary verstanden werden: eine definierte Grenze, innerhalb derer bestimmte Materialien, Regeln und Gespräche zu einem Projekt gehören.

Das erlaubt beispielsweise eine Trennung zwischen einem Forschungs- oder Methodenraum, einem konkreten Kunden- oder Produktprojekt, einem experimentellen Prototyp, einem produktiven Arbeitsraum und einem Archiv abgeschlossener Entscheidungen.

Diese Trennung ist nicht bürokratisch. Sie schützt vor Kontextverschmutzung.

Wenn etwa allgemeine Recherche, persönliche Notizen, mehrere Kundenprojekte und experimentelle Agentenprompts im selben Raum landen, wächst die Wahrscheinlichkeit, dass ein System gültige und ungültige Informationen vermischt.

Ein Projektordner ist gut, wenn er Relevanz erhöht. Er ist schlecht, wenn er nur Masse sammelt.

Der wichtigste Projektordner enthält nicht die meisten Dateien

Die Qualität eines Projektordners lässt sich nicht an seiner Dateizahl messen.

Ein tragfähiger Ordner braucht wenige besonders klare Anker:

1. Project Charter: Ziel, Scope, Non-Scope, Erfolgskriterien.

2. Current State: Was ist jetzt wahr? Welche Version gilt?

3. Decision Register: Welche wesentlichen Entscheidungen sind aktiv?

4. Constraints: Welche Regeln, Rechte, Budgets und Verbote gelten?

5. Source Index: Welche Quellen tragen welche Aussagen?

6. Open Issues: Was ist ungeklärt, blockiert oder umstritten?

7. Next Actions: Was darf als Nächstes tatsächlich passieren?

Dazu kommen Fachquellen und Arbeitsartefakte.

Der Unterschied ist entscheidend: Quellen sagen, was wir wissen könnten. Ein kanonischer Projektzustand sagt, was das Projekt derzeit als gültig behandelt.

Chats sind Arbeitsräume – nicht das Betriebssystem des Projekts

Ein langer Chat kann sehr produktiv sein. Er kann Stil, Fachsprache und lokale Entscheidungen gut halten. Doch ab einem gewissen Punkt wird seine Stärke zur Schwäche.

Der Verlauf wächst, Seitenthemen entstehen, Annahmen ändern sich, alte Instruktionen bleiben sichtbar und die Zahl impliziter Abhängigkeiten nimmt zu.

Die Frage „Soll ich im selben Chat weitermachen?“ ist deshalb keine Komfortfrage. Sie ist eine Architekturentscheidung.

Ein sinnvoller Chat sollte eine kohärente Arbeitseinheit besitzen, zum Beispiel Recherche zu einer klaren Frage, Architektur eines Moduls, Review einer Version, Ausarbeitung eines bestimmten Slices oder Umsetzung eines klar abgegrenzten Work-Packages.

Wenn sich Auftrag, Rollenlogik oder Projektphase grundlegend ändern, ist ein neuer Chat häufig sauberer.

Der Fehler wäre nur, den neuen Chat ohne geregelte Übergabe zu starten.

Neuer Chat heißt nicht Neustart des Projekts

Ein frischer Chat hat einen großen Vorteil: Er entfernt lokalen Ballast.

Aber er darf nicht gleichzeitig Projektamnesie erzeugen.

Das Ziel lautet daher:

frischer Arbeitskontext + stabiler Projektzustand.

Dafür wird nicht der komplette alte Chat blind kopiert. Stattdessen erhält der neue Arbeitsraum ein kompaktes, explizites Startpaket: Auftrag des neuen Chats, aktueller Projektstand, verbindliche Entscheidungen, relevante Quellen und Artefakte, offene Risiken, bekannte Gegenargumente, Nicht-Ziele und klar definierte nächste Schritte.

Damit entsteht Kontinuität ohne historische Überladung.

Ein Handoff ist serialisierter Projektzustand

Eine Übergabe ist mehr als eine Zusammenfassung.

Eine Zusammenfassung erzählt, was passiert ist.

Ein Handoff muss ermöglichen, korrekt weiterzuarbeiten.

Dafür braucht er mindestens folgende Felder:

Ein solcher Handoff ist ein Zustandscontainer.

Er reduziert die Wahrscheinlichkeit, dass eine neue Session alte Entscheidungen erfindet, abgeschlossene Arbeit wiederholt oder ein Projekt aus einem veralteten Zwischenstand fortführt.

Gute Handoffs übertragen nicht alles

Die Versuchung ist groß, eine Übergabe maximal vollständig zu machen. Doch Vollständigkeit ist nicht identisch mit Nützlichkeit.

Ein Handoff, der 80 Seiten Chatprotokoll enthält, verschiebt das Problem nur. Die neue Session muss wieder herausfinden, was davon aktuell, wichtig oder verbindlich ist.

Ein guter Handoff folgt deshalb drei Regeln.

1. Zustand vor Chronologie

Nicht „zuerst geschah A, dann B, dann C“, sondern: „Der aktuelle Stand ist X; X entstand aus den Entscheidungen A und C; B wurde verworfen.“

2. Verbindlichkeit markieren

Ein System muss unterscheiden können zwischen beschlossen, experimentell, verworfen, offen und historisch.

3. Quellen referenzieren statt duplizieren

Große Evidenzpakete werden verlinkt oder benannt. In die Übergabe gehört nur die Information, warum sie relevant sind und welche Aussage sie tragen.

Der kanonische Zustand verhindert Ghost Decisions

In langen KI-Projekten entsteht ein gefährliches Phänomen: Entscheidungen existieren nur noch in einzelnen Chats.

Eine Session hat beschlossen, API A nicht zu verwenden. Eine andere Session weiß davon nichts. Ein dritter Agent findet API A erneut attraktiv und integriert sie. Wochen später ist unklar, warum die Entscheidung ursprünglich getroffen wurde.

Das sind Ghost Decisions: projektwirksame Entscheidungen ohne stabilen, auffindbaren Zustand.

Dagegen hilft ein kanonisches Current-State-Dokument.

Es sollte nicht jede Diskussion enthalten. Es hält nur den derzeit gültigen Zustand fest: aktueller Scope, aktuelle Architektur, aktuelle Versionen, aktive Constraints, offene Risiken, letzte wesentliche Entscheidungen und nächste freigegebene Arbeit.

Chats dürfen explorativ sein.

Der kanonische Zustand darf es nicht.

Kanonisch heißt nicht unveränderlich

Ein kanonischer Zustand ist kein Dogma.

Er ist die aktuell gültige Baseline.

Wenn neue Evidenz eine Entscheidung verändert, wird die Baseline aktualisiert. Entscheidend ist, dass der Wechsel sichtbar geschieht.

Eine einfache Zustandslogik kann genügen:

PROPOSED – vorgeschlagen, noch nicht gültig.

ACTIVE – aktuell verbindlich.

SUPERSEDED – durch neuere Entscheidung ersetzt.

REJECTED – bewusst verworfen.

ARCHIVED – historisch erhalten, operativ nicht mehr aktiv.

So können Agenten neue Ideen entwickeln, ohne dass jede Idee sofort den Projektzustand überschreibt.

Kontext hat Freshness

Nicht jede Information altert gleich schnell.

Ein Unternehmensziel kann monatelang stabil bleiben. Eine API-Spezifikation kann sich in Tagen ändern. Ein Budgetstatus kann nach wenigen Stunden veraltet sein. Ein Forschungsergebnis kann langfristig gültig sein, aber durch neue Daten relativiert werden.

Deshalb braucht Kontext ein Freshness-Modell.

Für wichtige Kontextobjekte sollte sichtbar sein, wann sie zuletzt geprüft wurden, wodurch sie gültig sind, wann eine erneute Prüfung nötig wird und welche Folgeobjekte von ihnen abhängen.

Ohne Freshness entstehen stale truths: Aussagen, die früher richtig waren und deshalb weiterhin wie aktuelle Wahrheiten behandelt werden.

Kontextselektion ist wichtiger als maximale Kontextmenge

Große Context Windows verführen dazu, alles einzuspeisen.

Das klingt logisch: Wenn das Modell mehr sehen kann, sollte es besser entscheiden können.

Doch Kontext besitzt Opportunitätskosten. Irrelevante oder widersprüchliche Informationen konkurrieren mit den Informationen, die für die aktuelle Entscheidung wirklich wichtig sind.

Die professionelle Frage lautet daher nicht:

Wie viel Kontext kann das Modell aufnehmen?

Sondern:

Welche kleinste Kontextmenge ermöglicht für diese Aufgabe eine korrekte Entscheidung?

Das ist Context Engineering.

Ein Context Packet pro Work-Package

Für abgegrenzte Arbeitspakete ist ein kleines Context Packet oft wirkungsvoller als ein kompletter Projektordner im Prompt.

Ein Context Packet kann enthalten: Ziel des Work-Packages, Definition of Done, relevante Entscheidungen, notwendige Inputs, betroffene Dateien, gültige Constraints, bekannte Risiken, erwartetes Outputformat und Handoff-Ziel.

Damit erhält ein Agent genau die Informationen, die er braucht, ohne implizit zum Interpreter des gesamten Projekts zu werden.

Das knüpft direkt an kontrollierte Work-Packages an, geht aber eine Ebene weiter: Arbeitspakete brauchen nicht nur Scope, sondern auch einen definierten Kontextumfang.

Shared Knowledge Space ist nicht Shared Context Window

Ein gemeinsamer Wissensraum – etwa eine strukturierte Wissensdatenbank, ein Vault, ein Dokumentenbestand oder ein Projekt-Repository – ist wertvoll, weil mehrere Chats und Agenten auf dieselbe Wissensbasis zugreifen können.

Aber „gemeinsames Wissen“ bedeutet nicht, dass alle Akteure zu jedem Zeitpunkt dasselbe vollständige Kontextfenster benötigen.

Das Gegenteil ist oft besser.

Der Wissensraum ist breit und dauerhaft.

Der Arbeitskontext ist schmal und situativ.

Eine gute Architektur trennt daher:

Knowledge Pool: gesamtes relevantes Wissen.

Canonical State: aktuell verbindliche Projektsicht.

Retrieval Layer: Auswahl der für die Aufgabe relevanten Informationen.

Working Context: tatsächlich an den Agenten übergebener Ausschnitt.

So wird Wissen nicht mit Kontext verwechselt.

Research Pool und Projektwissen sind verschiedene Dinge

Gerade bei umfangreichen Recherchen entsteht schnell ein großer Pool aus Reports, Studien, Interviews und Analysen.

Dieser Pool ist wertvoll, aber noch kein Projektzustand.

Er enthält möglicherweise widersprüchliche Quellen, unterschiedliche Zeitstände, nicht verifizierte Hypothesen, konkurrierende Methoden und Informationen, die nur für andere Nischen relevant sind.

Der Übergang von Research zu Projektwissen benötigt daher Verdichtung:

Quelle → Befund → Einordnung → Entscheidung → kanonischer Zustand.

Wenn dieser Übergang fehlt, wird der Projektordner zu einer Bibliothek ohne Bibliothekar.

Parallele Chats brauchen getrennte Arbeitsräume und gemeinsame Integrationspunkte

Mehrere parallele Sessions sind mächtig. Eine Session kann recherchieren, eine andere implementieren, eine dritte reviewen.

Das funktioniert aber nur, wenn Parallelität nicht mit gemeinsamem Bewusstsein verwechselt wird.

Zwei Chats kennen nicht automatisch dieselben lokalen Zwischenschritte. Zwei Coding-Worktrees können auf demselben Repository basieren und dennoch unterschiedliche Branch-Zustände besitzen. Zwei Agenten können denselben Auftrag unterschiedlich interpretieren.

Deshalb braucht parallele Arbeit getrennte lokale Arbeitsräume, klar definierte Inputs, explizite Outputartefakte, Integrationspunkte, Konfliktregeln und eine gemeinsame Baseline.

Das Muster ist in Softwareentwicklung vertraut: Mehrere Worktrees erlauben parallele Arbeit an unterschiedlichen Branches desselben Repositories. Der gemeinsame Repository-Ursprung ersetzt aber nicht Merge-Disziplin.

Für KI-Arbeit gilt dasselbe.

Gemeinsamer Ursprung ist noch kein gemeinsamer Zustand.

Handoff vor Merge

Bevor ein paralleler Arbeitsstrang integriert wird, sollte er nicht nur ein Ergebnis liefern, sondern einen kurzen Handoff: Was wurde verändert? Welche Annahmen wurden verwendet? Welche Dateien oder Zustände sind betroffen? Was wurde getestet? Welche Unsicherheiten bleiben? Welche Konflikte mit der Baseline sind möglich? Was muss der Integrator entscheiden?

Damit wird aus „hier ist mein Output“ ein integrierbares Arbeitsergebnis.

Context Drift: Wenn Sessions langsam verschiedene Projekte bauen

Context Drift entsteht nicht zwingend durch einen offensichtlichen Fehler.

Er kann schleichend entstehen: Ein Chat verwendet eine ältere Version des Scopes, ein Agent kennt eine neue Restriktion nicht, ein Reviewer prüft gegen andere Erfolgskriterien als der Implementierer, ein Handoff lässt eine verworfene Annahme stehen, oder eine Wissensdatenbank enthält mehrere widersprüchliche Versionen ohne Statusmarkierung.

Nach einigen Zyklen arbeiten alle scheinbar am selben Projekt – tatsächlich aber an leicht unterschiedlichen mentalen Modellen.

Das ist besonders gefährlich, weil lokale Outputs jeweils plausibel aussehen können.

Vier Signale für Context Drift

1. Wiedereröffnung abgeschlossener Entscheidungen

Die KI diskutiert regelmäßig Themen, die bereits entschieden wurden.

2. Widersprüchliche Statusbehauptungen

Ein Chat bezeichnet Version 3 als aktuell, ein anderer Version 4.

3. Unterschiedliche Definition of Done

Agenten liefern formal fertige Arbeit, die aus Projektsicht unvollständig ist.

4. Überraschende Wiederholungen

Arbeit wird erneut ausgeführt, weil Ergebnisse aus einer anderen Session nicht übernommen wurden.