71% aller Unternehmen nutzen inzwischen KI-Agenten in irgendeiner Form. Nur 11% haben es bis zur Produktion geschafft. Diese Zahlen stammen aus einer Kore.ai-Befragung von Enterprise-Teams aus Anfang 2026 und decken sich mit dem, was Praktiker in Engineering-Blogs, Reddit-Threads und auf Konferenzen berichten. Die Agenten funktionieren in der Demo. In der Realität brechen sie auf Arten, die schwer zu diagnostizieren, schwer zu reproduzieren und schwer gegenüber Stakeholdern zu erklären sind.
Nach der Analyse dutzender Postmortems und Community-Diskussionen kristallisieren sich drei Problemcluster heraus. Sie sind keine getrennten Baustellen. Sie verstärken sich gegenseitig, und wer nur eines davon löst, kommt nicht weiter.
Zuverlässigkeit unter realer Last ist etwas völlig anderes als im Test
Ein wiederkehrendes Thema in Praktiker-Communities: Agenten performen gut in der Evaluierung, aber degradieren, sobald echte Nutzer, echte Datenvolumen und echte Randfälle ins Spiel kommen. Das hat nichts damit zu tun, dass das Modell “schlecht” ist. Es ist ein spezifisches Muster, bei dem Zuverlässigkeit durch Mechanismen erodiert, die Testumgebungen systematisch herausfiltern.
Die Mathematik der kaskadierenden Fehler
Dynatrace-CTO Bernd Greifeneder hat die Rechnung auf der Perform 2026 vorgemacht: Ein einzelner Agent mit 95% Genauigkeit pro Schritt fällt auf etwa 60% Genauigkeit, wenn man zehn Schritte hintereinander verkettet. Die meisten produktiven Agent-Workflows verketten 5 bis 12 Schritte. In diesem Bereich landen Erfolgsraten zwischen 54% und 77% für einen Agenten, der isoliert getestet einwandfrei funktioniert.
Diese Mathematik ist in Einzelbenchmarks unsichtbar. Man testet jeden Tool-Call. Man testet jeden Reasoning-Schritt. Alles besteht. Aber die Produktion verkettet diese Schritte unter Bedingungen, die ratenlimitierte APIs, variable Netzwerklatenz und Eingabeverteilungen einschließen, die vom Testdatensatz abweichen. Die Fehler potenzieren sich.
Drei Achsen der Zuverlässigkeit
Praktiker berichten über Zuverlässigkeitsprobleme in drei verschiedenen Ausprägungen, die jeweils unterschiedliche Lösungen erfordern:
Tool-Zuverlässigkeit. APIs liefern Fehler, Ratenlimits greifen, Schemas ändern sich upstream. Maxims Produktionsanalyse ergab, dass Tool-Calling in Produktionsumgebungen zwischen 3% und 15% der Zeit fehlschlägt. Die Genauigkeit bei der Tool-Auswahl sinkt deutlich, sobald mehr als sieben Tools zur Verfügung stehen.
Modell-Zuverlässigkeit. Derselbe Prompt erzeugt bei verschiedenen Durchläufen unterschiedliche Tool-Call-Sequenzen. Temperature, Modellversions-Updates und Kontextfenster-Sättigung bringen Variation ein. Ein Praktiker auf r/AI_Agents beschrieb, wie er zwei Wochen einem Bug hinterherjagte, der nur auftrat, wenn das Kontextfenster über 80% Auslastung lag und das Modell Tool-Parameter verschluckte.
Infrastruktur-Zuverlässigkeit. Speicherverwaltung, Zustandspersistenz zwischen Schritten und Aufräumen nach fehlgeschlagenen Runs. Ein häufiges Muster: Ein Agent scheitert bei Schritt sechs, startet bei Schritt eins neu, aber die Seiteneffekte der ersten fünf Schritte (Datenbankschreibvorgänge, API-Aufrufe, gesendete Nachrichten) sind bereits committed. Der Retry erzeugt Duplikate oder Konflikte mit seinem eigenen vorherigen Lauf.
Die Lösung für Tool-Zuverlässigkeit sind Retry-Logik und Circuit Breaker. Die Lösung für Modell-Zuverlässigkeit sind eingeschränkte Ausgaben, bessere Prompts und Validierung auf Schrittebene. Die Lösung für Infrastruktur-Zuverlässigkeit sind idempotente Operationen und transaktionales Zustandsmanagement. Teams, die “Zuverlässigkeit” als ein einziges Problem behandeln, wählen einen Ansatz und wundern sich, warum die anderen beiden Fehlermodi bestehen bleiben.
Halluzinierte Aktionen: Der Agent sagt, er hat etwas getan. Hat er nicht.
Text-Halluzinationen bekommen die meiste Aufmerksamkeit. Ein Agent erfindet eine Tatsache, zitiert eine nicht existierende Quelle oder produziert eine selbstbewusste Antwort, die falsch ist. Das ist gut erforscht, und Guardrail-Frameworks von NVIDIA NeMo bis AWS Automated Reasoning adressieren es direkt.
Halluzinierte Aktionen sind ein anderer, gefährlicherer Fehlermodus. Der Agent generiert eine Antwort, die bestätigt, dass er eine Aufgabe erledigt hat, aber der zugrundeliegende Tool-Call ist entweder leise fehlgeschlagen, wurde nie ausgeführt oder hat die falsche Ressource angesteuert. Die Ausgabe sieht korrekt aus. Die Aktion hat nie stattgefunden.
Wie sich Action-Halluzinationen zeigen
PolyAI, das Voice-Agenten betreibt, die Millionen von Kundenanrufen bearbeiten, hat dieses Muster über ihre Deployments hinweg dokumentiert: Agenten behaupteten, Erstattungen verarbeitet, Kontoeinstellungen aktualisiert oder Anrufe weitergeleitet zu haben, obwohl die entsprechenden API-Calls entweder fehlerhaft waren oder nie stattfanden. Der Agent erzeugte die Bestätigungsnachricht, indem er vorhersagte, wie eine erfolgreiche Antwort aussehen würde, anstatt das Tool-Call-Ergebnis zu prüfen.
Concentrix’ Analyse von 12 agentischen Fehlermustern fand eine verwandte Variante: Phantom-Datenpropagierung. Ein Inventar-Agent halluzinierte eine nicht existierende SKU und reichte sie an Preis-, Lager- und Versandsysteme weiter. Jedes nachgelagerte System behandelte die Daten als legitim, weil sie von einem autorisierten Agenten mit gültigen Credentials kamen. Der Fehler wurde erst entdeckt, als ein Lagermitarbeiter versuchte, ein Produkt zu kommissionieren, das nicht existierte.
Warum Standard-Validierung das verpasst
Output-Validierung prüft, ob der Text des Agenten faktisch fundiert ist. Aktions-Validierung prüft, ob die Tool-Calls des Agenten tatsächlich ausgeführt wurden und die erwarteten Ergebnisse produziert haben. Die meisten Guardrail-Frameworks konzentrieren sich auf Ersteres.
Die Lücke existiert, weil Aktions-Validierung erfordert, die Rückgabewerte von Tool-Calls bei jedem Schritt zu inspizieren, nicht nur die finale Ausgabe. MIT-Forscher adressierten das in ihrem Paper “Spectral Guardrails for Agents in the Wild” vom Februar 2026, das halluzinierte Tool-Calls durch Analyse von Attention-Mustern erkannte (97,7% Recall). Doch das ist ein Forschungsergebnis. In der Praxis brauchen die meisten Teams einfachere Ansätze: explizite Verifikation der Tool-Call-Ergebnisse, Status-Codes, die durch den Kontext des Agenten propagiert werden, und Post-Execution-Assertions, die bestätigen, dass erwartete Zustandsänderungen tatsächlich eingetreten sind.
Die Monitoring-Lücke: Teams beobachten Dashboards, bewerten aber keine Ergebnisse
Das ist das Problem, das die anderen beiden zusammenhält. LangChains State of Agent Engineering-Umfrage unter 1.340 Teams ergab: 89% haben irgendeine Form von Observability für ihre Agenten. Nur 52% führen Evaluierungen durch, die tatsächlich testen, ob die Ausgabe des Agenten korrekt war. Die verbleibenden 37% beobachten ihre Agenten, ohne zu wissen, ob sie erfolgreich sind.
Observability ohne Evaluierung ist nur Logging
Die meisten Teams beginnen mit Traces. Sie instrumentieren ihren Agenten mit LangSmith, Langfuse oder Arize Phoenix und können jeden LLM-Call, jeden Tool-Aufruf, jeden verbrauchten Token sehen. Das ist notwendig, aber nicht ausreichend. Zu wissen, dass der Agent bei Schritt drei eine Datenbankabfrage aufgerufen hat und eine 200-Antwort erhielt, sagt nichts darüber, ob die Abfrage die richtige war.
Die Monitoring-Lücke hat eine spezifische Form: Teams können Fehler diagnostizieren, nachdem Nutzer sie melden, aber können stille Fehler nicht proaktiv erkennen. Wenn ein Agent eine Aktion halluziniert und der Nutzer es nicht sofort bemerkt, taucht es nie im Monitoring auf, weil jeder Trace sauber aussieht. Latenz ist normal. Fehlerraten sind null. Token-Kosten liegen im Budget. Der Agent hat selbstbewusst das Falsche getan, und das Dashboard zeigt grün.
Was produktionsreifes Monitoring wirklich erfordert
Für Unternehmen im DACH-Raum kommt ein weiterer Aspekt hinzu: Die DSGVO und der EU AI Act verlangen Nachvollziehbarkeit von KI-Entscheidungen. Ein Agent, der Aktionen ausführt, ohne dass deren Ergebnisse verifiziert werden, erzeugt ein Compliance-Risiko. Drei Praktiken unterscheiden Teams, die diese Lücke schließen:
Online-Evaluierungen. Einen Teil der produktiven Agent-Ausgaben in Echtzeit durch automatisierte Evaluierungs-Pipelines laufen lassen. Anthropic empfiehlt, mit 20-50 Eval-Fällen zu starten, die aus realen Fehlern abgeleitet wurden. Tools wie Braintrust und LangSmith unterstützen Online-Eval-Pipelines, die Produktions-Traffic bewerten, ohne nutzerseitige Latenz hinzuzufügen.
Ergebnis-Verifikation. Nach jedem Tool-Call, der Zustand verändert (Datenbankschreibvorgang, API-Mutation, gesendete Nachricht), die Änderung unabhängig prüfen. Wurde die Erstattung tatsächlich im Zahlungssystem verbucht? Wurde das Ticket im CRM aktualisiert? Das ist die direkte Gegenmaßnahme gegen halluzinierte Aktionen.
Drift-Erkennung. Agent-Verhalten ändert sich über die Zeit, wenn Modellanbieter Gewichte updaten, Tool-APIs sich weiterentwickeln und Eingabeverteilungen sich verschieben. Datadog LLM Observability und Dynatrace AI Observability bieten beide Drift-Erkennung, die bei Abweichungen von etablierten Baselines alarmiert.
Ohne alle drei hat man Monitoring. Man hat keine Observability. Und man hat definitiv nicht die Feedback-Schleife, die nötig ist, um die Zuverlässigkeit von Agenten über die Zeit zu verbessern.
Ein Triage-Framework für produktive Agent-Probleme
Wenn ein produktiver Agent anfängt zu versagen, greifen die meisten Teams zu “das Modell ist schlecht” und versuchen Prompt-Engineering. Das funktioniert in etwa einem Drittel der Fälle. Für die anderen zwei Drittel liegt der Fehler in der Tool-Integration oder im Monitoring-Blindfleck. Hier eine Triage-Reihenfolge, die dem entspricht, was erfahrene Praktiker beschreiben:
Schritt 1: Tool-Call-Erfolgsraten prüfen. Bevor man den Prompt anfasst, sicherstellen, dass jedes Tool, von dem der Agent abhängt, gültige Ergebnisse liefert. Ratenlimits, Schema-Änderungen, Authentifizierungs-Ablauf und Netzwerk-Timeouts verursachen mehr Produktionsvorfälle als Modellverhalten.
Schritt 2: Aktions-Completion verifizieren. Wenn Tool-Calls erfolgreich sind, prüfen, ob die Ergebnisse den Erwartungen entsprechen. Eine API, die 200 zurückgibt, bedeutet nicht, dass die beabsichtigte Operation abgeschlossen wurde.
Schritt 3: Aktuelles Verhalten mit Baseline vergleichen. Wenn Tools funktionieren und Ergebnisse verifiziert sind, auf Modell-Drift prüfen. Aktuelle Agent-Trajectories gegen die Evaluierungs-Suite vergleichen.
Schritt 4: Auf kaskadierende Fehler prüfen. Wenn einzelne Schritte funktionieren, aber die End-to-End-Erfolgsrate sinkt, liegt das Problem in der Verkettung. Nach Fällen suchen, wo Schritt N schlechten Kontext an Schritt N+1 weitergibt.
Diese Sequenz ist nicht neu. Sie spiegelt, wie erfahrene SREs Ausfälle in verteilten Systemen triagieren, angepasst an die spezifischen Bruchmuster von Agenten.
Häufig gestellte Fragen
Warum scheitern KI-Agenten in der Produktion, aber funktionieren im Test?
KI-Agenten degradieren in der Produktion durch kaskadierende Fehler-Mathematik (95% Genauigkeit pro Schritt fällt auf 60% über zehn verkettete Schritte), reale Randfälle, die in Testsets fehlen, variable API-Latenz und Ratenlimits, sowie Eingabeverteilungen, die von den Evaluierungsdaten abweichen.
Was sind halluzinierte Aktionen bei KI-Agenten?
Halluzinierte Aktionen treten auf, wenn ein KI-Agent eine Antwort generiert, die bestätigt, dass er eine Aufgabe erledigt hat, aber der zugrundeliegende Tool-Call entweder leise fehlgeschlagen ist, nie ausgeführt wurde oder die falsche Ressource ansteuerte. Die Ausgabe sieht korrekt aus, aber die Aktion hat nie stattgefunden. PolyAI und Concentrix haben dieses Muster über Enterprise-Deployments hinweg dokumentiert.
Was ist die KI-Agenten-Monitoring-Lücke?
Die Monitoring-Lücke bezeichnet die Diskrepanz zwischen vorhandener Observability (89% der Teams) und tatsächlicher Ergebnis-Evaluierung (nur 52% der Teams). Die verbleibenden 37% können Traces, Latenz und Fehlerraten sehen, aber nicht erkennen, wenn Agenten selbstbewusst falsche Ergebnisse produzieren.
Wie behebt man KI-Agenten-Zuverlässigkeitsprobleme in der Produktion?
Triage in dieser Reihenfolge: Erst Tool-Call-Erfolgsraten prüfen (Ratenlimits, Schema-Änderungen), dann Aktions-Completion verifizieren, dann Verhalten gegen Evaluierungs-Baselines auf Modell-Drift prüfen, und schließlich auf kaskadierende Fehler in verketteten Schritten prüfen. Jede Ebene erfordert eine andere Lösung.
Welcher Prozentsatz der KI-Agenten-Projekte erreicht die Produktion in 2026?
Laut der Kore.ai Enterprise-Befragung 2026 nutzen 71% der Organisationen KI-Agenten in irgendeiner Form, aber nur 11% haben volles Produktions-Deployment erreicht. Gartner prognostiziert, dass über 40% der agentischen KI-Projekte bis 2027 eingestellt werden.