Le contexte, pas le contrôle
Chaque règle du prompt de votre agent a commencé par un bug.
Quelqu'un a constaté un mauvais comportement, a écrit une règle, puis est passé à autre chose. Quelqu'un d'autre a fait de même. Une troisième personne a ajouté un « ne jamais faire X » parce que le modèle avait fait quelque chose d'étrange un mardi. Personne n'a jamais rien supprimé.
Six mois plus tard, l'agent passe plus de temps à parcourir son règlement, dans sa fenêtre de contexte, qu'à réfléchir à la tâche réelle.
C'est une logique de contrôle. Et c'est, selon moi, l'une des plus grandes erreurs de conception que commettent les équipes qui construisent des agents IA.
Un petit exemple qui révèle un schéma plus large
Nous avons rencontré un problème où un agent déclenché par une tâche planifiée n'arrêtait pas de créer de nouvelles tâches planifiées depuis l'intérieur de son exécution. Une récursion infinie, mais avec des effets de bord bien réels.
Deux façons de réagir.
Style contrôle : l'interdire. Écrire du code qui empêche les planifications de créer des planifications. Ajouter une règle au prompt : « ne jamais créer de planification à l'intérieur d'une planification ». Et livrer.
Style contexte : dire à l'agent ce qui se passe réellement.
Vous avez été déclenché par une tâche planifiée à 3 h 00, heure du Pacifique. ID de la planification : sched_29x8f. Une exécution planifiée est une exécution isolée, dotée d'une portée définie que l'utilisateur a initialement autorisée. Créer une nouvelle tâche planifiée étendrait cette portée au-delà de l'autorisation d'origine.
La première approche corrige un seul comportement. La seconde donne à l'agent un modèle de la situation.
Désormais, il peut aussi raisonner sur des questions voisines : dois-je envoyer une notification à 3 h du matin ? Dois-je créer un processus de suivi que l'utilisateur n'a pas explicitement demandé ? Dois-je modifier quelque chose qui dépasse la portée de l'exécution d'origine ?
Aucune règle nécessaire. L'agent a trouvé tout seul.
Beaucoup d'équipes se tournent vers le contrôle alors que ce dont elles ont réellement besoin, c'est de contexte.
La même distinction se retrouve à l'intérieur des prompts
Il ne s'agit pas uniquement d'une application au niveau du système. La distinction entre contexte et contrôle existe aussi à l'intérieur des prompts.
Prompting de style contexte : essentiellement des faits, un minimum d'opinion :
Vous vous exécutez en raison d'une tâche planifiée. Déclenché à 3 h 00, heure de Pékin. ID de la tâche : sched_29x8f. L'utilisateur a autorisé cette exécution pour une portée précise.
Prompting de style contrôle : orienté, prescriptif :
Évitez de créer des planifications. Vous devez notifier l'utilisateur avec l'outil X. Ne faites jamais Y sauf si Z.
Parfois, les instructions prescriptives sont utiles. Mais très souvent, elles compensent des faits manquants. Et dès qu'on commence à compenser de cette façon, cela devient addictif.
Comment les prompts deviennent une bureaucratie
C'est là le mode d'échec le plus profond.
Une équipe constate un problème et ajoute une règle. Puis une autre. Puis encore une autre. Chacune corrige un problème local, mais ensemble elles créent un système rempli de proxys.
Bezos a décrit ce schéma dans sa lettre aux actionnaires de 2016 : un bon processus vous sert, afin que vous puissiez servir les clients. Mais si vous n'y prenez pas garde, le processus devient une fin en soi.
C'est exactement ce qui se produit dans les systèmes d'agents.
La règle n'est pas la finalité. La règle est un proxy du résultat que vous recherchez. Et les proxys s'accumulent. L'un crée des cas limites qui en exigent davantage. Bientôt, l'agent raisonne à travers des couches d'instructions accumulées, chacune ajoutée pour une raison historique dont plus personne ne se souvient vraiment.
Dans les organisations humaines, cela devient de la bureaucratie. Dans les systèmes d'agents, cela devient un prompt géant rempli de cicatrices.
Les faits vieillissent. Les opinions pourrissent.
Un fait comme « cette exécution a été déclenchée par une tâche planifiée à 3 h du matin » est stable. Il reste vrai quel que soit le modèle qui le lit : Claude, GPT, Gemini, ou ce qui sortira au prochain trimestre.
Une affirmation comme « vous devriez éviter de créer des sous-planifications » est fragile. Elle dépend de l'interprétation. Elle peut aider dans une situation et se retourner silencieusement contre vous dans une autre.
Quand vous changez de modèle, chaque opinion présente dans votre prompt est une mine potentielle. Le nouveau modèle a des tendances de raisonnement différentes, et votre « évitez » soigneusement calibré pourrait signifier tout autre chose pour lui.
En revanche, les faits ancrés concernant l'environnement, les permissions, la portée et les contraintes ont tendance à se généraliser à travers les modèles et les cas limites. C'est pourquoi les faits constituent un meilleur matériau de construction.
Le piège des bizarreries de modèle
C'est peut-être la version la plus insidieuse du problème de contrôle : les équipes transforment en permanence des défauts temporaires de modèle en structure permanente du système.
Un modèle se comporte mal dans un cas particulier et restreint. L'équipe ajoute un garde-fou : un correctif dans le prompt, une vérification dans le code, une branche étrange qui n'existe que pour empêcher un mode d'échec bien précis.
Ce correctif est un pari : celui que la bizarrerie persistera. Ce n'est presque jamais le cas.
Trois mois plus tard, le modèle change. Le comportement d'origine disparaît. Mais le correctif demeure. Personne ne veut le retirer, parce qu'il était peut-être là pour une raison.
C'est ainsi que les prompts système deviennent du code hérité.
Il est facile de reconnaître le danger lorsqu'on l'énonce de façon abstraite. Mais en pratique, corriger les tendances de raisonnement actuelles de Sonnet, prompt après prompt, c'est le même schéma sous un autre déguisement.
Documenter un comportement système stable a de la valeur. Corriger les tendances de raisonnement d'un modèle, c'est un tapis roulant. Le modèle changera sous vos pieds plus vite que vous ne pourrez maintenir vos correctifs.
Un bon cas de test : permission refusée
On voit clairement la distinction dans les diagnostics d'outils. Lorsqu'un agent rencontre une erreur de permission :
Style contrôle :
TOKEN est manquant. Exécutez « zero permissions request gmail.send » pour le corriger.
Direct, mais l'agent n'apprend rien. La prochaine fois qu'il rencontre une erreur de permission différente, il est bloqué.
Style contexte :
process.env.GMAIL_TOKEN → existe zero connectors inspect gmail → connecté zero permissions inspect gmail.send → refusé
Options :
- Demander l'approbation de l'utilisateur pour gmail.send
- Utiliser un chemin déjà autorisé s'il en existe un
L'agent sait désormais que le token existe, que le connecteur fonctionne, et que la permission précise est refusée. Il comprend l'état du système et peut raisonner sur des situations inédites que l'auteur de la règle n'avait jamais anticipées.
L'heuristique
Voici ce à quoi je reviens sans cesse :
Chaque fois que vous êtes sur le point d'écrire « ne pas », « éviter » ou « jamais » dans un prompt. Arrêtez-vous. Demandez-vous : quel fait cette règle vient-elle compenser ?
En général, il manque un fait. L'agent ne comprend pas dans quel environnement il se trouve, ce que l'utilisateur a autorisé, quelles actions sont irréversibles, ou en quoi cette exécution diffère d'une interaction de chat ordinaire.
Notez ce fait. Supprimez la règle.
Parfois, vous voudrez tout de même la contrainte, en particulier autour des actions destructrices, des mouvements d'argent ou des limites de sécurité. Les contrôles stricts comptent toujours.
Mais beaucoup de règles de prompt ne sont pas de véritables limites. Ce sont des compensations pour une compréhension manquante. Et ce sont précisément celles-là qui s'accumulent et pourrissent.
L'objectif
L'objectif n'est pas un agent qui mémorise une checklist.
L'objectif est un agent qui comprend suffisamment bien sa situation pour prendre de bonnes décisions à l'intérieur de limites claires.
Une philosophie contrôle le comportement en empilant des règles. L'autre améliore le comportement en rendant le monde lisible.
La première tend vers la bureaucratie. La seconde tend vers la compréhension.
Construisez du contexte. Supprimez les cicatrices. Livrez des agents capables de penser.
