Claude Code adopte le pattern Chief of Staff pour orchestrer les agents

Problème des sessions Claude Code longues

Une session unique de Claude Code fonctionne correctement pendant environ une heure, puis sa performance chute. Deux phénomènes sont identifiés : la fenêtre de contexte, limitée à quelques milliers de tokens, est compactée ; les détails qui figuraient il y a trois heures sont résumés, et le résumé omet souvent les informations critiques. Parallèlement, les auto‑rapports de l’agent (ex. « les tests passent ») ne sont que des souvenirs, pas des observations fraîches. La combinaison de perte de contexte et de dérive des rapports entraîne des erreurs coûteuses, surtout lorsqu’une session doit persister sur plusieurs heures de développement.

Principe du pattern Chief of Staff

Le pattern, appelé aussi orchestrateur‑travailleur ou coordinator‑implementor‑verifier, introduit deux rôles distincts. Le coordinateur (ou Chief of Staff) reste long‑vivant, rédige des briefs, récupère les tâches depuis une file durable, relit les diff, et vérifie chaque affirmation en relançant les commandes. Les agents d’exécution sont des sessions courtes qui ne font que réaliser les instructions du brief. Le coordinateur ne code jamais ; dès qu’il commence à écrire du code, le modèle redevient une session unique et les bénéfices s’effondrent.

Mise en œuvre technique

Trois composants sont nécessaires :

1. Runtime Claude Code : fournit les sessions capables d’utiliser des outils, d’éditer des fichiers et d’accéder à un shell. Chaque session possède sa propre fenêtre de contexte, garantissant que la confusion d’une session ne pollue pas les autres.

2. Substrat de session – cmux : gère les espaces de travail terminale et est pilotable en ligne de commande. Exemple d’instanciation d’une session d’exécution :

cmux workspace create \
    --name project-session-12 \
    --cwd /path/to/repo \
    --command 'claude "Read docs/briefs/current.md and do exactly what it says."'

Le paramètre --command transmet le texte au shell ; il ne lance pas l’agent automatiquement, ce qui oblige le coordinateur à invoquer explicitement Claude. La recommandation est de garder la chaîne d’invite courte et de pointer vers un fichier de brief, afin que le brief soit réexécutable et versionnable.

3. Stockage durable : un tableau, une base de données ou tout système de tickets disposant d’une API. Ce store persiste au-delà de la durée de vie d’une session, évite la compaction du contexte et garantit que chaque leçon ou état intermédiaire est disponible pour la prochaine session.

Analyse des limites et bonnes pratiques

Le modèle ne supprime pas les erreurs de code ; il les rend détectables en exigeant la re‑exécution des commandes et en considérant les codes de sortie comme la source de vérité. Les messages entre sessions peuvent être retardés ou expirés, mais un artefact durable (fichier, carte de tableau) assure la livraison. Le temps de reporting doit être fixé à intervalles réguliers, sans que ces intervalles dictent l’arrêt du travail. Enfin, la multiplication d’agents augmente le bruit : chaque agent supplémentaire doit être soumis à la même chaîne de vérification, sinon le système redevient incohérent.