Les agents IA de longue durée ont besoin de canaux durables

La documentation d’OpenAI sur le mode en arrière-plan décrit désormais un problème courant des agents : les tâches de raisonnement peuvent prendre plusieurs minutes, les développeurs peuvent interroger une réponse par ID, annuler cette réponse et reprendre un flux à partir d’un numéro de séquence enregistré.¹

Quels sont les principaux enseignements ?

• Une exécution d’agent de longue durée a besoin d’une adresse. Le client doit pouvoir se reconnecter au même travail, reprendre le flux depuis un curseur connu, envoyer une commande d’orientation, annuler l’exécution et inspecter les preuves.
• L’interrogation périodique seule offre un contrat trop limité. Elle peut indiquer un état, mais un vrai travail d’agent a aussi besoin de commandes, d’un historique d’événements, de flux reprenables, d’artefacts, d’autorisations et de points de contrôle.
• L’exécution durable ne résout qu’une partie du système. Les flux de travail de type Temporal préservent l’état d’exécution et l’historique d’événements, mais l’utilisateur a tout de même besoin d’une surface de communication durable autour du travail en cours.²³
• Les WebSockets aident, mais une connexion WebSocket n’est pas toute l’adresse. Une connexion interrompue ne devrait pas effacer le chemin qui permet à l’utilisateur de revenir à l’exécution de l’agent.
• La surface produit compte. L’utilisateur devrait voir une exécution cohérente, avec preuves, décisions et prochaines actions, et non des journaux dispersés accompagnés d’un texte d’état optimiste.

Les agents IA de longue durée ne rentrent pas dans l’ancien modèle requête-réponse. Une requête classique a un point de terminaison, une réponse et un délai d’expiration. Une vraie exécution d’agent a une durée, un historique d’événements, des artefacts intermédiaires, des interruptions utilisateur, un état de modèle et d’outils, des règles d’annulation, ainsi qu’un humain susceptible de partir puis de revenir.

L’objet manquant n’est pas un message de chat supplémentaire. C’est un canal durable : une adresse stable pour un travail en cours.

J’ai déjà expliqué que les agents managés absorbent l’infrastructure d’exécution, et que les traces d’exécution des agents deviennent le contrat de l’environnement d’exécution. Les canaux durables se placent entre ces deux idées. Une trace prouve ce qui s’est passé. Un environnement d’exécution managé maintient le travail en vie. Un canal durable permet au produit et à l’utilisateur de parler au travail pendant qu’il existe.

Où l’ancien modèle de requête casse-t-il ?

L’ancien modèle du web suppose que le calcul se termine dans une requête ou part dans une tâche en arrière-plan. La base de données conserve l’état durable. Le serveur applicatif reste sans état. Un client peut actualiser la page, arriver sur un autre serveur et lire la même ligne de base de données.

Le travail d’agent met ce modèle sous tension de trois façons. Il peut durer des minutes ou des heures. Il transporte un état de processus qui ne se réduit pas proprement à un seul enregistrement de base de données. Il exige un contrôle bidirectionnel : observer, interrompre, approuver, réorienter, annuler et reprendre.

Zak Knill a décrit la même pression comme un problème de routage. Dans son article de mai 2026, il soutient que le travail d’agent long, avec état et interactif, a besoin d’une primitive routable capable d’adresser le processus qui fait le travail, et pas seulement la base de données qui stocke ses sorties.⁴ Ce cadrage est utile pour une raison simple : le client veut pouvoir dire « transmettre la commande Y à l’exécution X », même si la connexion WebSocket, le worker, l’onglet ou le processus d’origine a disparu.

Les tâches en arrière-plan restent adaptées aux cas simples. Le redimensionnement d’une image, l’export d’une facture ou une synchronisation nocturne peuvent se contenter d’états comme en file d’attente, en cours, réussi ou échoué. Le travail d’agent franchit une limite lorsque l’utilisateur doit orienter le travail avant sa fin.

Pourquoi l’interrogation périodique ne suffit-elle pas ?

L’interrogation périodique donne au client un moyen de demander : « est-ce terminé ? » Elle ne lui donne pas un contrat d’interaction complet.

Le mode en arrière-plan d’OpenAI inclut l’interrogation périodique parce qu’elle résout le problème du délai d’expiration. La documentation indique aux développeurs de récupérer une réponse en arrière-plan tant que son état reste queued ou in_progress, puis de s’arrêter lorsqu’elle atteint un état terminal.¹ La même page expose aussi l’annulation et la reprise de flux avec un curseur sequence_number, ce qui dépasse l’interrogation périodique de base et pointe vers un contrat d’exécution plus riche.¹

Un produit qui s’arrête à l’interrogation périodique disperse généralement l’état de l’agent dans trop d’endroits :

L’interrogation périodique peut rester un chemin d’accès. L’erreur consiste à la traiter comme le contrat produit.

Que doit contenir un canal durable ?

Un canal durable est un contrat de communication nommé autour d’une exécution. L’implémentation peut utiliser un moteur de flux de travail, une file d’attente, une table d’événements, une connexion WebSocket, un flux SSE, un sujet pub/sub, une session d’agent managé ou un mélange de ces éléments. Le contrat produit compte davantage que le transport.

Le contrat minimal comporte neuf éléments :

Chaque événement a besoin d’un type, d’un numéro de séquence, d’un horodatage, d’un acteur, d’une référence de charge utile et d’une politique de masquage. Sans cette structure, le journal d’événements devient une transcription de chat de plus.

Le canal a aussi besoin de jugement. Ne diffusez pas chaque token lorsque l’utilisateur a besoin de décisions. Ne cachez pas les échecs d’outils derrière un indicateur de chargement aimable. Ne transformez pas un agent en cours d’exécution en avalanche de notifications. Un bon canal montre les quelques événements qui aident l’utilisateur à faire confiance, à orienter ou à arrêter le travail.

Comment les systèmes existants dessinent-ils déjà ce modèle ?

Temporal donne au côté exécution un vocabulaire mûr. Une exécution de flux de travail possède un historique d’événements, une capacité de rejeu, du code de flux de travail déterministe et des activités pour le travail avec le monde extérieur, comme les appels API, les requêtes de base de données, les appels LLM et les entrées/sorties de fichiers.² La documentation de Temporal sur le passage de messages dans le SDK TypeScript décrit les flux de travail comme des services avec état qui reçoivent des requêtes, des signaux et des mises à jour. Les clients peuvent récupérer une référence de flux de travail par ID de flux de travail, interroger l’état, envoyer des signaux et exécuter des mises à jour.³

Ce modèle correspond bien au travail d’agent. Les requêtes répondent à « quel état l’exécution signale-t-elle ? ». Les signaux répondent à « veuillez changer de cap ». Les mises à jour répondent à « effectuez un changement suivi et renvoyez un résultat ». L’historique d’événements répond à « que s’est-il passé ? ». Une équipe n’a pas besoin de Temporal pour apprendre de cette forme, mais cette forme donne aux produits d’agents un meilleur vocabulaire que « tâche en arrière-plan plus chat ».

Les Durable Objects de Cloudflare pointent vers un autre élément : la coordination adressable. Cloudflare décrit chaque Durable Object comme une instance globalement unique avec stockage, utile pour coordonner un état entre plusieurs clients.⁵ Sa documentation WebSocket décrit des connexions bidirectionnelles de longue durée et une hibernation qui garde les clients connectés pendant que l’objet dort, puis réveille l’objet lorsqu’un message arrive.⁶ Cela ne fait pas des Durable Objects un environnement d’exécution universel pour agents. Cela montre en revanche pourquoi un objet de coordination adressable paraît naturel pour les surfaces d’agent en direct.

L’article d’Anthropic sur les agents de longue durée ajoute la dimension du travail humain. Il explique que les agents peinent encore à traverser de nombreuses fenêtres de contexte et décrit un modèle où les sessions ultérieures progressent par incréments tout en laissant des artefacts clairs pour la session suivante.⁷ Les canaux durables devraient porter ces artefacts jusqu’à la surface produit, au lieu de les enfouir dans des journaux privés.

Que construirais-je en premier ?

Je commencerais par un petit service d’exécution, pas par une grande plateforme d’orchestration.

Créez une table runs avec propriétaire, état, horodatages et résumé actuel. Créez une table ou un flux run_events avec des numéros de séquence strictement croissants. Stockez séparément les charges utiles volumineuses et les artefacts, puis référencez-les depuis les événements. Ajoutez un point de terminaison de flux reprenable et un point de terminaison de signal typé. Rendez l’annulation idempotente. Inscrivez chaque transition d’état dans le journal d’événements.

Ensuite, limitez le vocabulaire des événements :

L’UI peut alors montrer une exécution cohérente. L’utilisateur peut partir, revenir, examiner les événements, inspecter les artefacts et orienter le travail depuis la même adresse. L’agent peut cesser d’affirmer sa réussite en prose et commencer à attacher des preuves aux transitions d’état.

Quelles erreurs les équipes doivent-elles éviter ?

Évitez trois raccourcis.

D’abord, évitez la simple transcription de chat. Le chat peut lancer le travail et recueillir des clarifications. Il ne devrait pas servir d’unique objet d’exécution pour une tâche longue.

Ensuite, évitez de faire de la diffusion brute de tokens la principale surface de progression. Les flux de tokens aident un développeur à déboguer la latence, mais la plupart des utilisateurs ont besoin de jalons, de blocages, d’artefacts et de décisions. Un canal durable peut toujours exposer des événements bruts pour une inspection experte.

Enfin, évitez les fuites de processus privés. Une surface produit publique devrait montrer des preuves, pas des prompts privés, des corps de points d’accroche, des chemins de fichiers locaux ou des mécanismes internes de notation. L’utilisateur a besoin d’assez d’éléments pour faire confiance au travail. Il n’a pas besoin de chaque astuce interne qui l’a rendu possible.

Cette limite de confidentialité vaut aussi pour l’écriture publique sur les systèmes d’agents. Partagez le contrat. Gardez la machinerie privée privée.

Comment un canal durable change-t-il l’évaluation ?

Un canal durable rend l’évaluation moins théâtrale.

Au lieu de demander si la réponse finale semble plausible, l’évaluateur peut inspecter l’exécution :

• L’exécution a-t-elle démarré avec le bon propriétaire, les bonnes autorisations et le bon périmètre ?
• L’agent a-t-il émis un plan avant d’agir ?
• Chaque artefact revendiqué provient-il d’un événement enregistré ?
• Les échecs ont-ils produit des points de contrôle utiles ?
• Les signaux utilisateur ont-ils modifié l’exécution comme prévu ?
• L’annulation s’est-elle terminée par un seul état terminal ?
• Le rapport final cite-t-il des preuves issues du journal d’événements ?

Cette liste transforme la barrière de preuve en quelque chose que l’environnement d’exécution peut soutenir directement. Elle rejoint aussi la couche de nettoyage : beaucoup de produits d’agents gagneront en rendant les exécutions désordonnées compréhensibles, reprenables et vérifiables.

Résumé rapide

Les agents IA de longue durée ont besoin de canaux durables parce que l’utilisateur a besoin d’un chemin stable pour revenir au travail. L’interrogation périodique peut indiquer un état, mais elle ne peut pas porter tout le contrat à elle seule. Une bonne exécution d’agent a besoin d’un ID de flux de travail, d’événements ordonnés, de flux reprenables, de signaux typés, d’une annulation idempotente, de références d’artefacts, d’autorisations et de points de contrôle lisibles par un humain. L’exécution durable maintient le travail en vie ; les canaux durables permettent à l’utilisateur et au produit d’interagir avec lui.

FAQ : agents IA de longue durée et canaux durables

Les agents IA de longue durée exigent-ils Temporal ?

Non. Temporal donne aux équipes un vocabulaire de flux de travail solide et un modèle d’exécution mûr, mais le contrat de canal durable peut fonctionner sur une infrastructure plus simple. Commencez par des ID d’exécution stables, des événements ordonnés, des flux reprenables, des commandes typées et des artefacts. Passez à un moteur de flux de travail lorsque les reprises, le rejeu, les minuteurs et l’échelle opérationnelle le justifient.

Les WebSockets suffisent-elles pour suivre la progression d’un agent ?

Non. Les WebSockets fournissent une connexion bidirectionnelle en direct. Le produit a tout de même besoin d’une adresse durable, d’un historique d’événements, d’un curseur de reconnexion, d’autorisations et d’états terminaux. Une connexion WebSocket peut transporter un canal, mais elle ne devrait pas définir tout le canal.

L’interrogation périodique est-elle toujours mauvaise ?

Non. L’interrogation périodique fonctionne pour les simples vérifications d’état et peut rester un chemin de secours. Les problèmes commencent lorsqu’elle devient le seul moyen d’observer, d’orienter ou de récupérer une exécution d’agent de longue durée.

Que doit construire une petite équipe en premier ?

Construisez une ressource runs et un journal run_events en ajout seul. Ajoutez un flux reprenable dès que le journal d’événements dispose de numéros de séquence. N’ajoutez des signaux typés que pour les commandes que le produit peut honorer en sécurité : approuver, mettre en pause, réviser, ajouter du contexte et annuler.

Que doit-on mettre dans les événements d’exécution d’agent ?

Enregistrez les transitions d’état, les plans, les débuts et fins d’outils, la création d’artefacts, les signaux humains, les blocages, les annulations, les échecs et les réussites. Gardez les charges utiles sensibles hors du texte d’événement intégré. Stockez les détails privés derrière des références masquées et des contrôles d’accès.

Références