Diviser le contexte de l'agent en trois couches pour résoudre le problème du monolithe de 700 lignes

Lors de la construction d'agents autonomes persistants, un problème courant émerge : le contexte de l'agent commence dans un seul fichier mais s'étend à plus de 700 lignes, mélangeant règles d'identité, stratégie actuelle, références d'outils, mises à jour de tarification et procédures de publication. Ce monolithe devient ingérable – éditer ce sur quoi se concentrer cette semaine se trouve dans le même fichier que les règles "ne jamais faire cela", provoquant hésitations et erreurs. Une équipe construisant un système à 6 agents qui s'auto-démarre à partir de zéro a rencontré exactement ce problème : dès la deuxième semaine, le lanceur atteignait les limites d'arguments et les sessions échouaient silencieusement.

La séparation en trois couches

La solution a été de séparer le contexte de l'agent par type de préoccupation et fréquence de changement en trois fichiers distincts :

• CLAUDE.md - Identité : qui est l'agent, règles strictes, personnalité. Change presque jamais. Peut être mis en cache.
• BRIEFING.md - Mission : sur quoi se concentrer actuellement, stratégie actuelle, tarification, objectifs. Change chaque semaine.
• PLAYBOOK.md - Opérations : comment faire les choses mécaniquement : procédures, commandes CLI, références d'outils. Change lorsque les outils changent.

Une information vit dans exactement une couche. Si une référence d'outil est dans PLAYBOOK, elle n'est pas dans BRIEFING. La duplication conduit à des contradictions silencieuses.

Pourquoi cette architecture fonctionne

Édition pratique : Tout le monde sait quel fichier éditer. Sur quoi se concentrer ? BRIEFING. Comment publier ? PLAYBOOK. Ne jamais faire cela ? CLAUDE.md. Pas de suppositions ni de fouille dans 700 lignes.

Efficacité technique : Lorsqu'un agent redémarre (ce qui arrive fréquemment), l'identité reste stable. Le même CLAUDE.md est utilisé à chaque session, permettant aux couches de cache de voir un préfixe de prompt identique pour des accès au cache presque gratuits. BRIEFING et PLAYBOOK arrivent via des appels d'outils au premier démarrage – l'agent les lit avant de faire un travail substantiel, donc ils ne sont pas redondants. L'argument de lancement reste petit pour toujours, même si PLAYBOOK atteint 2000+ lignes.

Discipline : Un monolithe accepte n'importe quel contenu n'importe où. Cette spécification vous oblige à vous demander : est-ce lié au caractère, à la mission ou à la mécanique ? Répondre à cette question change votre façon de penser au système.

Modèles d'injection

Modèle A (Simple) : Lire les trois fichiers au lancement, les concaténer et les injecter. Fonctionne si la taille totale respecte votre limite d'arguments du lanceur.

Modèle B (Agents persistants) : Injecter uniquement CLAUDE.md au lancement. CLAUDE.md contient un mandat : Première action, lire BRIEFING.md et PLAYBOOK.md. L'agent effectue d'abord des appels d'outils pour charger les documents de mission et d'opérations avant que tout travail ne commence. L'invite de lancement reste petite même si les playbooks grandissent. C'est la valeur par défaut pour les agents qui redémarrent.

L'équipe utilise le Modèle B. À chaque session, l'agent se réveille, lit BRIEFING, lit PLAYBOOK, puis exécute. Contexte frais à chaque fois, identité mise en cache, aucune anxiété liée aux limites d'arguments.

Résultats après mise en œuvre

• L'édition prenait des secondes au lieu de minutes – aucune peur de casser des éléments non liés.
• Les modifications de BRIEFING entre sessions fonctionnent simplement – l'agent lit le BRIEFING frais au prochain redémarrage.
• PLAYBOOK a atteint 2000+ lignes sans aucune anxiété de lancement.
• L'intégration de nouveaux agents était plus rapide – il y a une structure claire à remplir.

Cette approche n'est pas révolutionnaire – c'est la séparation des préoccupations appliquée au contexte des agents. Mais une fois que vous avez rencontré le problème du monolithe, cela le corrige structurellement. Pour les équipes construisant des agents autonomes qui redémarrent, cette architecture vaut la peine d'être connue.