Die Kluft zwischen Demo und Produktion bei Agents: 4 Dinge, die niemand demonstriert

Eine gute Demonstration eines Agenten dauert einen Nachmittag. Ein produktionsbereiter Agent erfordert ein ganzes Quartal, und die meisten Teams kommen nie am Ziel an. 88 % der AI-Agent-Piloten erreichen laut Daten von Forrester und Anaconda aus dem Jahr 2026 nie die Produktionsphase, und die größten Hindernisse waren dabei nicht die intelligenteren Modelle. Es waren Lücken bei der Evaluierung (64 % der Führungskräfte), Hürden bei der Governance (57 %) und die Zuverlässigkeit des Modells (51 %). Lesen Sie diese Liste noch einmal. Jeder einzelne Punkt ist eine Disziplin, die in einer Demo niemals auftaucht. Die Lücke zwischen einer eleganten Demo und einem Live-Agenten besteht aus vier unglamourösen Dingen: Guardrails und Berechtigungen, Evaluierungen (Evals), Observability und Tracing sowie Human-in-the-Loop-Design. Teams arbeiten sich immer wieder an Prompts und Kontext ab. Doch die Lücke zwischen Demo und Produktion wird durch diese vier geschlossen.

Die Demo lügt durch Auslassung

Eine Demo läuft auf einem einzigen optimalen Pfad vor einem wohlgesonnenen Publikum. Sie haben den Input ausgewählt. Sie wussten, welche Tools Ergebnisse liefern würden. Niemand hat gefragt, was beim 40.000sten Durchlauf passiert, bei einem fehlerhaften Datensatz oder an dem Tag, an dem eine vorgelagerte API ihr Schema ändert. Die Demo beantwortet die Frage: „Kann es einmal funktionieren?“ Die Produktion fragt: „Funktioniert es jedes Mal, und können Sie es beweisen, wenn es nicht klappt?“

Das sind völlig unterschiedliche Fragen, und die zweite ist die, bei der die eigentliche Arbeit liegt. Die Demo ist die 10 %, die man sieht. Die vier unten aufgeführten Disziplinen sind die 90 %, die darüber entscheiden, ob das System den Kontakt mit echtem Arbeitsvolumen überlebt.

Lücke 1: Guardrails und Berechtigungen – der Teil, den die Demo einfach voraussetzt

In einer Demo hat der Agent immer genau den Zugriff, den er braucht, und missbraucht ihn nie. In der Produktion führt ein Agent echte Aktionen in echten Systemen aus. Er versendet E-Mails, aktualisiert Datensätze, stößt Zahlungen an, verschiebt Vorgänge zwischen Warteschlangen. In dem Moment, in dem er handeln kann, ist die Frage „Was darf er tun?“ keine Randnotiz mehr, sondern das zentrale Designelement.

Hürden bei der Governance waren mit 57 % der zweithäufigste Grund für das Scheitern von Pilotprojekten in den Daten von Forrester und Anaconda. Gartner erwartet, dass die Quittung erst später kommt: Die Analysten prognostizieren, dass bis 2027 rund 40 % der Unternehmen autonome Agenten zurückstufen oder stilllegen werden, nachdem Governance-Lücken in der Produktion zutage getreten sind. Diese Lücken sind in einer Demo unsichtbar, da eine Demo Berechtigungen nie streng einschränkt. Sie läuft als Admin-Konto ab, erledigt die eine Sache und stoppt.

Guardrails für die Produktion bedeuten konkrete Arbeit:

• Grenzen Sie die Berechtigungen des Agenten auf das erforderliche Minimum ein, nicht auf das maximal Mögliche.

• Entscheiden Sie, welche Aktionen unumkehrbar sind und welche nicht, und sichern Sie die unumkehrbaren separat ab.

• Definieren Sie, was der Agent niemals tun darf, und setzen Sie dies außerhalb des Prompts durch, damit ein Modell das Verbot nicht umgehen kann.

• Führen Sie ein Audit-Protokoll über jede Aktion, denn irgendwann wird jemand fragen: „Warum hat er das getan?“

Darunter liegt auch eine Identitätsebene. Ein Agent, der im Namen eines Benutzers handelt, sollte die Berechtigungen dieses Benutzers besitzen und nicht über ein allgemeines Dienstkonto laufen, das alles sehen darf. Eine Demo überspringt diese Frage, weil sie mit einer einzigen, allmächtigen Identität läuft. In der Produktion geht das nicht. Denn sobald ein Agent einen Datensatz anzeigt, den der anfragende Benutzer niemals hätte sehen dürfen, ist das Problem kein Bug mehr. Es ist ein Sicherheitsvorfall.

Nichts davon ist glamourös. Aber genau das macht den Unterschied aus zwischen einem Agenten, den Sie bereitstellen können, und einem Risikofaktor, bei dem das unmöglich ist.

Lücke 2: Evals, weil man einen Verlauf nicht wie eine Funktion testen kann

Dies ist der Punkt, den Teams am meisten unterschätzen, und laut den Daten mit 64 % das größte Hindernis. Traditionelle Software ist deterministisch. Gleicher Input, gleiches Ergebnis – ein Unit-Test ist somit eine klare Angelegenheit. Ein Agent ist keine Funktion. Er trifft eine Kette von autonomen Entscheidungen, und derselbe Input kann jedes Mal zu einem anderen Pfad führen.

Das sprengt das Testmodell, das Entwickler aus der klassischen Softwareentwicklung gewohnt sind. Wie LangChain es in seinem Evaluierungs-Framework formuliert: „Die alleinige Bewertung der finalen Ergebnisse übersieht kritische Fehler bei AI-Agenten, die Dutzende von internen Entscheidungen, Tool-Aufrufen und Argumentationsschritten durchlaufen, bevor sie eine Antwort generieren.“ Eine richtige finale Antwort kann auf einer völlig fehlerhaften Argumentation beruhen. Der Agent ruft vielleicht das falsche Tool auf, ruft ein irrelevantes Dokument ab und landet am Ende durch pures Glück trotzdem beim richtigen Ergebnis. Wenn Sie nur das Ergebnis bewerten, bringen Sie dieses Glück in die Produktion – und dort wird es irgendwann aufgebraucht sein.

Evals für Agenten müssen daher den gesamten Verlauf bewerten, nicht nur das Endergebnis:

• Hat er im richtigen Schritt das richtige Tool mit den richtigen Parametern ausgewählt?

• Hat er sich erholt, als ein Tool einen Fehler zurückgegeben hat, oder hat er um den Fehler herum halluziniert?

• Hält das System bei Tausenden von verschiedenen Inputs stand und nicht nur bei den drei, die Sie eingespielt haben?

• Führen Sie jeden Fall mehrmals aus und bilden Sie den Durchschnitt, da ein einziger Durchlauf aufgrund des Nicht-Determinismus gar nichts beweist.

Der Aufbau dieser Testumgebung macht den Großteil dessen aus, was es eigentlich bedeutet, einen Agenten „produktionsbereit zu machen“. In einer Demo bleibt dies unsichtbar, weil eine Demo ein einzelner, nicht wiederholter Durchlauf ist. Eine detailliertere Analyse dazu, wie Sie eine Agenten-Plattform beurteilen können, finden Sie in unserem Leitfaden zur Evaluierung einer agentischen Plattform.

Lücke 3: Observability, weil es bei Schritt 14 von 30 scheitert

Wenn ein Agent bei einer Aufgabe mit 30 Schritten eine falsche Antwort liefert, sagt Ihnen das Endergebnis so gut wie nichts. Der Fehler ist irgendwo in der Mitte aufgetreten, und ohne ein Tracing raten Sie nur. In einer Demo stoßen Sie nie darauf, weil der Demopfad kurz ist und funktioniert hat.

In der Produktion ist es genau umgekehrt. Die Arbeit von LangChain zur Observability von Agenten beschreibt das exakte Problem: Wenn „ein Benutzer meldet: ‚Der Agent hat mir eine falsche Antwort gegeben‘, können Sie das Problem ohne Zugriff auf den vollständigen Ausführungskontext (Unterhaltungsverlauf, Abrufergebnisse und Modellargumente) lokal nicht reproduzieren.“ Sie müssen sehen können, welcher Schritt fehlgeschlagen ist – ob „der Abruf irrelevante Dokumente geliefert hat, das Modell einen Tool-Parameter halluziniert hat oder die Argumentationsschleife nicht konvergierte“.

Das ist Tracing. Es zeigt Ihnen den internen Pfad Schritt für Schritt, sodass eine falsche Antwort zu einem diagnostizierbaren Ereignis wird und nicht zu einem bloßen Achselzucken führt. Und mit zunehmender Skalierung wird es schwieriger, nicht leichter. Ab einem bestimmten Volumen können Sie nicht mehr jeden Durchlauf manuell prüfen. Sie benötigen eine automatisierte Mustererkennung, um systematische Probleme abzufangen, bevor sie einem Menschen auffallen. Tracing ist wie die Rohrleitung im Haus. Niemand zeigt Rohrleitungen in einer Demo. Aber wenn der Agent bei Schritt 14 von 30 abbricht, ist das Tracing der einzige Grund, warum Sie Schritt 14 überhaupt finden.

Lücke 4: Human-in-the-loop – entscheiden, was niemals delegiert wird

Vollständige Autonomie sieht in einer Demo fantastisch aus, bewährt sich in der Praxis jedoch selten. Die eigentliche Designfrage lautet nicht „Kann der Agent alles tun?“, sondern „Welche Entscheidungen sollte er niemals allein treffen?“. Wenn Sie diese Grenze in die eine oder andere Richtung falsch ziehen, scheitern Sie: Prüfen Sie alles manuell, haben Sie nichts automatisiert; prüfen Sie wichtige Vorgänge zu wenig, riskieren Sie teure Fehler.

Databricks formuliert das Design von Human-in-the-loop treffend: Agenten „erhöhen das Risiko, weil sie echte Aktionen in Geschäftssystemen ausführen können“, weshalb „viele Agenten so konzipiert sind, dass sie vor folgenreichen Aktionen innehalten und zuerst um menschliche Freigabe bitten“. Das Prinzip besteht darin, die Kontrolle an das Risiko anzupassen: Behalten Sie die menschliche Prüfung „für folgenschwere, unsichere oder regulierte Entscheidungen“ vor und lassen Sie Routineaufgaben autonom laufen, gefolgt von einer Zusammenfassung. Eine Freigabe ist jedoch nur dann wertvoll, wenn der Prüfer tatsächlich sehen kann, was das Modell erzeugt hat und warum – andernfalls ist sie „kaum mehr als ein reines Abnicken“.

Diese Grenze zu ziehen, ist Produktdesign, kein Prompt-Tuning:

• Welche Aktionen erfordern immer die Freigabe durch einen Menschen, ganz gleich, wie sicher sich der Agent ist?

• Welche Unsicherheitsschwellen lösen eine Eskalation an einen Menschen aus?

• Welche Aktionen können autonom laufen und werden im Nachhineis stichprobenartig geprüft?

Eine Demo zeigt einen Agenten, der völlig unberührt von Anfang bis Ende durchläuft, weil das beeindruckend wirkt. Die Produktion bindet im Stillen einen Menschen an den zwei oder drei Stellen ein, die teuer, schwer umkehrbar oder reguliert sind. Diese Zurückhaltung ist das eigentliche Design – und sie schafft es nie in das Demo-Video.

Warum Teams bei den Prompts hängen bleiben

Wenn die Lücke aus diesen vier Punkten besteht, warum verbringen die meisten Teams ihre Zeit dann woanders? Weil Prompts und Kontext die Teile sind, die man sehen und schnell ändern kann. Sie bearbeiten einen Prompt, lassen die Demo erneut laufen, sehen die Verbesserung und es fühlt sich nach Fortschritt an. Guardrails, Evals, Tracing und Human-in-the-loop sind langsamer, weniger sichtbar und führen nicht zu einer besseren Demo. Sie führen zu einem System, dem Sie auch bei hohem Volumen vertrauen können – was ein völlig anderes und weitaus schwierigeres Ziel ist.

Das ist auch der Grund, warum interne Entwicklungen ins Stocken geraten. Nur etwa 22 % der internen AI-Entwicklungen erreichen je die Produktionsreife – fast das exakte Spiegelbild der 88-prozentigen Ausfallrate von Pilotprojekten. Der Prototyp steht in wenigen Wochen. Dann stößt das Team auf die vier Disziplinen, stellt fest, dass jede davon ein eigenes Projekt für sich ist, und der Zeitplan dehnt sich von einem Quartal auf fast ein Jahr aus.

Das ist das stärkste Argument für den Aufbau auf einer Plattform, die diese vier bereits als das eigentliche Produkt und nicht als nachträglichen Gedanken behandelt. Bei Beam wird Zuverlässigkeit systematisch entwickelt, nicht bloß erhofft. Ein Agent für das Forderungsmanagement klassifiziert Fälle mit einer Genauigkeit von 96 % bei einer Regression von unter 2 % über mehr als 100 Millionen Dateien pro Jahr. Diese Zahl resultiert aus dem System um das Modell herum – den Evals, dem Tracing, den Guardrails und den menschlichen Kontrollpunkten – nicht aus einem besonders glücklichen Prompt. Beam ist bewusst modellunabhängig, da das Modell selbst noch nie der Flaschenhals war. Die agentischen Workflows, die in der Produktion überleben, sind diejenigen, in denen diese vier Disziplinen fest integriert sind. Aus diesem Grund erreichen Teams mit uns einen Live-Agenten in 4 bis 6 Wochen, anstatt der 9 bis 12 Monate, die eine interne Entwicklung meist in Anspruch nimmt.

Das Fazit

Hören Sie auf, die Demo als den schwierigen Teil zu betrachten. Die Demo ist der einfache Teil, und sie zeigt Ihnen nicht die ganze Wahrheit. Die Lücke zwischen Demo und Produktion besteht aus vier Disziplinen, die niemand auf die Bühne bringt: Guardrails und Berechtigungen, Evals zur Bewertung des Verlaufs, Observability, die Ihnen den fehlerhaften Schritt anzeigt, und eine Human-in-the-loop-Linie, die festlegt, was niemals delegiert wird. Teams, die bei den Prompts hängen bleiben, polieren nur die 10 %, die man auf den ersten Blick sieht. Die Produktion entscheidet sich in den 90 %, die unsichtbar bleiben. Entwickeln Sie diese vier Säulen, und die Demo erledigt sich von selbst.

Sie wollen fundierte Berichte über produktionsbereite Agenten statt bloßem Hype? Wir versenden wöchentlich einen kurzen Bericht darüber, was AI-Agenten tatsächlich zuverlässig macht, sobald sie die Demo-Phase verlassen. Hier abonnieren.