Die erste Welle der KI-Agenten war schnell. Zu schnell, wenn man einigen Teams zuhört, die ihre Systeme inzwischen im produktiven Betrieb sehen. Ein Agent, der in einer Demo mehrere Werkzeuge aufruft, Informationen zusammenzieht und Entscheidungen vorbereitet, ist eine Sache. Ein Agent, der über Stunden oder Tage hinweg zuverlässig durch Unternehmenssysteme läuft, ist eine andere.
Genau dort beginnt die neue Phase. Nicht bei besseren Prompts, nicht bei größeren Modellen, nicht bei einer weiteren Oberfläche über bestehenden Anwendungen. Sondern bei der Frage, ob ein KI-Agent nach einem Absturz weiß, wo er war. Ob er einen Prozess fortsetzen kann, ohne alles neu zu starten. Ob er nachvollziehbar bleibt, wenn er mehrere Modelle, APIs, Datenbanken und interne Anwendungen nacheinander nutzt. Und ob ein Unternehmen überhaupt erkennt, warum ein Agent gescheitert ist.
Preeti Somal, Senior Vice President Engineering bei Temporal Technologies, beschrieb diese Lage bei einer Veranstaltung in New York mit einem Satz, der nüchtern genug ist, um ernst genommen zu werden: Viele Kunden kämen inzwischen zurück und bauten Version 2.0 desselben Agenten. Sie hätten schnell liefern müssen, aber sich nicht ausreichend um die technische Grundlage gekümmert. Dann seien Dinge abgestürzt, und nun werde mit einem verlässlicheren Fundament neu gebaut.
Das Problem liegt nicht nur im Modell
In vielen Debatten über Agentic AI dominiert noch immer die Modellfrage: Welches LLM ist genauer, schneller, günstiger, besser im Reasoning? Das ist nicht irrelevant. Aber im Unternehmensbetrieb entscheidet LLM-Performance allein nicht darüber, ob ein Agent brauchbar ist.
Ein produktiver Agent ist kein Chatfenster mit Zusatzrechten. Er ist ein mehrstufiger Workflow. Er ruft möglicherweise ein Modell auf, greift auf ein Retrieval-System zu, liest Daten aus Unternehmensanwendungen, stößt externe Prozesse an, wartet auf Antworten, entscheidet über den nächsten Schritt und hält dabei Kontext. Wenn dieser Ablauf unterbrochen wird, reicht es nicht, den Agenten einfach noch einmal loszuschicken.
Das hat sicherheitsrelevante Folgen, auch wenn es nicht immer wie klassische IT-Sicherheit aussieht. Ein unkontrollierter Neustart kann doppelte Aktionen auslösen. Ein verlorener Zustand kann zu falschen Folgeentscheidungen führen. Ein nicht nachvollziehbarer Tool-Aufruf erschwert die Untersuchung nach einem Fehler. Und wenn ein Agent nach einem Timeout den gesamten Ablauf wiederholt, steigen nicht nur Latenz und Inferenzkosten. Es entsteht auch ein operatives Risiko, weil Systeme in einen Zustand geraten können, den niemand sauber dokumentiert hat.
Agenten bringen alte Architekturfragen zurück
Somal formulierte den Kern trocken: Diese Muster seien nicht unbedingt neu, KI verstärke sie nur. Das ist eine wichtige Korrektur am üblichen Agenten-Hype. Unternehmen haben seit Jahren mit verteilten Systemen, Workflows, Zustandsverwaltung, Wiederholbarkeit, Fehlerbehandlung und Monitoring zu tun. Agentische Systeme vergrößern diese Probleme, weil sie zusätzliche Unschärfe einführen.
Ein klassischer Workflow kann scheitern, weil ein Dienst nicht antwortet. Ein KI-Agent kann ebenfalls an einem Dienst scheitern, zusätzlich aber an einer Modellantwort, an einem fehlerhaften Zwischenschritt, an einem unklaren Ziel, an veraltetem Kontext oder an der Koordination mehrerer Werkzeuge. Der Unterschied liegt weniger in einem völlig neuen Fehlertyp als in der Kombination vieler bekannter Schwachstellen mit probabilistischem Verhalten.
Für Teams, die frühe Agenten schnell in Betrieb genommen haben, wird diese Kombination nun teuer. Die Frage lautet nicht mehr: Können wir einen Agenten bauen? Sondern: Können wir ihn abbrechen, fortsetzen, prüfen, begrenzen und im Fehlerfall rekonstruieren?
Durable Execution statt Demo-Logik
Temporal positioniert sich in dieser Debatte naturgemäß aus Sicht der Workflow-Orchestrierung. Das Unternehmen hat seine Infrastruktur nicht erst für die aktuelle Agentenwelle gebaut. Gerade deshalb passt sein Blick auf den Moment: Produktionssysteme brauchen dauerhafte Ausführung, Zustandsmanagement, Sichtbarkeit in laufende Abläufe und Mechanismen zur Erholung, wenn Modelle oder nachgelagerte Systeme ausfallen.
Der Begriff klingt unspektakulär, ist aber zentral. Durable Execution bedeutet, dass ein Workflow nicht einfach verschwindet, wenn ein Prozess abstürzt oder ein Dienst vorübergehend nicht erreichbar ist. Der Ablauf bleibt rekonstruierbar. Er kann an einem definierten Punkt fortgesetzt werden. Das ist in klassischen Backend-Systemen bereits schwierig genug. Bei KI-Agenten wird es komplizierter, weil der Workflow nicht nur deterministische Programmlogik enthält, sondern auch Modellentscheidungen und Tool-Auswahl.
Damit entsteht ein Spannungsfeld: Je autonomer ein Agent arbeiten soll, desto stärker muss seine Umgebung begrenzen, protokollieren und absichern, was er tut. Autonomie ohne robuste Laufzeitumgebung ist im Unternehmen kein Produktivitätsgewinn, sondern ein schwer zu prüfender Prozess mit Zugriff auf reale Systeme.
Observability wird zur Kontrollfrage
Viele Agentenprojekte werden an einer Stelle erwachsen, die selten auf Strategiefolien steht: Observability. Teams müssen sehen, welche Schritte ein Agent ausgeführt hat, welches Modell wann aufgerufen wurde, welche Datenquellen beteiligt waren, welche Kosten entstanden sind und an welcher Stelle ein Fehler begann. Ohne diese Sichtbarkeit bleibt nur das Endergebnis. Das reicht im Betrieb nicht.
Gerade in regulierten oder sicherheitsbewussten Umgebungen ist diese Nachvollziehbarkeit keine Komfortfunktion. Sie entscheidet darüber, ob ein System auditierbar ist. Wenn ein Agent Kundendaten verarbeitet, interne Tools nutzt oder Entscheidungen vorbereitet, muss ein Unternehmen erklären können, wie ein Ergebnis zustande kam. Nicht im philosophischen Sinn vollständiger Modelltransparenz, sondern auf operativer Ebene: welche Eingaben, welche Aufrufe, welche Zustände, welche Wiederholungen.
Die zweite Agenten-Generation dürfte deshalb weniger spektakulär aussehen als die erste. Weniger Demo, mehr Leitplanken. Weniger improvisierte Verkettung von Tools, mehr definierte Workflows. Weniger Vertrauen in den glücklichen Pfad, mehr Planung für den Fehlerfall.
Der Umbau ist ein Reifezeichen
Dass Unternehmen ihre frühen Agentenarchitekturen überarbeiten müssen, ist kein Beleg dafür, dass das Konzept gescheitert ist. Es zeigt eher, dass die Systeme die Spielzeugphase verlassen. In Produktion zählt nicht, ob ein Agent einmal beeindruckend durchläuft. Entscheidend ist, ob er auch beim dritten Ausfall eines nachgelagerten Dienstes, bei steigenden Kosten, bei langsamen APIs und bei widersprüchlichen Zwischenergebnissen kontrollierbar bleibt.
Die nächste Phase wird daher von Infrastrukturfragen geprägt sein: Orchestrierung, Wiederaufnahme, Kostenkontrolle, Governance, Protokollierung, Rechteverwaltung und klare Abbruchbedingungen. Das sind keine Nebenthemen. Sie bestimmen, ob Agentic AI in Unternehmen als belastbares Werkzeug endet oder als Sammlung fragiler Automatisierungen, die nur unter idealen Bedingungen funktionieren.
Der Umbau der KI-Agenten ist also weniger eine Kurskorrektur als eine verspätete Ingenieursphase. Erst wurde gezeigt, was möglich ist. Jetzt müssen Unternehmen entscheiden, was davon betriebsfest genug ist, um es an reale Systeme anzuschließen.
