Warum KI-Agenten einen zweiten Kopf brauchen

KI-Agenten scheitern bei langen Aufgaben erstaunlich oft nicht an einer schweren Einzelfrage. Sie verlieren unterwegs den Faden: eine schon erkannte Vorgabe, einen fehlgeschlagenen Befehl, eine offene Teilaufgabe. Ein aktuelles Forschungspapier schlägt deshalb vor, dem ausführenden Agenten einen zweiten, still mitlaufenden Gedächtnis-Agenten zur Seite zu stellen. Der soll nicht dauernd klüger reden, sondern nur dann erinnern, wenn eine frühere Erkenntnis die nächste Entscheidung wirklich verändern müsste.

Das klingt zunächst nach einer kleinen Architekturidee. Für den praktischen Einsatz von Agenten in Entwicklung, Recherche oder Kundenprozessen ist es aber ein wichtiger Perspektivwechsel: Nicht die Länge des Kontextfensters allein entscheidet über Zuverlässigkeit, sondern ob relevantes Wissen im passenden Moment wieder handlungswirksam wird.

Das Wichtigste in Kürze

• Das Papier beschreibt bei langen Agentenläufen einen Zustand, in dem frühere Erkenntnisse zwar noch gespeichert sein können, aber spätere Entscheidungen nicht mehr prägen.
• Ein separater Memory-Agent führt eine strukturierte Liste aus Anforderungen, Beobachtungen, Fehlschlägen und offenen Teilzielen.
• Er darf auch bewusst schweigen. Genau diese selektive Erinnerung schnitt in den Tests besser ab als ein ständig eingeblendeter kompletter Speicher.
• Mit Claude Sonnet 4.5 stieg die Erfolgsquote auf Terminal-Bench 2.0 im Versuch von 37,6 auf 45,9 Prozent. Das sind 8,3 Prozentpunkte, kein Beweis für allgemeine Produktreife.
• Für Teams folgt daraus vor allem eine nüchterne Aufgabe: Agenten brauchen überprüfbare Zustände, Abbruchregeln und Tests, nicht bloß mehr Tokenbudget.

Der Fehler ist nicht immer Vergessen

Wer einen Chatbot benutzt, kennt die einfache Variante: Eine Information fällt aus dem Gesprächskontext. Bei einem Agenten, der über viele Schritte Dateien prüft, Programme ausführt und Ergebnisse kontrolliert, ist das Problem subtiler. Das Papier nennt es „behavioral state decay“: Anforderungen, frühere Diagnosen oder bereits gescheiterte Versuche liegen noch irgendwo im Verlauf, beeinflussen die nächste Aktion aber nicht mehr zuverlässig.

Ein Coding-Agent kann etwa zuerst feststellen, dass eine Bibliothek in einer bestimmten Version fehlt. Später repariert er einen anderen Fehler und versucht denselben Installationsweg noch einmal. Oder er hat eine Sicherheitsvorgabe gelesen, optimiert danach lokal eine Funktion und verletzt die Vorgabe unbemerkt. Das ist keine klassische Wissenslücke. Es ist ein Steuerungsproblem: Welcher Teil der bisherigen Arbeit muss jetzt noch gelten?

Genau dort liegt die Grenze eines großen Kontextfensters. Viel Text verfügbar zu halten, macht den relevanten Satz nicht automatisch wichtig. Microsoft beschreibt ein ähnliches Muster für parallele Büroaufgaben: Mit steigender Zahl gleichzeitig laufender Aufgaben sinkt die Erfolgsquote von Agenten deutlich. In solchen Situationen stören sich Informationen auch gegenseitig. Wie bei KI-Agenten für Forschungssoftware verschiebt sich die schwierige Arbeit damit vom bloßen Erzeugen eines Ergebnisses zur Prüfung, ob die Zwischenschritte weiterhin stimmen.

Ein Gedächtnis, das sich nicht aufdrängt

Der vorgeschlagene Aufbau trennt Ausführung und Erinnerung. Der Aktions-Agent arbeitet weiter mit seinen Werkzeugen. Daneben beobachtet ein zweiter Agent in festen Abständen den jüngsten Verlauf und eine strukturierte Memory Bank. Darin stehen nicht einfach Gesprächszusammenfassungen, sondern zum Beispiel harte Aufgabenanforderungen, stabile Umgebungsfakten, fehlgeschlagene Ansätze, Diagnosen und offene Teilziele.

Danach fällt der Memory-Agent eine zweite Entscheidung: Gibt es gerade einen kurzen Hinweis, der die kommende Aktion verändern sollte? Falls ja, wird er als Kontext für den nächsten Schritt eingeblendet. Falls nein, bleibt der Kanal leer. Diese Leerstelle ist kein Detail. Ein ständig eingespeister Speicher kostet Rechenzeit und Token, kann vom lokalen Problem ablenken und erzeugt im schlimmsten Fall eine zweite Quelle für falsche Sicherheit.

Die Forschenden vergleichen diesen Mechanismus ausdrücklich mit anderen Varianten. Ein vollständiger Speicher bei jedem Schritt und ein „immer erinnern“-Modus waren in ihren Ablationen nicht die stärkste Kombination. Die bessere Idee ist also nicht: Der Agent braucht ein Tagebuch, das er permanent laut vorliest. Eher braucht er eine sachliche Projektassistenz, die kurz vor einem bekannten Fehler an die richtige Notiz erinnert.

8,3 Punkte sind ein Signal, kein Freifahrtschein

Getestet wurde die Architektur auf Terminal-Bench 2.0 und auf τ²-Bench. Terminal-Bench stellt Agenten realistische Aufgaben in einer Terminal-Umgebung: Dateien untersuchen, Code ändern, Fehler suchen und am Ende versteckte Tests bestehen. τ²-Bench prüft mehrstufige Werkzeug-Nutzung in den Bereichen Airline, Handel und Telekommunikation. Damit decken die Tests zwei wichtige, aber begrenzte Welten ab: technische Ausführung und regelgebundene Dialoge.

Im Terminal-Test stieg die Passquote von Claude Sonnet 4.5 laut Papier von 37,6 auf 45,9 Prozent. Beim gewichteten Mittel der drei τ²-Bench-Domänen ging sie von 55,0 auf 61,8 Prozent. Auch ein stärkerer Aktions-Agent gewann noch hinzu, allerdings geringer. Das spricht dafür, dass die Architektur nicht nur einen schwächeren Agenten kaschiert.

Die Zahlen verdienen dennoch Vorsicht. Es handelt sich um eine Forschungsarbeit mit klar abgegrenzter Testumgebung, nicht um eine unabhängige Feldstudie in einem Unternehmen. Die Memory-Komponente selbst lief im Hauptversuch mit einem leistungsfähigen Modell und wird bei jedem Schritt aufgerufen. Wer daraus sofort eine günstige Standardzutat für jeden Support-Bot ableitet, unterschlägt Kosten, Latenz und die Frage, ob die Erinnerung überhaupt korrekt ist.

Interessant ist ein weiterer Befund: Ein auf Qwen3.5-27B trainierter Memory-Agent verbesserte in einem gehaltenen Terminal-Test die Erfolgsquote eines eingefrorenen Aktions-Agenten von 37,6 auf 41,1 Prozent. Das ist deutlich kleiner als die Variante mit dem Frontier-Modell, zeigt aber eine mögliche Richtung. Das Gedächtnis muss nicht dauerhaft das teuerste Modell im System sein, wenn die Auswahl der richtigen Erinnerung lernbar wird.

Was Teams daraus für echte Agenten ableiten sollten

Für Produktteams ist die Forschung weniger eine Kaufempfehlung als eine Designregel. Zuerst sollte sichtbar sein, welche Fakten einen Agenten über viele Schritte binden: Nutzerfreigaben, Sicherheitsgrenzen, fehlgeschlagene Versuche, Änderungen an Daten und noch offene Prüfungen. Diese Informationen gehören in eine überprüfbare Zustandsverwaltung, nicht nur in eine immer länger werdende Unterhaltung.

Danach braucht es eine Politik für Eingriffe. Ein guter Memory-Mechanismus muss nicht nur relevante Dinge finden, sondern auch unnötige Hinweise unterlassen. Praktisch heißt das: Erinnerungen an konkrete Ereignisse koppeln, ihre Herkunft speichern und nach jedem Eingriff messen, ob der Agent dadurch eine bessere oder schlechtere Entscheidung getroffen hat. Eine fehlerhafte Notiz, die wiederholt eingespeist wird, kann einen Lauf genauso zuverlässig auf Abwege bringen wie eine vergessene.

Der Ausblick ist deshalb weniger spektakulär als viele Agenten-Demos, aber wichtiger. Leistungsfähige Modelle werden lange Arbeitsketten nicht allein dadurch meistern, dass ihre Fenster noch größer werden. Sie brauchen eine Art Arbeitsgedächtnis mit Buchführung: Was wissen wir? Was wurde versucht? Was darf jetzt nicht mehr passieren? Erst wenn solche Antworten geprüft und bei Bedarf zurückgenommen werden können, wird aus einem eloquenten Werkzeugnutzer ein verlässlicher digitaler Kollege.