Die Agenten-Zuverlässigkeitskrise 2026: Ein Runtime-Problem, kein Modell-Problem

Die Begeisterung war groß: 2024 und 2025 hat fast jeder Mittelständler mindestens einen Piloten mit Agentic AI gestartet. Ein KI-Agent, der eigenständig recherchiert, Tools aufruft und mehrstufige Aufgaben erledigt – im Demo-Termin lief das beeindruckend rund. Doch 2026 holt viele Projekte die Realität ein. Was im Pilot zu über 90 % funktionierte, liefert in Produktion plötzlich nur noch rund jede zweite Aufgabe sauber ab.

Die Versuchung ist groß, dem Modell die Schuld zu geben. „Vielleicht ist GPT noch nicht gut genug", heißt es dann. Das ist in den meisten Fällen falsch. Die Modelle sind leistungsfähiger denn je. Was fehlt, ist die Betriebsschicht darunter – die Runtime, die einen Agenten erst produktionstauglich macht. Dieser Artikel zeigt, woran Agenten konkret scheitern und wie eine Architektur aussieht, die auch unter Last und bei Fehlern verlässlich bleibt.

Die Pilot-zu-Produktion-Lücke

Der erste Schritt zur Lösung ist, das Problem ehrlich zu benennen. In kontrollierten Pilotumgebungen erreichen Agenten regelmäßig Erfolgsquoten von 90 % und mehr. Die Daten sind bereinigt, die Tasks kurz, die externen Systeme antworten zuverlässig. Sobald derselbe Agent jedoch auf echte Produktionsdaten, mehrstündige Aufgaben und unzuverlässige Schnittstellen trifft, fällt die Erfolgsquote bei komplexen Workflows auf rund 50 %.

Diese Lücke ist kein Einzelfall, sondern ein Muster. Analystenhäuser wie Gartner gehen davon aus, dass deutlich über 40 % der agentic-AI-Projekte bis 2027 scheitern oder abgebrochen werden – nicht weil die Idee falsch war, sondern weil die Umsetzung an Betrieb, Kosten und Organisation scheitert. Die genannten Zahlen sind Prognosen und Spannen, kein Naturgesetz; die Richtung ist aber eindeutig.

Die Ursachen lassen sich in drei Cluster fassen:

• Unterschätzte Betriebskosten: Token-Verbrauch, Tool-Aufrufe und Wiederholungen summieren sich in Produktion zu einem Vielfachen der Pilotkosten.
• Security- und Compliance-Komplexität: Ein Agent, der eigenständig handelt, braucht klare Grenzen – sonst entstehen Risiken, die kein Pilot abbildet.
• Organisationswandel: Prozesse, Verantwortlichkeiten und Eskalationswege müssen sich ändern, damit autonome Systeme produktiv arbeiten dürfen.

Gartner spricht in diesem Zusammenhang von einer „Rebuild Era": dem notwendigen Übergang von schnell zusammengesteckten v1.0-Prototypen zu robust gebauten v2.0-Systemen. Wer diesen Schritt überspringt, bleibt im Pilotmodus stecken – oder bricht ab.

Warum es ein Runtime-Problem ist

Um zu verstehen, warum Agenten in Produktion einbrechen, lohnt ein Blick auf die typische v1.0-Architektur. Sie besteht aus einem Modell, einer Handvoll Tools und einer Schleife, die Reasoning und Tool-Aufrufe abwechselt – oft als ReAct-Agent umgesetzt. Diese Schleife läuft in einem zustandslosen Prozess: Stürzt er ab oder wird neu gestartet, ist der gesamte Kontext verloren.

Stateless-Infrastruktur verliert Kontext

Ein langer Agenten-Lauf besteht aus dutzenden Zwischenschritten: gesammelte Fakten, Teilergebnisse, offene Entscheidungen. In einer stateless Umgebung existiert all das nur im Arbeitsspeicher des laufenden Prozesses. Ein Timeout, ein OOM-Kill, ein Deployment – und der Agent beginnt bei null. Bei einem Task, der 90 Minuten und 60 Tool-Aufrufe umfasst, ist die Wahrscheinlichkeit hoch, dass irgendwo etwas schiefgeht.

Fehlende Failure-Recovery

Noch gravierender: In v1.0 killt ein einziger gescheiterter Schritt den ganzen Workflow. Eine API antwortet mit HTTP 503, ein Tool liefert ungültiges JSON, das Modell läuft in ein Rate-Limit – und statt den fehlerhaften Schritt zu wiederholen, bricht der komplette Lauf ab. In Produktion, wo externe Systeme ständig mal kurz nicht erreichbar sind, ist das fatal.

Keine Orchestrierung, keine Wiederaufnahme

Ohne eine echte Agenten-Orchestrierung gibt es keine Möglichkeit, einen Workflow an der Fehlerstelle wieder aufzunehmen. Die Orchestrierungsschicht ist es, die weiß, welche Schritte bereits erledigt sind, welche noch ausstehen und an welcher Stelle nach einem Fehler weitergemacht werden muss. Fehlt sie, bleibt nur der Komplett-Neustart – teuer, langsam und oft mit doppelten Seiteneffekten.

Das Fazit ist unbequem, aber befreiend: Das Modell ist in aller Regel gut genug. Was fehlt, ist die Betriebsschicht – Persistenz, Wiederaufnahme, Überwachung und Kontrolle. Genau dort entscheidet sich, ob ein Agent ein Showcase bleibt oder produktiv Geld verdient.

State-Preservation und Checkpointing

Das Herzstück einer produktionsreifen Runtime ist die durable, also dauerhafte Ausführung. Die Idee stammt aus der Welt der Workflow-Engines und lässt sich auf Agenten übertragen: Jeder Schritt wird persistiert und ist wiederaufsetzbar.

Durable Execution als Fundament

Bei durable Execution schreibt die Runtime nach jedem abgeschlossenen Schritt den aktuellen Zustand in einen persistenten Speicher (Checkpoint). Fällt der Prozess danach aus, lädt die Runtime den letzten Checkpoint und setzt exakt dort fort. Der Agent „erinnert" sich also nicht nur an seine Aufgabe, sondern an jeden bereits getätigten Schritt. Frameworks im Stil von Temporal haben dieses Muster für klassische Microservices etabliert; für Agenten dient es als Referenzarchitektur.

Memory-Layer richtig schneiden

Verlässliche Agenten trennen zwei Arten von Gedächtnis sauber: den Kurzzeit-Kontext eines laufenden Tasks (Zwischenergebnisse, aktuelle Tool-Outputs) und das persistente Wissen, das über Läufe hinweg erhalten bleibt. Diese Trennung verhindert, dass der Kontext überläuft, und macht klar, welche Informationen nach einem Neustart wiederhergestellt werden müssen. In Multi-Agent-Systemen wird dieser Memory-Layer zur gemeinsamen Wahrheit, auf die mehrere Agenten koordiniert zugreifen.

Idempotenz: die unterschätzte Pflicht

Wer Schritte wiederholt, muss sicherstellen, dass eine Wiederholung keinen Schaden anrichtet. Ein Tool-Aufruf, der eine Bestellung auslöst oder eine E-Mail versendet, darf bei einem Retry nicht doppelt feuern. Idempotente Tool-Aufrufe – etwa über eindeutige Idempotency-Keys – sind daher keine Kür, sondern Voraussetzung für sichere Failure-Recovery.

Aspekt	v1.0 (Pilot)	v2.0 (Produktion)
State	Nur im RAM, geht bei Absturz verloren	Persistente Checkpoints nach jedem Schritt
Fehlerfall	Kompletter Abbruch, Neustart von vorn	Retry des Schritts, Resume ab Fehlerstelle
Seiteneffekte	Doppelte Aktionen bei Wiederholung	Idempotente Tool-Aufrufe
Transparenz	Blackbox, kaum nachvollziehbar	Tracing jedes Reasoning- und Tool-Schritts
Kontrolle	Agent darf faktisch alles	Policy-Gates, Least Privilege, HITL

Observability für Agenten

Man kann nicht verbessern, was man nicht sieht. Ein klassischer Webservice lässt sich über Logs, Metriken und Traces überwachen – bei Agenten ist das nicht anders, nur dass die zu überwachende Einheit der Reasoning-Schritt ist. Observability ist deshalb keine nachträgliche Zugabe, sondern Teil der Architektur. Sie ist auch ein zentrales Element professioneller LLMOps-Praxis.

Tracing bis auf Schritt-Ebene

Jeder Reasoning-Schritt und jeder Tool-Call sollte mit Ein- und Ausgabe, Dauer und Ergebnis erfasst werden. So lässt sich nachvollziehen, warum ein Agent eine bestimmte Entscheidung getroffen hat – und an welcher Stelle er abgebogen ist, wenn das Ergebnis nicht stimmt. Ohne dieses Tracing bleibt jede Fehlersuche Kaffeesatzleserei.

Die richtigen Metriken

Vier Kennzahlen gehören in jedes Agenten-Dashboard:

• Erfolgsquote pro Workflow-Typ – die ehrlichste Zahl überhaupt.
• Drift – verschlechtert sich die Qualität über die Zeit, etwa nach einem Modell-Update?
• Latenz – wie lange braucht ein Workflow von Start bis Abschluss?
• Kosten pro Workflow – Token und Tool-Aufrufe in Euro, nicht in abstrakten Einheiten.

Auditierbarkeit und Alarme

Lückenloses Logging ist zugleich die Voraussetzung für die Auditierbarkeit, die der EU AI Act für viele Einsatzszenarien verlangt. Jede Agenten-Entscheidung muss im Nachhinein nachvollziehbar sein. Ergänzend braucht es Alarme: bei Anomalien in der Erfolgsquote ebenso wie bei Kostenausreißern, etwa wenn ein Agent in eine Schleife läuft und plötzlich das Zehnfache an Tokens verbraucht.

Policy-Enforcement und Guardrails

Ein Agent, der eigenständig handelt, ist nur so sicher wie die Grenzen, die man ihm setzt. Guardrails und Policy-Enforcement sind die Schicht, die aus einem mächtigen, aber unberechenbaren System ein kontrollierbares Werkzeug macht. Wie man diese Kontrolle organisatorisch verankert, beschreiben wir ausführlich im Bereich Agent-Governance.

Purpose-Limitation und Least Privilege

Der Grundsatz ist einfach: Ein Agent darf nur die Aktionen ausführen, die für seine Aufgabe definiert sind – nicht mehr. Diese Purpose-Limitation wird technisch über Least-Privilege-Zugriffe durchgesetzt: Der Agent erhält nur Zugriff auf genau die Tools und Daten, die er braucht. Ein Support-Agent braucht keinen Schreibzugriff auf das ERP-System, ein Recherche-Agent keinen Zugriff auf Zahlungsfunktionen.

Human-in-the-Loop für kritische Schritte

Nicht jede Entscheidung darf autonom fallen. Für kritische oder irreversible Schritte – eine Überweisung, eine Vertragskündigung, das Löschen von Daten – braucht es ein Human-in-the-Loop-Gate. Der Agent bereitet die Aktion vor, ein Mensch gibt sie frei. Das verlangsamt nichts Wesentliches, verhindert aber genau die teuren Fehler, vor denen viele zu Recht Respekt haben.

Pre-Production-Policy-Gates

Bevor ein Agent überhaupt in Produktion geht, sollten automatisierte Policy-Gates greifen: Schwellen für Halluzinationsrate, Kosten pro Lauf und Latenz. Unterschreitet ein Agent diese Qualitätsschwellen, geht er gar nicht erst live. Diese Gates lassen sich in eine CI/CD-Pipeline integrieren, sodass jede neue Version automatisch geprüft wird. So entstehen verlässliche agentische Workflows, die man guten Gewissens auf echte Geschäftsprozesse loslassen kann.

Verlässliche Agenten on-premise

Gerade weil Verlässlichkeit so stark von der Betriebsschicht abhängt, spricht vieles dafür, diese Schicht selbst in der Hand zu behalten. On-Premise- oder Private-Cloud-Betrieb gibt Ihnen die volle Kontrolle über Orchestrierung, Logs und State – im eigenen Netz, ohne Umweg über fremde Infrastruktur.

Kontrolle und Reproduzierbarkeit

Wenn die Orchestrierungsschicht im eigenen Rechenzentrum läuft, bestimmen Sie, wie Checkpoints gespeichert, wie lange Logs aufbewahrt und wie State verschlüsselt wird. Über Container und Kubernetes werden Deployments reproduzierbar: Dieselbe Agenten-Version verhält sich in Test und Produktion identisch, und ein Rollback ist jederzeit möglich.

Keine Abhängigkeit von Cloud-Verfügbarkeit

Kritische Workflows dürfen nicht stillstehen, nur weil ein Cloud-Dienst gerade eine Störung hat. Läuft die Runtime im Haus, entkoppeln Sie Ihre Kernprozesse von der Verfügbarkeit externer Anbieter. Das einzelne Sprachmodell kann weiterhin extern oder lokal laufen – die orchestrierende, zustandshaltende Schicht bleibt unter Ihrer Kontrolle.

Audit-Trails DSGVO-konform im Haus

Audit-Logs enthalten oft sensible Informationen: welche Daten ein Agent verarbeitet, welche Entscheidungen er getroffen hat. Bleiben diese Trails im eigenen Netz, ist die DSGVO-Konformität deutlich einfacher zu gewährleisten als bei verteilter Cloud-Speicherung. Mehr zum laufenden Betrieb solcher Systeme finden Sie unter KI-Administration.

Migrationspfad zu v2.0

Der Weg von einem fragilen Piloten zu einem produktionsreifen System muss nicht in einem großen Wurf passieren. Ein schrittweiser Migrationspfad reduziert Risiko und zeigt früh messbare Erfolge.

1. Phase 1 – Workflows kartieren: Zeichnen Sie die bestehenden Agenten-Abläufe vollständig auf und identifizieren Sie die kritischen Failure-Punkte. Wo genau bricht der Agent heute ab? Welche Schritte sind irreversibel? Diese Bestandsaufnahme ist die Grundlage für alles Weitere.
2. Phase 2 – Durable Orchestrierung einführen: Ersetzen Sie die zustandslose Schleife durch eine zustandshaltende Orchestrierungsschicht mit Checkpointing und Retry-Logik. Bereits dieser Schritt hebt die Erfolgsquote spürbar an.
3. Phase 3 – Observability und Policy-Gates ergänzen: Bauen Sie Tracing, Metriken und Alarme auf und etablieren Sie Guardrails sowie Human-in-the-Loop-Gates für kritische Aktionen. Jetzt wird der Agent transparent und kontrollierbar.
4. Phase 4 – Autonomie schrittweise erhöhen: Geben Sie dem Agenten mehr Freiheiten, aber gemessen an realen Erfolgsquoten. Erst wenn ein Workflow stabil über der Zielschwelle liegt, lockern Sie die Human-in-the-Loop-Gates für diesen Bereich.

Ein hilfreiches Architekturmuster auf diesem Weg ist die Reflection: Der Agent prüft seine eigenen Zwischenergebnisse, bevor er weitermacht – ein zusätzlicher Hebel für Qualität, der sich gut mit Policy-Gates kombinieren lässt. Für komplexere Szenarien lohnt zudem der Blick auf koordinierte Multi-Agent-Systeme, in denen spezialisierte Agenten unter einer gemeinsamen Orchestrierung zusammenarbeiten.

Entscheidend ist die Reihenfolge: Erst Stabilität und Kontrolle, dann Autonomie. Wer diese Reihenfolge umdreht, landet wieder bei den 50 %.

Häufig gestellte Fragen zu verlässlichen KI-Agenten

Warum scheitern KI-Agenten in Produktion, obwohl Piloten funktionieren?

Piloten laufen mit bereinigten Daten und kurzen Tasks. In Produktion fehlen State-Preservation, Failure-Recovery und Orchestrierung – die Erfolgsquote fällt von 90 %+ auf rund 50 % bei komplexen, mehrstündigen Aufgaben.

Was bedeutet "Runtime-Problem, kein Modell-Problem"?

Die Modelle sind leistungsfähig genug. Was fehlt, ist die Betriebsschicht: durable Ausführung, Wiederaufnahme nach Fehlern, Observability und Policy-Enforcement. Genau dort entscheidet sich Verlässlichkeit.

Was ist durable/stateful Orchestrierung?

Ein Ausführungsmodell, bei dem jeder Schritt persistiert wird, sodass ein Workflow nach einem Absturz an der Fehlerstelle wiederaufgenommen wird – statt komplett neu zu starten.

Lassen sich verlässliche Agenten on-premise betreiben?

Ja, und es ist oft sinnvoll: Orchestrierung, State und Audit-Logs bleiben im Haus, Deployments sind über Container reproduzierbar und es gibt keine Abhängigkeit von der Cloud-Verfügbarkeit.