Warum gute KI-Agenten nichts mit guten Demos zu tun haben

Die Demo dauerte etwa neunzig Sekunden. Ich sah zu, wie ein KI-Agent einen Termin buchte, die Follow-up-Mail entwarf und das CRM aktualisierte, während das Vertriebsteam, für das er gebaut worden war, danebenstand – und am Ende war jeder im Raum überzeugt. Sechs Wochen später buchte derselbe Agent stillschweigend Termine in die falsche Zeitzone und zitierte einen Rabatt, den es längst nicht mehr gab. Am Modell hatte sich nichts geändert. Geändert hatte sich der Kontext, in dem es arbeitete.

Das klingt nach einer Geschichte über ein unzuverlässiges Modell. Ist es nicht. Es ist eine Geschichte über Engineering: das unglamouröse Handwerk, das darüber entscheidet, ob ein Agent auch in Woche sechs noch funktioniert.

Die meisten Agenten bleiben auf Demo-Niveau stehen, weil die Demo der einfache Fall ist. Die Teams, die darüber hinauskommen, benutzen kein geheimes Modell. Sie sind diszipliniert in drei Dingen: was der Agent sieht (Kontext-Engineering), was er sich merkt (Gedächtnis) und wie seine Fähigkeiten zusammengesetzt sind (Skills).

Dieser Beitrag geht alle drei auf der Flughöhe durch, die Sie als Entscheider tatsächlich brauchen, und endet mit den Fragen, mit denen Sie Meisterschaft von Theater unterscheiden. Wer zuerst die Teileliste sehen will – woraus ein Agenten-Harness eigentlich besteht –, findet dazu einen eigenen Beitrag in diesem Journal; hier geht es darum, diese Teile gut zu betreiben. Eines setzt der Text voraus: dass ein Mensch in der Verifikationsschleife bleibt. Kontext, Gedächtnis und Skills sind das, was diese Schleife lohnend macht.

Warum die Demo lügt

Eine Demo lebt in einer kurzen, sauberen, einmaligen Konversation. Ein produktiver Agent akkumuliert Verlauf, Werkzeuge und abgerufene Dokumente, bis sein Arbeitskontext lang und unordentlich ist. Die naheliegende Lösung wäre ein größeres Kontextfenster. Der kontraintuitive, gut belegte Befund: Ein größeres Fenster erzeugt keinen besseren Agenten – oft sogar einen schlechteren.

Anthropics Engineering-Team beschreibt den Grund als „Aufmerksamkeitsbudget“. Ein Modell hat eine endliche Kapazität, seine Aufmerksamkeit über die gegebenen Tokens zu verteilen, und jedes zusätzliche Token verbraucht etwas von diesem Budget. Kontext ist ein Budget, kein Eimer. Man gewinnt nicht, indem man ihn füllt.

Der Beleg für diese Sicht ist nicht das Wort eines Anbieters. Chroma hat 18 Modelle getestet (darunter GPT-4.1, Claude 4 und Gemini 2.5) und gezeigt, dass die Leistung mit wachsendem Input abnimmt, selbst bei einfachen Aufgaben: ein empirisches Ergebnis über eine Bandbreite von Modellen, keine Marketingaussage. Längerer Kontext öffnet zudem spezifische, benannte Fehlermodi, die eine kurze Demo nie auslöst:

• Vergiftung. Eine Halluzination rutscht in den Kontext und wird dann wieder und wieder zitiert, bis sich ein falscher Fakt zur Prämisse verhärtet.
• Ablenkung. Angesammelter Verlauf zieht das Modell dahin, vergangene Aktionen zu wiederholen, statt einen neuen Plan zu bilden.
• Zu viele Werkzeuge verstopfen die Entscheidung. Im GeoEngine-Benchmark scheiterte ein quantisiertes (komprimiertes) Llama 3.1 8B an einer Anfrage mit allen 46 geladenen Tools und bestand sie, als das Set auf 19 gekürzt wurde – alles bequem innerhalb des Kontextfensters. Gleiches Modell, gleiches Fenster, weniger Auswahl.
• Widerspruch. Teile eines langen Kontexts geraten in Konflikt. LLMs Get Lost in Multi-Turn Conversation von Microsoft und Salesforce verteilte einzelne Prompts über mehrere Gesprächszüge und maß im Schnitt 39 % Einbruch über sechs Generierungsaufgaben; OpenAIs o3 fiel von 98,1 auf 64,1 (lesen Sie das als kontrollierten Test einer Fehlerform, nicht als universelle Zahl).

Nichts davon ist exotisch. Eine Databricks-Studie verortete den Beginn des Verfalls bei rund 32.000 Tokens für Llama 3.1 405B, weit unterhalb des beworbenen Fensters: ein Benchmark an einem Modell, aber eine nützliche Größenordnung. Die Lücke zwischen Demo und Produktion ist keine Frage der Modellwahl. Sie entsteht, weil niemand den Kontext engineert hat – und der Kontext ist der Ort, an dem Agenten tatsächlich scheitern.

Was Sie dem Modell vorlegen – und was Sie draußen halten

Kontext-Engineering ist die Technik mit der größten Hebelwirkung, weil sie diejenige ist, die Sie am direktesten kontrollieren. Das Ziel ist die kleinste Menge signalstarker Tokens, die das gewünschte Verhalten noch vollständig beschreibt. Minimal heißt nicht kurz: Es heißt, dass nichts im Fenster totes Gewicht ist.

Ein gut engineerter Kontext: wenig signalstarkes Material im Fenster – und Zeiger auf alles andere außerhalb, geholt, wenn die Aufgabe es verlangt.

Drei Dinge gehören hinein. Ein System-Prompt auf der richtigen Flughöhe, zwischen brüchigen, hartkodierten Regeln (zu fragil) und vagem Ungefähren (zu lose). Ein Werkzeug-Set, das klein und überschneidungsfrei ist – denn der häufigste Produktionsfehler, den Anthropic berichtet, ist ein aufgeblähtes Tool-Set mit mehrdeutigen Entscheidungspunkten: Wenn ein menschlicher Engineer nicht sagen kann, welches Werkzeug zu benutzen ist, kann es der Agent auch nicht. Und eine Handvoll kanonischer Beispiele statt einer langen Liste von Sonderfällen.

Die härtere Disziplin ist, was Sie draußen halten. Das Feld bewegt sich weg vom Vorab-Hineinstopfen und hin zu „Just-in-time“-Abruf: Der Agent hält leichte Zeiger (einen Dateipfad, eine gespeicherte Abfrage, einen Link) und zieht den vollen Inhalt erst, wenn er ihn braucht – so, wie Sie aus einem Posteingang heraus arbeiten, statt jede E-Mail auswendig zu lernen. Der Zeiger selbst trägt Signal. Eine Datei unter tests/test_utils.py sagt dem Agenten etwas anderes als eine unter src/core_logic, noch bevor eine einzige Zeile gelesen ist.

Kontext im Griff – eine kurze Checkliste.

• Hinein: ein System-Prompt auf der richtigen Flughöhe, wenige überschneidungsfreie Tools, eine Handvoll kanonischer Beispiele.
• Hinaus: alles andere – als Zeiger gehalten und nur geholt, wenn die Aufgabe es verlangt.
• Der Test für alles, bei dem Sie unsicher sind: Benennen Sie die Entscheidung, bei der dieses Token dem Agenten hilft. Wenn Sie keine benennen können, verbraucht es Aufmerksamkeitsbudget, das Sie später zurückhaben wollen.

Kuratieren bringt mehr als Tokens. Es bringt Zuverlässigkeit. In Making Failure Safe, erschienen im Juni 2026, ersetzte ein Team einen offenen KI-Web-Scraper durch typisierte, verifizierbare Konfigurationsdateien; auf den 80 der 138 Benchmark-Aufgaben, deren Quellen unabhängig verifiziert waren, lief das System mit null Modell-Tokens in der Ausführungsphase. Lesen Sie das als einen sauberen Datenpunkt, nicht als Gesetz: Ein enger, prüfbarer Vertrag schlägt freie Generierung.

Zuverlässigkeit kommt aus dem Gerüst um das Modell herum, nicht aus einem größeren Modell. Das Erste, was nach dem Kontext ein Gerüst braucht, ist das Gedächtnis.

Was der Agent sich merkt – und wann Erinnern schadet

Beim Gedächtnis übernehmen sich Teams am häufigsten, denn „er soll sich alles merken“ klingt nach Fortschritt. Gedächtnis ist gestuft, und die nützliche Frage ist enger als „kann er sich erinnern“: Was soll bestehen bleiben – und wann soll es zurückkommen?

Drei Gedächtnisstufen. Das meiste, was ein Agent braucht, sollte als Zeiger auf die Grundwahrheit in der dauerhaften Stufe liegen – und nur die relevante Scheibe ins Arbeitsfenster geholt werden.

Das Arbeitsgedächtnis ist das aktuelle Kontextfenster: flüchtig, und beim Zurücksetzen der Sitzung verschwunden. Das Sitzungsgedächtnis ist ein Notizzettel, den der Agent innerhalb einer Aufgabe führt – etwa eine laufende To-do-Liste, die er immer wieder neu schreibt, damit das Ziel über einen langen Auftrag hinweg im Blick bleibt. Das dauerhafte Gedächtnis überdauert Sitzungen, und es nimmt meist eine von zwei Formen an.

In der ersten schreibt der Agent Notizen in eine Datei, die er später wieder lesen kann. Anthropics eigener Kontext-Engineering-Beitrag verweist auf Claude Plays Pokémon, einen Agenten, der über Tausende Spielschritte präzise Zählungen führt und Karten der erkundeten Regionen zeichnet – ganz ohne Anweisungen, wie er sein Gedächtnis strukturieren soll (ein Anbieter, der sein eigenes System illustriert, aber eine anschauliche Illustration). In der zweiten lagert das System Informationen auf Abruf ins Fenster ein und wieder aus, so wie ein Betriebssystem Daten zwischen Arbeitsspeicher und Festplatte bewegt. Läuft das Fenster voll, fasst die Verdichtung es zusammen und beginnt ein frisches Fenster aus der Zusammenfassung.

Die andere Hälfte lassen die Anbieter weg. Erinnern hat einen Preis, und dauerhaftes Gedächtnis importiert jeden Fehlermodus aus dem Abschnitt oben erneut. Ein falscher Fakt, der es ins dauerhafte Gedächtnis schafft, wäscht sich beim nächsten Zurücksetzen nicht aus; er wird wieder abgerufen und wieder zitiert – das Gedächtnis verstärkt den Fehler, statt ihn zu vergessen. Mehr erinnerter Verlauf heißt mehr Sog, das zu wiederholen, was der Agent schon getan hat. Und Verdichtung ist konstruktionsbedingt verlustbehaftet: Aggressives Zusammenfassen kann ein feines Detail fallen lassen, dessen Bedeutung sich erst später zeigt.

Die Regel, die daraus folgt: Machen Sie Gedächtnis zu einem Zeiger auf die Grundwahrheit, nicht zu einer verlustbehafteten Kopie, die leise driftet. Speichern Sie den Link und holen Sie die Seite neu, statt eine veraltete Paraphrase von ihr abzulegen.

Nichts davon braucht schwere Infrastruktur. Paul Iusztins quelloffenes AI Research OS baut dauerhaftes Agenten-Gedächtnis aus drei schlichten Schichten: den rohen Quelldateien, einem index.yaml-Katalog, den der Agent zuerst liest, und einem Wiki, das er mit jeder neuen Frage weiterschreibt. Keine Vektordatenbank, keine Plattform: Dateien und Disziplin – das Register, das ein mittelständisches Team tatsächlich betreiben kann. Bleibt die letzte Technik, die darüber entscheidet, welche Fähigkeiten dieses Gedächtnis überhaupt lesen dürfen.

Ein sauberer Skill schlägt einen riesigen Prompt

Der Instinkt, sobald ein Agent funktioniert, ist, seine Anweisungen immer weiter zu ergänzen, bis der Prompt eine Textwand ist, die jeden Fall abdeckt. Das ist der Mega-Prompt, und er scheitert aus dem Grund, der oben schon begegnet ist: Jede Anweisung und jedes Werkzeug sitzt gleichzeitig im Fenster. Das Budget geht für Overhead drauf. Die Alternative ist, Fähigkeiten als komponierbare Skills mit sauberen Grenzen zu behandeln.

Links das Demo-Muster, das nicht skaliert: ein Prompt, der alles hält. Rechts das Produktionsmuster: ein kleiner Kern, der die richtige Fähigkeit erst lädt, wenn sie gebraucht wird – und Spezialarbeit an einen Sub-Agenten mit eigenem, sauberem Kontext übergibt.

Anthropics Agent Skills sind das Referenzmodell, und der Mechanismus ist dieselbe Disziplin wie beim Kontext-Engineering. Ein Skill ist ein Ordner mit Anweisungen und, optional, ausführbarem Code; Anthropics eigene Metapher dafür ist der Einarbeitungsleitfaden, den man einer neuen Mitarbeiterin schreiben würde. Geladen wird in drei Stufen:

• Beim Start sieht der Agent nur den Namen und die Ein-Zeilen-Beschreibung jedes Skills – billig genug, um Dutzende davon zu halten.
• Wirkt ein Skill relevant, liest er die vollständigen Anweisungen.
• Erst wenn die Arbeit es verlangt, öffnet er die beigelegten Details: die Skripte, die Referenzdateien, die durchgerechneten Beispiele.

Weil fast nichts im Fenster sitzt, bevor es gebraucht wird, kann ein Skill sehr viel Material zu sehr geringen laufenden Kosten tragen.

Zwei Eigenschaften machen daraus mehr als ordentliche Ablage. Ein Skill kann deterministischen Code enthalten, sodass Arbeit, die exakt sein soll (eine Liste sortieren, Felder aus einem Formular ziehen), als Code läuft statt als generierter Text – konsistent und wiederholbar. Und wenn ein Auftrag mehrere Spezialitäten umspannt, kann ein Sub-Agent einen Teil in seinem eigenen sauberen Fenster übernehmen und eine kurze Zusammenfassung zurückgeben, sodass der führende Agent den Überblick behält, statt im Detail zu ertrinken.

Anthropics Multi-Agenten-Recherchesystem berichtet eine Verbesserung von 90,2 % gegenüber einem einzelnen Agenten in der internen Recherche-Evaluation (der Benchmark des Anbieters auf dem System des Anbieters: als Richtung lesen, nicht als Punktzahl) – und beziffert im selben Beitrag die Token-Kosten auf rund das Fünfzehnfache eines Chats. Der Gewinn ist real. Er ist nicht gratis.

Eine Faustregel aus der Praxis leistet hier die meiste Arbeit: Jedes Verhalten, an das Sie einen Agenten mehr als zweimal erinnern müssen, gehört in einen wiederverwendbaren Skill. Das ist der Grenztest. Wenn Ihr Team nicht zeigen kann, wo ein bestimmtes Verhalten lebt, lebt es überall – also im Mega-Prompt. Das können Sie prüfen, ohne eine Zeile Code zu lesen.

Die Fragen, die Sie stellen sollten, bevor Sie der Demo glauben

Sie müssen keinen Code schreiben, um zu beurteilen, ob ein Anbieter oder ein internes Team das hier beherrscht. Fragen Sie nach den drei Techniken und hören Sie auf die Form der Antwort. Gute Antworten beschreiben Entscheidungen, die jemand tatsächlich getroffen hat; Theater beschreibt Ambition.

• Zum Kontext: „Was halten Sie bewusst aus dem Kontext des Modells heraus, und wie entscheiden Sie das?“ Eine Kuratierungsgeschichte ist Meisterschaft. „Wir nutzen ein Fenster mit einer Million Tokens und legen alles hinein“ ist das Gegenteil.
• Zu den Werkzeugen: „Was haben Sie aus dem Tool-Set entfernt, und warum?“ Meisterschaft benennt den Zu-viele-Werkzeuge-Fehler und kann auf etwas zeigen, das entfernt wurde; Theater fügt immer nur hinzu.
• Zum Gedächtnis: „Was behält der Agent über Sitzungen hinweg, wo liegt es, und wie verhindern Sie, dass ein falscher Fakt spätere Läufe vergiftet?“ Meisterschaft beschreibt wiederherstellbares, zeigerbasiertes Gedächtnis und einen Korrekturpfad; Theater sagt „er merkt sich einfach alles“.
• Zum Vergessen: „Wann vergisst der Agent absichtlich?“ Ein Team, das Vergessen nie gestaltet hat, ist den Produktions-Fehlermodi noch nicht begegnet.
• Zur Komposition: „Ist das ein großer Prompt – oder komponierbare Skills mit sauberen Grenzen, und wo läuft deterministische Arbeit als Code?“

Und dann eine übergreifende Frage, die alle anderen übertrumpft: „Zeigen Sie mir, wo es scheitert – und wie es sich erholt.“ Die Erholung ist der Teil, den eine Demo nicht proben kann. Ein Team, das Ihnen nur den Schönwetterpfad zeigen kann, hat eine Demo, kein Produktionssystem. Bitten Sie darum, die Erholung zu sehen, und beobachten Sie, ob eine gestaltete Antwort kommt oder eine Entschuldigung.

Wenn Sie eine einzige Sache aus diesem Text in Ihr nächstes Anbietergespräch mitnehmen, nehmen Sie diese Frage.

Besser noch: Machen Sie den Test an einem Agenten, den Sie schon haben. Nehmen Sie einen, der seit einem Monat im Dienst ist, schauen Sie sich an, was er heute Morgen tatsächlich sieht, und finden Sie die Tokens, die niemand bewusst dorthin gelegt hat. Dann nehmen Sie sie heraus. Dieser Nachmittag lehrt Sie mehr über Kontext, Gedächtnis und Skills als jede Demo – und es ist ungefähr die Arbeit, die ich mit Klienten mache, wenn ein Agent aufhört, sich so zu verhalten wie in Woche eins.