Die meisten KI-Teams, die die Leistung ihrer Agenten steigern möchten, greifen zu denselben Mitteln: größeren Kontextfenstern, mehr Dokumenten und besseren Prompts. Dieser Artikel erklärt, warum dieser Ansatz grundlegend falsch ist. Es fehlen nicht mehr Informationen. Es fehlt die Steuerung. Eine durchdachte Steuerungsebene unterscheidet einen Agenten, der in einer Demo funktioniert, von einem, der sich im Produktivbetrieb bewährt.
Ein größerer Speicher, mehr Dokumente oder ein längeres Kontextfenster machen einen KI-Agenten nicht intelligenter, sondern nur langsamer und teurer. Die eigentlichen Verbesserungen entstehen, wenn der Agent auswählt, was er wann benötigt, statt alles auf einmal zu verarbeiten.
Zuverlässigkeit entsteht durch die Schleife, nicht durch das Modell. Ob ein Agent nur in einer Demo beeindruckt oder sich auch im Produktivbetrieb bewährt, hängt nicht von der Qualität der KI ab, sondern davon, ob das System seine eigene Arbeit prüft. Agenten, die bei jedem Schritt planen, handeln, beobachten und verifizieren, erkennen eigene Fehler, statt selbstbewusst falsche Ergebnisse zu liefern.
Die meisten KI-Agenten sind heute im Grunde Chatbots mit zusätzlichen Schritten. Ihnen fehlt ein Mechanismus, um zu erkennen, ob sie auf dem richtigen Weg sind, wann sie aufhören oder wann sie einen anderen Ansatz versuchen sollten. Erst eine geeignete Steuerungsebene mit klaren Erfolgskriterien, strukturiertem Zustand und Validierungsprüfungen macht aus einem Gebilde in Agentenform etwas, dem du tatsächlich vertrauen kannst.
Was hast du gestern zu Mittag gegessen?
Wahrscheinlich hast du nicht jede Erinnerung deines Lebens durchlaufen, bis du bei „gestern + Mittagessen“ angekommen bist. Du bist direkt zu dem Teil deiner Erfahrung gesprungen, in dem diese Konzepte liegen. Das ist ein hilfreiches Denkmodell für die Entwicklung von Agenten:
Ein riesiges Kontextfenster ist kein Speicher.
Eine Ansammlung abgerufener Dokumente ist kein Verständnis.
Eine lange Gedankenkette ist keine Zuverlässigkeit.
Das sind nur Bestandteile. Was einen Agenten tatsächlich wie einen Agenten wirken lässt, sorgt auch dafür, dass dein Gehirn nicht dein gesamtes Leben mit roher Rechenleistung durchsucht: Steuerung.
Die kürzlich veröffentlichte Übersicht Agentic Reasoning for Large Language Models fasst den Wandel treffend zusammen und gibt ihm einen Namen, den viele von uns bei der Entwicklung bereits wahrgenommen haben: vom Reasoning innerhalb des Modells zum Reasoning durch Interaktion. Dieser Beitrag ist keine Zusammenfassung des Papers. Er überträgt diesen Wandel auf die praktische Systementwicklung:
Wenn du Agenten wie Chatbots mit Tools entwickelst, erhältst du weiterhin typische Chatbot-Fehler, nur mit teureren Folgen.
Lange bestand unser Standardrezept für „das Modell intelligenter machen“ im Wesentlichen aus besseren Prompts, Gedankenkette, Selbstkonsistenz oder stichprobenbasierten Verbesserungen und vielleicht etwas Suche.
ReAct war ein Wendepunkt, weil es „Gedanke → Aktion → Beobachtung“ selbstverständlich erscheinen ließ. Beachte jedoch die implizite Einschränkung: Vieles davon läuft weiterhin auf „One-Shot-Inferenz, aber mit mehr Tokens“ hinaus. Die Übersicht formuliert es präziser: Agentenbasiertes Reasoning betont die Skalierung der Interaktion zur Testzeit. Inferenz wird zu einem iterativen Prozess, in dessen Schleife Modell, Speicher und Umgebung durchgehend eingebunden bleiben.
Wenn du Agenten entwickelt oder verwendet hast, die in Demos beeindrucken, aber in echten Workflows unzuverlässig sind, richtet sich dieser Beitrag an dich.
Ich möchte ein Muster beschreiben, das mir häufig begegnet ist und von dem ich selbst einige Varianten entwickelt habe:
Ein gutes Chat-Modell auswählen
Einige Tools ergänzen (Suche, Datenbankabfragen, eventuell Codeausführung)
RAG ergänzen
Einen System-Prompt mit „Du bist ein autonomer Agent“ ergänzen
Alles in eine While-Schleife verpacken, bis der Vorgang endet oder das Zeitlimit erreicht ist
Glückwunsch, du hast ein Gebilde in Agentenform. Es scheitert jedoch meist auf vorhersehbare Weise:
Aufgeblähter Kontext: Jede Beobachtung wird angehängt, sodass Prompts zu archäologischen Schichten anwachsen.
Planloser Tool-Einsatz: „selbstbewusst das falsche Tool verwenden“ wird zum üblichen Fehlermuster.
Keine Abbruchbedingungen: Der Agent macht weiter, weil er kann, nicht weil er sollte.
Keine konsequente Verankerung: Der Agent bemerkt Fehler nur, wenn du ihn zur Prüfung zwingst.
Speicher = Chatverlauf: Im Grunde werden Protokolle geschrieben und als Lernen bezeichnet.
Deshalb wirken „Agenten“ in Demos oft wie Magie und im Produktivbetrieb chaotisch. Unsere Erfahrung mit agentenbasierten Systemen im Produktivbetrieb bestätigt das: Sobald du nicht mehr ein Modell, sondern ein System bewertest, umfassen die Fehlermuster auch Navigation, sorgfältigen Tool-Einsatz, Kontextbereinigung und Evaluationsdesign. Es geht nicht mehr nur darum, ob das Modell richtig geantwortet hat.
Damit stellt sich die Frage: Wie sieht ein gezielt entwickelter Agent aus?
Um das anschaulicher zu machen, folgt ein einfacher Workflow, den sich die meisten gut vorstellen können: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Eine typische Implementierung, die wie ein Agent wirken soll, sieht so aus:
Sie ruft sofort zahlreiche Dokumente zu Fluggesellschaften und Reiserichtlinien ab, auch wenn noch keines davon benötigt wird.
Sie ruft ein Such-Tool auf, fügt eine lange Ergebnisliste in den Prompt ein und „wählt eines aus“.
Sie bucht voreilig, ohne die Vorgaben zu prüfen (Ankunftszeit, Gepäck, Sitzplatz und Richtlinien).
Wenn sie scheitert, versucht sie es etwas anders erneut, allerdings ohne klar zu erfassen, was sich geändert oder was sie gelernt hat.
Das Problem besteht nicht darin, dass das Modell kein Reasoning beherrscht, sondern dass das System den Workflow nicht steuert.
Eine stärker agentenbasierte Version behandelt die Aufgabe als interaktiven Prozess mit explizitem Zustand und klaren Prüfungen:
PLANEN: Vorgaben wiederholen und fehlende Informationen aufführen, etwa „Welcher Flughafen wird bevorzugt?“ oder „Ist ein Zwischenstopp in Ordnung?“
HANDELN: die Flugsuche mit einer strukturierten Abfrage aufrufen (Datumsfenster, späteste Ankunft und Budget).
BEOBACHTEN: Ergebnisse in einem kompakten Zustandsobjekt speichern (die fünf besten Optionen mit Preis, Ankunftszeit und Zwischenstopps), statt einen riesigen Textblock einzufügen.
AKTUALISIEREN: die Abfrage verfeinern, wenn Vorgaben nicht erfüllt sind, etwa: „Eine Ankunft vor 18 Uhr ist zu restriktiv. Soll das Zeitfenster erweitert oder das Budget erhöht werden?“
VERIFIZIEREN: Validatoren ausführen („Ankunft < 18:00 Uhr“, „Preis ≤ 900 GBP“, „richtlinienkonform“, „Sitzplatzauswahl verfügbar“).
BEENDEN: erst, wenn die Buchungs-API eine Bestätigung zurückgibt und alle Validatorprüfungen bestanden sind.
Die Änderung ist subtil, aber entscheidend. Der Abruf erfolgt bedarfsgerecht statt reflexartig, der Kontext wird verwaltet statt angehäuft und der Zustand ist strukturiert. Außerdem ist die Verifizierung Teil der Schleife und wird nicht den Nutzenden überlassen. Ersetze „einen Flug buchen“ durch „eine Bestellung erstellen“, „eine Erstattung veranlassen“, „eine Produktivkonfiguration ändern“ oder „einen PR ausliefern“. Das Prinzip bleibt gleich: Sobald der Agent handeln kann, ist die Schleife wichtiger als der Prompt.
Die oben erwähnte Übersicht gliedert agentenbasiertes Reasoning in drei Ebenen: grundlegend (Planung, Tool-Nutzung und Suche), selbstlernend (Feedback und Speicher) sowie kollektiv (Koordination mehrerer Agenten).
Der tiefer liegende Gedanke lautet jedoch: Reasoning wird zum Organisationsprinzip für Planung, Entscheidungsfindung und Verifizierung, statt nur eine plausible Gedankenkette zu erzeugen. Das klingt abstrakt, bis du es auf die Änderungen an deiner Architektur überträgst. Drei Kernpunkte solltest du beachten:
Ein guter Agent sollte den Abruf nicht als etwas behandeln, das immer erfolgen muss. Er ist eine Entscheidung, kein Reflex.
Eine praktische Faustregel lautet:
Wenn dein System bei jedem Schritt Inhalte abruft, hast du keinen gezielten Abruf entwickelt, sondern eine Kontextsteuer eingeführt.
Das zeigt sich in der Praxis ständig. Beim Debuggen eines Vorfalls im Produktivbetrieb lädst du nicht sämtliche Protokolle in den Kontext. Du entscheidest anhand deiner aktuellen Hypothese, welche Metriken oder Protokolle als Nächstes abgerufen werden. Das ist „agentenbasierter Abruf“. Ein konkreteres Muster sieht so aus:
Entscheiden, ob ein Abruf erforderlich ist
Falls ja: Abfrage formulieren, Inhalte abrufen, überfliegen und Relevantes extrahieren
Bei widersprüchlichen Belegen: weitere Inhalte abrufen
Erst dann zusammenführen
Hier beginnt sich auch „agentenbasiertes RAG“ von herkömmlichem RAG zu unterscheiden: Der Abruf wird zu einem bewussten Reasoning-Schritt und ist nicht länger eine standardmäßige Pipeline-Phase.
Sobald du nicht mehr „ein Modell“, sondern „ein System“ bewertest, werden Zustandsverfolgung und Tracing wichtig.
Bei der Beobachtbarkeit von Agent-Workflows ist die Branche inzwischen deutlich konkreter geworden. Das Agents SDK von OpenAI enthält beispielsweise integriertes Tracing und ein Traces-Dashboard. Es zeichnet Agent-Durchläufe auf (Generierungen, Tool-Aufrufe, Übergaben, Schutzmechanismen und benutzerdefinierte Ereignisse), damit du Schritt für Schritt untersuchen und prüfen kannst, was passiert ist.
Das ist kein optionales Extra. Es entscheidet darüber, ob du ein System debuggen oder nur nach Gefühl beurteilen kannst.
Am praktischsten ist an der Übersicht meiner Meinung nach, wie klar sie das Thema Feedback behandelt. Sie unterscheidet drei Arten: reflektierendes Feedback (generieren → prüfen → überarbeiten), parametrische Anpassung (durch Feinabstimmung/RL lernen) und validatorgestütztes Feedback (wiederholen, bis ein Validator die Prüfung besteht).
Die meisten Teams sollten mit validatorgestütztem Feedback beginnen, weil es unspektakulär und wirksam ist. Wenn du irgendeinen Validator schreiben kannst, der Unit-Tests ausführt, das Schema prüft, Geschäftsregeln oder Einschränkungen festlegt („keine Erstattung über X ohne Eskalation“) oder die Faktentreue sicherstellt („Quellenangaben erforderlich“), kannst du nicht deterministische Modellergebnisse in etwas verwandeln, dem du tatsächlich vertrauen kannst.
Eine der zuvor nicht absehbaren Veränderungen ist einfach: Bei Agenten entsteht Zuverlässigkeit oft eher durch die Schleife als durch das Modell.
Dies ist die einfachste Schleifendisziplin, die meiner Erfahrung nach das Verhalten ohne Training zuverlässig verbessert:
Arbeite schrittweise: Planen → Handeln → Beobachten → Aktualisieren,
fasse nach jeder Aktion die Beobachtung in ein bis drei Stichpunkten zusammen,
beende den Vorgang, sobald die Erfolgskriterien erfüllt oder das Budget ausgeschöpft ist, und gib das beste bisher bekannte Ergebnis sowie verbleibende Unsicherheiten zurück.
Es geht nicht darum, das Modell zu ausführlichen Antworten zu bringen. Es geht darum, das System nachvollziehbar zu machen und bei jedem Schritt den Abgleich mit der Realität zu erzwingen. Ein für Entwicklungsteams sehr anschauliches Beispiel ist die Verankerung in einem geschlossenen Regelkreis nach CI-Vorbild:
Planen: Änderungsliste vorschlagen
Handeln: Tests/Linting ausführen
Beobachten: Fehler auswerten
Aktualisieren: Korrektur anwenden und erneut versuchen
Einige Fragen decken unbeabsichtigt entstandene Agent-Designs zuverlässig auf:
„Entscheidet mein Agent, was abgerufen wird, oder rufe ich immer Inhalte ab?“
Wenn Inhalte bedingungslos abgerufen werden, bezahlst du dafür mit höherer Latenz und höheren Kosten, verwässertem Kontext sowie einem größeren Risiko für schlechte Ergebnisse durch schlechte Eingaben.
„Kann mein Agent erkennen, dass er falschliegt?“
Wenn das einzige Feedbacksignal für deinen Agenten darin besteht, dass Nutzende verärgert sind, betreibst du RL auf Kosten von Menschen. Eine validatorgestützte Wiederholungsschleife ist die sauberste Möglichkeit für einen Abgleich mit der Realität.
„Kann der Speicher beschrieben werden, und wird er mit der Zeit besser?“
Wenn dein „Speicher“ lediglich den Chatverlauf ergänzt, schreibst du im Grunde nur Protokolle. Die Einordnung des Speichers in der Übersicht ist wichtig: Der Speicher wird zu einem dynamisch wachsenden Kontext, den Agenten mit der Zeit verfeinern, statt nur zu einem Gesprächsprotokoll.
Protokolle zeigen dir, was passiert ist. Der Speicher zeigt dir, was du beim nächsten Mal tun solltest. Der Chatverlauf ist ein Gesprächsprotokoll. Der Speicher ist eine sich weiterentwickelnde Richtlinie dazu, was für die Zukunft bewahrt werden sollte.
Ein praktischer Einstieg ist eine kleine Tabelle mit Erkenntnissen. Als Schlüssel dienen Aufgabentyp, Tool und Fehlerart, als Wert wird erfasst, was funktioniert hat und was vermieden werden sollte. Es geht nicht darum, einen perfekten Wissensgraphen zu entwickeln. Es geht um eine kumulative Verbesserung: Speicher und Feedback machen aus „zustandslosen Helfern“ Agent-Systeme, die mit der Zeit besser werden.
Es ist verlockend, mehr Agenten auf das Problem anzusetzen, doch dadurch steigt der Koordinationsaufwand oft überproportional. Ein gutes Muster für ein kleinstmögliches funktionsfähiges Team:
Koordination: zerlegt Aufgaben und weist sie zu
Ausführung: nimmt Tool-Aufrufe oder Änderungen vor
Prüfung/Bewertung: kontrolliert Korrektheit und Risiken
Speicherverwaltung: dokumentiert und pflegt Erkenntnisse
Wenn du nicht erklären kannst, wofür jeder Agent zuständig ist, brauchst du wahrscheinlich noch nicht mehrere Agenten.
Wenn wir diesen Paradigmenwechsel ernst nehmen, hören wir wahrscheinlich auf, alles in Prompts zu packen, Fehler als endgültige Ergebnisse zu behandeln und Agenten wie Chatbots zu bewerten. Stattdessen behandeln wir Agenten als das, was sie sind: Softwaresysteme, in denen Sprache die Steuerungsebene bildet und Zuverlässigkeit aus der Schleife entsteht.
Bevor du ein weiteres Modell hinzufügst, ergänze eine weitere Evaluationsschleife. Bevor du alles abrufst, knüpfe den Abruf an Bedingungen. Liefere zunächst einen Validator aus, nicht gleich zehn. Behandle den Speicher wie eine Sammlung von Richtlinienentscheidungen, nicht wie eine Datenbank. Und wenn du auf ein Multi-Agent-System umstellst, beginne mit zwei Agenten statt mit zwanzig. Das sind keine Regeln, sondern Muster, die sich im Produktivbetrieb bewährt haben.