Analyse: Was sich tatsächlich geändert hat, als KI-Agenten von der Demo zur Produktion übergingen

Es gibt einen vertrauten Bogen bei Agentenprojekten. Ein Prototyp leistet in der ersten Woche Erstaunliches. Bis zur sechsten Woche produziert er plausible Unsinnigkeiten auf Eingaben, die niemand erwartet hat, und das Team streitet darüber, ob ein weiteres Modell hinzugefügt oder aufgegeben werden soll.

Die Projekte, die die andere Seite erreichten, fanden kein besseres Modell. Sie veränderten die Form des Problems.

Die Arithmetik, die Demos tötet

Nehmen Sie eine Aufgabe, die in Schritte zerlegt ist, von denen jeder Agent zu 95 % korrekt abschließt. Das ist eine gute Rate für einen offenen Schritt, der Urteilsvermögen erfordert.

Ketten Sie drei Schritte aneinander, und etwa 86 % der Läufe sind erfolgreich. Ketten Sie zwanzig aneinander, und etwa ein Drittel ist erfolgreich. Ketten Sie fünfzig aneinander, und Sie sind bei 8 %.

Die Demo zeigte Ihnen einen Durchlauf einer fünffachen Aufgabe, und ein Mensch startete leise die beiden Versuche neu, die schiefgingen. Die Produktion führt die zwanzigstufige Version zehntausendmal aus, ohne dass jemand zusieht.

Alles, was folgt, ist eine Reaktion auf diese Arithmetik.

Was die funktionierenden Einsätze gemeinsam haben

Ein enger Bereich. Nicht "Betriebsabläufe verwalten", sondern "diese beiden Rechnungssysteme abgleichen". Weniger Verzweigungen, weniger Werkzeuge, weniger Möglichkeiten, falsch zu liegen. Fast jeder Agent, der den Kontakt mit der Produktion überlebte, ist weniger ehrgeizig als die Demo, die ihn rechtfertigte.

Günstige Verifizierung. Dies ist der stärkste einzelne Prädiktor. Codierungsagenten funktionierten zuerst, weil Tests ein objektives, automatisches Signal liefern: Der Agent kann versuchen, prüfen und wiederholen, ohne einen Menschen. Wo die Verifizierung teuer ist – ein Rechtsgutachten, eine Preisentscheidung – muss die Ausgabe des Agenten von einer Person überprüft werden, was den Hebel begrenzt und den Business Case verändert.

Eine Berechtigungsgrenze außerhalb des Modells. Breit lesen, eng schreiben. Genehmigungsschwellen für Geldausgaben, Kontaktaufnahme mit Kunden, Löschen von Daten, Bereitstellung. Dies wird zur Laufzeit erzwungen, niemals durch Anweisungen in einem Prompt: Ein Agent, der nicht vertrauenswürdige Inhalte liest, ist ein Agent, dessen Anweisungen kontaminiert werden können.

Budgets. Maximale Schritte, maximale Wandzeit, maximale Token. Ein Agent, der bei einer fehlerhaften Tool-Antwort in einer Schleife hängt, ist ein Abrechnungszwischenfall ohne natürliches Ende.

Ein wiederholbar protokollierter Verlauf. Jeder Tool-Aufruf und jedes Ergebnis wird gespeichert. Wenn etwas schiefgeht, muss "was hat er tatsächlich getan" sofort beantwortet werden können – sowohl zur Behebung als auch, zunehmend, zur Zufriedenstellung eines Prüfers.

Die Bewertung ist erwachsen geworden

Die folgenschwerste Veränderung ist die am wenigsten sichtbare. Frühe Agentenarbeit wurde durch Beobachtung bewertet. Das skaliert nicht und fängt keine Regressionen ab.

Die aktuelle Praxis besteht darin, Trajektorien aufzuzeichnen – die vollständige Abfolge von Schritten, Tool-Aufrufen und Ergebnissen aus realen Läufen – und diese gegen jede Änderung des Prompts, des Modells oder des Tool-Sets abzuspielen. Jede Trajektorie trägt eine Behauptung darüber, wie ein korrekter Lauf aussieht. Eine neue Modellversion wird nicht übernommen, weil sie auf einem öffentlichen Benchmark besser abschneidet; sie wird übernommen, weil sie die aufgezeichnete Menge nicht beschädigt.

Die zweite Veränderung ist die Bewertung pro Schritt. End-to-End-Erfolgsraten sagen Ihnen, dass etwas falsch ist. Schrittweise Bewertungen sagen Ihnen, dass das Abruf-Tool montags veraltete Ergebnisse liefert.

Werkzeuge wurden zur Infrastruktur

Eine Zeit lang schrieb jedes Agentenprodukt seine eigenen Konnektoren. Das Model Context Protocol verwandelte die Tool-Bereitstellung in eine standardisierte Schnittstelle: Ein Server beschreibt, was er anbietet, und jeder kompatible Client kann ihn nutzen. Das hat die Integrationsarbeit von maßgeschneidertem Klebstoff in jeder Anwendung zu wiederverwendbaren Servern verlagert, die einmal gewartet werden.

Die praktische Auswirkung ist alltäglich und groß: Die interessante Frage verschob sich von "Wie verbinde ich meinen Agenten mit diesem System?" zu "Was darf mein Agent mit diesem System tun?". Das ist eine Governance-Frage, und es ist die richtige.

Wo es nicht funktioniert hat

Es lohnt sich, dies klar auszusprechen, da die Misserfolge weniger öffentlich gemacht werden:

• Langfristiger autonomer Betrieb. Agenten, die stundenlang für offene Ziele laufen gelassen werden, driften immer noch ab, und die Kosten einer falschen Abzweigung summieren sich lautlos.
• Aufgaben mit teurer Verifizierung. Wenn ein Mensch die gesamte Ausgabe lesen muss, um zu wissen, ob sie richtig ist, hat der Agent Tipparbeit gespart, aber keine Arbeit.
• Umgebungen mit hoher Varianz. Websites, die ihr Layout ändern, Systeme, die inkonsistente Fehler zurückgeben, Prozesse mit undokumentierten Ausnahmen.
• Schwärme um ihrer selbst willen. Multi-Agenten-Architekturen helfen, wenn Teilaufgaben wirklich unterschiedliche Werkzeuge und Kontexte benötigen. Wenn sie auf eine Aufgabe angewendet werden, die ein einzelner Agent bewältigen könnte, führen sie zu Koordinationsfehlern.

Die ehrliche Zusammenfassung

Agenten funktionieren heute dort, wo das Ziel klar ist, der Bereich eng ist, das Ergebnis günstig zu überprüfen ist und der Schadensradius durch etwas anderes als das gute Urteilsvermögen des Modells begrenzt ist. Das ist eine reale und wachsende Kategorie – und sie ist kleiner, als das Wort "agentisch" in einer Produktankündigung impliziert.

Die Teams, die erfolgreich liefern, sind ausnahmslos diejenigen, die dies zuerst akzeptiert haben.