Ce que la plupart des gens appellent un agent est une séquence fixe d'étapes avec un ou deux appels de modèle au milieu. Le flux de contrôle est connaissable à l'avance, mais les équipes le confient quand même au modèle, puis passent des semaines à faire se comporter correctement une boucle non déterministe. Quand la forme du travail est connue, l'orchestrateur devrait être déterministe, et AWS Step Functions convient mieux à ce travail qu'une boucle d'agent codée à la main. Il résout déjà les retries, les timeouts, la gestion d'erreurs, le parallélisme et l'approbation humaine, exactement les choses qu'un framework d'agent vous demande de réimplémenter.

Le recadrage à intérioriser : laissez le modèle prendre des décisions, pas la plomberie. Utilisez le modèle pour les étapes qui exigent réellement du jugement, extraire, classer, rédiger, et laissez une machine à états décider quoi s'exécute, dans quel ordre, et ce qui se passe quand une étape échoue. Vous n'avez pas besoin d'un LLM pour savoir que l'étape trois suit l'étape deux.

L'orchestration déterministe est une fonctionnalité, pas une limitation

Une boucle d'agent maison met le modèle aux commandes du flux de contrôle : il décide quel outil appeler, lit le résultat, décide de l'outil suivant, et ainsi de suite jusqu'à ce qu'il pense avoir terminé. C'est la bonne conception quand le chemin est vraiment inconnu au moment de l'écriture. C'est la mauvaise conception quand le chemin est un workflow que vous pourriez dessiner sur un tableau blanc, parce qu'à ce moment-là chaque exécution peut prendre un itinéraire différent, les retries sont improvisés, et un échec à mi-parcours laisse un état que vous devez reconstruire.

Step Functions inverse ça. Vous déclarez les états et les transitions. Chaque état qui a besoin de jugement invoque Bedrock (directement ou via une Lambda) ; chaque état qui n'en a pas besoin est de la logique simple. L'exécution est reproductible, chaque transition est journalisée, et l'historique d'exécution est une piste d'audit intégrée. Pour un workflow de forme connue, le déterminisme est exactement ce que vous voulez.

Des retries et une gestion d'erreurs que vous n'écrivez pas

La majorité peu glamour du travail de fiabilité d'un agent, c'est la politique de retry. Un appel de modèle throttle, un outil timeout, une API en aval renvoie un 500 transitoire. Dans une boucle maison, vous écrivez le backoff, le jitter et la gestion par type d'erreur à la main, et vous vous trompez généralement d'une manière subtile.

Step Functions rend ça déclaratif. Chaque état porte son propre comportement de retry et de catch :

"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"
  }]
}

Le throttling reçoit un backoff exponentiel, tout le reste est routé vers un état d'échec que vous contrôlez. Pas de code de retry, pas d'exceptions perdues, et le comportement est visible dans la définition au lieu d'être enterré dans une boucle.

L'humain dans la boucle est un état de première classe

L'endroit où les agents faits maison souffrent le plus, c'est la pause pour un humain. Un agent qui peut dépenser de l'argent, envoyer un email ou changer la production devrait s'arrêter et attendre une approbation, et faire ça dans un processus longue durée signifie conserver un état quelque part pendant qu'une personne prend des heures ou des jours pour répondre.

Step Functions a ça intégré via le pattern de callback. Une tâche démarrée avec .waitForTaskToken met l'exécution en pause, émet un token, et ne fait rien jusqu'à ce que quelque chose appelle SendTaskSuccess ou SendTaskFailure avec ce token. Le workflow peut rester en pause aussi longtemps que l'approbation le nécessite sans qu'aucun processus ne tourne, puis reprendre exactement là où il s'était arrêté. Vous obtenez une barrière humaine durable et auditable sans construire vous-même une file, un stockage d'état et un mécanisme de reprise.

Quand vous voulez encore une vraie boucle d'agent

Ce n'est pas un argument contre les boucles d'agent, c'est un argument pour les utiliser là où elles méritent leur place. Optez pour une boucle pilotée par modèle quand le chemin est vraiment ouvert : le modèle doit décider, à l'exécution, lequel parmi de nombreux outils utiliser et dans quel ordre, et aucun graphe fixe ne le capture. La recherche ouverte, le débogage libre et les tâches où l'étape suivante dépend de ce que la dernière étape a renvoyé d'une manière que vous ne pouvez pas énumérer sont le vrai domaine de la boucle d'agent.

Le piège, c'est d'utiliser ce pattern pour un pipeline de cinq étapes avec une seule branche. Si vous pouvez dessiner l'organigramme, encodez l'organigramme. Réservez la boucle non déterministe au travail qui est réellement non déterministe.

À retenir

Une grande part du travail d'agent en production est de l'orchestration déterministe déguisée en agent. Pour ce travail, Step Functions vous donne des retries, un routage d'erreurs, du parallélisme et un état d'approbation humaine durable que vous devriez sinon construire et maintenir à la main, plus un historique d'exécution qui fait aussi office de journal d'audit. Laissez le modèle faire les appels qui demandent du jugement, et laissez une machine à états posséder le flux de contrôle. L'agent le plus fiable est souvent celui où le modèle décide le moins.

À lire ensuite

Pour la lecture infrastructure et plateforme du même pattern, y compris les portes d'approbation sur les opérations à haut risque, les notes de terrain cloud vivent sur ercan.cloud, et le hub est sur ercanermis.com.