Context engineering : comment garder vos agents IA sur la bonne voie

Un agent convaincant en démo peut perdre le fil en situation réelle. Avant d’ajouter des consignes, examinez ce qui parvient au modèle. Le context engineering consiste à maîtriser 5 éléments à chaque étape : les instructions, les outils, les faits récupérés, la mémoire et l’historique. L’objectif : fournir assez d’éléments pour permettre la prochaine action correcte, en emportant le moins possible de contenu sans rapport avec elle.

Qu’est-ce que le context engineering ?

Le context engineering, ou ingénierie du contexte, consiste à décider ce que le modèle voit au moment de prendre sa prochaine décision. Cela comprend la consigne rédigée, les outils disponibles, les éléments qu’ils renvoient, les informations chargées depuis la mémoire et les échanges conservés.

La fenêtre de contexte d’un modèle est son espace de travail pour une requête. Un token est une unité de texte ou d’un autre contenu que le modèle traite. Un document enregistré quelque part dans votre système constitue une information disponible ; son contenu n’entre dans le contexte actif que lorsque l’application ou l’agent le charge.

Cette distinction explique un échec courant en production. Un agent peut avoir accès à la bonne politique et répondre malgré tout à partir d’une ancienne conversation, parce que la politique en vigueur n’a jamais été transmise au modèle au moment de décider. À l’inverse, charger toutes les politiques peut introduire des exceptions sans rapport avec le cas traité et des versions obsolètes.

Dans son article technique du 29 septembre 2025, Anthropic décrit ce travail comme le fait de « sélectionner et maintenir l’ensemble optimal de tokens (informations) pendant l’inférence d’un LLM ». L’entreprise distingue la rédaction des instructions de la gestion de l’ensemble des informations fournies pendant l’exécution. L’article d’Anthropic sur le context engineering.

Dans son article du 2 juillet 2025, LangChain parle de « remplir la fenêtre de contexte avec exactement les bonnes informations à chaque étape du parcours d’un agent ». Le travail se répartit en quatre opérations : écrire, sélectionner, compresser et isoler. Autrement dit, sauvegarder l’état utile, récupérer les éléments pertinents, raccourcir ce qui reste et séparer les investigations indépendantes. L’article de LangChain sur le context engineering.

Le changement concret porte sur ce que vous concevez. Un prompt isolé peut rester fixe. La prochaine requête d’un agent évolue chaque fois qu’il lit un fichier, reçoit le résultat d’un outil, termine une sous-tâche ou découvre qu’une hypothèse précédente était fausse. Il faut donc définir comment assembler cette requête tout au long de la tâche.

Documentation vérifiée le 13 octobre 2026 : le fonctionnement des outils décrit ci-dessous a été contrôlé dans la documentation alors en vigueur d’Anthropic et d’OpenAI. L’exemple détaillé illustre une conception possible ; il ne s’agit pas d’un benchmark en production.

Context engineering et prompt engineering : quelle différence ?

Le prompt engineering améliore la consigne ; le context engineering améliore l’ensemble de la requête qui l’entoure. Les deux restent nécessaires.

Pour un agent de développement, le prompt engineering peut remplacer « corrige l’inscription » par « trouve pourquoi les nouvelles tentatives d’inscription envoient des e-mails de bienvenue en double ; propose une correction minimale et un test de non-régression ». Le context engineering détermine ensuite quels fichiers liés à l’inscription, quels logs de nouvelles tentatives, quelles règles du projet et quels constats antérieurs l’agent reçoit avant de proposer cette correction.

Une consigne parfaitement rédigée ne compense pas des logs chargés depuis le mauvais environnement. Un extrait de log soigneusement choisi ne compense pas une consigne qui ne précise jamais si l’agent doit diagnostiquer, modifier le code ou déployer.

La compétence clé : savoir poser les limites du contexte

Pour chaque information, déterminez quand elle doit entrer dans le contexte et quand elle peut en sortir. Les règles permanentes du projet, l’état temporaire de la tâche et les éléments de preuve bruts n’ont pas la même durée d’utilité.

Une convention de code a sa place dans les instructions persistantes. « La branche de nouvelle tentative n’a pas encore été testée » relève de la note de reprise de la tâche en cours. La réponse complète d’un fournisseur doit rester dans un fichier de référence accessible ; ses champs pertinents sont chargés lorsqu’ils influent sur la décision.

C’est aussi pourquoi la génération augmentée par récupération, ou RAG, ne couvre qu’une partie du travail. Le RAG récupère des documents ou des données pour étayer la réponse d’un modèle. Il reste à choisir les instructions, les outils, l’historique conservé et le contenu renvoyé par cette recherche.

Comment gérer le contexte d’un agent IA ?

Commencez par la principale source de contexte inutile à l’étape qui échoue. N’introduisez pas tous les mécanismes à la fois. Un agent de débogage submergé de logs ne demande pas la même première correction qu’un assistant qui oublie régulièrement les contraintes du projet.

Compacter l’historique autour des décisions, pas seulement des sujets

Claude Code, l’agent de développement d’Anthropic, propose /context pour examiner l’utilisation du contexte et /compact pour raccourcir une conversation. Sa gestion automatique efface les anciennes sorties d’outils, puis résume la conversation si nécessaire. La documentation avertit explicitement que des instructions détaillées données plus tôt dans l’échange peuvent être perdues. La gestion du contexte dans Claude Code.

Donnez un objectif à la compaction. Pour l’enquête sur les e-mails de bienvenue, utilisez /compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question. Cette commande fournit des consignes propres à la tâche ; elle ne garantit pas que tous les détails seront conservés.

Avant de poursuivre, vérifiez que le résumé distingue toujours ce qui a été observé, déduit et non vérifié. « Nouvelles tentatives d’envoi examinées » ne fait que nommer un sujet. « L’acceptation par le fournisseur est établie ; le traitement de l’accusé de réception côté local reste à examiner » décrit un état à partir duquel on peut agir.

La compaction perd de l’information. Gardez les éléments de preuve d’origine accessibles et les règles permanentes dans les instructions du projet, pour qu’une étape ultérieure puisse retrouver le détail dont elle a besoin.

Récupérer les éléments de preuve au moment utile

Récupérez la source qui répond à la prochaine question, puis élargissez la recherche uniquement si le résultat ne suffit pas. L’article technique d’Anthropic décrit cette approche comme la conservation de références légères, avec des outils qui chargent les informations à la demande. Le contexte chargé au moment utile.

Dans Claude Code, les outils de lecture de fichiers et d’exécution de commandes permettent ce workflow. Demandez à l’agent de localiser le gestionnaire des nouvelles tentatives, de lire ce gestionnaire et le code qui l’appelle, puis d’examiner la séquence d’erreurs correspondante. Lorsque l’outil dédié Grep est activé, il peut renvoyer des chemins de fichiers, les passages correspondants ou des décomptes, sans transmettre les fichiers entiers. La référence des outils de Claude Code.

Pour votre propre agent, renvoyez une référence permettant d’accéder à la source, un extrait pertinent et assez de métadonnées pour en établir le périmètre : environnement, identifiant de l’enregistrement, version ou date d’entrée en vigueur. Un appel d’outil ultérieur pourra ouvrir les éléments qui entourent l’extrait.

La recherche peut manquer des éléments pertinents. Prévoyez une règle d’élargissement. Si une recherche ciblée ne donne rien, changez de périmètre ou de requête avant de conclure que le fait recherché n’existe pas. Si l’extrait ne permet pas de déterminer si une exception s’applique, chargez la section qui l’entoure.

Réduire les résultats des outils avant leur entrée dans la conversation

Renvoyez le résultat nécessaire à la prochaine décision, tout en permettant de retrouver les détails omis. Pour les outils verbeux, Anthropic recommande le filtrage, la pagination, la sélection de plages et la troncature, avec des indications utiles lorsque les résultats sont abrégés. Les recommandations d’Anthropic pour concevoir des outils.

Claude Code applique ce principe aux sorties volumineuses des commandes shell réussies : au-delà du plafond d’affichage dans la conversation, il fournit le chemin d’un fichier sauvegardé et un aperçu. L’agent peut ensuite rechercher dans ce fichier ou le lire si nécessaire. Le traitement documenté des commandes en échec est différent : ne supposez pas que toute erreur tronquée s’accompagne d’un chemin vers un fichier récupérable. Le traitement des sorties shell.

Pour l’agent chargé de l’inscription, un résultat de log utile comprend l’événement correspondant, l’opération qui le précède, l’erreur et l’emplacement de la source. Les requêtes répétitives sans anomalie peuvent rester dans le fichier de logs. Conservez exactement le code d’erreur et l’identifiant de l’événement ; une reformulation comme « quelque chose a expiré » peut effacer l’indice qui détermine la correction.

Une troncature aveugle peut supprimer l’exception décisive. Signalez ce qui a été omis et fournissez une requête complémentaire ou une référence de fichier. Éliminez le bruit répétitif avant de retirer les éléments qui contredisent votre hypothèse.

Mener des investigations indépendantes avec des sous-agents sans fork

Les sous-agents de Claude Code peuvent mener une investigation délimitée dans une fenêtre de contexte distincte et en renvoyer le résultat. Un sous-agent sans fork repart de sa définition et de la tâche fournie ; un fork de conversation hérite de l’historique du parent. Les deux séparent le travail effectué ensuite, mais seul le premier démarre avec un contexte vierge. Sous-agents et forks.

Vous pouvez déléguer une tâche de ce type : « Examine le traitement des nouvelles tentatives d’envoi d’e-mail. Ne modifie aucun fichier. Renvoie les chemins pertinents, les éléments attestant une livraison en double, les explications concurrentes et la prochaine vérification. » Fournissez les contraintes nécessaires au sous-agent au lieu de supposer qu’il connaît la conversation principale.

Limitez le retour à ce qui est exploitable : constats, références aux éléments de preuve et incertitudes. Un sous-agent qui renvoie tout son historique de lecture ne fait que reporter l’encombrement dans la conversation principale.

Les sous-agents effectuent leurs propres requêtes et consomment des ressources. Ils peuvent refaire du travail si leur consigne omet une décision déjà établie par le parent. Utilisez-les lorsque l’investigation peut être séparée et que ses sorties intermédiaires n’ont pas à être conservées dans le contexte principal. Gardez ensemble les raisonnements étroitement liés. Les détails de configuration figurent dans le guide des sous-agents Claude Code.

Donner aux fichiers mémoire un rôle limité et stable

CLAUDE.md est un fichier d’instructions du projet, pas un endroit où coller toutes les conversations terminées. Claude Code dispose aussi d’une mémoire automatique pour les notes acquises au fil du travail. Sa documentation distingue ces deux mécanismes d’une configuration techniquement contraignante : inscrire une interdiction dans un fichier mémoire ne rend pas l’action impossible. La mémoire de Claude Code.

Pour une petite équipe produit, réservez le fichier permanent aux règles propres au dépôt, aux commandes de build et de test réellement utilisées, aux limites des modifications et aux liens vers les références détaillées. Gardez l’état temporaire d’une investigation dans une note de tâche séparée. Le guide CLAUDE.md comme mémoire d’équipe détaille la structure du fichier.

Attention à une limite discrète : importer un long document dans CLAUDE.md charge aussi son contenu. Déplacer du texte dans des fichiers importés peut améliorer l’organisation sans réduire le contexte actif. Pour les instructions utiles à une partie du dépôt seulement, envisagez les règles documentées dont l’application dépend du chemin. Pour les workflows réutilisables, les skills de Claude Code exposent normalement d’abord leur description, puis chargent leurs instructions complètes lorsqu’ils sont invoqués. Imports mémoire et règles à portée limitée, chargement des skills.

Les fichiers persistants conservent les hypothèses obsolètes aussi efficacement que les connaissances utiles. Supprimez les incidents résolus et les commandes remplacées. Notez une source ou une révision pour les faits susceptibles de changer. Pour comprendre plus largement la différence entre session, contexte de travail et stockage durable, consultez notre explication de la mémoire des agents.

Comment Claude Agent SDK et Codex appliquent ces principes

Ces mécanismes existent dans les outils cités ; votre application reste responsable du choix des éléments de preuve et du périmètre de la tâche. La gestion automatique du contexte ne peut pas déterminer quelle information métier votre workflow a oublié de récupérer.

Claude Agent SDK : intégrer la boucle de l’agent à votre application

Claude Agent SDK met les outils, la boucle d’exécution et la gestion du contexte de Claude Code à la disposition des applications Python et TypeScript. Utilisez-le pour intégrer un agent à un produit ou à une automatisation que vous exploitez. Présentation d’Agent SDK.

Le SDK compacte automatiquement l’ancien historique lorsque la fenêtre approche de sa limite et émet un événement système compact_boundary. Consignez cet événement avec les résultats des tâches pour repérer les échecs qui apparaissent après un résumé. Les sous-agents du SDK sans fork gardent leur travail intermédiaire dans leurs propres conversations et renvoient leur message final. La boucle de l’agent dans le SDK, les sous-agents du SDK.

Définissez explicitement le chargement des instructions du projet. Les options par défaut actuelles de query() activent les sources utilisateur et projet. Si vous renseignez settingSources en TypeScript ou setting_sources en Python, incluez project lorsque vous avez besoin du CLAUDE.md du projet ; un tableau vide empêche son chargement. Ce sont les sources de configuration qui pilotent ce comportement, et non le choix du préréglage de prompt système claude_code. Le chargement des instructions dans le SDK.

Même une boucle performante a besoin d’une politique de recherche adaptée au métier. Pour un agent d’assistance, vous devez toujours définir qui est le client concerné, quelle politique s’applique et quels éléments sont requis avant toute action.

Codex : séparer les instructions du dépôt de la conversation en cours

Codex, d’OpenAI, lit les instructions AGENTS.md avant de travailler. Il combine les consignes globales avec les fichiers du projet, depuis la racine du dépôt jusqu’au répertoire de travail ; les consignes chargées ensuite prennent le dessus, et AGENTS.override.md est prioritaire dans son répertoire. Les instructions de projet dans Codex.

Servez-vous de cette hiérarchie pour placer les règles générales de build à la racine et les règles spécialisées près du code concerné. Codex CLI propose aussi /compact pour résumer la conversation visible et /init pour créer une ébauche de fichier d’instructions. Vérifiez que cette ébauche correspond bien à votre dépôt avant d’en faire une référence. Les commandes de Codex.

Un fichier d’instructions du dépôt ne capture pas automatiquement la tâche en cours. Sauvegardez séparément l’objectif actuel, les constats confirmés, le travail restant et l’emplacement des éléments de preuve. Après un redémarrage ou une compaction, la requête suivante doit donner accès à cet état sans rejouer toute l’investigation.

Exemple de context engineering : alléger le contexte d’un agent

Réduisez le contenu autour de la décision tout en conservant ce dont elle dépend. Prenons un agent de développement fictif chargé d’enquêter sur des e-mails de bienvenue envoyés en double après de nouvelles tentatives d’inscription. Les noms de fichiers et les éléments présentés ci-dessous illustrent la conception ; ils ne proviennent pas d’un système déployé.

Au départ, son contexte surchargé contient tout le manuel d’ingénierie, de larges extractions du dépôt, des logs de services sans rapport avec le problème, tous les échanges de débogage antérieurs et des outils d’administration inutiles ici. Sa tâche réelle est plus précise : trouver le chemin qui déclenche l’envoi en double, proposer la plus petite modification possible et déterminer un test de non-régression. Les changements de schéma sont exclus du périmètre.

1. 1

   Conserver la tâche active et les contraintes permanentes

   Remplacez les demandes concurrentes de l’historique par l’objectif actuel et les critères d’acceptation. Gardez visible l’interdiction de modifier le schéma. Exposez les outils du dépôt nécessaires à ce travail et laissez les définitions des outils d’administration sans rapport hors de cette exécution. Placez les conventions stables du dépôt dans le fichier d’instructions du projet approprié ; gardez les observations temporaires dans la note de tâche. N’importez pas automatiquement l’intégralité du manuel.

2. 2

   Remplacer les fichiers complets par une carte des éléments de preuve

   Conservez des références à signup-handler.ts, à welcome-job.ts, au test des nouvelles tentatives et au fichier de logs pertinent. Ces noms sont donnés à titre d’illustration. Lisez le gestionnaire et le worker lorsqu’ils permettent de répondre à la prochaine question, puis examinez leurs dépendances si nécessaire. Cette carte rend les éléments accessibles ; elle ne dispense pas de les lire.

3. 3

   Filtrer le résultat de l’outil autour de l’échec

   Demandez l’événement d’inscription concerné et sa séquence de nouvelles tentatives. Supposons que cet enregistrement fictif montre une acceptation par le fournisseur, suivie d’un accusé de réception local manquant et d’une autre tentative mise en file d’attente. Conservez cette séquence, l’identifiant de l’événement et l’emplacement de la source. Laissez les requêtes réussies sans rapport dans le log d’origine. Gardez explicite l’incertitude sur la livraison effective lors de la seconde tentative.

4. 4

   Isoler une recherche bien délimitée

   Confiez à un sous-agent sans fork la recherche du code de prévention des envois en double. Fournissez le périmètre de la tâche et les chemins pertinents. Demandez les emplacements et les éléments de preuve, avec une mention explicite si la recherche est incomplète. Transmettez ce constat à l’agent principal ; gardez les lectures exploratoires du sous-agent hors de son contexte.

5. 5

   Compacter l’investigation en une note de reprise exploitable

   Conservez l’objectif actuel, les éléments établis, les explications écartées, la question non résolue et la prochaine action. Préservez la distinction entre une nouvelle tentative mise en file d’attente et une livraison en double confirmée. Archivez la conversation d’origine pour que l’agent puisse retrouver un détail au lieu de le deviner.

6. 6

   Assembler la prochaine requête à partir du contenu conservé

   Chargez la tâche, les règles permanentes, l’extrait pertinent du gestionnaire, la séquence d’événements filtrée et le constat du sous-agent. La prochaine action consiste à examiner le traitement de l’accusé de réception et la prévention des doublons, puis à proposer le test de non-régression. Chargez davantage d’éléments si cette action l’exige ; ne joignez pas à nouveau toute l’archive par habitude.

La note de tâche obtenue pourrait être la suivante :

Objectif : Expliquer les e-mails de bienvenue en double après de nouvelles tentatives d’inscription et proposer une correction minimale avec un test de non-régression.
Contrainte : Exclure les changements de schéma du périmètre.
Éléments de preuve : La séquence de logs sélectionnée montre une acceptation par le fournisseur, un accusé de réception local manquant et une autre tentative mise en file d’attente. Conserver la référence de l’événement et l’emplacement du log d’origine.
Inconnues : La livraison effective lors de la tentative en attente et l’endroit où s’applique la prévention des envois en double.
Prochaine vérification : Examiner les chemins de traitement de l’accusé de réception et de prévention des doublons dans le gestionnaire et le worker référencés.

Cette note fictive laisse l’incertitude apparente. Au moment d’établir le diagnostic, le modèle reçoit aussi l’extrait qui étaye les constats.

On obtient un ensemble de contenus plus restreint, sans affirmer une réduction du nombre de tokens. Le décompte exact dépend de la requête réelle et du tokenizer. Une baisse des dépenses et une amélioration du taux d’achèvement doivent être mesurées ; cet exemple définit ce qu’il faut retirer et ce qu’il faut préserver.

Un modèle de note pour reprendre la tâche sans perdre le fil

Utilisez une note de tâche avec les champs suivants, renseignés à partir des éléments réellement recueillis pendant l’exécution :

• Objectif et condition de réussite : la demande actuelle et ce qui permettra de la considérer comme terminée.
• Contraintes : les limites que l’étape suivante doit conserver.
• Faits établis : chaque constat, accompagné de l’emplacement de sa source et de la révision ou du périmètre pertinent.
• Incertitudes : ce qui reste déduit, contradictoire ou non examiné.
• Prochaine action : la vérification suivante et l’endroit où récupérer les éléments nécessaires.

Mettez cette note à jour lorsqu’un constat change. Ajouter chaque nouvelle idée sans réviser les précédentes recrée le problème initial dans un fichier plus petit.

Taille du contexte et coût : deux mesures à distinguer

Optimisez le coût d’un résultat accepté, pas la longueur d’une seule requête. Une conversation principale plus courte peut s’accompagner de davantage d’appels aux sous-agents, de recherches ou de tentatives en échec.

Deux budgets d’instructions documentés montrent pourquoi les unités comptent. Le plafond cumulé par défaut des documents de projet dans Codex est de 32 KiB, soit 32 × 1,024 = 32,768 octets. C’est une limite en octets, pas un budget de tokens. Claude Code recommande de garder chaque CLAUDE.md sous 200 lignes ; il s’agit d’un conseil de rédaction, pas d’une limite stricte de la fenêtre de contexte. Aucun de ces chiffres ne permet de prévoir des économies. La limite des instructions de Codex, les conseils de rédaction de Claude Code.

Pour un workflow en production, relevez le coût de l’agent principal, des sous-agents, de la compaction, de la recherche d’informations et des nouvelles tentatives. Calculez ensuite :

Coût par tâche acceptée = coût total du workflow sur l’ensemble des tentatives ÷ nombre de tâches qui satisfont les critères d’acceptation.

Pour un budget mensuel, ajoutez aux frais d’utilisation des modèles ceux des outils, de la recherche d’informations, du stockage et de l’hébergement. Le context engineering n’a pas de tarif mensuel unique, et aucune économie en dollars ne peut être justifiée sans connaître votre charge de travail et les tarifs applicables du fournisseur.

Le cache complique la comparaison. Le cache de prompts d’OpenAI réutilise les préfixes identiques des requêtes une fois assemblées. La compaction peut modifier ce préfixe et réduire la réutilisation du cache, même si la requête devient plus courte. Gardez les instructions réutilisables stables lorsque c’est possible et comparez le coût total avant et après le changement. Une baisse du taux de succès du cache ne prouve pas, à elle seule, qu’une optimisation a échoué. Le cache de prompts d’OpenAI.

Consultez le guide de diagnostic du cache de prompts de GPT-6 pour distinguer les problèmes liés à des préfixes qui changent de ceux liés à du contenu inutile. Un cache réduit le coût de traitement des entrées répétées ; il ne détermine pas si elles ont leur place dans la tâche.

Bonnes pratiques du context engineering : que changer en premier ?

Intervenez lorsque la trace révèle un problème de contexte ; choisissez la plus petite modification qui le résout. Une trace enregistre la séquence des requêtes, des appels d’outils et des résultats, y compris ce que le modèle a vu avant chaque décision.

Pour les développeurs, examinez l’étape qui précède immédiatement l’action erronée. Si les éléments de preuve manquent, corrigez leur récupération. S’ils sont noyés dans des sorties répétitives, filtrez le résultat de l’outil. Si une discussion antérieure prend le dessus sur la tâche actuelle, corrigez l’état de la tâche et la note de reprise. Si une investigation qui peut être séparée envahit la conversation principale, isolez-la.

Pour les équipes qui exploitent les agents, définissez ce qui constitue un résultat accepté et conservez des échecs représentatifs pour l’évaluation. Sur les mêmes tâches, comparez la qualité d’exécution, les affirmations non étayées, les nouvelles tentatives, la latence et le coût total. Modifiez une seule règle de gestion du contexte à la fois pour pouvoir interpréter le résultat. Utilisez les traces existantes pour concevoir des cas d’évaluation hors ligne.

Pour les acheteurs, demandez si le produit donne accès au contexte et aux résultats d’outils à l’origine d’une réponse, conserve les références aux sources après un résumé et permet de maîtriser les instructions persistantes. Une fonction « mémoire » qui ne montre pas ce qui est chargé est difficile à diagnostiquer.

Attendez avant d’ajouter des mécanismes si un workflow court et bien délimité fonctionne déjà de manière fiable. Une consigne plus claire ou un message d’erreur d’outil plus utile peut suffire, sans service de mémoire ni réseau de sous-agents. Si l’échec vient de permissions incorrectes, d’une logique applicative défaillante ou de données sources indisponibles, traitez directement cette cause ; la sélection du contexte ne peut pas, à elle seule, la corriger.

Quelles promesses du context engineering sont exagérées ?

Une fenêtre de contexte plus grande, davantage de mémoire et davantage d’agents offrent des capacités ; ils ne prouvent pas que les décisions seront meilleures. La question utile est de savoir s’ils aident ce workflow à transmettre les bonnes informations à l’étape suivante.

« Tout mettre dans le prompt » évite de choisir, mais introduit des contenus concurrents. « Tout résumer » sélectionne trop brutalement si l’exception décisive disparaît. « Confier le sujet à un sous-agent » n’aide que si la tâche peut passer cette frontière sans perdre de décisions essentielles.

L’erreur la plus coûteuse consiste à confondre une requête plus courte avec un système validé. Un agent qui répond à bas coût à partir de la mauvaise politique reste dans l’erreur. Une bonne politique de gestion du contexte doit rendre la réponse plus facile à vérifier : la règle applicable est visible, les éléments qui étayent la décision ont une source et les incertitudes non résolues restent explicites.

Questions fréquentes quand un agent perd le fil

Le context engineering peut-il corriger un agent qui fonctionne en démo mais échoue en production ?

Il peut traiter les éléments de preuve manquants, les instructions obsolètes, les sorties d’outils excessives et la perte de l’état de la tâche. Commencez par examiner la requête qui échoue. Un outil défaillant, une logique applicative incorrecte ou une tâche au-delà des capacités du modèle demande une correction spécifique. Jugez le changement sur les résultats acceptés de tâches représentatives.

Faut-il une base vectorielle ou un framework multi-agents pour commencer ?

Non. Commencez par des instructions de projet explicites, une recherche ciblée dans les fichiers ou documents, des résultats d’outils limités au nécessaire et une note de reprise. Ajoutez la recherche sémantique lorsque trouver les éléments pertinents l’exige, ou un sous-agent lorsqu’une investigation autonome bénéficie d’un contexte séparé.

Comment savoir si j’ai trop réduit le contexte ?

Vérifiez que la prochaine décision dispose encore de la règle applicable, des éléments qui l’étayent, du périmètre concerné et des exceptions importantes. Si l’agent doit deviner un fait supprimé, le contexte est trop réduit. Gardez une source récupérable et élargissez la lecture lorsque l’extrait ne permet pas de trancher.

À faire dès lundi : reprenez une exécution en échec que vous avez déjà et examinez la requête précédant sa première action erronée. Classez son contenu : instructions permanentes, état de la tâche active, éléments nécessaires maintenant ou contenu qui peut rester stocké. Apportez la plus petite modification correspondante, puis comparez le résultat et le coût total du workflow sur les mêmes cas d’évaluation.

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur la création et l’exploitation d’agents utiles.