Transmettre une tâche d'un agent à un autre : ce que le brief transporte et ce qu'il laisse de côté

Objectif

Donner à un second agent (un sous-agent, un contexte neuf après un compactage, ou un spécialiste différent) tout ce dont il a besoin pour poursuivre correctement une tâche, et rien qui puisse l'induire en erreur ou remplir son contexte de matériel inutilisable.

Prérequis

Une raison claire de la transmission : le destinataire dispose d'outils, de permissions ou d'un contexte propre dont l'émetteur ne dispose pas. L'article d'ingénierie d'Anthropic cité, consacré à son système de recherche, indique que chaque sous-agent a besoin d'un objectif, d'un format de sortie, d'indications sur les outils et les sources à utiliser, et de limites de tâche claires, et que sans description détaillée de la tâche, les agents dupliquent le travail, laissent des lacunes ou ne parviennent pas à trouver l'information nécessaire. La documentation de l'agent de codage décrit la direction complémentaire : un sous-agent démarre avec un contexte neuf qui ne voit pas l'historique de la conversation, travaille à partir du message de délégation qui lui est donné, et ne renvoie que le résumé.

Étapes

1. Rédiger l'objectif en une phrase et le critère de réussite dans une autre (« terminé lorsque la suite de tests passe et que le diff ne touche que billing/ »).
2. Transmettre le matériel par identifiant, pas par contenu : chemins de fichiers, hachages de commit, URL, identifiants d'enregistrement, plages de lignes. Le destinataire peut aller chercher ce dont il a besoin ; une copie collée devient obsolète et coûte des tokens deux fois.
3. Lister les décisions déjà prises avec leur raison (« utilisation de la bibliothèque X car Y n'est plus maintenue »), afin que le destinataire ne les rouvre pas.
4. Lister explicitement les inconnues ouvertes (« pas encore vérifié si l'API est soumise à une limite de débit »). Une inconnue omise ressemble à quelque chose déjà tranché.
5. Préciser le périmètre et le budget : quels outils et répertoires sont dans les limites autorisées, quelles actions nécessitent une approbation, combien d'appels ou de temps le destinataire a à disposition.
6. Fixer le format de retour : résultat, preuves (quelles vérifications ont été exécutées, avec leur sortie), ce qui a changé, et les inconnues restantes, dans une structure que l'émetteur peut fusionner sans lire une transcription.
7. Laisser tomber le reste : la sortie brute des outils, la conversation complète et les impasses. Conserver une ligne par impasse (« essayé X, échoué avec Y ») pour qu'elle ne soit pas répétée, et laisser de côté le raisonnement qui y a mené.
8. Relire le brief une fois comme s'il était la seule chose présente dans le contexte ; tout ce qui n'a de sens qu'avec l'historique de l'émetteur est réécrit ou supprimé.

Résultat attendu

Un destinataire qui commence à travailler dès son premier tour au lieu de poser des questions de clarification ou de redériver les décisions de l'émetteur, et un retour que l'émetteur peut fusionner de façon mécanique.

Limites et base de vérification

Ces étapes constituent une proposition dérivée de la documentation citée ; aucune mesure de la qualité des transmissions n'est avancée. Les briefs destinés à des tâches adversariales ou sensibles pour la sécurité doivent en outre expliciter les permissions et les limites de confiance de l'émetteur, car le destinataire n'hérite implicitement de rien.