TL;DR
- Der Engpass für KI-Agenten in Produktion ist 2026 nicht das Modell, sondern die Zuverlässigkeit über viele Schritte. Ein Agent, der pro Schritt zu 85 % richtig liegt, schafft eine 10-Schritt-Aufgabe nur in rund 20 % der Fälle vollständig (0,85 hoch 10).
- Viele "Agent-Fehler" sind in Wahrheit Mess-Fehler. Wer nicht sauber evaluiert, optimiert ins Blaue.
- Evals sind die neuen Unit-Tests. Ohne sie ist der Sprung von beeindruckender Demo zu verlässlichem Betrieb nicht zu schaffen — und genau dort scheitern die meisten Projekte.
Die Demo funktioniert. Die Produktion nicht. Warum?
Fast jeder, der 2025/26 einen KI-Agenten gebaut hat, kennt das Muster: In der Demo löst der Agent die Aufgabe souverän. Im echten Betrieb, über hunderte Durchläufe, bricht er an Stellen ein, die im Test nie auffielen. Die naheliegende Erklärung — "das Modell ist noch nicht gut genug" — ist meistens falsch. Das Problem ist struktureller.
Die Mathematik hinter dem Scheitern
Ein Agent erledigt eine Aufgabe in mehreren Schritten: lesen, planen, ein Tool aufrufen, das Ergebnis prüfen, den nächsten Schritt wählen. Jeder Schritt hat eine Erfolgswahrscheinlichkeit kleiner als 100 %. Und diese Wahrscheinlichkeiten multiplizieren sich.
Bei 85 % Erfolg pro Schritt gelingt eine Aufgabe mit 10 Schritten nur in etwa 20 % der Fälle vollständig — 0,85 hoch 10. Nicht, weil das Modell schlecht ist, sondern weil sich kleine Fehlerquoten über viele Schritte aufsummieren.
Das nennt sich compounding step failure, und es erklärt, warum ein Agent, der in der Einzelaufgabe brilliert, in der mehrstufigen Realität strauchelt. Die Konsequenz für den Bau: Nicht die Qualität des einzelnen Modell-Aufrufs ist der Hebel, sondern die Verlässlichkeit der gesamten Kette — und die Fähigkeit, fehlgeschlagene Schritte zu erkennen und sauber zu wiederholen, statt blind weiterzulaufen.
Der teuerste Fehler: nicht zu wissen, ob es funktioniert
Hier kommt der Punkt, der die meisten überrascht: Ein großer Teil der gemessenen Agent-Fehler sind Fehler in der Mess-Infrastruktur, nicht im Agenten.
Anthropic hat das öffentlich dokumentiert: Bei einem Standard-Benchmark (CORE-Bench) sprang die gemessene Leistung ihres Modells von 42 % auf 95 % — nachdem Fehler im Eval-Harness behoben waren, nicht nachdem das Modell verbessert wurde. Der Agent war die ganze Zeit fähig; die Messung war kaputt.
Das ist keine Randnotiz. Wer ohne saubere Evaluation entwickelt, optimiert gegen ein verzerrtes Signal: Man "fixt" Probleme, die keine sind, und übersieht echte. Bevor man also die Architektur eines strauchelnden Agenten umbaut, lautet die erste Frage immer: Messen wir überhaupt richtig?
Was gute Evaluation 2026 ausmacht
Die Reife eines KI-Agenten-Projekts erkennt man weniger am Modell als an seiner Eval-Disziplin. Drei Prinzipien haben sich herauskristallisiert:
1. Die Trajektorie bewerten, nicht nur das Endergebnis
Klassische Evals prüfen den finalen Output: richtig oder falsch. Bei Agenten reicht das nicht — denn der Weg zählt. Hat der Agent die richtigen Tools in der richtigen Reihenfolge aufgerufen? Hat er einen Fehlschlag erkannt und korrigiert, oder ist er zufällig trotz falschem Pfad zum richtigen Ergebnis gestolpert? Moderne Eval-Werkzeuge (z. B. Trajectory-Evals) bewerten die gesamte Tool-Call-Sequenz, nicht nur die letzte Antwort.
2. LLM-as-Judge — nützlich, aber mit bekannten Schwächen
Ein verbreitetes Muster ist, ein Modell die Antworten eines anderen bewerten zu lassen ("LLM as a judge"). Das skaliert, hat aber dokumentierte Schwächen: Solche Judges urteilen inkonsistent, wenn man dieselbe Frage nur umformuliert. Heißt in der Praxis: LLM-Judges sind ein Werkzeug, kein Ersatz für eine menschlich kuratierte Referenzmenge — und ihre Urteile gehören selbst stichprobenartig geprüft.
3. Beobachtbarkeit als Standard
Man kann nicht verbessern, was man nicht sieht. Produktionsreife Agenten brauchen Tracing über jeden Schritt — welches Tool, mit welchen Argumenten, mit welchem Ergebnis. Die Branche standardisiert das gerade: Die OpenTelemetry-Konventionen für generative KI (mit Bausteinen für Agenten- und Tool-Aufrufe) sind im Entstehen, auch wenn vieles davon noch im Entwicklungsstatus ist. Wer früh strukturiert mitschneidet, kann Fehler überhaupt erst zurückverfolgen.
Was das für ein Projekt heißt
| Reifegrad | Woran man ihn erkennt |
|---|---|
| Demo | Funktioniert im Happy Path, kein systematisches Testen |
| Pilot | Erste Eval-Suite, aber nur Output-basiert |
| Produktionsreif | Trajektorien-Evals + Tracing + Gates in der CI, fehlgeschlagene Schritte werden erkannt und wiederholt |
Der Sprung von "beeindruckende Demo" zu "verlässlicher Betrieb" ist kein Modell-Upgrade — er ist eine Engineering-Disziplin. Evals sind dafür das zentrale Werkzeug, so wie Unit-Tests es für klassische Software sind. Teams, die das früh ernst nehmen, liefern Agenten aus, die unter Last halten. Teams, die es überspringen, bleiben in der Demo-Phase stecken — oft ohne zu wissen, warum.
Genau diese Disziplin — kleine, verifizierte Schritte, messbare Gates, nachvollziehbare Trajektorien — ist der Kern, wie wir bei azena KI-Systeme bauen, die man auch unbeaufsichtigt laufen lassen kann. Wie wir das für mittelständische Unternehmen umsetzen, zeigt unsere KI-Beratung für den Mittelstand. Wenn ihr einen Agenten von der Demo in den Betrieb bringen wollt, sprecht mit uns.
Stand: Mitte 2026. Faktenbasis quellengeprüft (u. a. Anthropic Engineering, LangSmith, OpenTelemetry). Kein Hype, nur Substanz.
Nächster Schritt
Passt das auf Ihren Fall?
30-Min-Erstgespräch, kostenfrei und unverbindlich. Wir gehen Ihren konkreten Fall durch — und sagen ehrlich, wenn nichts passt.