Mémoire d’un agent : séparer conversation, état métier et sources de vérité

L’agent reprend un ticket interrompu et se souvient que le colis était encore en transit. Il prépare sa qualification à partir de ce résumé, alors que le transporteur a depuis enregistré une livraison et qu’un opérateur a peut-être déjà fermé le dossier. La conversation paraît continue ; les faits et la décision ont changé. Le risque vient de cette continuité trompeuse, qui permet à une ancienne photographie de guider un nouveau travail.

En pratique, la mémoire doit préserver ce que l’agent cherche à accomplir sans devenir propriétaire de tous les faits qu’il a rencontrés. Conversation, état applicatif de mission et sources métier conservent des responsabilités différentes. La conception d’agents IA sur mesure organise leur reprise autour de ces autorités, avec des versions, des droits actuels et des chemins de suspension explicites.

Nous examinons neuf reprises entièrement fictives dans un contrôleur SQLite en mémoire. Les résumés sont manuscrits ; aucun modèle ne les produit et aucune opération ERP n’est exécutée. Pour reprendre un ticket avec une IA sur mesure, séparez l’objectif encore actif, le brouillon du gestionnaire et le statut de livraison à relire. La mémoire conserve ce que l’équipe cherchait à résoudre ; elle ne peut pas décider que le colis est encore en transit.

Pour qui préparer une reprise sans rejouer une ancienne décision

Repérer les missions qui traversent plusieurs interactions

Le problème concerne un agent support qui attend une pièce, un assistant de préparation de devis qui reprend après arbitrage ou un traitement qui s’interrompt pendant l’indisponibilité d’un logiciel. La mission dure plus longtemps qu’un appel de modèle. Entre deux interactions, une personne peut modifier le dossier, un droit peut être retiré et une source peut être corrigée. La mémoire utile doit rendre cette différence visible.

Une demande ponctuelle de reformulation n’exige pas nécessairement un registre de mission complexe. En revanche, dès qu’une reprise peut influencer une qualification ou préparer une action, il faut nommer le dossier, le périmètre et la condition de fin. La taille du contexte ne décide pas de ce besoin. Un échange de trois messages peut contenir une décision sensible ; un long dialogue peut n’être qu’une recherche sans effet métier.

Définir ce que la reprise est autorisée à faire

Notre mission fictive qualifie une contestation de livraison et prépare un brouillon. Elle n’autorise ni remboursement ni envoi de message. Le système peut reprendre les pièces nécessaires à cette préparation, signaler un conflit et transférer la décision. Une phrase mémorisée telle que « le remboursement est autorisé » ne peut pas étendre ce contrat. La limite doit exister dans l’application qui propose les outils, indépendamment du résumé présenté au modèle.

Le propriétaire métier indique les états terminaux et les cas qui exigent une revue. L’équipe technique précise les lectures nécessaires et les dépendances. Le lecteur doit pouvoir demander : qui décide que cette mission existe encore, quel fait doit être relu et qu’arrive-t-il si cette lecture échoue ? Une réponse claire à ces questions vaut davantage qu’un stockage indifférencié de toute la conversation.

Trois catégories de mémoire, trois autorités différentes

Classer les objets selon leur rôle dans le travail

La conversation porte les demandes, les explications et les déclarations. L’état applicatif porte la mission, sa révision, son propriétaire et sa progression. Les sources métier portent les faits dont leur système est responsable : statut d’expédition, prix ou référence de commande. Une copie d’un fait dans un résumé reste une copie. Son stockage durable ou sa restitution dans plusieurs sessions ne lui transfère pas l’autorité du logiciel d’origine.

La séparation est logique : un même stockage peut contenir plusieurs catégories, à condition que leurs schémas et règles restent distincts. Inversement, trois bases séparées ne suffisent pas si le produit traite leur contenu comme des données interchangeables. Ce qui compte est le mécanisme qui vérifie l’état ou le fait avant son utilisation, et la personne capable d’arbitrer un conflit entre déclaration et observation.

Distinguer responsabilité et durée de mémoire

La documentation mémoire de LangChain distingue mémoire liée au thread et mémoire partagée au-delà d’une conversation, avec des mécanismes de checkpoint et de stockage. Cette distinction décrit une portée de rappel. Elle ne remplace pas notre distinction d’autorité : un état de mission et une ancienne source peuvent tous deux être stockés dans un thread sans avoir le même rôle décisionnel.

La mémoire longue peut conserver une préférence de présentation utile entre sessions. Elle ne doit pas généraliser un prix négocié, une exception locale ou une identité vérifiée pour une autre mission. Définissez le périmètre de chaque élément : utilisateur, société, dossier et usage. L’autorisation d’écrire une note de mémoire et l’autorisation de la réutiliser pour un fait ou une action doivent être examinées séparément.

Conserver les déclarations sans les convertir en faits

Préserver attribution et incertitude

« Le client déclare ne pas avoir reçu le colis » garde une attribution. « Le colis n’a pas été livré » transforme cette déclaration en fait du système. Le résumé peut être court tout en conservant cette nuance décisive. Une qualification de contestation peut avoir besoin des deux pièces : statut observé et déclaration contraire. Elle ne doit pas effacer l’une pour produire une histoire plus cohérente.

Les messages peuvent également contenir hypothèses, rectifications et citations d’un tiers. La mémoire doit indiquer leur provenance et, lorsque cela importe, quelle correction remplace une interprétation précédente. Le message le plus récent n’est pas automatiquement la procédure applicable. Une affirmation utilisateur peut expliquer la demande sans décider du droit de remboursement, de l’identité du compte ou de l’état enregistré par le transporteur.

Empêcher la mémoire d’accorder une autorité nouvelle

Une instruction copiée dans une conversation ou un document ne devient pas une règle applicative parce qu’elle a été résumée. Le service garde les permissions et les outils hors de cette mémoire descriptive. Dans notre banc, le résumé peut demander un envoi et annoncer un remboursement ; le contrôleur n’exécute aucun de ces effets et relit le statut autorisé. Cela vérifie une frontière déterministe, pas la résistance d’un modèle à une injection.

Un indicateur utile observe les affirmations présentes dans le brouillon qui n’ont plus de pièce associée. Le signal faible est une phrase familière que l’agent répète à chaque reprise sans refaire la lecture qui la justifiait. La supervision distingue alors déclaration conservée, observation courante et déduction proposée. L’évaluation métier peut examiner si la réponse respecte cette séparation, avec des cas de contradiction et de correction.

Porter la mission dans un état applicatif versionné

Écrire ce qui doit survivre à un changement de contexte

L’état applicatif garde identifiant du dossier, société, mission, révision, étape courante et référence de source nécessaire. Le contrat de reprise précise cette entrée et la sortie admissible ; la responsabilité de transition appartient au service métier. Une mission en attente ne doit pas devenir « terminée » parce qu’un résumé annonce qu’elle l’est. Le seuil de divergence de révision déclenche une suspension ou une reconstruction explicitement conçue.

La mission peut rester active après suppression de l’historique conversationnel dans un essai technique. Cela ne signifie pas que toutes ses informations doivent toujours être conservées dans un produit réel. Cela montre que progression et historique de messages sont des objets différents. Leur cycle de vie doit être décidé selon finalité, droits et obligations applicables, avec les responsables compétents, plutôt que dépendre accidentellement de la longueur du prompt.

Relire l’état actuel avant de poursuivre le travail

Une photographie indique TASK26 à la révision 4. Si le registre courant est à la révision 5, le contrôleur ne réapplique pas silencieusement l’étape précédente. Dans notre choix conservateur, il renvoie stale_task pour une mission toujours en qualification. Le service réel pourrait proposer un mécanisme de migration ou une nouvelle confirmation, mais devrait définir quels champs changent et quelles validations restent pertinentes.

Si la mission est déjà fermée, la reprise renvoie task_terminal avant de lire la source. Ce chemin évite de préparer une nouvelle réponse pour un traitement fini. Il ne démontre pas une transaction distribuée ou une garantie contre toutes les courses concurrentes. Le banc est séquentiel ; une application avec plusieurs acteurs doit aussi protéger la transition actuelle au moment où elle accepte ou exécute une sortie.

Relire les sources qui font autorité aujourd’hui

Traiter la mémoire d’un fait comme une pièce datée

Une observation garde identifiant, version lorsqu’elle existe, moment de lecture et périmètre. Une révision 7 consultée hier peut avoir été correcte et ne plus être actuelle. L’agent peut la conserver pour expliquer son ancien travail, mais doit la revalider avant une nouvelle qualification dépendant du statut courant. Cette politique de relecture est adaptée à notre mission ; elle ne définit pas une durée de validité universelle pour toute donnée métier.

Exemple concret : SHIP26 passe de in_transit à la révision 7 à delivered à la révision 8. La mission ne change pas : qualifier la contestation et préparer un brouillon. La nouvelle observation peut cependant changer les questions utiles et le transfert attendu. La déclaration de non-réception reste pertinente ; elle devient contradictoire avec une observation de livraison, sans qu’une simple copie de statut permette de résoudre ce désaccord.

Recontrôler l’accès au moment où la pièce est demandée

Un accès antérieur ne fournit pas une autorisation actuelle. Le contrôleur fictif vérifie une permission de lecture dans son registre local avant de retourner la source. Une permission révoquée donne access_denied et aucune lecture de source. Alice et la société A sont fixées dans la fixture ; ce contrôle ne remplace pas une authentification complète ou une politique réelle de permissions par objet.

Si la source est indisponible, le service ne présente pas la photographie ancienne comme un statut vérifié aujourd’hui. Il conserve la mission en qualification et renvoie source_unavailable. Un produit peut afficher l’observation ancienne comme historique, avec son âge et ses limites, mais doit distinguer ce mode de la décision actuelle. Le repli est défini par le métier : attendre, demander une pièce ou transmettre une qualification incomplète.

Utiliser le checkpoint comme photographie de reprise

Associer la photographie au bon thread et à la bonne mission

La documentation de persistance LangGraph décrit des checkpoints rattachés aux threads et des possibilités de reprise. La persistance fournit une mécanique de conservation. Elle ne garantit pas que les systèmes externes sont encore dans l’état photographié. Notre contrôleur n’utilise pas LangGraph ; il illustre les vérifications métier qui doivent entourer une reprise, quelle que soit la bibliothèque retenue.

{
  "thread_id": "TH26",
  "company": "A",
  "task_id": "TASK26",
  "task_revision": 4,
  "snapshot": {
    "source_id": "SHIP26",
    "revision": 7,
    "status": "in_transit"
  },
  "summary": "Le client déclare ne pas avoir reçu le colis.",
  "messages": ["Je n'ai pas reçu le colis."]
}

Ce JSON est la photographie exacte utilisée par le banc, pas un format fournisseur. L’identité de thread TH26 et la société A sont confrontées au contexte fixé du contrôleur. Une photographie provenant d’un autre thread est refusée avant la lecture de mission. Le registre conserve ensuite l’état actuel et la source courante ; la formulation manuscrite du résumé ne décide d’aucun des trois contrôles.

Distinguer reprise, retour arrière et restauration d’un système métier

Restaurer un contexte ancien ne remet pas le transporteur, l’ERP ou les décisions humaines à leur état passé. Le checkpoint peut contenir une ancienne référence de devis, mais une nouvelle préparation exige les droits et versions courants. Un rollback de configuration et une reprise de conversation sont également différents. Le produit doit éviter d’utiliser le même bouton pour des opérations dont les effets ne sont pas comparables.

La reprise peut aussi retrouver un outil déjà appelé avant l’interruption. Son résultat et ses effets doivent être rapprochés par un mécanisme adapté, plutôt que rejouer l’appel en relisant une note. Notre fixture ne comporte aucune écriture externe ; elle ne prouve donc pas l’idempotence d’une action. La distinction reste nécessaire pour concevoir un agent qui pourra ultérieurement proposer des opérations réelles sans les répéter accidentellement.

Neuf reprises fictives exécutées dans SQLite

Modifier une pièce et vérifier le chemin de reprise

Chaque parcours repart d’une base en mémoire indépendante : mission TASK26 en qualification à la révision 4, source SHIP26 en transit à la révision 7 et accès de lecture actif. Nous modifions ensuite une pièce ou deux conditions décrites, puis appelons le contrôleur déterministe. Les traces vérifient verdict, source retournée, état de mission et absence de modification du registre de tâche. Aucun raisonnement ou texte de modèle n’est évalué.

MEM01 relit réellement la source, même si sa révision ne change pas. MEM02 et MEM03 retournent delivered à la révision 8. Dans MEM03, l’historique contient zéro message et aucun résumé ; la mission et son état restent disponibles dans le registre. Ce parcours vérifie une séparation des objets, sans démontrer qu’un assistant réel pourrait produire une qualification complète après disparition de toutes les déclarations utiles.

Examiner les refus et la photographie trompeuse

MEM04 à MEM07 et MEM09 ne retournent aucune source courante, et leur trace ne contient pas de lecture de source. Le refus d’un autre thread précède aussi la récupération de mission. Cas concret MEM08 : la photographie conserve la révision 7, mais remplace son statut par refunded et ajoute un résumé qui ordonne un envoi. La relecture retourne in_transit ; le verdict devient snapshot_replaced.

Le contrôle ne se contente donc pas d’un numéro de version copié dans un JSON : il prend le fait depuis la source du banc. Tous les parcours gardent zéro effet externe et la tâche inchangée. Ces résultats prouvent l’ordre des vérifications exécutées, pas une sécurité générale, une durabilité de stockage ou une restauration concurrente. Le coût d’une lecture systématique et son utilité doivent être évalués dans la vraie intégration. Le métier fixe également le délai d’attente et le repli lorsque la source ne répond pas ; notre banc simule l’indisponibilité sans réseau ni chronomètre.

Réduire le contexte sans effacer les conditions de travail

Garder un index de pièces plutôt qu’un récit autosuffisant

L’analyse d’Anthropic sur l’ingénierie du contexte décrit notamment compaction et notes structurées pour des tâches prolongées. Nous retenons la nécessité de préserver les informations utiles à la continuation. Notre choix applicatif ajoute des références vers mission et sources : un résumé sert à retrouver les pièces, sans remplacer leur vérification lorsque la décision dépend d’un fait actuel.

Une note peut indiquer question encore ouverte, déclaration attribuée, objet à relire et prochaine opération permise. Les identifiants de mission et révisions restent dans un état structuré indépendant du récit. Lorsqu’un résumé est reconstruit, le produit compare ses références et ses omissions utiles à une recette. Il ne suffit pas que le résumé soit plus court et fluide : il doit préserver les conditions qui expliquent pourquoi la mission n’est pas encore terminée.

Tester ce qui disparaît, pas seulement ce qui reste lisible

Une omission peut changer la décision : retirer « le client déclare », oublier une pièce manquante ou conserver une réponse ancienne sans sa date. Les cas d’évaluation doivent provoquer ces pertes et demander la sortie attendue : relire, clarifier ou suspendre. Notre banc ne génère aucun résumé ; ses variantes manuscrites établissent seulement le comportement du contrôleur face à certains contenus trompeurs et à l’absence d’historique.

Paradoxalement, une mémoire plus courte peut permettre une meilleure reprise si elle montre nettement les références à revalider, tandis qu’un historique complet entretient des faits périmés. Ce bénéfice reste une hypothèse à mesurer avec le système choisi. Ni plus de tokens ni plus de stockage ne certifient une meilleure qualification. La validation examine la mission préservée, les sources utilisées et les erreurs introduites après réduction du contexte.

Définir portée, invalidation et conservation par objet

Associer chaque mémoire à une finalité et un propriétaire

Historique, résumé, état de mission et copie documentaire peuvent avoir des besoins de conservation différents. Inventoriez leurs emplacements et leurs usages, puis définissez accès, corrections et retrait avec les responsables du produit et des données. Aucune durée universelle ne découle du mot « mémoire ». Les besoins opérationnels et les obligations applicables doivent être examinés sur les objets réellement stockés, leurs destinataires et leur finalité.

Une mémoire partagée entre conversations doit conserver un périmètre explicite. La connaissance d’une préférence de présentation ne justifie pas de réutiliser une déclaration client dans tous les tickets ou toutes les sociétés. L’ajout automatique d’un souvenir peut également élargir le corpus sans décision de propriétaire. Distinguez candidature à la mémoire, contenu validé pour un usage et retrait ; l’autorisation d’accès reste vérifiée au moment du rappel.

Distinguer invalidation de fait et effacement d’historique

Un fait devenu périmé peut rester nécessaire pour expliquer une décision passée, tout en devenant inadmissible comme preuve actuelle. L’invalidation ferme cet usage sans prétendre effacer toutes les copies. L’effacement d’un historique répond à une autre opération, dont les conséquences traversent résumés, index et traces concernés. Il faut définir ces chemins séparément, avec des contrôles correspondant à l’usage et aux règles retenues.

MEM03 efface uniquement les messages et le résumé d’une photographie fictive. Il ne constitue pas un test de suppression juridique ni une procédure complète de purge. Le parcours montre qu’une mission peut être conservée séparément ; il ne prescrit pas de conserver cet état dans tous les cas réels. Cette limite évite de transformer une facilité technique de reprise en règle générale sur la conservation des données.

Erreurs fréquentes dans les mémoires d’agents

Empiler des souvenirs sans hiérarchie de preuve

Un stockage peut mélanger ancien résultat d’outil, note de l’agent, affirmation utilisateur et procédure. La recherche les rapproche ensuite par similarité, sans expliquer leur autorité. Une note récente paraît alors plus pertinente qu’une source courante. La correction consiste à conserver type, provenance, périmètre et référence, puis à choisir les contrôles nécessaires avant usage. Une bonne similarité textuelle n’établit ni droit d’accès ni vérité métier.

La fuite de portée survient lorsqu’un identifiant de thread est traité comme seule protection ou qu’un souvenir de société A est rappelé dans un dossier B. La conception doit vérifier contexte d’identité et accès aux objets. Notre contrôle TH26/A est réduit et fixe ; une application réelle doit éprouver utilisateurs, sociétés, changements de droits et références étrangères avec les mécanismes d’autorisation qu’elle utilise effectivement.

Perdre le travail ou répéter ses effets à la reprise

Le coût caché d’une mémoire mal structurée est la reconstruction humaine : relire tout le ticket, retrouver la source et vérifier si l’opération a déjà été faite. Un premier symptôme est le gestionnaire qui demande systématiquement « où en était-on ? » après une interruption. Le registre de mission doit fournir l’étape et les pièces manquantes, sans exiger une nouvelle interprétation d’un récit complet à chaque reprise.

Une autre alerte est une mission fermée qui revient dans la file après restauration d’un checkpoint ancien. La photographie a probablement remplacé l’état courant au lieu de lui être confrontée. Testez la fermeture par un autre acteur et la reprise tardive. Si le service autorise une réouverture, elle doit devenir une transition explicite avec son responsable, son motif et ses droits, pas l’effet secondaire du rappel d’une mémoire.

Plan d’action pour une reprise vérifiable

Dessiner les autorités avant de choisir le stockage

Commencez par une mission qui peut s’interrompre et dont le métier sait définir la fin. Le responsable de traitement décrit étapes et décisions ; le propriétaire des sources indique faits, versions et accès ; l’équipe technique identifie les photographies de reprise et leurs dépendances. Cette carte doit montrer où est l’état actuel, quelles pièces sont copiées et quelle information manque lorsqu’un retour de source devient impossible.

1. Inventorier messages, résumés, mission, résultats d’outils et faits métier. Associer chaque objet à une autorité, un périmètre et un usage ; garder les déclarations attribuées plutôt que les convertir en observations.
2. Structurer la mission avec identité, révision, étape et états terminaux. Définir une transition courante que le checkpoint doit vérifier ; préciser comment suspendre ou reconstruire lorsque les versions divergent.
3. Raccorder les sources nécessaires à une lecture autorisée actuelle. Conserver références et dates des anciennes observations, puis décider lesquelles exigent revalidation avant une nouvelle qualification ou proposition.
4. Provoquer interruption, source corrigée, droits retirés, résumé faux et fermeture concurrente simulée. Vérifier source retournée, état conservé et absence d’effet interdit ; distinguer cette recette du test d’un véritable modèle ou d’une écriture ERP.
5. Définir réduction du contexte, portée des souvenirs et parcours de retrait avec leurs propriétaires. Évaluer omissions et contradictions sur des exemples métier, puis choisir le stockage et les mesures de reprise adaptés aux preuves attendues.

Le livrable contient schémas des objets, ordre de vérification et motifs de refus compréhensibles. Il indique si la mission attend une source, une clarification ou une nouvelle décision. Les traces doivent permettre de retrouver quelle observation a été utilisée à quelle révision, sans recopier inutilement tout le contenu sensible. Une mémoire exploitable est une chaîne de pièces et d’états que l’équipe peut inspecter.

Éprouver le service complet dans son environnement réel

La traçabilité de reprise relie entrée, checkpoint, état courant et sortie. La responsabilité de chaque repli est nommée ; le contrat d’outil conserve les droits et la validation hors du résumé. Le runbook explique indisponibilité, révision incompatible et mission terminale. L’instrumentation distingue reprise réussie, suspension attendue et erreur technique afin que le monitoring ne présente pas tous les refus comme des pannes.

Après la recette locale, l’intégration réelle doit tester durabilité, accès et transitions avec ses stockages et logiciels. Si plusieurs acteurs peuvent modifier la mission, les conditions de concurrence doivent être protégées au moment de l’acceptation du travail. Une nouvelle stratégie de résumé exige également une évaluation des omissions. Les neuf cas fictifs sont un point de contrôle ciblé, pas une certification complète du service déployé.

Guides complémentaires entre mission, outil et preuve

Définir la mission et le contexte logiciel

Le contrat d’un agent support connecté définit outils, qualification et conditions d’arrêt. La mémoire sert cette mission ; elle ne la remplace pas. Une reprise fiable doit retrouver le livrable encore attendu et les décisions qui restent humaines, avec les sources que l’opérateur pourra consulter.

L’agent connecté à l’ERP et au CRM relie identité, état et actions possibles. Un contexte mémorisé ne donne pas un nouveau droit logiciel. Les outils doivent garder les contrôles métier au moment où ils lisent ou proposent une opération, même lorsque le dialogue semble poursuivre naturellement une session antérieure.

Revalider les faits et isoler les contenus prescriptifs

Le contrôle d’un contexte ERP périmé approfondit la vérification au moment de préparer une action. Il complète la reprise en montrant qu’une lecture antérieure et une nouvelle décision peuvent être séparées par une modification métier. La mémoire conserve une référence ; l’outil vérifie l’état nécessaire à son effet actuel.

L’isolement des instructions contenues dans les documents examine une autre frontière : un contenu peut informer la mission sans commander ses outils. Cette règle doit survivre à la copie dans un résumé ou une mémoire partagée. Reconditionner une phrase non fiable ne lui confère pas l’autorité d’une procédure applicative.

Conclusion : reprendre une mission avec des faits revalidés

Une mémoire d’agent utile préserve la continuité du travail et les limites de ses pièces. La conversation conserve des déclarations ; le registre de mission conserve une progression contrôlée ; les systèmes métier restent propriétaires de leurs faits actuels. Une photographie ancienne peut expliquer le passé sans être admissible comme preuve pour la prochaine décision.

Les neuf reprises SQLite vérifient cette séparation sur des données fictives. Une source changée est relue, un résumé prescriptif ne crée aucun effet, une mission fermée ne repart pas et une permission retirée bloque la lecture. Les essais ne produisent aucune réponse de modèle et n’établissent ni persistance durable, ni gestion concurrente ou suppression complète. Ils montrent les contrôles que le service a réellement exécutés.

Des agents IA intégrés à vos missions métier ont besoin de cette carte avant de multiplier les souvenirs ou les outils. Elle permet de choisir ce qui doit être conservé, ce qui doit être relu et ce qui doit suspendre le travail. Le produit peut ensuite afficher une reprise compréhensible, avec ses pièces actuelles et ses questions ouvertes.

Dawap accompagne la reprise d’un ticket par votre IA sur mesure en identifiant qui fournit chaque information : application pour la mission, source métier pour le statut courant, service d’accès pour les droits. Avec les responsables du support, nous faisons varier ces trois entrées après une interruption. La recette précise ce que le copilote peut préparer de nouveau et quelle pièce ou autorisation demander lorsque le souvenir ne suffit plus à reprendre le dossier.