Step Functions legt die Reihenfolge fest, nicht der Agent

Ein fester Workflow als Werkzeug lohnt sich, weil die Reihenfolge der Schritte dann im Workflow festliegt und nicht im Modell. Seit dem 29. Oktober lassen sich laut AWS Standard- und Express-Workflows von Step Functions über das Amazon Bedrock AgentCore Gateway für Agenten bereitstellen. Der Agent kann Ausführungen starten, beobachten und stoppen sowie Callbacks per Task-Token beantworten. Abgerechnet wird zu den regulären Preisen von Step Functions und Gateway, verfügbar ist die Funktion in allen Regionen mit AgentCore Gateway. Für Freigaben, Erstattungen oder Buchungen heißt das: Der Agent führt aus, die Policy bestimmt den Weg. Voraussetzung ist ein Betrieb auf AWS.

Was AWS am 29. Oktober freigeschaltet hat

Step Functions ist der Workflow-Dienst von AWS. Ein Ablauf wird dort als State Machine beschrieben, also als Folge von Zuständen mit festen Übergängen: prüfen, genehmigen, buchen, im Fehlerfall abbrechen. Die Ankündigung in AWS‘ What’s New vom 29. Oktober besagt, dass sich solche Workflows jetzt über das Amazon Bedrock AgentCore Gateway als Werkzeuge für KI-Agenten anbinden lassen, und zwar sowohl in der Standard- als auch in der Express-Variante.

Das Gateway ist die Schicht, über die Agenten auf Werkzeuge zugreifen. Laut den AgentCore Release Notes exponiert der neue, eingebaute Connector die State Machines als Werkzeuge im Model Context Protocol (MCP). MCP ist ein offener Schnittstellenstandard, über den Agenten Werkzeuge entdecken und aufrufen. Ein Agent sieht den Workflow also wie jedes andere Werkzeug, hinter dem Aufruf steckt aber ein Ablauf, den er nicht umbauen kann.

Das Beispiel, das AWS selbst nennt, ist ein Erstattungsprozess. Ein Agent im Kundendienst startet den Erstattungs-Workflow. Step Functions führt danach die Berechtigungsprüfung, die Freigabe durch eine Führungskraft und die Gutschrift aus, sodass laut AWS jede Erstattung der hinterlegten Richtlinie folgt. Der Agent entscheidet, ob er den Prozess anstößt, nicht, ob die Freigabe übersprungen wird.

Dazu kommt die lesende Seite. AWS beschreibt, dass Agenten Workflow-Läufe auch nachschlagen können. Ein Betriebsagent kann so einem Bereitschaftsdienst sagen, welche Aufträge über Nacht fehlgeschlagen sind und an welcher Stelle. Nach dm-Einschätzung dürfte das im Alltag der häufigere Fall sein, weil Statusfragen öfter anfallen als Prozessstarts.

Bemerkenswert ist die Voraussetzung. Laut AgentCore-Dokumentation lassen sich bestehende Standard- und Express-State-Machines bereitstellen, ohne sie zu ändern. Das Betriebsteam legt ein Gateway-Target an, hinterlegt die State Machine und vergibt die nötigen Rechte.

Die technische Vermittlung übernimmt laut AgentCore-Dokumentation das Gateway selbst: Es verwaltet die Werkzeugschemas, steuert die erlaubten Parameter, löst den Endpunkt auf und authentifiziert sich gegenüber Step Functions. Dabei ruft es den Step-Functions-Endpunkt in derselben Region auf, in der das Gateway läuft. Die Werkzeuge müssen Sie laut AWS nicht selbst definieren.

Zu Verfügbarkeit und Kosten sagt AWS zweierlei: Die Funktion ist in allen AWS-Regionen verfügbar, in denen es AgentCore Gateway gibt, und es gelten die Standardpreise von Step Functions und AgentCore Gateway. Eine Regionenliste und konkrete Beträge nennt die Ankündigung nicht. Laut AWS ist die Funktion damit allgemein verfügbar.

Zehn Operationen und wo sie festgenagelt sind

Der Connector trägt in der AgentCore-Dokumentation die connectorId „states“ und umfasst zehn Operationen. Entscheidend ist, wie sie sich in zwei Gruppen teilen: Vier sind an eine bestimmte State Machine gebunden, sechs beziehen sich auf eine konkrete Ausführung oder ein Task-Token. Diese Aufteilung ist das Rechtemodell des Ganzen, und wer sie nicht versteht, vergibt entweder zu viel oder zu wenig.

Gepinnt sind StartExecution, StartSyncExecution, ListExecutions und DescribeStateMachine. „Gepinnt“ heißt: Der Betreiber legt im Gateway-Target fest, welche State Machine gemeint ist. Der Agent sieht diese State Machine laut Dokumentation nicht und kann sie nicht ändern; das Gateway weist jeden Aufruf zurück, der es versucht. Der Agent kann also „starte den Erstattungsprozess“ auslösen, aber nicht „starte stattdessen einen anderen Workflow“.

Eine Einschränkung verdient Beachtung: Jede Operation nimmt pro Target genau einen Pin. Sollen mehrere State Machines für dieselbe Operation erreichbar sein, braucht es laut Dokumentation für jede ein eigenes Target. Das ist mehr Konfiguration, dafür bleibt jede Zuordnung eindeutig und prüfbar.

Auch die Unterschiede der Workflow-Typen schlagen durch. StartSyncExecution funktioniert nur mit Express-Workflows und schlägt bei einer Standard-State-Machine fehl. ListExecutions gibt es nur für Standard. Wer beide Typen im Einsatz hat, sollte deshalb nicht davon ausgehen, dass jede Operation für jede State Machine nutzbar ist, sondern pro Prozess festlegen, welche Operationen er freischaltet.

Die zweite Gruppe sind DescribeExecution, StopExecution, GetExecutionHistory, SendTaskSuccess, SendTaskFailure und SendTaskHeartbeat. Sie arbeiten mit einer Ausführungs-ARN (der eindeutigen Kennung eines Laufs bei AWS) oder mit einem Task-Token. Hier greift kein Pin, sondern die IAM-Richtlinie der Gateway-Service-Rolle. Laut Dokumentation lassen sich DescribeExecution, StopExecution und GetExecutionHistory begrenzen, indem man die Richtlinie auf die Ausführungs-ARNs der freigegebenen State Machines zuschneidet.

dm-Einordnung: Ohne diese Eingrenzung könnte ein Agent Läufe einsehen oder beenden, die mit seinem Auftrag nichts zu tun haben. StopExecution ist das schärfere Werkzeug, denn es bricht einen laufenden Prozess ab. Ob das Teil des Agentenauftrags sein soll, ist eine fachliche Entscheidung, die vor der Konfiguration fallen muss. Wer einen Prozess nur beobachten lassen will, vergibt die Beschreibungsrechte und lässt den Rest weg.

AWS betont ausdrücklich, dass Pinning und IAM sich ergänzen und keine Alternativen sind. Das Pinning legt fest, welche State Machine ein Startaufruf trifft. IAM legt fest, welche Läufe der Agent danach einsehen oder anhalten darf. Wer sich auf eine der beiden Kontrollen verlässt, hat ein Loch in der anderen.

Das eigentliche Argument für das Muster steht ebenfalls in der Dokumentation: Die State Machine entscheidet, welche Schritte in welcher Reihenfolge laufen, der Agent kann sie weder überspringen noch umsortieren. AWS nennt das hilfreich, wenn ein Prozess einer genehmigten Abfolge folgen muss oder wenn für Prüfzwecke ein Nachweis jedes Schritts nötig ist. Bei Standard-Workflows steht dieser Nachweis in der Ausführungshistorie, die sich über GetExecutionHistory abrufen lässt.

Callbacks und Task-Tokens: Wenn der Agent mitten im Ablauf gebraucht wird

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptEngineering team in a modern office looking at a large whiteboard with an abstract flowchart of boxes and arrows, one person pointing at a step in the sequence, daylight. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Nicht jeder Schritt lässt sich automatisch erledigen. Manchmal soll der Agent eine Teilaufgabe übernehmen, etwa Unterlagen zusammentragen oder eine Rückfrage klären, und der Workflow wartet auf das Ergebnis. Dafür gibt es das Callback-Muster, das nur mit Standard-Workflows funktioniert. Express-Workflows unterstützen es laut AWS nicht.

Der Ablauf, wie ihn die Dokumentation beschreibt: Ein Task der State Machine nutzt das Muster .waitForTaskToken, und Step Functions erzeugt ein Task-Token. Der Workflow muss dieses Token samt Aufgabenbeschreibung an die Anwendung des Agenten liefern, zum Beispiel über eine Amazon-SQS-Warteschlange oder über eine Activity, die die Anwendung abfragt. Der Agent erledigt die Arbeit und meldet das Ergebnis mit SendTaskSuccess zurück, bei Misserfolg mit SendTaskFailure. Bei langen Aufgaben signalisiert er mit SendTaskHeartbeat, dass er noch arbeitet.

Der Zweck dieser Konstruktion ist die Trennung der Zuständigkeiten. Der Workflow bleibt Herr des Ablaufs, der Agent bekommt eine klar umrissene Aufgabe und liefert ein Ergebnis zurück. Er entscheidet nicht, was danach passiert. Das passt zu Prozessen, in denen ein Zwischenschritt Urteilsvermögen oder Textarbeit verlangt, der Rest aber verbindlich bleiben soll.

Dazu kommt die Laufzeit. Standard-Workflows können laut Dokumentation bis zu einem Jahr laufen und führen eine Ausführungshistorie. Arbeit kann deshalb weitergehen, nachdem die Sitzung des Agenten längst beendet ist. Ein Freigabeprozess, der auf die Antwort einer Führungskraft wartet, braucht damit keinen Agenten, der tagelang offen bleibt. Das Warten übernimmt der Workflow.

Das Rechteproblem steckt im Detail der Rückmeldung. Laut Dokumentation lassen sich SendTaskSuccess, SendTaskFailure und SendTaskHeartbeat per IAM nicht auf bestimmte Ausführungen einschränken. Daraus folgt der Satz, den AWS ausdrücklich aufschreibt: Jeder Agent mit einem gültigen Task-Token kann diese Aufgabe abschließen. Task-Tokens sind deshalb wie Geheimnisse zu behandeln und nur an den Agenten zu senden, der darauf reagieren soll.

Was das praktisch bedeutet, ist eine dm-Einordnung und keine Angabe von AWS: Das Token gehört in den Kanal, den nur der zuständige Agent lesen kann, also nicht in gemeinsam genutzte Logs, nicht in Chatverläufe und nicht in Warteschlangen, auf die mehrere Anwendungen Zugriff haben. Wer eine SQS-Queue als Zustellweg wählt, sollte ihre Zugriffsrechte so eng fassen wie die der Gateway-Rolle. Ein Token, das im falschen Postfach landet, ist ein Schlüssel zur Freigabe.

Besonders heikel ist das bei Prozessen mit Folgen. Wenn ein Task die Genehmigung eines Zahlungsvorgangs bedeutet, kann ein Agent mit fremdem Token ihn abschließen, ohne dass die IAM-Richtlinie das verhindert. Der Schutz muss deshalb außerhalb von IAM entstehen: durch Zustellwege, Rechte auf der Queue und dadurch, dass sensible Freigaben gar nicht über Agenten-Callbacks laufen. Wer das nicht will, lässt kritische Freigaben von Menschen in einem eigenen Schritt erledigen und gibt dem Agenten nur das Starten und Beobachten.

Wann ein fester Ablauf die bessere Wahl ist

Die Entscheidung folgt einer einfachen Frage: Darf das Ergebnis davon abhängen, ob das Modell an diesem Tag die richtige Reihenfolge wählt? Bei Freigaben, Compliance-Prüfungen und Erstattungen lautet die Antwort in aller Regel nein. Dort ist die Abfolge selbst die Vorgabe, und ein Agent, der sie frei plant, ist an dieser Stelle ein Risiko. Das ist eine dm-Einordnung, die sich auf die Begründung von AWS stützt: Wenn ein Prozess einer genehmigten Abfolge folgen muss, überspringt oder vertauscht der Workflow keine Schritte.

Freie Planung hat ihre Stärke dort, wo die Schritte vorher nicht feststehen, etwa bei Recherche, Entwurfsarbeit oder Fehlersuche in unbekannten Systemen. Die Mischform ist oft die sinnvollste: Der Agent plant frei, was nicht festgelegt sein muss, und ruft für alles Verbindliche einen Workflow auf. Das Gateway macht daraus ein einheitliches Werkzeugangebot.

Ein zweiter Vorteil ist die Nachvollziehbarkeit. Standard-Workflows halten laut Dokumentation eine Ausführungshistorie vor, die jeden Schritt festhält. Wer einem Prüfer erklären muss, warum eine Erstattung genehmigt wurde, kann auf eine Abfolge verweisen, statt Modellprotokolle zu deuten. Ob die Historie für eine bestimmte Auflage genügt, entscheidet am Ende die Prüfung im Einzelfall, und eine Garantie gibt AWS dafür nicht.

Wer bereits mit der Orchestrierung mehrstufiger Abläufe in Bedrock Agents arbeitet, kann den neuen Weg als Ergänzung für die verbindlichen Teile betrachten. Und weil ein fester Ablauf nur die Reihenfolge begrenzt, nicht die Zahl der Aufrufe, bleiben Budgetgrenzen und ein Kill Switch für Agenten auch hier nötig. Ein Agent, der einen Erstattungsworkflow tausendmal startet, hält sich an jede Regel und richtet trotzdem Schaden an.

Die erste Grenze ist die Bindung an AWS. Der Connector funktioniert nur mit Step Functions und AgentCore Gateway. Wer Workflows in einem anderen Orchestrator pflegt, hat davon nichts. Als dm-Einordnung gilt: Wer seine Prozesse jetzt in State Machines gießt, vertieft die Abhängigkeit von einem Anbieter. Die MCP-Schnittstelle zum Agenten ist offen, die Workflow-Definition dahinter ist es nicht.

Die zweite Grenze sind die Kosten. AWS nennt keine Preise für die Kombination, sondern verweist auf die Standardpreise von Step Functions und von AgentCore Gateway. Es laufen also zwei Abrechnungen nebeneinander, dazu kommen die Kosten des Agenten selbst und gegebenenfalls Dienste wie SQS für die Zustellung von Task-Tokens. Sinnvoll ist ein Pilot mit einem Prozess, dessen Aufrufzahl man kennt, und der Vergleich der Rechnung mit dem bisherigen Aufwand.

Dazu kommt die Konfigurationsarbeit. Pro Operation und State Machine ein Target, eine sauber zugeschnittene IAM-Richtlinie für die Gateway-Service-Rolle, ein geschützter Zustellweg für Tokens: Diese Betriebsarbeit fällt vor dem ersten Agentenlauf an und lohnt sich nach dm-Einschätzung nur für Prozesse, die ohnehin feststehen.