Das meiste, was Leute einen Agenten nennen, ist eine feste Abfolge von Schritten mit ein oder zwei Modellaufrufen in der Mitte. Der Kontrollfluss ist im Voraus bekannt, aber Teams übergeben ihn trotzdem dem Modell und verbringen dann Wochen damit, eine nicht-deterministische Schleife zum gewünschten Verhalten zu bringen. Wenn die Form der Arbeit bekannt ist, sollte der Orchestrator deterministisch sein, und AWS Step Functions passt für diese Aufgabe besser als eine selbstgebaute Agent-Schleife. Es löst bereits Retries, Timeouts, Fehlerbehandlung, Parallelität und menschliche Freigabe, genau die Dinge, die ein Agent-Framework einen bitten, neu zu implementieren.

Die Umdeutung, die sich lohnt zu verinnerlichen: Das Modell soll Entscheidungen treffen, nicht die Verrohrung. Das Modell für die Schritte einsetzen, die wirklich Urteilsvermögen brauchen, Extrahieren, Klassifizieren, Entwerfen, und eine State Machine entscheiden lassen, was in welcher Reihenfolge läuft und was passiert, wenn ein Schritt fehlschlägt. Man braucht kein LLM, um zu wissen, dass Schritt drei auf Schritt zwei folgt.

Deterministische Orchestrierung ist ein Feature, keine Einschränkung

Eine selbstgebaute Agent-Schleife stellt das Modell an die Spitze des Kontrollflusses: Es entscheidet, welches Tool aufgerufen wird, liest das Ergebnis, entscheidet das nächste Tool, und so weiter, bis es denkt, fertig zu sein. Das ist das richtige Design, wenn der Pfad zur Autorenzeit wirklich unbekannt ist. Es ist das falsche Design, wenn der Pfad ein Workflow ist, den man auf ein Whiteboard zeichnen könnte, denn jetzt kann jeder Lauf einen anderen Weg nehmen, Retries sind Ad-hoc, und ein Fehler auf halber Strecke hinterlässt einen Zustand, den man rekonstruieren muss.

Step Functions kehrt das um. Man deklariert die States und Übergänge. Jeder State, der Urteilsvermögen braucht, ruft Bedrock auf (direkt oder über eine Lambda), jeder State, der das nicht braucht, ist einfache Logik. Der Lauf ist reproduzierbar, jeder Übergang wird geloggt, und die Execution History ist eine eingebaute Audit-Spur. Für einen Workflow mit bekannter Form ist Determinismus genau das, was man will.

Retries und Fehlerbehandlung, die man nicht selbst schreibt

Der unglamouröse Großteil der Arbeit an Agent-Zuverlässigkeit ist Retry-Policy. Ein Modellaufruf drosselt, ein Tool läuft in ein Timeout, eine nachgelagerte API liefert einen vorübergehenden 500er. In einer selbstgebauten Schleife schreibt man Backoff, Jitter und Fehlerbehandlung pro Fehlertyp von Hand, und meist macht man dabei einen subtilen Fehler.

Step Functions macht das deklarativ. Jeder State trägt sein eigenes Retry- und Catch-Verhalten:

"InvokeModel": {
  "Type": "Task",
  "Resource": "arn:aws:states:::bedrock:invokeModel",
  "Retry": [{
    "ErrorEquals": ["Bedrock.ThrottlingException"],
    "IntervalSeconds": 2,
    "BackoffRate": 2.0,
    "MaxAttempts": 5
  }],
  "Catch": [{
    "ErrorEquals": ["States.ALL"],
    "Next": "HandleFailure"
  }]
}

Throttling bekommt exponentiellen Backoff, alles andere routet in einen Failure-State, den man selbst kontrolliert. Kein Retry-Code, keine verlorenen Exceptions, und das Verhalten ist in der Definition sichtbar statt in einer Schleife vergraben.

Human-in-the-Loop ist ein State erster Klasse

Die Stelle, an der selbstgebaute Agenten am meisten wehtun, ist das Pausieren für einen Menschen. Ein Agent, der Geld ausgeben, E-Mails senden oder Produktion ändern kann, sollte anhalten und auf Freigabe warten, und das in einem langlaufenden Prozess zu tun bedeutet, irgendwo Zustand zu halten, während eine Person Stunden oder Tage zum Antworten braucht.

Step Functions hat das über das Callback-Pattern eingebaut. Ein mit .waitForTaskToken gestarteter Task pausiert die Ausführung, gibt einen Token aus und tut nichts, bis etwas mit diesem Token SendTaskSuccess oder SendTaskFailure aufruft. Der Workflow kann so lange pausiert bleiben, wie die Freigabe braucht, ohne dass ein Prozess läuft, und dann genau dort weitermachen, wo er aufgehört hat. Man bekommt ein dauerhaftes, auditierbares menschliches Gate, ohne selbst eine Queue, einen State-Store und einen Resume-Mechanismus zu bauen.

Wenn man trotzdem eine echte Agent-Schleife will

Das ist kein Argument gegen Agent-Schleifen, sondern ein Argument dafür, sie dort einzusetzen, wo sie sich lohnen. Eine modellgetriebene Schleife greift, wenn der Pfad wirklich offen ist: Das Modell muss zur Laufzeit entscheiden, welches von vielen Tools in welcher Reihenfolge genutzt wird, und kein fester Graph erfasst das. Offene Recherche, freies Debugging und Aufgaben, bei denen der nächste Schritt auf eine Weise vom letzten Ergebnis abhängt, die man nicht aufzählen kann, sind das eigentliche Zuhause der Agent-Schleife.

Die Falle ist, dieses Muster für eine Fünf-Schritte-Pipeline mit einer Verzweigung einzusetzen. Wenn man das Flussdiagramm zeichnen kann, sollte man das Flussdiagramm kodieren. Die nicht-deterministische Schleife für die Arbeit aufheben, die tatsächlich nicht-deterministisch ist.

Fazit

Ein großer Teil der Agent-Arbeit in Produktion ist deterministische Orchestrierung im Agent-Kostüm. Für diese Arbeit liefert Step Functions Retries, Fehler-Routing, Parallelität und einen dauerhaften Freigabe-State für Menschen, den man sonst von Hand bauen und pflegen müsste, plus eine Execution History, die zugleich als Audit-Log dient. Das Modell soll die Aufrufe treffen, die Urteilsvermögen brauchen, und eine State Machine soll den Kontrollfluss besitzen. Der zuverlässigste Agent ist oft der, bei dem das Modell am wenigsten entscheidet.

Weiterlesen

Für die Infrastruktur- und Plattformlesart desselben Musters, inklusive Freigabe-Gates für risikoreiche Operationen, gibt es die Cloud-Field-Notes auf ercan.cloud, und den Hub auf ercanermis.com.