Les flux AWS Step Functions deviennent des outils d’agents d’IA via AgentCore Gateway : la machine d’états fixe l’ordre des étapes

Le 29 octobre 2026, AWS a annoncé que les flux de travail d’AWS Step Functions peuvent désormais servir d’outils aux agents d’IA via Amazon Bedrock AgentCore Gateway. L’agent décide quand lancer un flux et quelle entrée lui passer, et Step Functions exécute chaque étape exactement comme définie. Les flux Standard et Express existants peuvent servir d’outils, et l’on paie les tarifs habituels de Step Functions et d’AgentCore Gateway.

L’intérêt tient à la répartition des rôles. AgentCore Gateway relie les agents aux outils par le Model Context Protocol (MCP), et Step Functions exécute les processus métier à plusieurs étapes dans un ordre fixe. L’exemple d’AWS est un agent de support client qui lance un flux de remboursement, où Step Functions enchaîne la vérification d’éligibilité, l’approbation d’un responsable et le crédit, de sorte que chaque remboursement suit la politique. Un agent d’exploitation peut aussi consulter les exécutions et dire à l’ingénieur d’astreinte quelles commandes ont échoué dans la nuit et à quelle étape. L’annonce indique que Step Functions peut orchestrer plus de 220 services AWS, un chiffre d’AWS lui-même. La fonction est disponible dans toutes les Régions où AgentCore Gateway l’est.

Le guide du développeur explique le fonctionnement. En créant une cible de passerelle, on choisit le connecteur Step Functions intégré. Il n’y a ni fonction Lambda ni serveur MCP à écrire, ni outils à définir soi-même : la passerelle crée les schémas d’outils et appelle Step Functions pour l’agent. Le connecteur expose dix opérations. Quatre agissent sur une machine d’états que l’on épingle à la création de la cible : StartExecution, StartSyncExecution, ListExecutions et DescribeStateMachine. L’agent ne voit pas la machine d’états épinglée et ne peut pas la changer ; s’il transmet stateMachineArn, la passerelle rejette l’appel. Les six autres agissent sur un ARN d’exécution ou un jeton de tâche fourni par l’agent : DescribeExecution, StopExecution, GetExecutionHistory, SendTaskSuccess, SendTaskFailure et SendTaskHeartbeat. Elles ne sont pas limitées à la machine d’états épinglée, si bien que seule la politique IAM du rôle de service de la passerelle les encadre.

La frontière des droits mérite l’attention. La documentation conseille de restreindre cette politique autant que possible, par exemple en limitant DescribeExecution, StopExecution et GetExecutionHistory aux ARN d’exécution des machines d’états exposées, au lieu d’accorder states:*. Les trois opérations SendTask n’ont pas de droits au niveau de la ressource dans IAM et doivent être accordées sur « * » ; le jeton de tâche est alors le seul contrôle, et il faut le traiter comme un secret. Si une opération épinglable est incluse sans stateMachineArn, la passerelle peut créer la cible, mais l’outil échoue à chaque appel.

Les deux types de flux n’acceptent pas les mêmes opérations. StartSyncExecution ne fonctionne qu’avec Express et échoue sur Standard. ListExecutions ne fonctionne qu’avec Standard et renvoie StateMachineTypeNotSupported sur Express. DescribeExecution, GetExecutionHistory et StopExecution ne fonctionnent qu’avec les exécutions Standard, car une exécution Express ne peut plus être adressée par ARN une fois démarrée. StartExecution, DescribeStateMachine et les opérations SendTask fonctionnent avec les deux. Les flux Standard consignent chaque étape dans un historique d’exécution et peuvent durer jusqu’à un an, ce qui convient aux longs processus soumis à audit ou à validation humaine : un flux se met en pause sur .waitForTaskToken, remet le jeton à l’application de l’agent, et l’agent appelle SendTaskSuccess ou SendTaskFailure pour le reprendre. Express avec StartSyncExecution convient à une requête et une réponse synchrones. Ici, « les deux » décrit les opérations du connecteur ; le rappel .waitForTaskToken lui-même exige un flux Standard et n’est pas pris en charge par Express.

Le tutoriel utilise une machine d’états Standard avec un seul état Pass et passe les mêmes appels MCP que le ferait un agent, avec awscurl. Toutes les ressources doivent être créées dans la même Région, car la passerelle appelle Step Functions dans sa propre Région, et les ressources du tutoriel entraînent des frais de transitions d’état et d’appels d’outils jusqu’à leur suppression. Les pages d’AWS ne donnent ni latence, ni échelle, ni chiffres de clients : c’est une description de capacité, pas un rapport de performance. Son intérêt pratique dépend de la qualité de définition de vos flux et de la rigueur avec laquelle vous restreignez le rôle de la passerelle.