AWS-Step-Functions-Workflows werden über AgentCore Gateway zu KI-Agenten-Werkzeugen: Die Zustandsmaschine legt die Schrittfolge fest
Am 29. Oktober 2026 hat AWS angekündigt, dass sich Workflows von AWS Step Functions nun über Amazon Bedrock AgentCore Gateway als Werkzeuge für KI-Agenten nutzen lassen. Der Agent entscheidet, wann ein Workflow läuft und welche Eingabe er erhält, und Step Functions führt jeden Schritt genau wie definiert aus. Bestehende Standard- und Express-Workflows können als Werkzeuge dienen, und man zahlt die üblichen Preise für Step Functions und AgentCore Gateway.
Am 29. Oktober 2026 hat AWS angekündigt, dass sich Workflows von AWS Step Functions nun über Amazon Bedrock AgentCore Gateway als Werkzeuge für KI-Agenten nutzen lassen. Der Agent entscheidet, wann ein Workflow läuft und welche Eingabe er erhält, und Step Functions führt jeden Schritt genau wie definiert aus. Bestehende Standard- und Express-Workflows können als Werkzeuge dienen, und man zahlt die üblichen Preise für Step Functions und AgentCore Gateway.
Der Nutzen liegt in der Arbeitsteilung. AgentCore Gateway verbindet Agenten über das Model Context Protocol (MCP) mit Werkzeugen, und Step Functions führt mehrstufige Geschäftsprozesse in fester Reihenfolge aus. AWS’ Beispiel ist ein Kundensupport-Agent, der einen Erstattungs-Workflow startet, wobei Step Functions Berechtigungsprüfung, Freigabe durch eine Führungskraft und Gutschrift abarbeitet, sodass jede Erstattung der Richtlinie folgt. Ein Betriebs-Agent kann außerdem Workflow-Läufe nachschlagen und dem Bereitschaftsingenieur sagen, welche Bestellungen über Nacht fehlschlugen und bei welchem Schritt. Die Ankündigung nennt, Step Functions könne über 220 AWS-Dienste orchestrieren, eine Zahl von AWS selbst. Die Funktion ist in allen Regionen verfügbar, in denen AgentCore Gateway verfügbar ist.
Der Entwicklerleitfaden erklärt die Funktionsweise. Beim Anlegen eines Gateway-Ziels wählt man den eingebauten Step-Functions-Konnektor. Man schreibt keine Lambda-Funktion und keinen MCP-Server und definiert keine Werkzeuge selbst, denn das Gateway erzeugt die Werkzeugschemata und ruft Step Functions für den Agenten auf. Der Konnektor stellt zehn Operationen bereit. Vier wirken auf eine Zustandsmaschine, die man beim Anlegen des Ziels festnagelt: StartExecution, StartSyncExecution, ListExecutions und DescribeStateMachine. Der Agent sieht die festgelegte Zustandsmaschine nicht und kann sie nicht ändern; übergibt er stateMachineArn, lehnt das Gateway den Aufruf ab. Die anderen sechs wirken auf einen vom Agenten gelieferten Ausführungs-ARN oder Task-Token: DescribeExecution, StopExecution, GetExecutionHistory, SendTaskSuccess, SendTaskFailure und SendTaskHeartbeat. Sie sind nicht auf die festgelegte Zustandsmaschine beschränkt, daher begrenzt sie allein die IAM-Richtlinie der Dienstrolle des Gateways.
Die Berechtigungsgrenze verdient Aufmerksamkeit. Die Dokumentation rät, diese Richtlinie so eng wie möglich zu fassen, etwa DescribeExecution, StopExecution und GetExecutionHistory auf die Ausführungs-ARNs der bereitgestellten Zustandsmaschinen zu beschränken, statt states:* zu erteilen. Die drei SendTask-Operationen haben in IAM keine Berechtigungen auf Ressourcenebene und müssen auf „*“ gewährt werden; dann ist das Task-Token die einzige Kontrolle und sollte als Geheimnis behandelt werden. Wird eine festnagelbare Operation ohne stateMachineArn aufgenommen, kann das Gateway das Ziel zwar anlegen, aber das Werkzeug scheitert bei jedem Aufruf.
Die beiden Workflow-Typen unterstützen unterschiedliche Operationen. StartSyncExecution funktioniert nur mit Express und scheitert bei Standard. ListExecutions funktioniert nur mit Standard und liefert bei Express StateMachineTypeNotSupported. DescribeExecution, GetExecutionHistory und StopExecution funktionieren nur mit Standard-Ausführungen, weil sich Express-Ausführungen nach dem Start nicht per ARN ansprechen lassen. StartExecution, DescribeStateMachine und die SendTask-Operationen funktionieren mit beiden. Standard-Workflows halten jeden Schritt in einem Ausführungsverlauf fest und können bis zu einem Jahr laufen, was zu langen Prozessen mit Audit oder menschlicher Freigabe passt: Ein Workflow pausiert an .waitForTaskToken, reicht das Token an die Anwendung des Agenten, und der Agent ruft SendTaskSuccess oder SendTaskFailure auf, um ihn fortzusetzen. Express mit StartSyncExecution passt zu synchronem Anfrage-Antwort-Betrieb. „Beide“ bezieht sich hier auf Connector-Operationen; der .waitForTaskToken-Callback selbst ist nur mit Standard-Workflows möglich, nicht mit Express.
Das Tutorial nutzt eine Standard-Zustandsmaschine mit nur einem Pass-Zustand und setzt mit awscurl dieselben MCP-Aufrufe ab, die ein Agent machen würde. Alle Ressourcen müssen in derselben Region angelegt werden, weil das Gateway Step Functions in der eigenen Region aufruft, und die Tutorial-Ressourcen verursachen bis zum Löschen Kosten für Zustandsübergänge und Werkzeugaufrufe. Die AWS-Seiten nennen weder Latenz noch Umfang noch Kundenzahlen; es ist eine Funktionsbeschreibung, kein Leistungsbericht. Der praktische Nutzen hängt davon ab, ob Ihre Workflows schon gut definiert sind und wie eng Sie die Rolle des Gateways fassen.
Sources
FAQ
Was hat AWS angekündigt, und wer bestimmt die Reihenfolge der Schritte?
AWS hat angekündigt, dass Agenten Step-Functions-Workflows über AgentCore Gateway als MCP-Werkzeuge aufrufen können, sowohl Standard- als auch Express-Workflows. Der Agent entscheidet, wann ein Workflow läuft und welche Eingabe er erhält, die Zustandsmaschine bestimmt Schritte und Reihenfolge, sodass der Agent sie weder überspringen noch umordnen kann.
Wie begrenzt man, was der Agent tun kann?
Vier Operationen sind auf die gewählte Zustandsmaschine festgelegt, die der Agent weder sieht noch ändert, und das Gateway lehnt ein übergebenes stateMachineArn ab. Die anderen sechs begrenzt die IAM-Richtlinie der Dienstrolle des Gateways, die so eng wie möglich sein sollte, etwa ohne states:. SendTask-Operationen lassen sich nur auf „“ gewähren, daher sind Task-Token wie Geheimnisse zu behandeln.
Welche Operationen funktionieren mit Standard- und welche mit Express-Workflows?
StartExecution, DescribeStateMachine, SendTaskSuccess, SendTaskFailure und SendTaskHeartbeat sind Connector-Operationen für beide Typen. StartSyncExecution gilt nur für Express; ListExecutions, DescribeExecution, GetExecutionHistory und StopExecution nur für Standard-Ausführungen. Der .waitForTaskToken-Callback selbst ist dennoch nur mit Standard möglich, nicht mit Express.