Les boucles agentiques ne sont que des machines à états

Le premier agent que j'ai livré en production bouclait indéfiniment. L'utilisateur posait une question, l'agent raisonnait, appelait un outil de recherche, recevait des résultats pas tout à fait pertinents, raisonnait à nouveau, rappelait le même outil avec une formulation légèrement différente, recevait les mêmes résultats. En boucle. Aucun état terminal. Le modèle aurait raisonné tranquillement jusqu'à la fin des temps si on n'avait pas tué le processus.

La correction tenait en trois lignes : un compteur max_iterations et une transition done explicite quand la confiance dépassait un seuil. À partir de là, j'ai arrêté de penser aux agents comme à des systèmes qui « réfléchissent », et j'ai commencé à les penser comme des machines à états.

ReAct, c'est observer, raisonner, agir, observer

Le pattern ReAct (observer, raisonner, agir, observer) est présenté dans les papiers comme un paradigme nouveau. Il ne l'est pas. C'est une machine à états finis à quatre états, avec une boucle sur elle-même et une transition terminale. Les états sont le paquet que vous appelez votre contexte courant : system prompt, mémoire accumulée, scratchpad, dernier résultat d'outil. Les transitions sont les réponses du LLM et les appels d'outils. L'état terminal est la condition que vous avez définie : un outil finish, un plafond d'itérations, une regex sur la sortie.

C'est tout le pattern. Une fois qu'on l'accepte, l'« agent » cesse d'être mystique et devient ingéniérié.

Pourquoi ce recadrage compte

Les évaluations deviennent traitables. Dès qu'il y a des états et des transitions, on peut énumérer les chemins et asserter des invariants. Après une transition search, l'état suivant doit contenir une citation. Après un tool_error, l'état suivant ne doit pas rappeler le même outil avec les mêmes arguments. Ce sont des propriétés testables, pas des intuitions à éprouver à la main.

Le débogage cesse d'être de l'archéologie. Quand un run dérape, on logue la transition qui a rompu le contrat, pas l'historique entier de la conversation. La trace devient une séquence de changements d'état, plus un mur de texte.

Le travail de fiabilité a un vocabulaire. Transitions idempotentes. Gardes terminales. Récupération d'états morts. Ce sont des problèmes FSM classiques avec des solutions FSM classiques. La littérature des agents en réinvente la moitié sous d'autres noms.

Implication pratique

Arrêtez d'écrire du code qui « réfléchit ». Construisez des machines à états qui émettent du raisonnement en effet de bord.

C'est le cadrage « réflexion » qui a fait que mon premier agent a bouclé sans fin. J'avais écrit une fonction qui appelait le modèle, parsait la sortie, et décidait de continuer en fonction de ce que le modèle disait. Pas d'état, juste une conversation. Le modèle était parfaitement content de rester conversationnel à l'infini.

Le cadrage FSM oblige à poser les bonnes questions dès le départ. Quels sont les états ? Quelles transitions existent entre eux ? Quel est l'état terminal ? Quelles transitions sont atteignables depuis quels états ? Quand on ne sait pas y répondre, on n'a pas conçu un système. On a écrit un while True.

La prochaine fois que quelqu'un vous dit que son agent « décide » quelque chose, demandez-lui de dessiner la FSM. S'il n'y arrive pas, l'agent ne décide rien. Il transite, mal.