Un agent logiciel agit sur le monde auquel il a accès. Si ce monde est incomplet, périmé, contradictoire ou sans limites, une meilleure génération ne règle pas le problème : elle accélère la mauvaise action.

Le contexte est une limite architecturale

Les équipes traitent souvent le contexte comme le contenu d’une invite : elles accumulent des fichiers, ajoutent de l’historique et espèrent que le modèle saura ce qui compte. Cette approche confond volume et autorité. Un dépôt peut contenir à la fois du code actuel, des plans abandonnés, des artéfacts générés et d’anciens rapports. L’agent doit savoir quelle source fait autorité pour la décision à prendre.

L’ingénierie du contexte consiste à concevoir cette limite : ce qui est inclus, pourquoi on peut s’y fier, comment sa portée est définie, quand il expire et quelles actions il peut éclairer.

Objectif d’affairesContrat produitSource actuellePreuves d’exécutionCadre de décision
Le contexte doit se resserrer à mesure qu’on approche de la décision. Chaque couche a son propre responsable et son propre rythme d’évolution.

Cinq propriétés d’un contexte utile aux agents

Fait autorité

Le contexte désigne la source de vérité. Le code actuel peut primer sur un ancien plan lorsqu’il s’agit du comportement de la mise en œuvre; une décision approuvée relative au produit peut primer sur une mise en œuvre existante, même si celle-ci est pratique.

Circonscrit

L’agent reçoit assez d’information pour accomplir la tâche circonscrite sans absorber silencieusement des systèmes sans lien. La portée limite à la fois les erreurs et le coût de l’examen.

Actuel

Les faits susceptibles de changer — état du déploiement, dépendances, API de plateforme, configuration des comptes, résultats de tests en production — doivent être récupérés de nouveau dès que l’exactitude en dépend.

Structuré

Les exigences, les contraintes, les preuves, les questions ouvertes et les actions interdites doivent être clairement distinctes. Un bloc de texte oblige l’agent à reconstruire le modèle opérationnel à chaque échange.

Vérifiable

Le contexte comprend l’artéfact ou l’observation qui prouverait l’achèvement. Sans cet élément, l’agent cherche à produire un résultat plausible plutôt qu’un résultat vérifiable.

Un contexte minimal

  1. Objectif : le résultat attendu, pas seulement l’activité demandée.
  2. État actuel : les fichiers, l’exécution, le déploiement et les preuves connues.
  3. Contraintes : les limites liées à la sécurité, à la plateforme, au produit, au droit et aux autorisations.
  4. Historique des décisions : uniquement les décisions entérinées qui régissent toujours le travail.
  5. Preuve d’achèvement : les tests, les artéfacts ou les observations en direct requis.

Pourquoi cela compte au-delà d’un seul agent

Dès que le contexte repose sur des responsabilités et des contrats explicites, le travail peut être réparti de façon sûre. Une personne chargée de la recherche peut recueillir des preuves externes, un rôle de mise en œuvre peut modifier une surface délimitée, un rôle de test peut mettre le comportement à l’épreuve et un rôle de vérification peut évaluer la déclaration d’achèvement. Le livrable transmis est l’artéfact lui-même, et non un simple résumé du niveau de confiance.

Voilà pourquoi le contexte relève de l’architecture. Il détermine les décisions que le système peut prendre de manière fiable, la répartition des responsabilités et la possibilité d’examiner le travail une fois la session du modèle terminée.