Kontextengineering für langlaufende Agenten: Vektordatenbanken, KV-Caches, Claude Code

Es wurde viel über das Konzept des Context Engineering geschrieben. Weit weniger befasst sich mit der Frage, der sich Entwickler in der Praxis gegenübersehen: Wie sollte die Context-Pipeline für einen Agenten gestaltet werden, der 200 Schritte ausführt? Ein Fenster mit einer Million Token klingt großzügig, doch eine Studie von Chroma aus dem Jahr 2025 an 18 führenden Modellen ergab, dass die Qualität bereits abnimmt, wenn das Fenster zu 50 bis 70 Prozent gefüllt ist. Folgend finden Sie einen Leitfaden zur Bewältigung dieses Problems, der sich an Entwickler richtet, die produktionsreife Agenten bereitstellen. Er behandelt, warum lange Kontexte an Qualität verlieren, ein aus der Informatikarchitektur übernommenes Gedächtnismodell, vier Muster zur Verwaltung von Kontexten, die wirtschaftlichen Aspekte des KV-Caches, die Unterschiede zwischen drei bekannten Produkten sowie einen Entscheidungsweg mit entsprechenden Metriken.

Ein Agent ohne Gedächtnisdesign leidet an Amnesie

Stellen Sie sich einen Agenten vor, der die Schritte 1 bis 40 korrekt ausführt. Bei Schritt 41 scheint er das Ziel zu vergessen und beginnt, Entscheidungen zu wiederholen, die er bereits getroffen hat. Das ist selten ein Logikfehler. Es handelt sich dabei um Context Rot – den messbaren Rückgang der Antwortqualität mit zunehmender Eingabellänge. Je mehr Informationen das Modell erhält, desto mehr verliert es effektiv an Leistung.

In einer im Jahr 2026 von Zylos AI veröffentlichten Studie wird dasselbe festgestellt: Eine Verdopplung der Dauer einer Aufgabe soll die Fehlerquote um das Vierfache erhöhen, und die Agenten scheinen nach etwa 35 Minuten Arbeitszeit abzubauen. Das oben erwähnte Chroma-Ergebnis zeigte, dass alle 18 Modelle mit zunehmendem Kontext an Leistung verloren. Der NoLiMa-Benchmark (ICML 2025) zeigte sogar noch schlimmere Ergebnisse: Schon bei 32K Tokens fielen 11 von 13 Modellen unter die Hälfte ihrer Ausgangsleistung, obwohl sie 128K oder mehr versprochen hatten, während GPT-4o von 99,3 % auf 69,7 % abfiel.

Warum die Zerfallsfunktion integriert ist

Die Transformer-Aufmerksamkeit vergleicht jeden Token mit jedem anderen Token. Das Verdoppeln des Textes kostet daher etwa viermal so viele Rechenoperationen, nicht nur doppelt so viele. Bei 200.000 Tokens sind das im Größenbereich von 40 Milliarden Aufmerksamkeitspaaren pro Schicht. Alles im Kontext unterzubringen, funktioniert einfach nicht skalierbar für einen Agenten, der Hunderte von Schritten durchläuft.

Ein weiterer Effekt ist das „Verlorengehen in der Mitte“. Modelle bewältigen den Anfang und das Ende eines langen Kontexts am besten und verlieren in der Mitte an Präzision, sodass wichtige Informationen, die dort versteckt sind, fast unsichtbar werden können. Seltsamerweise schadet text, der kohärent und gut strukturiert ist, aber irrelevant ist, der Genauigkeit mehr als dieselben Sätze, die zufällig neu angeordnet werden. Semantische Ähnlichkeiten innerhalb des Rauschens erschweren es, das eigentliche Signal zu finden.

Die angegebene Fenstergröße ist ebenfalls irreführend. Ein Modell, das eine Million Token aufnehmen kann, bietet nicht automatisch eine Million Token an nutzbarem Speicherplatz.

Kontextangst

Die Nutzer haben eine weitere Besonderheit festgestellt, die auch von Anthropic anerkannt wurde: Claude Sonnet 4.5 neigte dazu, Aufgaben zu früh abzuschließen, sobald der Kontextlimit näher rückte. Dies wird als Kontextangst bezeichnet. Das Modell verhält sich, als würde ihm der RAM ausgehen, und zieht sich zurück, bevor seine Ressourcen tatsächlich aufgebraucht sind.

Da eine Verschlechterung nicht vermieden werden kann, muss die Architektur des Agenten damit umgehen. Die Systemtechnik bietet dazu eine seit langem bekannte Analogie.

Das Modell ist die CPU, der Kontext ist der RAM, die Vektordatenbank ist der Festplattenspeicher

Mitte 2025 befürwortete Andrej Karpathy den Begriff „Context Engineering“ gegenüber „Prompt Engineering“ und beschrieb ihn als die feine Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen für den nächsten Schritt zu füllen. Er erfand keinen Modetrend, sondern wies auf eine Veränderung der Sichtweise hin: Der LLM ist die CPU, das Kontextfenster die RAM, und der Entwickler, der den Agenten konstruiert, übernimmt die Rolle des Betriebssystems.

Die Analogie lässt sich ganz natürlich in die Praxis übertragen. Die Komprimierung ähnelt der Müllsammlung, die Zustandsinjektion einer Startsequenz, Sub-Agenten der Prozessisolation, und eine Datei wie CLAUDE.md ist die bei der Startzeit geladene Konfiguration. Was sich ändert, ist der Fokus: Weniger Aufwand geht in die Formulierung des Prompts, mehr in das, was in den Speicher geladen wird und wann.

Eine Speicherverwaltungshierarchie für Agenten

Ein Agent verfügt genauso wie ein Computer über eine Hierarchie, wobei jede Ebene Geschwindigkeit gegen Kapazität eintauscht:

• In-Kontext-Arbeitsspeicher. Keine zusätzliche Verzögerung, 200K bis 1M Token. Er entspricht Registern und L1-Cache: am schnellsten, teuersten und am stärksten eingeschränkt.
• KV-Cache. Unter 10 ms. Vergleichbar mit L2- oder L3-Cache, er speichert vorberechnete Aufmerksamkeitsmatrizen für frühere Token und behält sie zwischen Anfragen bei.
• Vektor-Datenbank oder semantische Suche. Etwa 5 bis 50 ms sowie Millionen von Einträgen, das Gegenstück zum RAM. Die angegebenen Werte beinhalten etwa 0,34 ms pro Abfrage für FAISS im lokalen Betrieb sowie 7 ms p99 für Pinecone.
• Dateisystem oder Notizen. Über 100 ms ohne wirklichen Größenlimit, ähnlich wie eine Festplatte.
• Archivspeicherung. Sekunden zum Lesen, vergleichbar mit Netzwerk- oder Backup-Speicher.

Jede Entscheidung darüber, wo eine Information gespeichert wird, bedeutet ein Abwägen zwischen Kosten, Latenz und Kapazität. Wird die falsche Ebene gewählt, führt das entweder zu hohen Kosten oder dazu, dass das System etwas vergisst. Die 2023 veröffentlichte Arbeit von MemGPT, die häufig zitiert wird, formalisierte diese Idee unter dem Begriff „virtuelle Kontextverwaltung“, wobei als Vorbild die Art und Weise herangezogen wurde, wie Betriebssysteme mehrstufige Speicher verwalten. Dies setzt sich heute im Letta-Framework fort.

Falls der Kontext im RAM des Systems liegt – welche Muster werden in einem echten System verwendet, um ihn zu verwalten, und wie passen diese zusammen?

Vier Muster: Schreiben, Auswählen, Komprimieren, Isolieren

Die Kontextverwaltung basiert auf vier grundlegenden Mustern. Es handelt sich dabei nicht um Alternativen, zwischen denen man wählen kann, sondern um ergänzende Komponenten eines zusammenhängenden Designs – jedes produktive System nutzt letztendlich alle vier.

Schreiben: Den Zustand außerhalb des Fensters speichern

Schreiben bedeutet die Externalisierung des Zustands. Der Agent speichert Notizen in einer Datei wie todo.md, NOTES.md oder progress.md und liest sie in späteren Schritten wieder ein. Manus ist für die sogenannte „Todo-Liste-Rezitation“ bekannt: Der Agent schreibt seine Aufgabenliste immer am Ende des Kontexts um, damit die Aufmerksamkeit des Modells auf den Gesamtplan gelenkt wird. Das ist eine bewusste Steuerung der Aufmerksamkeit und bekämpft das Phänomen des Verlorengehens in der Mitte des Prozesses.

Claude Opus 4 in einem Experiment mit Pokémon-Spielen führte Berichten zufolge genaue Notizen über Tausende von Spielzügen – zu Charakterstufen, Karten und Strategien – ohne explizite Anweisungen darüber, wie seine Erinnerung strukturiert werden soll.

Selektiv: Nur zum richtigen Zeitpunkt abrufen

Durch Auswahl wird der Kontext erst dann abgerufen, wenn er benötigt wird, anstatt ihn im Voraus zu laden. CLAUDE.md fungiert als statische Vorausladung, ähnlich wie ein Einarbeitungsdokument, das einem neuen Mitarbeiter am ersten Tag übergeben wird. Danach durchforstet der Agent die Codebasis mit grep und glob und lädt nur das herunter, was der aktuelle Schritt benötigt.

Laut Berichten hat Claude Code Vektordatenbanken ausprobiert und sie wieder verworfen, weil sich der Code aus dem Gleichgewicht bringt und die Berechtigungen kompliziert werden. Cursor ging in die entgegengesetzte Richtung und setzte auf dynamische Entdeckung durch semantische Indexierung. Ein dort durchgeführter A/B-Test zeigte angeblich eine Verringerung der benötigten Tokens um 46,9 %, als der Agent die MCP-Tools nach Bedarf lud.

Komprimieren: das Volumen verringern

Durch Komprimieren wird das Volumen durch Zusammenfassung oder Abschneiden reduziert. Bei der Kompaktkennung wird ein LLM gebeten, das bisherige Gespräch zusammenzufassen, wodurch Platz freigeworden wird, während das Wichtige beibehalten wird.

Laut Angaben warnt Claude Code bei etwa 80 Prozent der Kapazität und komprimiert automatisch bei nahezu 95 Prozent, wobei architektonische Entscheidungen beibehalten werden. Eine zu aggressive Kompression führt zum Verlust subtiler, aber wichtiger Kontexte, wodurch der Agent erneut Gebiete untersucht, die er bereits abgeklärt hat. In der Praxis scheint eine Kompressionsrate von 3 bis 6 Mal der ideale Wert für produktive Anwendungen zu sein. Akademische Vergleiche weisen deutlich höhere Werte auf (LLMLingua nennt 20 Mal Kompression mit nur einem Genauigkeitsverlust von 1,5 Punkten bei GSM8K), doch produktive Anwendungen erfordern eine höhere Genauigkeit.

Isolieren: Trennung durch Unteragenten

Isolieren bedeutet, Kontexte voneinander zu trennen. Ein spezialisierter Kind-Agent arbeitet in seinem eigenen Kontextfenster und übermittelt ein zusammengefasstes Ergebnis an seinen Elternteil. Er kann 10.000 Token oder mehr durchsuchen und lediglich eine Zusammenfassung von 1.000 bis 2.000 Token zurückgeben – weitaus weniger als bei einem gemeinsamen Kontext. Manus wendet ein aus Go übernommenes Prinzip an: Kommuniziere nicht durch gemeinsame Speicherung, sondern speichere gemeinsam durch Kommunikation.

Es geht nicht darum, welches Muster gewählt wird, sondern darum, wie sie kombiniert werden und wann jedes aktiviert werden sollte. Schreiben plus Auswahl ist die erste Verteidigungslinie, während Komprimieren plus Isolieren der Weg ist, auf dem sich ein System skalieren lässt.

Ein Aspekt der Kontextverwaltung hat einen überproportionalen Einfluss auf die Produktionskosten und wird bei der Konzeption oft übersehen.

KV-Cache-Hit-Rate – die entscheidende Zahl

Der KV-Cache speichert die bereits berechneten Aufmerksamkeitsmatrizen für frühere Token, sodass das Modell sie für jedes neue Token nicht erneut berechnen muss. Man kann sich das wie eine Datenbank vorstellen, die für häufige Abfragesuffixe Join-Operationen im Voraus berechnet. In einer Messung von GPT-2 dauerte die Erzeugung von 200 Token mit Cache 11,9 Sekunden und ohne Cache 56,2 Sekunden – das entspricht einer Geschwindigkeitssteigerung von etwa 4,7 Mal.

Warum sich dies auf die Kostenstruktur auswirkt

Ein typischer Produktionsagent weist ein Eingang-zu-Ausgang-Verhältnis von nahezu 100 zu 1 auf, im Vergleich zu etwa 1 zu 1 bei Chatbots. Die Neuberechnung des gesamten Eingangs dominiert dabei jede Anfrage. Prompt-Caching ist ein auf der Provider-Seite implementierter Mechanismus, der berechnete Token für identische Abfragesuffixe zwischen Anfragen speichert und dadurch Lesevorgänge um das Zehnfache günstiger macht. Für Claude Sonnet betragen die angegebenen Preise 0,30 US-Dollar pro Million gespeicherter Token im Vergleich zu 3,00 US-Dollar ohne Caching.

Durch eine Anpassung des Kontextdesigns um den KV-Cache lässt sich eine monatliche API-Rechnung von 8.000 Dollar plausibel von einer von 800 Dollar unterscheiden – was mit Anthropics zehnfachem Caching-Rabatt übereinstimmt. Yichao „Peak“ Ji, Mitbegründer von Manus, sagte, dass für einen in Produktion befindlichen Agenten nichts wichtiger sei als die Häufigkeit, mit der auf den KV-Cache zugegriffen wird.

Drei Regeln, um den Cache aktiv zu halten

• Ein stabiles Präfix. Ein Unterschied von einem Token bedeutet einen Cache-Miss. Ein Fehler, auf den Manus hinweist, ist das Hinzufügen einer Zeitstempelangabe an den Anfang des Systemprompt – dadurch kann das Modell die Uhrzeit angeben und die Trefferquote wird zerstört.
• Nur appendbaren Kontext. Fügen Sie nur Inhalte zum Kontext hinzu, ändern Sie ihn niemals rückwirkend. Die Historie bleibt unveränderlich, da jede Änderung zu einem Cache-Miss führt. Auch die JSON-Serialisierung muss deterministisch sein, da die Reihenfolge der Schlüssel eine Rolle spielt.

Eindeutige Cache-Bruchpunkte. Markieren Sie im Kontext Stellen, die dem Anbieter mitteilen, wo der Präfix gespeichert werden soll.

Es gibt außerdem eine Art „Skalentrugbild“, das manchmal als „MCP-Steuerung“ bezeichnet wird. Angenommen, 10 bis 15 Tools enthalten jeweils 10.000 bis 15.000 Token mit Definitionen. Das bedeutet bereits vor dem Eingeben von Inhalten durch den Benutzer 100.000 bis 225.000 Token an Overhead. Bei 1.000 Entwicklern mit fünf Sitzungen pro Tag liegt eine grobe Schätzung bei fast 1,2 Millionen Dollar jährlich, die allein für Tool-Definitionen ausgegeben werden. Die Lösung ist die schrittweise Offenlegung: Die Tools werden erst zum richtigen Zeitpunkt geladen und nicht auf einmal.

Die Cache-Erfolgsraten sowie die vier Muster sind Theorie. Wie sehen sie in Systemen aus, die das Problem bereits in der Produktion erlebt haben?

Claude Code und zwei weitere Produkte – drei Philosophien

Claude Code, Cursor und Manus liefern drei kohärente und unterschiedliche Lösungen für dasselbe Problem. Jede Lösung ergibt sich aus ihrem eigenen Kontext, nicht aus Unwissenheit über Alternativen.

Claude Code: statische Vorausladeung plus just-in-time-Lesungen

Claude Code von Anthropic lädt bei Start der Sitzung CLAUDE.md als Einführungsdokument herunter und navigiert anschließend mit glob und grep durch die Codebasis, ohne Vektordatenbank. Es komprimiert automatisch zu fast 95 % und bewahrt die architektonischen Entscheidungen bei. Die Kombination eines Speicherwerkzeugs mit Kontextbearbeitung soll eine Verbesserung um 39 % gegenüber dem Ausgangswert gebracht haben.

Bei Sonnet 4.5 führte Kontextangst dazu, dass das Modell externe Kontext-Neustellungen benötigte. Laut Anthropic wurde dieses Problem in späteren Modellversionen ohne Änderung der Architektur des Werkzeugs behoben.

Cursor: zwei Ebenen und dynamische Entdeckung

Cursor (von Anysphere entwickelt) trennt den „Intent-Context“, also das, was der Benutzer anfragt, vom „State-Context“, also dem aktuellen Zustand der Dateien, Änderungen und Fehler. Standardmäßig werden nur die ersten 250 Zeilen jeder Datei gelesen – eine bewusste Entscheidung, um Tokens und Kosten zu sparen.

Im Januar 2026 kam es zu einer bedeutenden Änderung. Cursor gab an, dass da die Modelle als Agenten verbessert wurden, es besser funktioniere, zunächst weniger Details bereitzustellen und den Agenten die Möglichkeit zu geben, selbst den relevanten Kontext abzurufen. Der zuvor erwähnte A/B-Test zeigte eine 46,9-prozentige Reduzierung der benötigten Tokens im Vergleich zum Aufladen nach Bedarf.

Manus: Gradientenabstieg durch Versuch und Irrtum

Manus bezeichnet seinen Ansatz als „stochastischen Gradientenabstieg“, wobei das Dateisystem als ultimativer Kontext dient. Berichten zufolge wurde sein Framework seit März 2025 bereits fünfmal umgebaut. Ji fasst es wie folgt zusammen: Der Kontextaufbau erwies sich als alles andere als einfach und gehört zu den experimentellen Wissenschaften.

Dem Team werden sechs Prinzipien zugeschrieben:

• Setzen Sie den KV-Cache an erste Stelle.
• Verwenden Sie Maskierungstools anstelle deren Entfernung, um den Cache zu bewahren.
• Betrachten Sie das Dateisystem als unbegrenzten externen Speicher.
• Aufzählen Sie die To-Do-Liste, um die Aufmerksamkeit auf den Gesamtplan zu lenken.
• Behalten Sie Fehler im Kontext, da das Löschen eines Fehlers Beweise beseitigt.
• Variieren Sie die Serialisierungsvorlagen, um der Few-Shot-Falle zu entgehen.

Was die Vergleichsstudie lehrt

Es gibt keine einzige richtige Philosophie. Claude Code ist auf lange Programmier Sessions ausgelegt, die Stabilität erfordern. Cursor richtet sich an kurze, unterstützte Sessions, die dynamisch auf den Editorkontext reagieren. Manus wurde für vollständig autonome Web-Agenten entwickelt, die pro Aufgabe 50 oder mehr Toolaufrufe tätigen. Fünf Neubauten bei Manus zeigen etwas Grundlegendes: Der Kontextaufbau ist eine empirische Disziplin, kein einmal erstelltes und dann bereitgestelltes Konzept. Jedes Produktionsystem durchläuft seine eigenen Iterationen.

Es ist verlockend anzunehmen, dass größere Speicherkapazitäten das Problem lösen werden, da eine Million Tokens ausreichen sollten. Die Daten von NoLiMa und Chroma widerlegen diese Annahme schnell. Claude 4 Sonnet weist eine deutlich bessere Widerstandsfähigkeit gegen Kontextverluste auf als ältere Modelle – doch das ist eine Ausnahme, die die Regel bestätigt, kein Beweis dafür, dass das Problem beseitigt ist.

Diese Systeme und Muster umfassen das, was funktioniert. Was übrig bleibt, ist, sie in konkrete Gestaltungsentscheidungen für einen bestimmten Agenten umzuwandeln und herauszufinden, ob die Kontextgestaltung ihre Aufgabe erfüllt.

Ein Leitfaden: Was zu verwenden ist und was gemessen werden muss

Ein Paper von März 2026 über die Unternehmens-Multi-Agent-Architektur (arXiv:2603.09619, über den Übergang von Prompts zur Kontexttechnik) legt fünf Kriterien für die Qualität des Kontexts vor und betrachtet den Kontext als Betriebssystem des Agenten:

• Relevanz. Ist die Information für den aktuellen Entscheidungsschritt relevant? Irrelevanter Kontext führt direkt zu Fehlentscheidungen.
• Genügsamkeit. Hat der Agent alles, was er benötigt, ohne raten zu müssen?
• Isolation. Sind die Kontexte der Agenten ordnungsgemäß getrennt, sodass die Daten von Mieter A niemals in Mieter B gelangen?
• Ökonomie. Bezieht sich der Kontext auf die kleinste mögliche Menge an hochwertigen Signal-Tokens? Jedes überflüssige Token verbraucht Ressourcen der Aufmerksamkeit.
• Ursprung. Können Sie nachvollziehen, woher jeder Teil des Kontextes stammt? Das ist wichtig für das Debuggen.

Entscheidungsweg

Bei einer kurzen Aufgabe, bei etwa 20 Schritten ohne langfristige Abhängigkeiten, reicht ein schräg verlaufendes Fenster aus. Behalten Sie die letzten N Schritte sowie die festgelegten Systemanweisungen bei. Es entstehen keine zusätzlichen Kosten und die Implementierung ist am einfachsten.

Bei einer lang andauernden Aufgabe, bei der eine Entscheidung in Schritt 5 Auswirkungen auf Schritt 50 hat, verwenden Sie eine Komprimierung, die die architektonischen Entscheidungen beibehält. Warnen Sie bei etwa 80 Prozent Kapazität und komprimieren Sie automatisch bei etwa 95 Prozent.

Für unabhängige Unteraufgaben mit mehr als 10 Werkzeugen sollten Sub-Agenten verwendet werden, die Zusammenfassungen von 1.000 bis 2.000 Token liefern, wobei jede in einem eigenen Fenster arbeitet.

Für viele Werkzeuge, aber kurze Sitzungen sollten die Werkzeuge erst zum Zeitpunkt der Nutzung geladen werden, anstatt alles im Voraus zu laden. Die schrittweise Offenlegung reduziert die Belastung durch MCP.

Was zu überwachen ist

Ohne diese Metriken verfügt eine Kontextarchitektur über keine Überwachungsmöglichkeiten:

• Wachstumsrate der Token. Ein stetiges, monotones Wachstum deutet darauf hin, dass es keine Komprimierungsstrategie gibt. Ein zahnförmiges Muster aus Anstieg, Zurücksetzung und erneutem Anstieg zeigt, dass die Komprimierung funktioniert.
• Hit-Rate des KV-Caches. Ein Wert unter 50 % deutet darauf hin, dass sich etwas im Systemprompt-Prefix ständig ändert. Überprüfen Sie zunächst Zeitstempel und andere dynamische Elemente.
• Die 35-Minuten-Heuristik. Es scheint, als würden die Agenten nach etwa 35 Minuten Arbeitszeit an Leistung verlieren, daher sollten Kontrollpunkte unter Berücksichtigung dieser Zeitspanne geplant werden.
• Amnesie nach Kompression. Wenn der Agent Gebiete erneut erkundet, die er bereits abgegrast hat, ist die Kompression vermutlich zu aggressiv.

Für alle, die solche Systeme entwerfen, ist ein Mangel besonders auffällig: Es gibt keine standardisierte Messgröße für die im Zuge der Kompression verloren gegangenen Informationen. Der Fehler zeigt sich erst später, nicht bereits zum Zeitpunkt der Kompression. Die beste Zeit für die Kompression bleibt weiterhin ein offenes Problem – zu früh verschwendet sie Zeit, zu spät führt sie zu Problemen.

SWE-ContextBench (arXiv:2602.08316) bestätigt dies, indem es feststellt, dass unfiltrierte oder schlecht ausgewählte Erfahrungen nur begrenzte oder sogar negative Vorteile bringen. Mehr Kontext ist nicht immer besser, und schlechter Kontext schadet aktiv.

Regeln für den Kontextaufbau bei langlaufenden Agenten

Das Entwerfen eines Kontextpipelines ist eine andere Frage als die nach dem, was Kontextengineering ist, und es ergeben sich daraus einige Schlussfolgerungen.

• Kontextverfall ist eine physikalische Eigenschaft von Transformern. Ein besseres Modell behebt ihn nicht; eine Speicherverwaltungskonstruktion kümmert sich darum.
• Das Modell ist die CPU, der Kontext ist der RAM, und Kontextengineering ist das Betriebssystem des Agenten, wodurch die Diskussion von der Linguistik in die Systemtechnik verschoben wird.
• Schreiben, Selektieren, Komprimieren und Isolieren sind ergänzende Schichten, keine Alternativen, und jeder Produktionsagent verwendet alle vier.
• Die Trefferquote im KV-Cache ist der wichtige Indikator, und ein einziger fehlerhafter Zeitstempel in einem Systemprompt kann monatliche Rechnungen um Zehntausende von Dollar erhöhen.
• Es gibt keine einzige richtige Philosophie, wie Claude Code, Cursor und Manus zeigen.
• Gute Kontextengineering bedeutet die fünf Qualitätskriterien zusammen mit messbaren Metriken – nicht Intuition.

Ein praktischer erster Schritt ist es, dem Kontext in der nächsten Überprüfung der Agentenkonzeption einen zentralen Platz einzuräumen: Wo der Zustand gespeichert wird, wie der KV-Cache gehandhabt wird, welches Kompressionslimit gilt und welche Unteraufgaben an Sub-Agenten verteilt werden. Dies ist keine Leistungsanpassung – es ist die Grundlage für ein funktionierendes System.