Agent IA interrompu : résoudre l’action en attente avant la suite

Un agent support lit le dossier, propose une note et appelle son outil. L’exécution s’interrompt alors que le résultat de cette écriture manque encore dans l’état de mission. Au redémarrage, un modèle peut proposer la même note sous un autre appel, ou choisir une nouvelle action sur un objectif modifié. Le risque est de poursuivre une conversation sans avoir résolu le geste déjà engagé.

En pratique, la reprise doit d’abord retrouver la mission et traiter ses actions pendantes, puis réexaminer les conditions de sa progression. Un checkpoint n’est pas une autorisation permanente ni une preuve d’absence d’effet. La conception d’agents IA sur mesure doit conserver faits acquis, identités d’opération et limites pour que la planification suivante ne redémarre pas sur une histoire incomplète.

Vingt checkpoints fictifs sont écrits en JSON puis relus face à un registre de notes SQLite. Le parcours commence par rapprocher une note précédemment envoyée, avant de décider de la prochaine étape. Celle-ci est fixée dans le programme : aucun LLM, moteur d’agent ou nouvel effet n’est exécuté. L’accompagnement IA sur mesure de Dawap peut prolonger cette recette en reliant preuve d’action passée, objectif courant et réserves encore ouvertes dans l’environnement de reprise retenu.

Pour qui la reprise doit conserver une mission

Distinguer prochaine étape choisie et étape connue d’un pipeline

Un workflow de dossier possède souvent des étapes prédéfinies. Une mission d’agent peut choisir sa prochaine lecture ou proposition selon ce qu’elle a découvert. Après interruption, elle doit conserver les faits et les restrictions qui orientent ce choix. Rejouer une liste de messages ne garantit pas que le modèle retrouvera la même décision, particulièrement lorsqu’un outil reste sans résultat ou que l’objectif a changé.

Le banc représente M39, société A, utilisateur Alice et ticket T39. Une note OP39 indique que l’analyse du dossier O39 est préparée. La cible locale peut déjà posséder cette note, tandis que le checkpoint la garde en action_unknown. Les notes sont insérées pour construire les situations fictives ; aucun agent de support ni outil distant n’a effectivement été interrompu pendant cette expérience.

Définir la reprise comme une décision du service

Le modèle peut proposer un prochain geste, mais le service décide si la mission peut reprendre, s’arrêter ou demander une revue. Cette décision dépend du checkpoint, des observations d’outil et du contexte courant. Elle doit intervenir avant que la planification crée une action concurrente avec celle qui reste inconnue. La conversation conserve le besoin du lecteur sans transformer son envie de continuer en preuve technique de sécurité.

Les formes d’interruption doivent être identifiées : attente utilisateur, panne de worker, outil sans réponse, annulation ou déploiement. Elles peuvent laisser des états différents. Un bouton continuer ne doit pas appliquer le même geste à tous. Le propriétaire de mission fixe les conditions de progression et la procédure qui résout un effet ambigu, avec les accès nécessaires au rapprochement.

Décrire le checkpoint et ce qu’il ne prouve pas

Conserver objectif, faits et frontière d’action

Le checkpoint nominal porte schéma, mission, tenant, personne, révisions d’objectif et de source, configuration, statut, faits, actions terminées, action pendante et limites. Ces champs permettent au contrôleur de retrouver ce qui était engagé. Ils ne prouvent pas tous une vérité distante : sourceRevision est un repère injecté, et action_unknown signifie précisément que le résultat n’est pas encore acquis dans cet état.

{"schema":1,"mission":"M39","tenant":"A","subject":"alice","goalRevision":1,"sourceRevision":4,"configVersion":"P1","status":"action_unknown","facts":{"order":"O39","quantity":2},"completedActions":[],"pendingAction":{"id":"OP39","tool":"append_note","target":"T39","params":{"note":"Analyse du dossier O39 préparée"}},"spent":20,"held":30,"stepCount":3}

Les fichiers sont écrits puis chargés avec un parseur JSON. Le contrôleur vérifie l’ensemble attendu de clés et la version 1 ; il ne fournit pas un validateur exhaustif de chaque type ou une signature cryptographique. La production doit décider qui peut modifier ces états et comment en protéger la cohérence. Un checkpoint lisible n’est pas nécessairement intègre, ni adapté à la version qui essaie de le reprendre.

Retrouver le contexte de mission avant les lectures de résultat

A39-10 et A39-11 présentent le checkpoint dans une autre mission ou société ; la reprise refuse avant lookup. L’état d’une conversation ne doit pas être chargé uniquement depuis un identifiant fourni par le navigateur. Le service vérifie aussi le sujet courant. Le laboratoire compare des valeurs fixées à la main ; il ne teste pas une authentification, une session ou un stockage partagé entre comptes.

La documentation LangGraph des interruptions relie la reprise au même thread et précise que le node interrompu redémarre depuis son début. Le code précédant l’interruption peut donc s’exécuter de nouveau. Ce comportement doit rejoindre la recette des effets et validations. Aucun graphe LangGraph n’est lancé dans le banc présenté.

Résoudre l’action inconnue avant une nouvelle planification

Retrouver l’opération plutôt que demander au modèle si elle a réussi

Cas concret : A39-01 possède OP39 dans la table de notes avec exactement les paramètres du checkpoint. Le contrôleur retrouve ce fait, inscrit l’action dans completedActions et retire pendingAction. Il peut ensuite proposer present_summary, qui utilise OP39 comme action connue. La reprise ne renvoie pas append_note. Une nouvelle suggestion ne doit pas être utilisée pour deviner ce qu’une ancienne invocation a réellement produit.

Le registre cible est une table SQLite locale où l’identifiant d’opération retrouve le payload. Ce rapprochement est autorisé dans le contexte fictif. Une production doit établir ce contrat auprès de l’outil réel : portée de l’identifiant, égalité de paramètres, identité de ressource et nature du résultat. Un message reçu du modèle ou une formulation ressemblant à un reçu ne remplace pas la preuve du système qui a appliqué l’effet.

Bloquer la suite pendant une résolution indisponible

A39-02 déclare le lookup indisponible. Le contrôleur conserve action_still_unknown, les 30 unités retenues et zéro proposition de suite. Le fait que la table cible possède une note n’est pas utilisé, puisque le service ne peut pas établir cette observation dans le scénario. La suite reste fermée jusqu’à ce qu’une preuve ou une décision de résolution soit disponible.

La documentation Temporal des activités distingue exécution, retries et réception du résultat. Ses mécanismes doivent être compris dans leur runtime et leur contrat d’outil. Ils ne prouvent pas, à eux seuls, qu’une reprise métier peut envoyer une nouvelle action sans rapprochement. Le banc ne lance ni activité Temporal ni retry automatique.

Traiter absence de reçu et paramètres contradictoires

Conserver une absence observée sans la transformer en permission de renvoi

A39-03 trouve la table cible sans OP39. Le verdict action_not_found_review ferme la planification. La politique locale demande une revue au lieu de rejouer automatiquement. Dans un outil distant, une lecture négative peut précéder une réponse tardive ou ne pas couvrir le bon périmètre. Le responsable doit établir comment cette absence soutient une nouvelle tentative, avec la même identité ou une décision distincte.

Cette frontière diffère du pipeline déterministe qui possède déjà son contrat de rejeu. Une mission d’agent pourrait proposer un autre outil ou reformuler les paramètres dès qu’elle pense l’action échouée. Le contrôleur doit donc résoudre l’opération pendante avant de rouvrir ce choix. Une tentative de remplacement ne peut pas rendre inconnue la filiation du premier geste.

Préserver la contradiction comme un défaut à instruire

A39-04 retrouve OP39 avec un payload différent. Action_receipt_conflict ne devient ni succès ni absence. La reprise conserve le checkpoint initial et ne propose rien de nouveau. Le service doit retrouver qui a produit ce résultat et quel geste était autorisé, plutôt que modifier ses paramètres pour les faire ressembler à la table. Les preuves contradictoires restent visibles pour les personnes habilitées à les examiner.

A39-18 déplace la cible de l’action pendante vers T40 et reçoit pending_contract_denied avant lookup. A39-19 présente une action pendante dans un statut ready incohérent et reçoit pending_state_inconsistent. Ces contrôles portent sur la combinaison locale prévue, pas un catalogue général de tous les outils. Une production doit définir les états autorisés et leurs transitions pour ses propres capacités.

Conserver les effets lorsque l’objectif change

Séparer la nouvelle demande de l’ancienne opération

Exemple concret : A39-05 change goalRevision à 2 alors qu’OP39 reste inconnue dans le checkpoint. Le contrôleur rapproche d’abord la note, conserve son résultat, puis renvoie goal_changed_review. Le nouveau besoin n’efface pas un effet passé. Il ne suffit pas non plus à autoriser une prochaine action fondée sur la mission précédente. La revue doit décider quelle partie du travail reste pertinente.

Une correction de demande peut être mineure ou changer ressource, destinataire et conséquences. Le service doit conserver la révision d’objectif à laquelle chaque proposition appartient. L’agent peut aider à reformuler le nouveau travail, mais ne réattribue pas une ancienne approbation à des paramètres différents. La reprise doit rendre cette rupture de décision compréhensible sans demander au lecteur de reconstituer tout l’historique.

Ne pas confondre conversation poursuivie et mission maintenue

La personne peut reprendre une conversation en demandant une autre tâche. Le produit doit décider s’il s’agit d’une continuation, d’une nouvelle révision ou d’une mission distincte. Réutiliser le même thread technique ne tranche pas cette question métier. Les faits acquis peuvent rester utiles, mais leurs usages et les effets ouverts doivent être réexaminés selon la nouvelle cible et les droits courants.

Le coût caché d’une reprise mal rattachée inclut notes contradictoires, opérations superflues et investigations pour distinguer les deux demandes. La traçabilité relie objectifs, actions et observations afin de résoudre ces écarts. Le nombre de tours de conversation ne constitue pas l’unité de résultat ; le service doit retrouver le travail attendu et la décision encore nécessaire pour le terminer.

Réexaminer configuration, sources et droits

Refuser une migration implicite de la logique d’agent

A39-06 change configVersion de P1 à P2. Le reçu d’OP39 reste conservé, mais la sortie config_changed_review ferme la prochaine proposition. Ce repère représente une configuration fictive ; aucun modèle ou prompt réel n’est chargé. La production doit identifier ce qui peut modifier interprétation d’état, choix d’outil et conditions d’arrêt, puis définir comment les missions ouvertes traversent cette évolution.

Un nouveau prompt peut comprendre différemment un ancien résumé ou proposer une capacité qui n’existait pas lors de la validation. Une migration doit conserver les effets acquis et réexaminer le contrat de progression. Restaurer une version antérieure ne garantit pas que tous les checkpoints lui sont encore compatibles. Le service doit pouvoir expliquer pourquoi un état est repris, migré ou placé en revue.

Ne pas porter les anciens droits dans une nouvelle étape

A39-07 exige une source plus récente et reçoit source_refresh_required ; A39-08 retire le droit du prochain geste et reçoit next_step_not_authorized. Le contrôleur rapproche l’opération passée avant ces décisions, sans nouvelle écriture. Le droit injecté concerne la progression, pas l’effacement de l’effet connu. Les capacités de lecture de reçu et de nouvelle action doivent être définies séparément dans le système réel.

Les faits du checkpoint portent ici un repère global de source. Le banc ne vérifie pas plusieurs documents, citations ou permissions documentaires. Une mission réelle doit conserver la provenance utile à chaque affirmation et établir quels changements invalident sa prochaine décision. Une source rafraîchie ne donne pas un droit plus large ; un droit maintenu ne rend pas actuelle une donnée ancienne.

Retrouver les dépenses et limites au redémarrage

Conserver les réserves pendant un effet inconnu

Le checkpoint garde spent égal à 20 et held égal à 30 unités fictives. Tant que l’action reste inconnue, la réserve ne disparaît pas. Lorsque le reçu est rapproché, le laboratoire transfère ces 30 unités vers spent, selon sa convention fixe, puis held devient zéro. Ce traitement ne mesure aucune facture fournisseur ni coût réel d’un appel IA ; il vérifie que la reprise ne repart pas avec un compteur vide.

La proposition suivante demande une disponibilité fictive de 10 unités. À budget 60, le total 50 plus 10 passe ; A39-13 utilise 59 et ferme la suite. L’absence de modèle exécuté interdit d’interpréter cette paire comme tarif ou rendement. Une production doit distinguer dépense connue, réserve ouverte et facture rapprochée, avec responsabilité de résolution de chaque exposition.

Ne pas réinitialiser les conditions d’arrêt

Le checkpoint conserve stepCount à 3 et le contexte autorise moins de 5 étapes déjà comptées pour proposer la suite. A39-14 arrive à 5 et reçoit resume_step_limit. Le programme n’incrémente pas une exécution de prochaine étape, puisqu’il n’en lance aucune. Il évalue seulement l’admission. Le compteur ne doit pas être remis à zéro parce qu’un worker, une session ou un service a redémarré.

La recette réelle ajoute temps engagé, tentatives et appels déjà reçus. Un agent interrompu peut continuer à attendre un outil dont la dépense ou l’effet n’est pas clos. Les limites doivent couvrir cette exposition et le coût du rapprochement. Multiplier les interruptions ne doit pas permettre de retrouver à chaque reprise le budget entier de la mission initiale.

Respecter une attente de validation ou une annulation

Retrouver la décision encore nécessaire au lecteur

A39-15 porte awaiting_approval sans action pendante. Le contrôleur conserve cette attente et ne propose pas une suite. Une demande de reprise technique ne remplace pas la validation prévue. L’interface doit retrouver l’objet à examiner, ses paramètres et les conditions qui peuvent avoir changé, au lieu de transformer un retour dans la conversation en accord sur tous les gestes possibles.

A39-16 porte completed et ne rouvre pas la mission. Le lecteur peut demander un nouveau travail, mais le service doit le distinguer de cette clôture. Une mission terminée n’est pas un checkpoint vide disponible pour une autre cible. Les faits et opérations passés restent rattachés, avec la décision qui fixe leur état et le prochain contexte éventuellement créé.

Arrêter la progression sans nier les effets passés

A39-09 annule la mission alors que la note est rapprochable. Le contrôleur conserve OP39 puis renvoie cancelled_observed. A39-20 combine annulation et lookup indisponible ; action_still_unknown reste la frontière à résoudre. Le contexte conserve la demande d’annulation, mais le résultat d’outil ne devient pas connu par cette demande. Aucun des deux cas ne propose une suite.

Paradoxalement, une mission arrêtée peut encore demander un travail de rapprochement. Une annulation peut empêcher un prochain appel sans arrêter un effet déjà en cours. Le contrat doit définir demande, réception et confirmation de l’arrêt auprès de l’outil. La recette conserve les opérations qui restent à résoudre, afin que l’interface ne les fasse pas disparaître avec la mission active.

Vingt checkpoints et les suites réellement proposées

Observer l’ordre des décisions du contrôleur

Les vingt checkpoints sont construits à la main, écrits puis relus dans des fichiers locaux. Le registre de notes utilise SQLite 3.53.1. Les essais changent contexte, état, disponibilité du rapprochement et limites. PlannerCalls est un compteur conventionnel de la branche qui construit le prochain geste fixe ; ce n’est pas un appel de modèle. Le tableau indique si cette proposition est produite.

Tous les cas envoient zéro nouvelle écriture cible. Des notes ont été insérées pour représenter les effets passés. A39-01 peut proposer la suite après rapprochement ; A39-17 sauvegarde le checkpoint obtenu puis le relit pour une seconde reprise. Cette dernière ne refait aucun lookup et conserve une seule action terminée. Elle peut proposer de nouveau le compte rendu, sans réappliquer la note.

Limiter la portée de la persistance observée

La lecture des JSON vérifie qu’un état construit peut traverser cette écriture et ce rechargement. Les sorties de reprise sont des objets calculés ; le cas 17 les sauvegarde explicitement. Aucun arrêt OS, concurrence ou transaction entre checkpoint et cible n’est testé. L’agent n’a pas choisi sa trajectoire ; le programme n’effectue ni planification générative ni exécution du compte rendu proposé.

La recette de production doit vérifier sauvegarde atomique de l’état utile, version du runtime et répétitions de planification. Proposer deux fois un compte rendu peut rester acceptable ; envoyer deux fois un effet métier peut ne pas l’être. Le service doit définir ces différences par outil et par mission. Le tableau local ne constitue pas une preuve universelle d’exécution exactement une fois.

Erreurs fréquentes dans une reprise d’agent

Créer un nouveau contexte pour contourner un état difficile

Un thread neuf peut faire disparaître visuellement une action inconnue, sans retirer son effet possible. La nouvelle mission doit conserver la relation avec l’opération antérieure et le travail de rapprochement qui reste ouvert. Le service ne doit pas utiliser un reset comme réparation de résultat. Un signal faible est une augmentation de nouvelles missions après incident, accompagnée de doublons ou de notes incohérentes.

Relancer le modèle avec seulement les derniers messages peut aussi perdre limites, refus et versions de source. Le checkpoint doit porter les éléments nécessaires au contrôleur, distincts du contexte utile à la génération. Une narration abrégée peut aider le modèle sans devenir l’autorité de progression. Les champs manquants doivent déclencher un état de revue plutôt qu’une reconstruction plausible de ce qui aurait dû être conservé.

Laisser le plan remplacer une preuve d’outil

Un agent peut annoncer que la note est faite parce qu’il avait prévu de l’écrire, ou la proposer de nouveau parce qu’il n’a pas reçu sa réponse. Ces deux déductions dépassent l’information disponible. Le service doit distinguer proposition, invocation et reçu correspondant. Une phrase de synthèse ne décide pas qu’un appel inconnu est réussi ou qu’il peut être remplacé par un autre.

Un autre signal apparaît lorsque des missions reprennent après déploiement et choisissent davantage d’outils, alors que leurs validations datent de la version précédente. La configuration peut avoir changé le contrat sans migration explicite. La supervision doit retrouver versions, état et prochaine capacité admise. Le gain de vitesse de reprise ne justifie pas la perte de filiation des décisions qui encadraient la mission.

Plan d’action pour un état de mission exploitable

Le contrat de reprise décrit entrée, sortie et ordre des vérifications. La responsabilité du rapprochement appartient au service d’outil ; celle du nouvel objectif à la mission. L’instrumentation relie checkpoint, opération et observation. Le repli garde les actions inconnues sans ouvrir une nouvelle capacité ; les personnes autorisées peuvent ensuite réexaminer la progression depuis les faits conservés.

1. Définir les éléments qui doivent survivre. Conservez mission, cible, personne, objectif, faits sourcés, opérations et limites. Séparez ce qui soutient le contrôleur de ce qui sert le contexte du modèle. Versionnez le contrat de checkpoint et décidez quels champs absents rendent la reprise impossible sans revue.
2. Traiter les effets pendants avant le prochain plan. Établissez identifiant et paramètres auprès de la cible, puis retrouvez résultat, absence interprétable ou incertitude. Fermez les contradictions. Une nouvelle proposition ne doit pas créer une opération concurrente avec le geste dont le résultat reste à résoudre.
3. Réexaminer les conditions courantes. Vérifiez objectif, configuration, source et droits après conservation de l’effet connu. Préservez validation en attente, annulation et mission terminée. Une migration de checkpoint doit expliquer ce qui reste acquis et ce qui exige une nouvelle décision avant progression.
4. Conserver les limites et leur résolution. Retrouvez dépense connue, réserves, étapes et temps engagé. Attribuez les expositions ambiguës et les seuils d’escalade. La reprise ne reçoit pas un budget neuf simplement parce qu’un worker a changé ; elle doit rendre son admission observable avec les conventions de coût réelles.
5. Éprouver le moteur d’exécution puis la trajectoire du modèle. Testez persistance, répétition de l’étape interrompue, arrêt et double reprise dans l’environnement retenu. Ajoutez les outils réels et les propositions variables. Mesurez effets, refus, travail terminé et cas en revue, avec une procédure qui peut interrompre de nouveau sans perdre l’état nécessaire.

Le rollback conserve les opérations passées et précise quels checkpoints l’ancienne version peut interpréter. La traçabilité permet d’isoler les missions concernées au lieu de remettre toutes les conversations à zéro. Le seuil d’ouverture porte sur une reprise dont la cible et les dépendances sont comprises, avec un propriétaire pour les états qui ne peuvent pas progresser automatiquement.

Guides pour mission, outils, mémoire et budget

Retrouver la frontière de chaque geste

Le contrat de mission d’un agent support fixe les faits à rechercher et les sorties acceptables. Le contrat d’outil entre autorisation et exécution conserve l’identité et les preuves de l’effet. La reprise doit retrouver ces deux dimensions avant de laisser le modèle choisir son prochain geste.

Le refus d’arguments d’outil invalides s’applique aussi aux actions tirées d’un checkpoint. Un état ancien peut conserver une cible qui n’est plus admissible ou un format devenu incompatible. Le contrôleur doit retrouver le motif de refus sans transformer la reprise en autorisation de modifier ces paramètres silencieusement.

Préserver mémoire utile et capacité encore disponible

La mémoire d’un agent entre état et sources distingue faits de mission et références à revalider. Le checkpoint conserve cette structure plutôt qu’un récit unique supposé vrai. Une correction de source peut changer la prochaine décision tout en laissant une opération passée connue et rattachée.

Le budget d’exécution d’un agent IA complète la conservation des limites. Les réserves ouvertes et les tentatives déjà engagées doivent suivre la mission lors d’une reprise. Leur disparition artificielle peut rendre une suite admissible dans le compteur alors qu’elle dépasse l’exposition réellement acceptée par le service.

Conclusion : conserver les faits avant de choisir la suite

La reprise d’une mission ne consiste pas à relancer une conversation comme si aucun outil n’avait été engagé. Le service retrouve identité, état et opérations pendantes, puis réexamine objectif et conditions de progression. Le résultat passé reste un fait lorsque la mission change ou s’arrête. Le checkpoint permet cette filiation lorsqu’il conserve les preuves et les limites que le contrôleur peut vérifier.

Les vingt cas locaux résolvent cette frontière sans nouvelle écriture cible. Deux situations proposent un compte rendu fixe après validation des conditions ; les autres restent inconnues, en attente ou en revue. Les JSON sont persistés et relus, avec notes SQLite fictives. Aucun agent génératif, runtime durable, authentification ou interruption OS n’est exécuté ; leurs recettes doivent établir la reprise du système réel.

La conception d’agents IA sur mesure doit préserver cette séparation entre preuve d’outil et prochaine proposition. L’ouverture d’une reprise dépend du contrat de mission et de ses capacités actuelles, avec un chemin explicable pour les résultats ambigus. Le lecteur et les équipes peuvent retrouver ce qui a été fait et la décision encore nécessaire.

Pour reprendre une mission depuis son checkpoint, notre expertise IA sur mesure peut éprouver le rapprochement d’une action en attente avant toute nouvelle proposition. La recette doit ensuite faire varier objectif, permissions, sources et budget, puis tenter une seconde reprise du même dossier. Si le résultat passé demeure inconnu, sa réserve et son responsable restent identifiés ; le planificateur ne peut pas résoudre cette incertitude en inventant une nouvelle suite.