
Les sous-agents sont des mécanismes de routage et de périmètre, pas une métaphore d'équipe
Le champ de description est une règle de routage, et la liste d'outils est la garantie
Un sous-agent de Claude Code fonctionne parce que deux mécanismes sont câblés dans un fichier markdown : une description qui route le travail vers le bon spécialiste, et une restriction d'outils qui garantit que le spécialiste ne peut pas quitter sa voie. Le guide de juillet 2026 de Professor Glitch, « Claude Code Subagents: Turn One AI Into a Whole Team », appelle la description « une règle de routage » et la restriction d'outils « la fonctionnalité » — exactement le cadre sur lequel nous construisons chez Everythink, où the space is the router.
L'échange central de l'article est précis : un sous-agent convertit un travail verbeux en une réponse courte, si bien qu'environ 40 000 tokens de recherche brute meurent dans le contexte du spécialiste et la conversation principale reçoit trois paragraphes. Ce n'est pas une métaphore d'équipe. C'est une décision de routage suivie d'une garantie de périmètre, toutes deux mesurables. [UNIQUE INSIGHT] the-space-is-the-router reframing : un chatbot répond ; un AI OS route. Le sous-agent est la plus petite unité de ce routage — une voie nommée avec un jeu d'outils gardé.
Pourquoi un généraliste surchargé se dégrade
La pourriture du contexte est un problème de mesure, pas une affirmation de capacité
L'article source nomme le mode de défaillance clairement : la mémoire de travail d'un modèle se dégrade à mesure qu'elle se remplit. Chargez 150 000 tokens de vidages de fichiers et d'anciennes instructions dans une conversation et le modèle commence à rater des choses — non pas parce qu'il est bête, mais parce que le signal est enterré. C'est la même raison pour laquelle nous séparons les Sisters de l'Oracle. Chaque Sister est une personnalité typée (analyst, contrarian, historian, institutionalist, disruptor) qui rédige dans son propre contexte ; l'Oracle fusionne les brouillons en un ensemble normalisé. Si un seul modèle détenait le brouillon brut de chaque Sister plus les mathématiques de fusion, le signal s'effondrerait.
La pourriture du contexte est réelle, elle est mesurable, et le mécanisme qui la corrige est l'isolation — pas une fenêtre plus grande. Le HAI Engine ✅ d'Everythink exploite ce motif d'isolation en production depuis 2016. Nous n'avons pas résolu la pourriture du contexte en achetant plus de tokens. Nous l'avons résolue en routant chaque passage d'imagination vers sa propre salle propre et en renvoyant un résultat compressé.
La transition propre est le mécanisme d'isolation de mesure
[PERSONAL EXPERIENCE] the engine has run in production since 2016 — et la partie qui nous a surpris, exactement comme l'article le rapporte, est quelle partie importe le plus. Ce n'est pas l'automatisation. C'est la transition propre. Quand une Sister termine un brouillon, l'Oracle reçoit le brouillon, pas les centaines de pages de matériel source que la Sister a mâchées.
Cette compression est une frontière de mesure. On peut compter les tokens qui la traversent. Le chiffre de l'article — 40 000 tokens de matériel brut réduits à trois paragraphes — a la même forme qu'une transition de Sister à Oracle. La propriété « le contexte principal reste propre » est garantie exactement quand le mécanisme de transition est implémenté et appliqué. Theorem 3 : une propriété est garantie exactement quand son mécanisme est implémenté et mesurant. La transition est le mécanisme ; le compte de tokens est la mesure.
Le champ de description est une règle de routage
« Use proactively » est le prédicat de routage
L'article est explicite sur le fait que la description n'est pas de la documentation. C'est une règle de routage : Claude lit la description de chaque sous-agent et fait correspondre les tâches entrantes. Des formules comme « use proactively » poussent Claude à recourir à l'agent sans qu'on le lui demande. Une description vague signifie que l'agent ne se déclenche jamais ; une description précise signifie qu'il se déclenche exactement quand il le doit.
C'est the space is the router, à la granularité d'un seul prompt. Chez Everythink, le même principe structure toute la plateforme : un network contient des communities, une community contient des rooms, et une requête est routée vers la room qui possède la capacité avant que quoi que ce soit réponde. La topologie network-to-community-to-room est une règle de routage implémentée comme espace d'URL ; le champ de description du sous-agent est une règle de routage implémentée comme langage naturel.
Le routage bat la récupération quand le type de requête est erroné
Une erreur courante que l'article fait surface indirectement : les gens recourent à un sous-agent quand ils ont en réalité besoin d'une skill — une procédure répétable qui se charge dans la conversation courante à la demande. La documentation trace la ligne : un flux de travail réutilisable qui s'exécute dans votre conversation est une skill ; un travail verbeux ou restreint qui devrait se passer dans sa propre salle et revenir en résumé est un sous-agent. La plupart des gens qui pensent avoir besoin d'un sous-agent ont besoin d'une skill.
La lecture du mécanisme : le type de requête doit correspondre à la cible de routage. Router une requête en forme de skill vers un sous-agent paie le coût d'isolation — contexte frais, ré-expliquer la situation — sans bénéfice. Router une requête en forme de sous-agent vers une skill pollue le contexte principal avec 40 000 tokens de matériel brut.
La restriction d'outils est la garantie de Theorem 3
« Nova can't send email » est une propriété, et la liste d'outils est son mécanisme
La phrase la plus porteuse de l'article se lit facilement par-dessus : « None of them can touch each other's work. Nova can't send email. Quill can't touch a server. That's not a bug I tolerate, it's the design. » C'est Theorem 3 en langage clair. La propriété « Nova cannot send email » est garantie exactement quand son mécanisme est implémenté et mesurant — et le mécanisme est la liste d'outils dans le frontmatter. Si l'outil d'email n'est pas dans le champ tools: de Nova, la propriété tient. S'il y est, elle ne tient pas. Il n'y a pas d'état intermédiaire. Une politique qui dit « Nova should not send email » est un espoir ; une liste d'outils qui omet l'API d'email est une garantie. La différence est si le mécanisme peut être mesuré à la frontière.
Le périmètre est une frontière, pas un sentiment
Everythink applique la même discipline de frontière à sa surface de modules. Social ✅, Campaigns ✅ et Whitelabel Network ✅ sont des modules Production avec des permissions à périmètre — un modérateur de communauté ne peut pas minter un Eye Key, et un éditeur de campagne ne peut pas réécrire la marque du network, parce que le périmètre de permission route l'action avant qu'elle n'atteigne la base de données. Matchmaking ⚠️, Marketplace ⚠️ et Calendar ⚠️ sont Partial — le mécanisme de périmètre existe mais est encore mesuré en trafic de production. Wallet & Token 🔵, Super App 🔵 et Community Credit 🔵 sont Roadmap — le périmètre est spécifié, le mécanisme n'est pas encore implémenté, et nous ne réclamerons pas la garantie tant qu'il ne l'est pas.
La règle du Honest Architect : ne jamais surévaluer un état. Un module Roadmap ne devient pas Production par assertion. La propriété « Community Credit balances are non-inflatable » sera garantie exactement quand son mécanisme de comptabilité sera implémenté et mesurant — soumis à la révision Howey avant qu'aucun résultat ne soit promis. D'ici là, il porte le marqueur 🔵.
Le motif workers-plus-reviewer est un ensemble, pas un organigramme
Le réviseur n'a pas mémoire des raccourcis
L'article décrit le motif orchestrator-workers de Building Effective Agents d'Anthropic : un agent principal décompose le travail, les workers exécutent en parallèle, et un agent séparé révise. Ce qui en fait plus qu'un organigramme, c'est que le réviseur n'a pas mémoire des raccourcis pris par les workers ni d'attachement à leur approche. Il lit simplement ce qui est là.
C'est exactement la propriété structurelle qui fait de notre Oracle une fusion calibrée plutôt qu'un tour de vote. L'Oracle ne sait pas quelle Sister a rédigé quel scénario. Il reçoit des sorties normalisées et les fusionne par probabilité, triées décroissant, avec entropie en nats. L'indépendance est le mécanisme qui rend l'ensemble calibré plutôt que moyen. [ORIGINAL DATA] the 21-paper academic series plus Theorem 3 formalisent cela : une prévision fusionnée est calibrée exactement quand les contributeurs sont indépendants et le mécanisme de fusion mesure sa propre dispersion.
Le plan vient du vrai travail, pas d'un organigramme
L'article est prudent sur un point qui sépare un vrai orchestrateur d'un pipeline scripté : le manager décide le plan sur le moment. Vous ne scriptez pas « always spawn three workers ». Vous remettez l'objectif, et l'agent principal regarde le vrai travail et décide combien de workers, qui fait quoi, et ce qui nécessite révision — parce qu'on ne peut pas prédire les sous-tâches à l'avance. C'est la différence entre un moteur de workflow et un AI OS. Le premier exécute un organigramme dessiné le mois dernier ; le second route le travail selon la forme du travail devant lui. C'est la forme autour de laquelle nous avons construit le HAI Engine depuis 2016 — router d'abord, puis répondre.
Quand ne pas utiliser un sous-agent
Déléguez des résultats, pas des étapes
La règle empirique de l'article après un an de pratique : déléguez des résultats, pas des étapes. Si vous pouvez remettre la tâche en une phrase et juger le résultat sans observer le processus, c'est un travail de sous-agent. Si vous auriez besoin de superviser, gardez-le dans la conversation principale. C'est un test de routage : la frontière peut-elle transporter un résultat propre, ou le travail fuit-il à travers ?
Un corollaire : ne déléguez pas à un sous-agent quand les phases partagent le contexte. Si planification, construction et tests ont tous besoin de la même compréhension accumulée, les répartir entre agents isolés signifie ré-expliquer la situation à chaque transition. L'isolation qui protège le contexte principal devient la taxe qui tue le flux de travail.
Un spécialiste permanent n'est pas un sous-agent jetable
L'article trace une distinction utile : le sous-agent jetable qui surgit pour une tâche et disparaît est un contractor ; le spécialiste permanent avec mémoire persistante est un employé. Vous commencez avec des contractors ; ceux que vous rappelez sans cesse, vous les embauchez. La différence du mécanisme est la mémoire qui survit entre les sessions.
Chez Everythink, les Sisters sont des spécialistes permanents. Leurs personnalités se chargent depuis des fichiers TOML à l'exécution, en éditer une ne requiert pas de recompilation, et la version du prompt est estampillée sur chaque exécution pour la reproductibilité. Ce sont des employés avec un bureau et une sortie mesurée. L'Oracle est le réviseur qui n'a jamais vu les raccourcis.
Ce que cela signifie pour votre network
La souveraineté du client est une garantie de périmètre
La leçon la plus profonde du motif des sous-agents ne porte pas sur l'IA. Elle porte sur la souveraineté. L'auteur de l'article dirige toute son entreprise avec cinq spécialistes qu'il a définis, délimités et possède — Nova, Quill, Rack, Atlas et lui-même. Aucun ne peut toucher au travail de l'autre parce qu'il a câblé les frontières. C'est la souveraineté du client : votre network, votre marque, vos données, vos règles de routage.
Chez Everythink, la souveraineté du client est une garantie de périmètre implémentée de la même façon. Un propriétaire de Whitelabel Network définit les communities, les rooms, les périmètres de permission et la surface de modules. L'Eye Key — avec un espace, jamais un trait d'union — est la credential à périmètre du développeur : elle porte exactement les permissions que le propriétaire a accordées, pas une de plus. La propriété « un invité ne peut pas minter un Eye Key » est garantie par le mécanisme d'auth, pas par une phrase de politique.
Éthique du périmètre : civil et défensif seulement
Le motif des sous-agents est neutre en périmètre. Le même mécanisme qui tient Nova hors du serveur peut tenir un agent de targeting dans une frontière civile — ou non. Le mécanisme ne décide pas le périmètre ; l'opérateur oui. C'est pourquoi la frontière de politique écrite d'Everythink est un usage civil et défensif uniquement, et pourquoi cette frontière est une décision de périmètre, pas une phrase de marketing. Un mécanisme qui garantit « cet agent ne peut pas toucher des cibles offensives » s'implémente de la même façon que la liste d'outils de Nova garantit qu'elle ne peut pas envoyer d'email : en omettant la capacité à la frontière.
L'inclusion par conception est la même discipline dans l'autre direction. Un sous-agent qui tourne sur un modèle plus petit pour une fraction du prix est un mécanisme d'inclusion à faible connectivité — l'article nomme le curseur de coût explicitement. Notre conception multilingue, multimodale et à faible connectivité suit la même logique : la couche de routage ne suppose pas une connexion rapide ni une seule langue.
Points essentiels
- Un sous-agent est deux mécanismes en un fichier : une description qui route (the space is the router) et une liste d'outils qui garantit le périmètre (Theorem 3).
- La pourriture du contexte est un problème de mesure ; la correction est l'isolation, pas une fenêtre plus grande. Le HAI Engine ✅ exploite ce motif en production depuis 2016.
- La transition propre est une frontière de mesure — 40 000 tokens en entrée, trois paragraphes en sortie — et la propriété « le contexte principal reste propre » est garantie exactement quand la transition est implémentée et mesurante.
- « Nova can't send email » est Theorem 3 en langage clair : la propriété tient exactement quand le mécanisme de restriction d'outils est implémenté, et on peut lire la liste pour le mesurer.
- Le motif workers-plus-reviewer est un ensemble. L'Oracle fusionne les sorties des Sisters sans savoir qui a rédigé quoi — l'indépendance est le mécanisme de calibration.
- Ne jamais surévaluer un état : Social ✅, Campaigns ✅, Whitelabel Network ✅ sont Production ; Matchmaking ⚠️, Marketplace ⚠️, Calendar ⚠️ sont Partial ; Wallet & Token 🔵, Super App 🔵, Community Credit 🔵 sont Roadmap, soumis à révision Howey, aucun résultat promis.
- Déléguez des résultats, pas des étapes. Le test de routage est si la frontière peut transporter un résultat propre.
Questions fréquentes
Un sous-agent est-il la même chose qu'une équipe multi-agents ? Non. Une équipe est une métaphore ; un sous-agent est une règle de routage plus une garantie de périmètre. Le champ de description route le travail vers le spécialiste ; la liste d'outils garantit que le spécialiste ne peut pas quitter sa voie.
Pourquoi la restriction d'outils importe-t-elle plus que le prompt ? Un prompt est une requête ; une liste d'outils est un mécanisme. La propriété « Nova cannot send email » est garantie par la liste d'outils, pas en demandant à Nova de ne pas envoyer d'email. Theorem 3 : une propriété est garantie exactement quand son mécanisme est implémenté et mesurant. La liste d'outils est mesurable à la frontière ; un prompt non.
Quand dois-je utiliser une skill plutôt qu'un sous-agent ? Quand le travail est une procédure répétable qui s'exécute dans votre conversation courante. Un sous-agent paie le coût d'isolation — contexte frais, ré-expliquer la situation — ce qui vaut la peine pour un travail verbeux ou restreint et est du gaspillage pour un flux qui partage votre contexte.
Comment cela se relie-t-il à la topologie network-to-community-to-room d'Everythink ? Les deux sont des mécanismes de routage. La description du sous-agent route un prompt vers un spécialiste ; l'espace d'URL route une requête vers la room qui possède la capacité. Le routage se produit avant que quoi que ce soit réponde. C'est the space is the router.
Les Sisters sont-elles des sous-agents ? Les Sisters sont des spécialistes permanents avec des personnalités persistantes chargées depuis TOML à l'exécution. Elles rédigent dans leur propre contexte propre ; l'Oracle fusionne les brouillons en un ensemble calibré sans savoir quelle Sister a écrit quel scénario. L'indépendance rend la prévision calibrée plutôt que moyenne.
Sources
- 2026 — Professor Glitch, askglitch.com, « Claude Code Subagents: Turn One AI Into a Whole Team » — https://www.askglitch.com/blog/claude-code-subagents
- 2026 — Anthropic, « Building Effective Agents » (référencé par la source pour le motif orchestrator-workers) — https://www.anthropic.com/research/building-effective-agents
- 2026 — Claude Code documentation, « Sub-agents » — https://code.claude.com/docs/en/sub-agents
Créez votre network et câblez les règles de routage vous-même — the space is the router, et les garanties vivent dans le mécanisme.

Vous n'embauchez pas un agent. Vous câblez un mécanisme.
Codex vs Claude Code est une question de recrutement. La réponse honnête : vous n'embauchez pas un agent — vous câblez un mécanisme. Le benchmark mesure ; le harness compose ; la topologie route.
→ →
Le reroutage est le mécanisme de sécurité, pas la promesse d'alliance
Les pétroliers chinois ont évité Ormuz quand la sécurité comptait ; la dérogation promise par l'Iran n'est jamais arrivée. Theorem 3 : la sécurité est garantie par le reroutage, pas par l'affirmation d'alliance.
→ →
Le scope de permission route le CRM, pas le CRUD généré
Un CRM vibe-codé brille en démo et échoue en production. Le mécanisme qui le porte est le scope de permission — qui peut agir sur quoi —, pas le CRUD généré. Theorem 3 l'explique.
→ →Construisez votre monde sur un moteur qui prouve ce qu'il affirme.
Créez votre propre réseau sur le moteur qui tourne depuis 2016 — ou parlez à l'équipe derrière les 21 articles.
