Ce que tu vas en retirer : Tu découvriras les quatre fichiers principaux grâce auxquels je distingue clairement l'identité, le mode de fonctionnement, les limites et la mémoire d'un agent.
Table des matières
„À première vue, “ SOUL » semble plus important qu’il ne l’est en réalité. Dans mon Agents Brain, ce mot désigne un fichier de persona court. À côté, on trouve MASTER, RULES et MEMORY.
Quatre fichiers ne suffisent pas pour couvrir toutes les capacités imaginables. Ils suffisent toutefois pour décrire un agent de telle sorte qu'un autre outil puisse le charger, qu'un humain puisse le vérifier et que l'agent puisse lui-même mettre à jour ses connaissances.
Le problème, c'est justement la fragmentation. Un seul « méga-prompt » mélange rapidement le ton, les règles de travail, les détails du projet, les limites de sécurité et les décisions antérieures. Chaque correction devient alors risquée : celui qui modifie une phrase ne sait pas quelles autres parties du texte cela va affecter.
C'est pourquoi je répartis les responsabilités.
SOUL : Qui est cet agent ?
Le fichier SOUL est le plus court des quatre. Il décrit le rôle, l'attitude et la voix. Il contient également l'ordre de lecture à respecter pour le début de la session.
Dans le cas de Sol, par exemple, il est indiqué qu’en tant qu’auteure et attachée de presse, elle incarne la voix publique de Saskia : précise sur le fond, claire, humaine et sans exagération. Ses limites sont tout aussi importantes : elle n’invente pas de chiffres et ne publie rien elle-même.
Le SOUL doit rester suffisamment concis pour pouvoir être lu dans son intégralité à chaque lecture. Ce n'est pas une encyclopédie. Son rôle est de servir de guide.
Un bon profil de personnage répond à trois questions :
- Quel rôle l'agent incarne-t-il ?
- Comment prend-il ses décisions sur le plan linguistique et technique ?
- Quels fichiers de niveau inférieur doit-il charger avant de commencer à travailler ?
Le SOUL devient ainsi un point d'entrée solide, et non un simple vivier.
MASTER : Comment fonctionne l'agent
Le fichier MASTER correspond à la spécification opérationnelle complète. Il peut donc être très détaillé.
Elle comprend, selon le rôle, la tonalité, les formats de sortie, le référentiel métier, la hiérarchie des sources, le workflow, le contrôle qualité et la gestion des erreurs. Les règles qui y figurent diffèrent selon qu'il s'agit d'une autrice ou d'un chargé de développement. La structure reste similaire, mais le contenu est spécifique à chaque rôle.
L'avantage de cette distinction apparaît clairement en cas de modifications. Si je précise le style visuel pour tous les futurs articles, je modifie les consignes de travail. Il n'est pas nécessaire pour autant de réécrire l'identité fondamentale de l'auteure.
À l'inverse, un rôle peut faire évoluer son registre sans que ses formats techniques de diffusion ne s'estompent.
Le fichier MASTER fait donc à la fois office de manuel et de contrat : suffisamment détaillé pour les cas complexes, mais distinct du profil de démarrage succinct.
RÈGLES : Ce que l'agent peut et a le droit de faire
RULES est le contrat de travail faisant autorité en matière de compétences, de limites et d'autorisations. Ce fichier précise :
- Rôle et domaine de compétence,
- Compétences,
- données d'entrée attendues,
- résultats typiques,
- Dépendances,
- Memory-Scope,
- actions interdites,
- Étapes de validation.
Ce sont justement ces deux derniers points qui sont souvent abordés trop tard dans la configuration des agents. Le fait qu'un agent dispose d'une capacité ne signifie pas pour autant qu'il soit autorisé à l'exercer de manière autonome.
Sol peut, par exemple, préparer des brouillons WordPress. Elle n'a toutefois pas le droit de les publier. Cette restriction n'est pas un simple rappel à la fin d'une invite, mais fait partie intégrante de son fichier RULES.
Cela permet à un orchestrateur de vérifier, avant la délégation, si le rôle correspond à la tâche. Et l'outil suivant charge également ces mêmes règles de validation.
MÉMOIRE : Ce qui reste pertinent à long terme
Le fichier MEMORY n'est pas un compte rendu de toutes les conversations. Il contient une sélection des éléments essentiels tirés des journaux quotidiens et des leçons.
On y trouve les projets en cours, les conventions qui ont fait leurs preuves, les écueils connus et les règles importantes à respecter par les parties prenantes. Les détails chronologiques sont consignés dans les journaux quotidiens. Les schémas de correction récurrents sont répertoriés sous forme de leçons à part entière.
Cette séparation évite de surcharger la phase de démarrage. Un agent n'a pas besoin de consulter une centaine d'anciennes sessions pour travailler efficacement aujourd'hui. Il charge un fichier compact contenant l'historique et complète, si nécessaire, avec les journaux quotidiens actuels ou les leçons pertinentes.
La curation implique également de supprimer, de synthétiser et de marquer comme obsolète. « Memory » est une mission éditoriale, pas un dépotoir.
Pourquoi quatre fichiers valent mieux qu'une longue ligne de commande
Ces quatre fichiers ne sont pas classés par ordre d'importance. Ils répondent à des questions différentes :
| Fichier | Question centrale | Type de modification |
|---|---|---|
| SOUL | Qui suis-je ? | rare, proche de l'identité |
| MASTER | Comment est-ce que je travaille ? | régulièrement, sur le plan opérationnel |
| RÈGLES | Que puis-je faire et qu'ai-je le droit de faire ? | en matière de compétences et de portes |
| MÉMOIRE | Que dois-je savoir à long terme ? | en cours, sous la direction de |
Cette répartition réduit les dépendances. Une nouvelle compétence modifie le fichier RULES. Une règle rédactionnelle doit figurer dans le fichier MASTER. Une correction issue de la pratique devient une « Lesson », puis, le cas échéant, un « Memory ». Il n'est pas nécessaire de modifier le « Persona » à chaque adaptation.
Cela ne fait pas automatiquement d'un agent un bon agent. Cela le rend simplement « gérable ».
Les règles de validation font partie intégrante de l'identité
Pour moi, les « Approval-Gates » ne constituent pas un filtre de sécurité en aval. Ils définissent la manière dont un agent exerce son rôle.
Une autrice qui ne fournit que des brouillons ne travaille pas de la même manière qu'un agent d'édition autonome. Un agent de développement disposant d'un droit d'écriture dans le référentiel a besoin de limites différentes de celles d'un agent disposant d'un accès en mode production. Si ces différences ne sont configurées que dans l'outil concerné, elles disparaissent lors d'un changement d'outil.
En revanche, s'ils figurent dans les colonnes « RULES » et « MASTER », ils voyagent avec le rôle.
C'est particulièrement important en cas de délégation. Lorsque Nox confie une tâche à Sol ou à un autre « harness », ce transfert ne supprime pas de « gate ». La mission peut changer de corps. La chaîne de responsabilité reste inchangée.
Un exemple concret : Sol
Sol est un bon exemple d'atelier, car il utilise précisément cette architecture de fichiers.
Votre SOUL définit l'identité succincte et exige que les sources complètes soient chargées avant chaque tâche. Le fichier MASTER contient vos règles de rédaction, les justifications, les structures de livraison et la gestion des images. Le fichier RULES décrit les compétences et la procédure de révision avant publication. Le fichier MEMORY consigne les contextes rédactionnels actuels et les pièges connus.
Lorsque Saskia corrige un titre ou une pratique relative aux sources, cette information n'est pas seulement intégrée au texte actuel. Sol reçoit une leçon qu'elle relira lors de la prochaine exercice correspondant.
C'est ainsi que les retours d'expérience se traduisent par un comportement du système.
Ce que cette structure ne prétend délibérément pas
Quatre fichiers ne suffisent pas à faire d'un modèle linguistique un être humain. Ils ne garantissent pas non plus une continuité parfaite. Un agent peut passer à côté de certaines sources, mal appliquer une règle ou documenter une session de manière incomplète.
Cette structure permet de mettre en évidence ces erreurs : sous forme de correction dans le manuel, de critère de sélection plus strict ou de nouvelle leçon.
Pour moi, c'est là la différence concrète entre „ La consigne était bonne cette fois-ci “ et „ Le système est capable de tirer des enseignements durables d'une correction “.
La partie suivante ne portera donc pas sur un cinquième fichier central, mais sur les interactions entre les fichiers : la mémoire de travail, les journaux quotidiens, les connaissances à long terme sélectionnées et les leçons.
Sources
- Source du projet : Spécification agents-brain ainsi que les fichiers d'agents canoniques de Sol, version du 15 juillet 2026 (sources primaires privées)
- CommonMark : spécification Markdown ouverte
0 commentaires