Nos garde-fous, nos circuits, nos skills — et ce qu'on doit à Superpowers
Ce qui fait tenir la tour n'est pas un secret, ni une philosophie. C'est du code : des garde-fous qui refusent, des circuits qu'on ne saute pas, des compétences qui encodent ce qu'on a appris. Et une partie de tout cela est publique — lisible, copiable, adaptable ailleurs.
Des garde-fous qui refusent en code
Une règle écrite n'est pas suivie ; une règle codée, si. Nous avons 32 garde-fous écrits — des règles claires, nommées, avec leur code. Longtemps, aucune n'était rattachée à l'endroit où le travail passe. Une règle sans endroit ne se fait respecter nulle part.
Un garde-fou, ce n'est pas un avis. C'est une porte qui refuse en code : même entrée, même verdict, toujours. Le modèle n'est pas appelé pour trancher ce qui n'est pas à trancher. La décision déterministe rend l'autonomie accordable à grande échelle — parce qu'elle ne dépend pas de l'humeur d'un modèle. C'est exactement ce que décrit notre front-door : une demande connue se résout avec zéro appel au modèle.
Un de nos agents a reçu une consigne et a voulu s'y mettre tout de suite. La porte l'a renvoyé : « redis-moi d'abord ce que tu as compris. » C'est le collationnement, la règle du pilote d'avion : on répète le cap avant de tourner. Le refus a maintenant un endroit sur la carte, un moment dans la lecture, et sa phrase à côté.
Des circuits qu'on ne saute pas
Un circuit, c'est une suite de portes. Un travail entre par la première, et ne sort que s'il les passe toutes. Chez nous, il y en a 155. Écrites, elles tiennent dans un tableau. Dessinées, on voit d'un coup d'œil celles qui refusent souvent, et celles qui ne refusent jamais.
Le chiffre qui dérange : 98 circuits sur 155 n'ont jamais été lancés. Ce sont des procédures écrites que personne ne suit. Le panneau les compte et le dit, famille par famille. Un tableau aurait caché ce chiffre dans sa dernière colonne.
Des skills qui encodent nos leçons
Au-dessus de la mécanique, il y a les compétences — les skills. Chacune est née d'une faute réelle, pas d'une théorie, et elle encadre un geste que l'on refait sans arrêt.
- éveil (開眼) — lire l'état réel de la machine avant d'agir. Née d'une carte fausse : on avait annoncé « vide » une carte qui contenait 461 éléments.
- circuits — suivre les workflows, ne jamais court-circuiter une étape.
- berzerk — ne jamais rendre la main : un refus se nomme, puis se contourne — sauf trois portes qu'on ne force jamais.
- portiers — dire qui est venu sur les sites et ce qu'il a essayé d'ouvrir.
- courrier — envoyer un courrier depuis la tour, sans jamais répondre « je ne sais pas ».
- kotodama — relire une conversation et n'en sortir que les questions posées.
- lecture-articles — lire les articles depuis les données du serveur, pas depuis le rendu.
Le point commun : une skill, c'est un souvenir de faute transformé en rail. On n'y met pas ce qu'on espère ; on y met ce qui a déjà cassé, pour que ça ne casse plus.
Ce que ça doit à Superpowers
Nous ne sommes pas les seuls à penser en skills. Superpowers, le framework de Jesse Vincent et Prime Radiant, formalise une méthodologie complète pour les agents de code : brainstorming, plans découpés, TDD en rouge-vert, développement par sous-agents, revue de code. Une philosophie en quatre mots : preuve plutôt que promesse.
Nos chemins se ressemblent, et se complètent. Superpowers couvre comment construire — le cycle du logiciel. Nous couvrons comment exploiter sans casser — la sécurité, la confidentialité, la publication par circuit, les garde-fous. Eux disent « écris le test d'abord » ; nous disons « ne dis pas c'est fait avant d'avoir regardé ». Eux disent « systématique plutôt qu'ad hoc » ; nous disons « ne devine jamais l'état, lis-le ».
La vraie différence n'est pas la qualité, c'est l'objet. Superpowers est portable, générique, et s'installe sur une quinzaine d'agents. Nos skills sont enracinés dans un seul système en production, et portent la trace de ses incidents. Les deux avancent sur la même idée : l'autonomie d'un agent ne se décrète pas, elle se gagne par des contrôles qui refusent.
Ce qui est public
Trois dépôts rendent cette mécanique lisible en dehors de la tour.
- Control Tower — le front-door déterministe d'une flotte d'agents : chaque requête franchit une porte qui refuse en code, le passage est enregistré, le modèle n'est appelé que si la demande est vraiment nouvelle. github.com/fotsopatrick/control-tower
- Agent Tracer — la salle des agents, notre « Packet Tracer » : on y voit les circuits au lieu de les lire. Un seul fichier HTML, sans dépendance, licence Apache 2.0. github.com/fotsopatrick/agent-tracer
- Superpowers — la référence dont nous nous inspirons, par Jesse Vincent. github.com/obra/superpowers
Pourquoi publier
Un garde-fou garde parce qu'il refuse, pas parce qu'il est secret. Publier le code, c'est permettre à quelqu'un d'autre de vérifier, de copier, d'adapter. La confiance ne se réclame pas : elle se lit dans un refus qui se reproduit à l'identique, et dans un code qu'on peut ouvrir.