Ab etwa 100.000 Tokens Kontext zeigte Gemini 2.5 Pro in Agentenläufen ein Verhalten, das in Googles Marketing wahrscheinlich nicht vorkam: Das Modell wiederholte frühere Aktionen aus seiner eigenen Geschichte, statt neue Pläne zu entwickeln. Die Beobachtung steht im Anhang des technischen Berichts, dort, wo die Einschränkungen stehen und nicht die Versprechen. Drew Breunig, Entwickler und Autor, hat daraus einen Vortrag gemacht.
Auf der AGNTCon sprach er über „Context Fails & Fixes“. Der Untertitel seiner Folien klingt wie eine Stellenbeschreibung: Man muss wissen, wann man deterministisch arbeiten muss und wann probabilistisch. Wer Agenten baut oder längere Chats führt, erkennt einiges wieder. Breunig schreibt auf dbreunig.com über Technologie, Daten und KI, hat Cmpnd mitgegründet und arbeitet an „The Context Engineering Handbook“.
Von RAG zum Millionen-Token-Fenster
Ende 2024 war die Stimmung kurzzeitig sehr optimistisch. Der Sprung von rund 128.000 auf eine Million Tokens Kontext, zuerst bei Gemini 1.5, wirkte wie die Lösung eines Problems, an dem bis dahin alle gebaut hatten. Breunig beschreibt diese Phase als den Moment, in dem „RAG ist tot“ zum geflügelten Wort wurde: Wenn alles in den Kontext passt, braucht man keine ausgefeilte Suche, keine selektive Auswahl, keine mehrstufige Agentenarchitektur.
Die Marketingmaterialien verstärkten das. Googles Grafik zu Gemini 1.5 Pro rechnete eine Million Tokens in eine Stunde Video, elf Stunden Audio, über 30.000 Zeilen Code und mehr als 700.000 Wörter um. Im Labor, hieß es damals, stehe schon ein Modell mit zehn Millionen Tokens bereit. Llama 4 Scout brachte diese Zahl auf den Markt, ein Erfolg wurde daraus nicht: Die Inferenz war zu aufwendig, das Modell setzte sich nicht durch.
Die Kurzfassung dieser Zeit: alles in den Kontext legen, das Modell sortiert es schon. Breunig hält das für einen Denkfehler. Ein Kontextfenster ist keine Ablage, sondern eine Arbeitsfläche. Wer den ganzen Aktenschrank auf den Schreibtisch kippt, hat nicht mehr Überblick, sondern weniger Platz zum Arbeiten.
Vier Fehlermodi des großen Kontexts
Mit dem größeren Fenster kamen die Probleme. Breunig sortiert sie in vier Muster. Kontextvergiftung entsteht, wenn ein Fehler oder eine Halluzination in den Kontext gerät und danach immer wieder als Bezugspunkt dient; das Modell kommt nicht mehr davon los. Kontextablenkung setzt ein, wenn der Verlauf so lang wird, dass das Modell stärker auf den Kontext als auf sein trainiertes Wissen schaut. In beiden Fällen ist die Ursache dieselbe: Der Schreibtisch ist so voll, dass die eigene Erfahrung nicht mehr zum Zug kommt.
Kontextverwirrung meint, dass nebensächliche Informationen die Antwort unvorhersehbar beeinflussen. Das Modell leitet Annahmen über den Nutzer ab, die es nie bestätigt bekommen hat, und diese Annahmen fließen still in jede Antwort ein. Kontextkonflikt tritt auf, wenn sich Werkzeuge, Fähigkeiten und Anweisungen innerhalb eines Systems widersprechen. Breunig nennt ein alltägliches Beispiel: Er hat die Memory-Funktion in ChatGPT und Claude abgeschaltet, weil berufliche Gespräche und ein Projekt mit seinem Sohn in denselben Notizen landen und sich gegenseitig verunreinigen.
Pokémon, Tee und Gegenbeispiele
Für Kontextvergiftung nennt Breunig ein konkretes Beispiel. In der ursprünglichen Pokémon Rot von 1996 muss der Spieler einem durstigen Wächter eine Limonade geben, um passieren zu dürfen. In der Neuauflage FireRed von 2004 wurde daraus ohne erklärten Grund Eistee. Als Forscher Gemini 2.5 Pro das ältere Spiel spielen ließen, wurde das Modell mehrfach überzeugt, es müsse Tee besorgen. Der Tee-Auftrag steckte in seinen Gewichten und vergiftete den Kontext. Laut dem technischen Bericht verbrachte das Modell viele Stunden damit, den Tee zu suchen oder ihn dem Wächter zu geben – eine einmal notierte Aufgabe, von der es nicht mehr loskam.
Der zweite Fehlermodus lässt sich ähnlich zeigen. Carolina Camassa und Derek Shiller haben in „Do as I Say, Not as I Do“ ein Modell angewiesen, jede Frage auf Russisch zu beantworten, ihm dann aber zahlreiche Beispiele geliefert, in denen die Antworten auf Französisch kamen. Diese Beispiele waren keine neuen Anweisungen, sondern nur Verlauf. Über 13 Modelle hinweg sank die Rate, mit der die ursprüngliche Anweisung befolgt wurde, mit jedem weiteren Gegenbeispiel. Kleine Modelle wie Gemma 3 12B fielen schon nach wenigen Runden unter fünfzig Prozent, leistungsfähige Modelle hielten länger durch, aber niemand blieb unberührt.
Übertragen auf die eigene Arbeit: Wie viele schlechte Zwischenstände sammeln sich in einer Sitzung, in der du eine Komponente Stück für Stück anpasst? Jede verworfene Variante bleibt im Verlauf stehen und wirkt weiter. Was du für einen sauberen Neuanfang hältst, ist oft nur die nächste Runde auf einem vollgeschriebenen Whiteboard.
Sechs Werkzeuge für präzise Anweisungen
Breunig bleibt nicht bei der Diagnose. Er nennt sechs Taktiken: Context Augmentation, Tool Loadout, Context Quarantine, Context Pruning, Context Summarization und Context Offloading. Context Augmentation heißt, den Kontext gezielt mit dem anzureichern, was für den nächsten Schritt gebraucht wird. Die Idee hinter RAG lebt hier weiter, als eine Methode unter mehreren statt als einzige Antwort. Tool Loadout bedeutet, einem Modell nur die Werkzeuge mitzugeben, die es in dieser Situation braucht.
Context Quarantine lagert einen Teil der Arbeit in einen separaten Lauf aus, damit ein Nebenschauplatz den Hauptverlauf nicht vergiftet. Context Pruning entfernt, was nicht mehr gebraucht wird. Context Summarization verdichtet lange Abschnitte, und Context Offloading schreibt Informationen in eine Datei oder Notiz außerhalb des Fensters. Allen sechs liegt derselbe Gedanke zugrunde: Kontext ist eine Ressource mit laufenden Kosten, kein Speicher, dessen Grenze man möglichst weit ausreizt. Wer nur das füttert, was der nächste Schritt verlangt, bekommt präzisere Antworten als jemand, der möglichst viel hineinschaufelt.
Deterministisch oder probabilistisch
Die These steckt im Untertitel des Vortrags. Ein Teil der Arbeit lässt sich berechnen und sollte berechnet werden: feste Formate, Schemata, klar definierte Abläufe, alles, was bei gleicher Eingabe zuverlässig dasselbe Ergebnis liefern muss. Der andere Teil verlangt Abwägung, Formulierung, Exploration. Dort ist das Modell stark, und dort darf es Wahrscheinlichkeiten produzieren. Context Engineering heißt vor allem, diese Grenze bewusst zu ziehen statt sie dem Zufall zu überlassen.
Breunig argumentiert, dass es hilft zu verstehen, wie Modelle gebaut und trainiert werden. Man darf sie im Gespräch vermenschlichen, solange man daraus keine falschen Schlüsse zieht: Modelle sind keine Menschen, und deshalb haben sie eigene, charakteristische Fehlermodi. Dieselbe Anweisung, die bei einem Kollegen funktioniert, kann im Kontextfenster untergehen, verdrängt oder mit vielen Gegenbeispielen überschrieben werden.
Was bleibt, wenn die Modelle besser werden
Im Juni 2025 fragte das Team von O’Reilly Breunig, woran man erkennt, dass ein Handbuch zu Context Engineering nicht in wenigen Wochen veraltet ist. Seine Antwort: Er wisse es nicht, sei aber optimistisch. Klare Anweisungen zu geben, Widersprüche zu vermeiden und Rauschen herauszuhalten, bleibt schwierig, egal wie gut die Modelle werden. Menschen bestehen den Turing-Test längst, und trotzdem fällt es uns schwer, einander Konzepte präzise zu vermitteln. Dieses Problem verschwindet nicht, es verschiebt sich.
Für die Praxis heißt das: Ein großes Kontextfenster ist kein Qualitätsmerkmal. Beobachte die Länge deiner Verläufe und starte neu, bevor du 200.000 Tokens erreichst. Trenne Projekte in getrennte Sitzungen, schalte Memory dort ab, wo sich Lebensbereiche vermischen würden, und schreibe die wichtige Anweisung an den Anfang statt in die Mitte. Das klingt banal. Es entscheidet aber, ob ein Modell arbeitet oder seit Stunden nach Tee sucht.
Quelle: dbreunig.com
