Agentic AI und die Mathematik der Zuverlässigkeit

Agentic AI verspricht autonome Agenten, die komplexe Aufgaben selbstständig in mehreren Schritten lösen. Doch zwei fundamentale Probleme begrenzen diese Vision: das endliche Kontextfenster von LLMs und die mathematische Realität kumulativer Fehlerwahrscheinlichkeiten. Warum 85% Genauigkeit pro Schritt nach zehn Schritten nur noch 20% bedeutet – und was das für den praktischen Einsatz heißt.

Agentic AI ist gerade das ganz große Thema. Die Idee klingt überzeugend: Man gibt einem LLM-basierten Agenten eine komplexe Aufgabe, und er zerlegt sie selbstständig in Teilschritte, führt sie aus, bewertet Zwischenergebnisse und korrigiert sich bei Bedarf. Statt einzelner Prompts entstehen ganze Arbeitsketten – von der Analyse über die Implementierung bis zur Validierung.

In der Praxis habe ich das in den letzten Monaten intensiv erprobt. Und ja: Es funktioniert beeindruckend gut – solange die Aufgabe überschaubar bleibt. Sobald die Kette länger wird, zeigen sich allerdings zwei fundamentale Grenzen, die kein noch so gutes Modell wegoptimieren kann. Die Lösung hierfür wird nicht ausschließlich in besseren Modellen liegen, sondern in der Art und Weise, wie wir mit diesen Modellen zusammenarbeiten.

Das Kontextfenster ist endlich

LLMs arbeiten mit einem Kontextfenster – einer festen Obergrenze an Tokens, die das Modell gleichzeitig „sehen" kann. Bei aktuellen Modellen liegt diese Grenze je nach Anbieter zwischen 128.000 und 1.000.000 Tokens. Das klingt nach viel. In der Praxis ist es das oft nicht.

Ein typischer Agentic-Workflow in einem Softwareprojekt sieht so aus: Der Agent liest Projektdokumentation, analysiert bestehenden Code, erstellt einen Plan, implementiert Änderungen, schreibt Tests, führt sie aus, interpretiert die Ergebnisse und iteriert. Bei jedem dieser Schritte wächst der Kontext: Vorherige Anweisungen, Tool-Aufrufe, deren Ergebnisse, Fehlermeldungen, Korrekturen – alles akkumuliert sich im selben Fenster.

Was passiert, wenn das Fenster voll ist? Das Modell beginnt, ältere Informationen zu verlieren. Nicht schlagartig, sondern graduell. Die Aufmerksamkeit auf frühe Instruktionen nimmt ab. Details aus den ersten Schritten verblassen. Das Ergebnis: Der Agent „vergisst" Teile seiner ursprünglichen Aufgabe. Nicht weil er fehlerhaft wäre, sondern weil die Architektur es so vorsieht.

In der Praxis äußert sich das konkret:

• Architekturentscheidungen vom Anfang eines Workflows werden in späteren Schritten ignoriert
• Naming-Konventionen driften auseinander
• Der Agent wiederholt Fehler, die er bereits korrigiert hatte
• Zusammenhänge zwischen früh definierten Anforderungen und später implementiertem Code gehen verloren

Das ist kein Bug. Es ist eine strukturelle Eigenschaft. Und sie betrifft jeden Agentic-Workflow, der komplex genug ist, um das Kontextfenster substantiell zu füllen.

Die Mathematik der kumulativen Fehlerwahrscheinlichkeit

Das zweite Problem ist subtiler, aber mathematisch unerbittlich. Angenommen, ein LLM-Agent löst jeden einzelnen Teilschritt mit einer Genauigkeit von 85%. Das ist ein realistischer Wert für komplexe Aufgaben – nicht triviale Textgenerierung, sondern echte Entscheidungen: den richtigen API-Endpunkt wählen, eine Datenstruktur korrekt ableiten, einen Edge-Case erkennen.

85% klingt solide. Aber was passiert, wenn der Agent zehn solcher Schritte hintereinander ausführen muss? Die Wahrscheinlichkeit, dass alle Schritte korrekt sind, berechnet sich als:

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

Aus 85% pro Schritt werden nach zehn Schritten knapp 20% Gesamtgenauigkeit.

Das ist keine pessimistische Schätzung. Es ist einfache Wahrscheinlichkeitsrechnung. Und die Kurve fällt steil:

Schritte	Genauigkeit pro Schritt	Gesamtgenauigkeit
1	85%	85,0%
3	85%	61,4%
5	85%	44,4%
7	85%	32,1%
10	85%	19,7%
15	85%	8,7%
20	85%	3,9%

Selbst bei 95% Genauigkeit pro Schritt – einem außergewöhnlich guten Wert – landet man nach 20 Schritten bei 35,8%. Bei 90% sind es nach 10 Schritten nur noch 34,9%.

Meredith Whitaker, Präsidentin von Signal, hat diese Rechnung auf dem 39C3 pointiert zusammengefasst: Selbst bei großzügig angenommenen 95% Genauigkeit pro Schritt ergibt eine 30-Schritt-Aufgabe – etwa eine Reisebuchung mit allen nötigen API-Aufrufen – eine Erfolgswahrscheinlichkeit von gerade einmal 21%. „You cannot build enterprise reliability on a system that fails 96 times out of 100 at their current capabilities." Und das ist keine Theorie: 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.

Das Entscheidende: In einem Agentic-Workflow sind die Schritte nicht unabhängig. Ein Fehler in Schritt 3 beeinflusst die Qualität aller folgenden Schritte. Der Agent baut auf seinem eigenen fehlerhaften Output auf. Das bedeutet, die tatsächliche Degradation ist oft schlechter als die rein multiplikative Berechnung, weil sich Fehler nicht nur addieren, sondern kaskadieren.

Warum das im Enterprise-Kontext besonders relevant ist

In einem privaten Hobbyprojekt ist ein Fehler in Schritt 7 ärgerlich. Man erkennt ihn, korrigiert ihn manuell und macht weiter. In einem Enterprise-Kontext sieht das anders aus:

• Fehler in Sicherheitskonfigurationen können Compliance-Verstöße verursachen
• Falsche API-Integrationen führen zu Dateninkonsistenzen, die erst Wochen später auffallen
• Architekturelle Fehlentscheidungen, die sich durch den gesamten Workflow ziehen, sind teuer zu korrigieren
• Der Agent erzeugt den Anschein von Fortschritt, während die Qualität längst degradiert ist

Das letzte Szenario ist das gefährlichste. Ein Agent, der selbstbewusst Code produziert, Tests schreibt und diese sogar bestehen lässt – der im Detail aber Annahmen trifft, die der ursprünglichen Aufgabe widersprechen – ist schwerer zu kontrollieren als ein Agent, der offensichtlich scheitert.

Die CMU-Forscher haben dafür den Begriff Reasoning Instability geprägt. Ein besonders eindrückliches Beispiel aus dem AgentCompany Benchmark: Ein Agent sollte eine Nachricht an einen Mitarbeiter senden, fand diesen aber nicht in der Datenbank. Statt den Fehler zu melden, versuchte er, einen anderen Mitarbeiter in der Datenbank umzubenennen, damit der Name zur Anfrage passt. Das ist kein Randfall – es ist die logische Konsequenz eines Systems, das probabilistisch auf ein Ziel hinarbeitet, ohne die Tragweite seiner Zwischenschritte einschätzen zu können.

Autonomie ohne Kontrolle ist keine Lösung

Die Zuverlässigkeitsprobleme verschärfen sich, wenn man eine weitere Dimension hinzunimmt: Damit Agenten überhaupt wirksam arbeiten können, brauchen sie Zugang zu möglichst viel Kontext. In der Praxis bedeutet das: E-Mails, Dateien, Kalender, Chatverläufe, Bildschirminhalte – alles, was dem Modell hilft, die Situation zu „verstehen". Weniger Zugang heißt weniger Fähigkeit.

Whitaker und Udbhav Tiwari beschreiben diesen Mechanismus in ihrem 39C3-Talk als Agentic Feedback Loop: Der Agent nimmt wahr (Perception), verarbeitet probabilistisch (Planning) und handelt (Action) – ohne Zustimmung pro Schritt. Denn ein System, das bei jedem Zwischenschritt um Erlaubnis fragt, ist per Definition kein autonomer Agent mehr. Dieses Spannungsfeld zwischen Autonomie und Kontrolle ist architekturbedingt und lässt sich nicht durch bessere Modelle auflösen.

Das betrifft nicht nur Softwareentwicklung. Microsoft Recall, Google Magic Cue und ähnliche Features integrieren Agentic AI direkt ins Betriebssystem – mit kontinuierlicher Bildschirmanalyse, OCR und semantischer Indexierung aller Nutzeraktivitäten. Signal musste als Reaktion darauf einen DRM-Mechanismus zweckentfremden, um zu verhindern, dass verschlüsselte Nachrichten über Betriebssystem-Screenshots abgegriffen werden. Whitaker nennt das treffend „Battlefield Medicine" – ein Pflaster auf eine strukturelle Wunde.

Für den Enterprise-Einsatz von Agentic AI ergibt sich daraus eine unbequeme Frage: Wie viel Kontrolle gibt man einem probabilistischen System, das bei 30 Schritten in 79% der Fälle scheitert, und das gleichzeitig uneingeschränkten Datenzugang braucht, um überhaupt wirksam zu sein?

Strategien, die in der Praxis funktionieren

Nach mehreren Monaten Arbeit mit Agentic AI haben sich für mich einige Muster herauskristallisiert, die die beschriebenen Probleme in den Griff bekommen – zumindest so weit, dass die Technologie produktiv einsetzbar wird.

Kurze Ketten, klare Checkpoints. Statt einen Agenten 20 Schritte autonom arbeiten zu lassen, breche ich Workflows in Blöcke von 3–5 Schritten. Nach jedem Block erfolgt eine menschliche Überprüfung. Das erhöht die Gesamtgenauigkeit massiv: Bei 85% pro Schritt und menschlicher Korrektur nach jeweils 5 Schritten springt die effektive Genauigkeit von 19,7% auf über 80%.

Kontextmanagement als explizite Aufgabe. Ich behandle das Kontextfenster wie eine knappe Ressource. Relevante Architekturentscheidungen werden in separaten Dokumenten festgehalten und bei Bedarf gezielt neu injiziert – statt darauf zu vertrauen, dass der Agent sie aus einer wachsenden Konversation heraus noch priorisiert. Referenzdokumente, Konventionen und Entscheidungsprotokolle werden zu expliziten Artefakten, nicht zu implizitem Gesprächskontext.

Validierung automatisieren. Jeder Agentic-Schritt muss überprüfbar sein – idealerweise automatisch. Tests, Linter, Type-Checker, statische Analysen: All das fängt einen Teil der kumulativen Fehler ab, bevor sie sich in Folgeschritten festsetzen. Der Agent wird dadurch nicht besser – aber seine Fehler werden früher sichtbar.

Aufgaben dekomponieren statt delegieren. Der größte Produktivitätsgewinn entsteht nicht, wenn man einem Agenten eine große Aufgabe gibt und hofft, dass er sie löst. Er entsteht, wenn man die Aufgabe so zerlegt, dass jeder Teilschritt isoliert überprüfbar und korrigierbar ist. Das ist im Grunde nichts anderes als gute Softwarearchitektur – nur eben angewandt auf die Zusammenarbeit mit KI.

Die Parallele zur Softwareentwicklung

Was mich an dieser Beobachtung am meisten fasziniert: Die Strategien, die Agentic AI zuverlässig machen, sind dieselben, die wir seit Jahrzehnten in der Softwareentwicklung kennen.

Kurze Feedback-Loops. Explizite Dokumentation. Automatisierte Tests. Klare Schnittstellen. Saubere Dekomposition. Separation of Concerns.

Wir haben diese Prinzipien nicht erfunden, weil wir es wollten – sondern weil wir mussten. Weil Komplexität in großen Systemen ohne diese Strukturen nicht beherrschbar ist. Und genau das gilt jetzt auch für Agentic AI.

Die Werkzeuge ändern sich. Die Geschwindigkeit ändert sich. Die Grundprinzipien nicht.

Fazit

Agentic AI ist ein mächtiges Werkzeug – aber kein autonomes. Die mathematische Realität kumulativer Fehlerwahrscheinlichkeiten setzt jeder Agentic-Kette eine harte Obergrenze. Und das endliche Kontextfenster sorgt dafür, dass selbst innerhalb dieser Grenze die Qualität bei wachsender Komplexität abnimmt.

Die Lösung ist nicht, auf bessere Modelle zu warten. Die Lösung ist, die Zusammenarbeit mit den heutigen Modellen so zu strukturieren, dass ihre Grenzen nicht zu unseren Fehlern werden.

Kurze Ketten, expliziter Kontext, automatisierte Validierung und menschliche Checkpoints – das klingt nicht nach Revolution. Aber genau darin liegt der Schlüssel. Nicht in der Fähigkeit des Modells, sondern in der Klarheit der Aufgabenstellung und der Disziplin im Prozess.

Wer Agentic AI produktiv einsetzen will, muss zuerst verstehen, wo die Mathematik aufhört mitzuspielen – und genau dort das Menschliche einsetzen, das nach wie vor den Unterschied macht.