La reprenabilité des agents expliquée : sessions, tours, pauses et reconnexions dans TrueForge

La reprise d'un agent n'est pas une opération unique. Les systèmes de production doivent distinguer la reconnexion d'un flux, la poursuite d'un flux de travail en pause et la récupération d'un effet secondaire externe incertain.

« Reprendre » dissimule trois problèmes de récupération distincts

Les agents à exécution longue échouent à plus d'endroits qu'une API requête-réponse classique. Un navigateur peut se déconnecter alors que le serveur continue de travailler. Un flux de travail peut s'arrêter intentionnellement parce qu'une personne, un outil côté client ou un flux OAuth doit fournir une entrée. Une API en aval peut expirer après avoir validé une mutation. Ces trois situations peuvent être décrites comme une « reprise », mais elles nécessitent des états, des preuves et des règles de sécurité différents.

Le premier est la récupération du transport : se reconnecter à un flux toujours actif sans dupliquer les événements. Le second est la poursuite du flux de travail : créer une nouvelle unité de travail qui répond à une pause enregistrée. Le troisième est la récupération des effets : établir si une opération externe a été validée avant de décider s'il faut réessayer, compenser ou arrêter. Traiter ces points comme un mécanisme unique crée le type de bug de fiabilité le plus dangereux : celui qui semble réussir tout en répétant ou en ignorant une action réelle.

Les trois branches aboutissent délibérément à des actions différentes. Une séquence de flux répare l'observation, une référence d'action requise poursuit le flux de travail, et un identifiant d'opération prend en charge le rapprochement ; substituer un identifiant par un autre crée des doublons ou une fausse exécution.

Commencez par la hiérarchie TrueForge

TrueForge documente une hiérarchie Agent → Session → Tour → Événement → Delta. Un agent est une définition réutilisable. Une session représente un problème ou une conversation et persiste au fil des tours. Un tour est un cycle de requête et d'exécution qui s'exécute jusqu'à sa fin ou sa mise en pause. Les événements décrivent ce qui s'est passé pendant ce tour. Certains événements de message produisent des deltas lors de la diffusion en continu ; les listes d'événements persistants renvoient l'événement fusionné plutôt que chaque fragment en direct.

Cette hiérarchie est importante car chaque couche répond à une question de récupération différente. La définition de l'agent établit le modèle configuré, les instructions, les outils et les limites. La session assure une continuité conversationnelle durable. Le tour fournit une limite d'exécution avec un état terminal. Les événements exposent les preuves ordonnées nécessaires pour reconstruire une vue client. Les deltas optimisent l'expérience en direct mais ne sont pas des faits commerciaux durables distincts.

TrueForge n'autorise qu'un seul tour à s'exécuter à la fois dans une session. Les tours s'enchaînent automatiquement, de sorte que l'application n'a pas besoin de renvoyer l'historique complet à chaque requête. Créer un nouveau tour alors qu'un autre est en cours annule le tour actif. Ce comportement est utile, mais cela signifie qu'une interface utilisateur ne doit pas traduire chaque clic impatient en un nouveau tour sans une décision produit explicite.

La reconnexion du transport n'est pas la poursuite du flux de travail

Un tour en direct utilise un flux d'événements envoyés par le serveur (Server-Sent Events). Chaque élément diffusé porte un identifiant de séquence que le client peut conserver. Si la connexion est interrompue, le client peut se réabonner après le dernier numéro de séquence traité. Le serveur peut alors rejouer les événements ultérieurs du même tour en cours. Un client correct stocke les événements par ID d'événement et fusionne les deltas dans leur événement de message de base, de sorte que la retransmission ne duplique pas la sortie visible.

C'est ce qu'on appelle la reconnexion du transport. Le tour original n'a pas été mis en pause pour une décision commerciale ; seule la connexion réseau a été interrompue. Le serveur peut continuer à s'exécuter pendant que le client est absent. Une interface utilisateur qui se reconnecte demande donc : « Quels événements de ce tour existant n'ai-je pas rendus ? » Elle ne doit pas créer un autre tour ni réémettre l'instruction utilisateur originale.

Une fois qu'un tour est terminé, ses événements persistants peuvent être lus à nouveau pour reconstruire l'historique établi. Il s'agit d'une relecture de preuves, et non d'une réexécution du modèle et des outils. La distinction est importante pour l'analyse des incidents : la même séquence stockée devrait produire la même vue reconstruite, mais une tentative d'exécuter à nouveau la tâche peut rencontrer des modèles, des outils, des identifiants et un état externe différents.

La figure sépare la hiérarchie durable des mécanismes de livraison. Les deltas appartiennent au flux en direct et sont fusionnés dans les événements de base, tandis que les sessions, les tours enchaînés, les états terminaux et les événements persistants fournissent l'enregistrement établi utilisé après une reconnexion ou un redémarrage.

Les pauses sont des états d'exécution explicites

Un tour peut se terminer par des actions requises plutôt que par une réponse finale. TrueForge documente trois cas importants : un outil verrouillé nécessite une approbation, un outil côté client nécessite une réponse, ou un serveur MCP nécessite une autorisation. L'état final du tour identifie les éléments en attente. L'application les traite en créant un nouveau tour contenant l'approbation, la réponse à l'outil ou la suite de l'authentification correspondante.

Il s'agit d'une poursuite de flux de travail, et non d'une reconnexion de flux. Le tour en pause est déjà validé. Le tour suivant préserve la continuité causale en faisant référence à l'action en attente et en s'enchaînant à l'historique de la session. Un seul tour peut faire apparaître plusieurs éléments en attente, y compris des pauses provenant de fils d'exécution d'agents parallèles ; les clients doivent donc collecter l'ensemble complet des actions requises au lieu de supposer qu'il n'y en a qu'une seule.

Pour les pauses liées à une approbation ou à une réponse, l'événement source lie l'élément en attente au message du modèle qui a proposé l'appel d'outil. Ce lien permet à l'application de montrer au réviseur le nom de l'outil et les arguments qui ont créé le point de contrôle. Il sert également de base pour vérifier que la suite répond bien à l'appel prévu et non à un appel visuellement similaire.

Établir un contrat de reprenabilité

‍