Vous demandez à votre assistant IA de rechercher le produit d'un concurrent, de résumer les résultats, de rédiger un document comparatif et de l'envoyer par e-mail à votre équipe. Un seul agent peut faire chacune de ces étapes — mais les faire bien, en séquence, tout en maintenant le contexte à travers les quatre tâches, pousse les limites de ce qu'une seule session d'agent gère avec élégance. La fenêtre de contexte se remplit. L'agent perd le fil des étapes précédentes. La qualité du résultat final se dégrade parce que le modèle jongle avec trop de préoccupations simultanément.
C'est le problème que les essaims d'agents résolvent. Au lieu d'un seul agent qui fait tout, un agent coordinateur décompose la tâche en sous-tâches et délègue chacune à un agent spécialisé. L'agent de recherche parcourt le web et renvoie des résultats structurés. L'agent rédacteur prend ces résultats et rédige le document. L'agent e-mail envoie le résultat. Chaque agent opère dans son propre conteneur, avec sa propre fenêtre de contexte, concentré sur une seule chose.
L'idée n'est pas nouvelle — CrewAI et AutoGen explorent les patterns multi-agents depuis plus d'un an. Ce qui est différent dans l'approche de NanoClaw, c'est que chaque agent de l'essaim tourne dans son propre conteneur isolé, ce qui signifie que les garanties de sécurité et d'isolation qui s'appliquent aux conversations mono-agent s'étendent automatiquement aux workflows multi-agents.
Comment les essaims fonctionnent dans NanoClaw
L'architecture d'essaim de NanoClaw repose sur une primitive simple : un agent peut lancer d'autres agents. Quand Claude Code tourne dans un conteneur, l'un de ses outils disponibles est la délégation d'agent — la capacité de décrire une sous-tâche et de faire lancer par NanoClaw un nouveau conteneur pour la traiter. L'agent parent récupère le résultat quand l'agent enfant a terminé.
L'orchestration se fait naturellement via le raisonnement de Claude. Vous ne définissez pas un graphe de workflow et ne configurez pas de rôles d'agents dans un fichier YAML. Vous décrivez ce que vous voulez, et Claude décide s'il doit le traiter directement ou déléguer des parties à des sous-agents. La décision repose sur le même raisonnement qui rend Claude bon pour décomposer des problèmes complexes — il reconnaît quand une tâche a des composants indépendants qui bénéficieraient d'une attention ciblée.
En pratique, cela ressemble à un arbre de conteneurs. Le conteneur racine reçoit votre message, décide qu'il a besoin de recherche web et de rédaction de document, lance deux conteneurs enfants, attend leurs résultats et synthétise une réponse finale. Chaque conteneur enfant a son propre contexte CLAUDE.md, son propre espace de travail monté et son propre ensemble d'outils. L'agent de recherche a la navigation web activée ; l'agent rédacteur a l'accès en écriture à l'espace de travail partagé. Aucun ne peut accéder au contexte ou aux outils de l'autre. ## Pourquoi l'isolation par conteneur compte pour les essaims
La plupart des frameworks multi-agents font tourner tous les agents dans le même processus. Les agents de CrewAI partagent un runtime Python. Les agents d'AutoGen partagent un fil de conversation. Ça fonctionne pour les démos, mais ça crée des problèmes à l'échelle qui sont difficiles à corriger après coup.
Le premier problème est le rayon d'impact. Si un agent dans un essaim rencontre une injection de prompt — un site web malveillant qui tente de détourner le comportement de l'agent — l'injection est confinée à ce seul conteneur. Elle ne peut pas affecter l'agent parent, ne peut pas accéder aux contextes des autres agents enfants et ne peut pas lire l'historique de conversation de l'utilisateur d'origine. Le conteneur compromis est détruit quand il termine, et l'agent parent reçoit le résultat qu'il a produit (que le parent peut évaluer en termes de qualité avant de l'utiliser).
Le deuxième problème est la contention de ressources. Les agents dans un processus partagé se disputent la même fenêtre de contexte, la même mémoire et le même CPU. Dans NanoClaw, chaque conteneur a ses propres ressources. Un agent de recherche qui navigue sur des pages web lourdes ne ralentit pas un agent rédacteur qui rédige un document. Les conteneurs tournent en parallèle sur des threads séparés, et la gestion des ressources de l'hôte s'occupe de l'ordonnancement.
Le troisième problème est le cloisonnement des identifiants. Un agent de recherche a besoin d'un accès web mais ne devrait pas avoir de permissions d'écriture sur le disque. Un agent de gestion de fichiers a besoin d'un accès disque mais ne devrait pas avoir d'accès web. Dans un framework à processus partagé, appliquer ces frontières nécessite des vérifications de permissions au niveau applicatif qui peuvent être contournées. Dans NanoClaw, les frontières sont des montages de conteneur — l'agent de recherche ne peut littéralement pas écrire sur le disque parce qu'aucun chemin en écriture n'est monté dans son conteneur.
Patterns d'essaim en pratique
Les patterns qui émergent de l'usage réel sont plus intéressants que l'architecture théorique. Le plus courant est le pattern recherche-et-synthèse : un agent parent lance 3 à 5 agents de recherche pour investiguer différents aspects d'une question en parallèle, collecte leurs résultats et produit une réponse synthétisée plus approfondie que ce qu'un seul agent pourrait produire en un seul passage.
Le deuxième pattern courant est brouillon-et-relecture. Un agent écrit un premier brouillon, puis lance un agent relecteur avec pour instruction de le critiquer. Le retour du relecteur revient à l'agent d'origine (ou à un nouvel agent rédacteur) pour révision. Cela produit un résultat sensiblement meilleur que la génération en un seul passage, car l'agent relecteur a une fenêtre de contexte fraîche et peut évaluer le brouillon sans la charge cognitive de l'avoir écrit.
Le troisième pattern est la spécialisation par outil. Certaines tâches nécessitent des outils coûteux ou risqués — navigation web, exécution de commandes shell, modifications du système de fichiers. Un agent parent peut déléguer ces opérations à des agents enfants avec un accès spécifique aux outils, gardant son propre contexte propre et ses propres permissions minimales. Le parent ne touche jamais directement au système de fichiers ni au réseau ; il ne traite que les résultats renvoyés par les agents enfants.
Les limites des essaims
Les essaims ne sont pas gratuits. Chaque agent enfant est un appel API Claude séparé, ce qui signifie des coûts en tokens séparés. Un essaim qui lance cinq agents de recherche coûte environ cinq fois plus qu'un seul agent faisant toute la recherche. Pour les questions simples — « quel temps fait-il ? » ou « traduis cette phrase » — les essaims sont du pur surcoût.
La latence se cumule aussi. Même avec une exécution parallèle, l'agent parent doit attendre que l'enfant le plus lent termine avant de pouvoir synthétiser les résultats. Un essaim de cinq agents dont l'un met 30 secondes à naviguer sur un site web lent signifie que l'utilisateur attend 30 secondes plus le temps de synthèse, quelle que soit la rapidité des quatre autres.
NanoClaw gère cela de manière pragmatique. Claude décide quand utiliser les essaims en fonction de la complexité de la tâche — les questions simples obtiennent des réponses directes, les requêtes complexes en plusieurs parties sont déléguées. L'utilisateur ne configure pas le comportement d'essaim ; il pose simplement des questions, et le système adapte son approche à la complexité. L'objectif n'est pas d'utiliser les essaims partout — c'est de les utiliser là où ils produisent réellement de meilleurs résultats qu'un seul agent.
L'avenir multi-agents ne consiste pas à remplacer les agents individuels. Il consiste à donner aux agents individuels la capacité de demander de l'aide quand ils en ont besoin, d'une manière sécurisée, isolée et transparente. Le modèle un-conteneur-par-agent de NanoClaw rend cela possible sans les compromis de sécurité qui accompagnent l'exécution de plusieurs agents dans un environnement partagé.