Modell austauschbar? Überlebt Ihr Workflow den Modellwechsel auch?

Stellen Sie sich einen Agenten vor, der seit drei Stunden arbeitet. 97 von 100 Schritten sind erledigt. Dann verschwindet das Modell, auf dem Schritt 98 laufen sollte. Was passiert mit den drei Stunden Arbeit?

In Teil 4 dieser Reihe ging es darum, das Modell austauschbar zu machen: ein Gateway davor, mehrere Anbieter, Fallbacks. Das löst eine Ebene. Es bleibt eine zweite, die selten jemand mitdenkt: der laufende Prozess selbst.

Der nächste Single Point of Failure

Solche Agenten rufen ein Modell hundertfach auf, sammeln Zwischenergebnisse und bauen darauf auf. Fällt das Modell mitten im Lauf weg, ändert sich sein Verhalten oder startet der Server neu, passiert in einem naiven Aufbau das Schlimmste: Der Prozess beginnt von vorn. Stunden Arbeit sind verloren, oder schlimmer, er bleibt in einem halben Zustand stehen.

Das Gateway hat das Modell ersetzbar gemacht. Den Prozess hat es nicht gerettet. Genau hier liegt der nächste Single Point of Failure.

Was eine durable Workflow-Engine anders macht

Die Antwort ist eine eigene Architekturschicht: durable execution. Eine Workflow-Engine hält jeden Schritt in einer Ereignis-Historie fest. Fällt etwas aus, läuft der Prozess am letzten abgeschlossenen Schritt weiter, statt von vorn. Fertige Schritte werden nicht wiederholt, ihr Ergebnis wird aus der Historie gelesen.

Konkret bedeutet das:

• Langläufer überstehen Neustarts. Ein Prozess kann Stunden oder Tage laufen und den Absturz eines Workers überleben.
• Schritte werden automatisch wiederholt. Fällt ein einzelner Modellaufruf aus, wird genau dieser Schritt erneut versucht oder auf ein anderes Modell gelenkt, nicht der ganze Lauf.
• Der Zustand bleibt erhalten. Was bis zum Ausfall erarbeitet wurde, ist nicht verloren.

Eine Grenze gehört dazu, sonst klingt es nach Zauberei: Durable execution macht ein nicht verfügbares Modell nicht verfügbar. Sie bewahrt den Fortschritt und ermöglicht den sauberen Wiederhol- oder Umleitungsversuch. Das Modell braucht weiterhin eine Alternative, aber der Prozess verliert seine Arbeit nicht.

Aus der Praxis

Ich betreibe Agenten, die nachts über lange Zeiträume durcharbeiten. Genau dort zahlt sich diese Schicht aus: Ein einzelner fehlgeschlagener Schritt wirft nicht den ganzen Lauf zurück. Das ist der Unterschied zwischen einem Rückschlag und einem Totalausfall, und es ist derselbe Gedanke wie beim Modell, nur eine Ebene höher.

Das Muster, nicht das Produkt

Durable execution ist kein Nischen-Trick, sondern ein etabliertes Muster. Es steckt in mehreren Systemen: Temporal als verbreiteter Open-Source-Engine, AWS Step Functions, Azure Durable Functions, Restate und auch Mistral Workflows, deren durable execution laut Anbieter auf Temporal aufsetzt. (Quelle: Mistral-Doku.)

Welches Werkzeug Sie wählen, ist zweitrangig. Die Architekturentscheidung zählt: Soll ein geschäftskritischer Ablauf einen Ausfall überstehen, gehört er in eine Engine, die Zustand und Wiederaufnahme garantiert, statt in ein Skript, das bei jedem Fehler von vorn beginnt.

Von der Modell- zur Workflow-Souveränität

Damit schließt sich der Kreis. Architektur-Souveränität endet nicht beim Modell. Wer kritische Prozesse ernst nimmt, braucht auch Workflow-Souveränität: die Fähigkeit, einen laufenden Ablauf über Modellwechsel, Neustarts und Ausfälle hinweg am Leben zu halten. Das Modell wird austauschbar, der Prozess überlebt Ausfälle.

Kernaussagen dieses Beitrags

• Ein Gateway macht das Modell ersetzbar, nicht den laufenden Prozess.
• Nicht abgesicherte langlaufende Abläufe werden schnell zum nächsten Single Point of Failure.
• Durable execution bewahrt den Zustand und nimmt den Betrieb nach einem Ausfall wieder auf.
• Sie macht ein fehlendes Modell nicht verfügbar, aber sie verhindert den Totalausfall des Prozesses.
• Architektur-Souveränität endet nicht beim Modell, sie reicht bis zur Workflow-Souveränität.

Wie lange läuft Ihr längster KI-Prozess am Stück, und was bliebe davon übrig, wenn er mittendrin neu starten müsste?

Klarheit. Verantwortung. Umsetzung.