Habr AI explique comment construire un agent de production avec état durable, étapes et événements

Pour qu'un agent IA vive correctement en production, il ne suffit pas de tout garder dans la mémoire du processus : après un redémarrage, il doit se rappeler ce que l'utilisateur a demandé exactement, quel plan avait déjà été construit, quels outils ont tourné et où l'exécution s'est arrêtée. Dans la première partie d'une nouvelle analyse pratique sur Habr AI, l'auteur propose de bâtir cet état durable autour de trois entités de base (un tour, une étape et un événement) et montre pourquoi, sans elles, les scénarios d'agents longs se transforment vite en pipeline opaque et fragile.

Le point de départ est simple : si l'agent ne conserve son état qu'en mémoire, toute panne du service remet la tâche à zéro. C'est tolérable pour une démo, mais un agent de production peut analyser des documents, attendre la confirmation de l'utilisateur et exécuter une longue chaîne d'actions ; après une panne, il doit donc se rétablir à partir de la base de données, et non à partir de bribes de prompt. Comme jeu minimal d'entités persistantes, l'auteur cite AgentTurn, AgentPlanItem et AgentEvent, et rappelle que ApprovalGrant, SessionContext et BackgroundJob apparaissent presque inévitablement à leurs côtés.

L'idée est que l'état durable décrive non seulement la réponse finale, mais tout le chemin qui y mène : la requête initiale, la commande normalisée, les indicateurs de confirmation, les statuts d'exécution et l'éventuelle erreur.

Dans ce schéma, AgentTurn est l'enregistrement complet d'un tour utilisateur. Il stocke l'identifiant de session et le turn_id, le texte du message, la commande normalisée et un statut de traitement tel que created, planned, awaiting_approval, running, completed ou failed. Point important : le tour consigne aussi l'output_text final et l'error si l'exécution a échoué.

On supprime ainsi une dépendance critique à la « mémoire » du modèle : le backend peut comprendre à tout moment ce qui est arrivé à la requête, même si le processus a redémarré. Pour les tâches longues, c'est d'autant plus important qu'une requête se réduit rarement à un seul appel au modèle ; elle s'accompagne plus souvent d'une chaîne de lectures de fichiers, d'appels d'outils, de vérifications et de préparation du résultat.

La couche suivante est AgentPlanItem, c'est-à-dire une étape distincte au sein du tour. Si l'utilisateur demande d'analyser un projet et de préparer un rapport, l'agent peut découper la tâche en plusieurs actions : trouver les documents, lire les fichiers pertinents, vérifier les données et assembler la réponse finale. Pour chaque étape, il est proposé de stocker son propre item_id, son numéro d'ordre, le nom de l'outil, les arguments, le mode de confirmation et le statut.

L'article souligne que les modes safe_readonly, confirm_once et mutating ne sont pas là pour la forme : ils permettent de séparer d'avance les opérations de lecture sûres, les actions confirmées une seule fois et les mutations potentiellement dangereuses. Le système sait ainsi non seulement que « l'agent fait quelque chose », mais aussi quel outil doit démarrer ensuite, ce qui est terminé, ce qui peut être relancé et à quel endroit l'exécution est bloquée.

La troisième entité indispensable est AgentEvent, une chronologie de ce qui se passe. Ce sont les événements qui font du tour un système observable plutôt qu'une boîte noire. Au lieu d'un état unique et flou, le frontend peut lire turn_started, tool_started, tool_progress, tool_completed, approval_requested, tool_failed et turn_completed, puis afficher une progression lisible.

L'exemple du texte est terre à terre, et donc utile : l'agent lance collect_documents et trouve 12 documents, puis, à l'étape analyze_documents, signale une progression de 40 sur 100 et, en cas de panne, consigne un timeout du service externe et marque l'erreur comme retryable. Pour l'utilisateur, cela donne une UX correcte au lieu d'un interminable « l'agent réfléchit » ; pour l'équipe de développement, la possibilité de déboguer le pipeline, de réaliser des audits, d'analyser les incidents et de restaurer les tâches après un redémarrage sans reconstituer l'historique à la main.

La principale conclusion de l'article de Habr AI est qu'un agent de production en 2026 n'est pas un bon prompt entouré d'un peu de plomberie, mais un système à état doté d'un journal d'exécution. Sans état durable au niveau du tour, de l'étape et de l'événement, un agent résiste mal aux pannes, reste opaque pour l'interface et se maintient très difficilement. La prochaine étape de l'évolution des applications d'agents tient donc moins aux nouveaux modèles qu'à la discipline de l'architecture backend : à la façon dont on enregistre l'état, dont on contrôle les confirmations et dont on transforme le travail du modèle en processus opérationnel reproductible.