Agentic AI und die Mathematik der Zuverlässigkeit

Autonome Agenten sollen komplexe Aufgaben in vielen Schritten selbst lösen. Zwei Dinge stehen im Weg: das endliche Kontextfenster und die Wahrscheinlichkeitsrechnung. Warum aus 85 % Genauigkeit pro Schritt nach zehn Schritten nur noch 20 % werden, und was das für den Einsatz bedeutet.

Man gibt einem LLM-Agenten eine Aufgabe, und er zerlegt sie selbst: Teilschritte planen, ausführen, Zwischenergebnisse prüfen, nachbessern. Aus einzelnen Prompts werden ganze Arbeitsketten, die analysieren, Code schreiben und am Ende testen. So weit die Idee, und sie klingt überzeugend.

Ich habe das in den letzten Monaten quer durch echte Projekte ausprobiert. Solange die Aufgabe klein bleibt, funktioniert es erstaunlich gut. Wird die Kette länger, stoßen die Agenten an zwei Grenzen, die auch ein besseres Modell nicht wegräumt. Der Ausweg liegt deshalb nicht allein in stärkeren Modellen, sondern darin, wie wir mit ihnen arbeiten.

Das Kontextfenster ist endlich

Ein LLM sieht immer nur einen begrenzten Ausschnitt: das Kontextfenster, eine feste Obergrenze an Tokens. Je nach Anbieter liegt sie heute zwischen 128.000 und einer Million Tokens. Klingt üppig. Im Alltag ist es das oft nicht.

Ein typischer Agentic-Workflow im Softwareprojekt läuft etwa so: Der Agent liest die Doku, sieht sich den bestehenden Code an, macht einen Plan, ändert etwas, schreibt Tests, führt sie aus, deutet die Ergebnisse und dreht die nächste Runde. Mit jedem Schritt wächst der Kontext. Frühere Anweisungen, Tool-Aufrufe und ihre Ergebnisse, Fehlermeldungen, Korrekturen: alles sammelt sich im selben Fenster.

Und wenn das Fenster voll ist? Dann fängt das Modell an, Älteres zu verlieren. Nicht auf einen Schlag, sondern nach und nach. Die Aufmerksamkeit auf die ersten Instruktionen sinkt, Details vom Anfang verblassen. Der Agent "vergisst" also Teile seiner ursprünglichen Aufgabe. Nicht weil er kaputt wäre, sondern weil die Architektur genau das vorsieht.

Konkret sieht das so aus:

• Architekturentscheidungen vom Anfang werden später ignoriert.
• Naming-Konventionen driften auseinander.
• Der Agent wiederholt Fehler, die er schon korrigiert hatte.
• Der Zusammenhang zwischen früh definierten Anforderungen und später geschriebenem Code geht verloren.

Das lässt sich nicht abstellen. Es ist eine strukturelle Eigenschaft und betrifft jeden Workflow, der komplex genug ist, um das Fenster wirklich zu füllen.

Die Mathematik der kumulativen Fehler

Das zweite Problem ist unauffälliger, aber rechnerisch hart. Nehmen wir an, ein Agent löst jeden einzelnen Teilschritt mit 85 % Genauigkeit. Für komplexe Aufgaben ist das realistisch, also keine triviale Textgenerierung, sondern echte Entscheidungen: den richtigen API-Endpunkt wählen, eine Datenstruktur korrekt ableiten, einen Edge-Case erkennen.

85 % klingt solide. Nur: Was passiert bei zehn solchen Schritten hintereinander? Die Wahrscheinlichkeit, dass alle zehn stimmen, ist

$P(\text{alles korrekt}) = 0{,}85^{10} \approx 0{,}197$

Aus 85 % pro Schritt werden nach zehn Schritten also knapp 20 % über die ganze Kette. Das ist keine pessimistische Annahme, sondern einfache Wahrscheinlichkeitsrechnung. Und die Kurve fällt steil:

Selbst mit 95 % pro Schritt, einem außergewöhnlich guten Wert, landet man nach 20 Schritten bei 35,8 %. Bei 90 % sind nach zehn Schritten nur noch 34,9 % übrig.

Meredith Whitaker, Präsidentin von Signal, hat das auf dem 39C3 auf den Punkt gebracht: Selbst bei großzügigen 95 % pro Schritt kommt eine Aufgabe mit 30 Schritten, etwa eine Reisebuchung mit allen nötigen API-Aufrufen, auf gerade 21 % Erfolg. "You cannot build enterprise reliability on a system that fails 96 times out of 100 at their current capabilities." Theorie ist das nicht: Forscher der Carnegie Mellon University haben mit dem AgentCompany Benchmark, einem Satz realistischer Unternehmensaufgaben, gezeigt, dass die besten verfügbaren Modelle in 70 % der Fälle scheiterten.

Wichtig ist der zweite Teil. In einem Workflow sind die Schritte nicht unabhängig. Ein Fehler in Schritt 3 verschlechtert alles, was danach kommt, weil der Agent auf seinem eigenen falschen Output weiterbaut. Die tatsächliche Degradation ist deshalb oft schlechter als die reine Multiplikation. Fehler addieren sich nicht nur, sie kaskadieren.

Warum das im Enterprise-Kontext zählt

Im privaten Bastelprojekt ist ein Fehler in Schritt 7 ärgerlich. Man sieht ihn, bessert von Hand nach, macht weiter. Im Unternehmen sieht die Sache anders aus:

• Fehler in Sicherheitskonfigurationen können Compliance-Verstöße auslösen.
• Falsch verdrahtete API-Integrationen erzeugen Dateninkonsistenzen, die erst Wochen später auffallen.
• Architekturfehler, die sich durch den ganzen Workflow ziehen, sind teuer zu reparieren.
• Der Agent erweckt den Eindruck von Fortschritt, während die Qualität längst abgerutscht ist.

Der letzte Punkt ist der gefährlichste. Ein Agent, der selbstbewusst Code produziert, Tests schreibt und diese sogar grün bekommt, im Detail aber Annahmen trifft, die der eigentlichen Aufgabe widersprechen, ist schwerer zu kontrollieren als einer, der sichtbar scheitert.

Die CMU-Leute nennen das Reasoning Instability. Ein Beispiel aus dem Benchmark, das hängen bleibt: Ein Agent sollte einer bestimmten Person eine Nachricht schicken, fand sie aber nicht in der Datenbank. Statt das zu melden, versuchte er, einen anderen Eintrag umzubenennen, damit der Name zur Anfrage passt. Kein Randfall, sondern die logische Folge eines Systems, das probabilistisch auf ein Ziel zusteuert, ohne die Tragweite seiner Zwischenschritte einschätzen zu können.

Autonomie ohne Kontrolle löst nichts

Es kommt eine Dimension dazu. Damit Agenten überhaupt gut arbeiten, brauchen sie möglichst viel Kontext: E-Mails, Dateien, Kalender, Chatverläufe, Bildschirminhalte, alles, was beim "Verstehen" der Lage hilft. Weniger Zugang bedeutet weniger Können.

Whitaker und Udbhav Tiwari beschreiben das im selben 39C3-Talk als Agentic Feedback Loop: wahrnehmen (Perception), probabilistisch verarbeiten (Planning), handeln (Action), und zwar ohne Freigabe pro Schritt. Ein System, das bei jedem Zwischenschritt um Erlaubnis fragt, ist kein autonomer Agent mehr. Dieser Konflikt zwischen Autonomie und Kontrolle steckt in der Architektur und verschwindet nicht durch bessere Modelle.

Das betrifft nicht nur die Softwareentwicklung. Microsoft Recall, Google Magic Cue und ähnliche Features bringen Agentic AI direkt ins Betriebssystem, mit dauerhafter Bildschirmanalyse, OCR und semantischer Indexierung sämtlicher Nutzeraktivität. Signal hat als Reaktion einen DRM-Mechanismus zweckentfremdet, damit verschlüsselte Nachrichten nicht über Betriebssystem-Screenshots abfließen. Whitaker nennt das "Battlefield Medicine", ein Pflaster auf einer strukturellen Wunde.

Für den Enterprise-Einsatz bleibt eine unbequeme Frage: Wie viel Kontrolle gibt man einem probabilistischen System, das bei 30 Schritten in 79 % der Fälle danebenliegt und gleichzeitig möglichst uneingeschränkten Datenzugang verlangt, um überhaupt zu funktionieren?

Was in der Praxis funktioniert

Nach ein paar Monaten mit Agentic AI haben sich bei mir vier Muster herausgeschält, die die genannten Probleme handhabbar machen. Genug jedenfalls, dass die Technik produktiv wird.

Erstens: kurze Ketten, klare Checkpoints. Statt einen Agenten 20 Schritte am Stück laufen zu lassen, schneide ich Workflows in Blöcke von drei bis fünf Schritten. Nach jedem Block schaut ein Mensch drüber. Das hebt die Gesamtgenauigkeit deutlich. Bei 85 % pro Schritt und einer Korrektur nach jeweils fünf Schritten steigt der effektive Wert von 19,7 % auf über 80 %.

Zweitens: Kontext aktiv bewirtschaften. Ich behandle das Fenster als knappe Ressource. Wichtige Architekturentscheidungen halte ich in separaten Dokumenten fest und spiele sie gezielt wieder ein, statt darauf zu hoffen, dass der Agent sie aus einer immer länger werdenden Konversation noch priorisiert. Referenzen, Konventionen und Entscheidungsprotokolle werden zu expliziten Artefakten statt zu implizitem Gesprächskontext.

Drittens: Validierung automatisieren. Jeder Schritt muss überprüfbar sein, am besten maschinell. Tests, Linter, Typprüfung und statische Analyse fangen einen Teil der Fehler ab, bevor sie sich in den Folgeschritten festsetzen. Der Agent wird dadurch nicht besser, aber seine Fehler werden früher sichtbar.

Viertens: Aufgaben zerlegen statt delegieren. Der größte Gewinn entsteht nicht, wenn man einem Agenten eine große Aufgabe hinwirft und hofft. Er entsteht, wenn man die Aufgabe so zerlegt, dass jeder Teilschritt für sich überprüfbar und korrigierbar ist. Das ist im Grunde gute Softwarearchitektur, nur angewandt auf die Zusammenarbeit mit KI.

Die alten Prinzipien greifen wieder

Das eigentlich Auffällige: Was Agentic AI zuverlässig macht, sind dieselben Regeln, die wir in der Softwareentwicklung seit Jahrzehnten kennen. Kurze Feedback-Loops, geschriebene Doku, automatisierte Tests, klare Schnittstellen, saubere Dekomposition, Separation of Concerns.

Wir haben die nicht aus Spaß erfunden, sondern weil große Systeme ohne solche Strukturen nicht beherrschbar sind. Genau das gilt jetzt auch hier. Die Werkzeuge ändern sich, das Tempo ändert sich, die Grundprinzipien nicht.

Fazit

Agentic AI ist ein mächtiges Werkzeug, aber kein autonomes. Die kumulative Fehlerwahrscheinlichkeit setzt jeder Kette eine harte Obergrenze, und das endliche Kontextfenster sorgt dafür, dass die Qualität schon innerhalb dieser Grenze mit wachsender Komplexität nachlässt.

Auf bessere Modelle zu warten hilft nicht. Was hilft, ist die Arbeit mit den heutigen Modellen so aufzubauen, dass ihre Grenzen nicht zu unseren Fehlern werden: kurze Ketten, expliziter Kontext, automatisierte Prüfungen, menschliche Checkpoints. Klingt unspektakulär, ist aber der Hebel. Er liegt nicht im Modell, sondern in einer klaren Aufgabenstellung und etwas Disziplin im Prozess. Wer Agentic AI produktiv nutzen will, muss zuerst wissen, wo die Mathematik nicht mehr mitspielt, und genau dort einen Menschen dazwischenschalten.