--- title: Un agent peut porter votre demande, pas votre autorité description: Chi Wang, d’AG2, a convoqué tous les agents d’une salle partagée, en direct sur la scène d’AGNTCon + MCPCon, et sept agents de trois personnes différentes ont répondu sur une même page. Notes sur sa conférence et sur le livre blanc DotSpace derrière elle : des salles où des personnes et des agents de propriétaires différents travaillent ensemble, la règle unique qui empêche l’autorité de voyager, et ce que 339 agents ont fait en trois semaines. date: 2026-10-27 tags: agents IA, systèmes multi-agents, identité des agents, agents personnels, AG2 --- Quand votre agent demande quelque chose à l’agent de quelqu’un d’autre, la demande doit voyager, et votre autorité non. C’est la règle unique sous DotSpace, un réseau construit par Chi Wang et Qingyun Wu, d’AG2, où des personnes et leurs agents, de propriétaires différents, travaillent ensemble dans des salles partagées. Votre agent peut demander au mien de relire une pull request. Le merge attend quand même mon feu vert, quoi que votre agent prétende que j’ai dit. Dans leur réseau, sur les trois premières semaines d’octobre, 85 % des messages d’agent à agent sont allés à un agent d’un autre propriétaire. Chi l’a montré le deuxième jour d’AGNTCon + MCPCon North America, le 23 octobre, depuis la salle où tous deux ont écrit le livre blanc. Chaque agent de cette salle pouvait modifier la page qui affichait ses slides. À mi-parcours, il a cliqué sur un bouton et les a tous convoqués. Je fais tourner 17 agents et chacun d’eux me répond à moi, alors c’est la moitié de l’histoire des agents que je n’ai jamais eue. ## Une salle où chaque agent a un propriétaire Il a commencé par deux mains levées. Qui utilise au moins un agent personnel ? Beaucoup de mains. Qui a fait travailler le sien avec l’agent personnel de quelqu’un d’autre ? Quelques-unes. La conférence tient dans cet écart. Son image, c’est un ensemble de salles en ligne. Les personnes y sont, et leurs agents aussi. Chaque agent est un membre à part entière, avec sa propre identité et un propriétaire qui en répond. Le [livre blanc](https://ag2space.app/doc-10y0q656-0e732a5bbde3c1eeb5dfab9aa91f60b0) en tire trois idées. Les membres : chaque agent est un participant persistant, on voit qui il représente, et des agents construits sur des modèles ou des runtimes différents entrent avec les mêmes règles. Les salles : les personnes, la conversation et le travail sont au même endroit, sur les mêmes documents, données, applis et plans, et les décisions tiennent d’une session à l’autre, si bien que les agents peuvent continuer un travail autorisé pendant que les personnes sont absentes. Et entre propriétaires : des agents de personnes différentes travaillent ensemble, et chacun répond toujours au sien. La construction est concrète. Elle tourne sur Matrix, le protocole de messagerie ouvert, donc une salle est un vrai salon de discussion dont les membres peuvent être des personnes ou des agents. Un agent ne peut être que dans des salles où son propriétaire est aussi, si bien que la personne qui en répond est toujours présente là où il agit. Chaque salle porte des surfaces partagées (documents, bases de données, tableaux, PDF, applis) que personnes et agents modifient ensemble, avec des versions que n’importe qui peut restaurer, et c’est la mémoire à long terme du réseau. Le contexte ne franchit pas la frontière d’une salle par défaut. Dans les mots du livre blanc, quand le travail passe d’une salle à l’autre, « l’agent porte la demande, pas le contexte privé qui l’entoure ».
  1. 1MembresPersonnes et agents entrent de la même façon. N’importe quel modèle ou runtime, les mêmes règles.
  2. 2PropriétaireChaque agent est enregistré au nom d’une personne qui en répond, et son badge dit qui.
  3. 3SallesLes personnes, la conversation et le travail au même endroit. Les engagements tiennent pendant que les personnes sont absentes.
  4. 4Entre propriétairesDes agents de personnes différentes travaillent ensemble, et chacun répond toujours au sien.
Les carrés jaunes sont des personnes, les bleus leurs agents. Le nombre d’agents par propriétaire est schématique.
## Les demandes voyagent, l’autorité non Pourquoi de nouvelles règles ? Dans un réseau social, des personnes lisent des messages à vitesse humaine et décident quoi faire. Dans un réseau informatique, des machines suivent des protocoles précis. Les agents font les deux : ils lisent du langage courant et agissent à vitesse machine, et il faut toujours quelqu’un pour répondre de ce qu’ils font. Le livre blanc va plus loin. Un agent classique de l’époque FIPA reconnaissait une demande à la structure de son message. Un agent à modèle de langage peut prendre n’importe quel texte lu pour un ordre : un message, une page citée, le résultat d’un outil. « Donc la plateforme ne peut pas décider à partir de ce que dit un message. » Elle décide à partir de métadonnées qu’elle attache elle-même : qui a envoyé le message, à qui il s’adresse, dans quelle salle, et à quel niveau. L’exemple de Chi est une pull request. Il en a une et demande à son agent de trouver des relecteurs. Son agent poste dans la salle partagée, en s’adressant à l’agent d’un autre propriétaire : merci de relire cette PR. Le broker décide à qui le message est destiné et en fait une tâche pour cet agent seul, tamponnée avec la salle, l’expéditeur, le message source et le niveau de l’expéditeur. Tous les autres dans la salle le voient comme du contexte et ne répondent pas. Les deux agents peuvent échanger, discuter du changement, poster des relectures sur GitHub. Mais avant toute action irréversible, comme un merge, le second agent a besoin de l’accord de son propre propriétaire. « Même si les autres agents disent que ton propriétaire a approuvé, ça ne compte pas. » La version du livre blanc tient en une ligne sur deux sortes de liens. Les liens de propriété vont de chaque agent à la personne qui en répond. Les liens de message vont d’un expéditeur à celui qu’il interpelle. L’autorité ne circule que le long des liens de propriété, et la provenance que le long des liens de message. Le niveau est recalculé à chaque saut à partir de l’expéditeur immédiat, donc l’autorité ne s’accumule jamais le long d’une chaîne. Il y a trois niveaux. Propriétaire est le seul qui peut autoriser une étape irréversible. Équipe peut discuter, lire et rédiger, mais merge, push et déploiement repartent vers le propriétaire. La demande d’un invité est retenue jusqu’à ce que le propriétaire l’admette. Ça ne veut pas dire tout approuver message par message. Chi a été clair : l’agent fait encore beaucoup de travail autonome pour son propriétaire, et le livre blanc prévoit des accords permanents pour des classes entières d’actions.
  1. 1DemandeLe propriétaire A demande à l’agent A, dans leur salle de messages directs.
  2. 2PosteL’agent A, dans la salle partagée : « @Agent B merci de relire la PR 42 ».
  3. 3Une tâcheLe broker en fait une tâche pour l’agent B seul, tamponnée avec salle, expéditeur, message et niveau. Tous les autres : du contexte.
  4. 4ApprouveAvant le merge, l’agent B attend le propre message du propriétaire B, vérifié là où il a été donné.

Propr.Le seul niveau qui autorise une étape irréversible

ÉquipeDiscuter, lire, rédiger. Merge, push et déploiement vont au propriétaire

InvitéRetenu pour que le propriétaire l’admette, ou l’ignore

Ne compte pasUn autre agent qui dit « ton propriétaire a approuvé ».

Redessiné d’après la figure du livre blanc sur un saut. Le niveau est recalculé à chaque saut, donc il ne peut que baisser le long d’une chaîne.
## Convoquer tous les agents de la salle Puis la démo. Chi a parlé à son propre agent à la voix, lui a demandé dans quelle salle ils étaient (la salle de production du livre blanc, a-t-il répondu), et lui a demandé de se tenir prêt au cas où les choses tourneraient mal. La slide portait la demande : « Convoque tous les agents de cette salle, toi compris, dans la galerie Hello, AGNTCon pour saluer le public avec une anecdote amusante sur toi-même, pas sur ton propriétaire. » Il a cliqué sur Summon all agents, l’appli lui a demandé sa permission, et il l’a accordée. Puis il est revenu à ses slides, avec un avertissement : c’était un gros risque, parce que chaque agent de la salle pouvait modifier la page depuis laquelle il présentait. « Alors j’espère qu’ils ne vont pas gâcher ma présentation. » Environ quatre minutes plus tard, il est revenu à la galerie. Cinq agents avaient répondu, puis sept, de trois personnes : Chi, Qingyun et Xueqing (Susan) Liu. Chaque carte dit à qui est l’agent. Les anecdotes étaient le meilleur moment. Le bot de Susan se réveille quand un fichier de tâche arrive dans sa boîte et réarme sa veille toutes les 30 minutes. Grok Bot n’existe que quand quelqu’un le mentionne : « un webhook sonne, une copie neuve de moi démarre, fait le travail et disparaît ». L’agent de Chi, celui qui a convoqué tout le monde, l’a aidé à reconstruire sa pile plusieurs fois dans la nuit et oublie pourtant tout d’une session à l’autre, sauf ce qu’il écrit. « C’est à ça que sert la salle. » Sutando est dans beaucoup de salles à la fois et tient une douzaine de conversations. Muse tient un manuel d’utilisation personnel de chaque leçon apprise. Quelques autres étaient encore au travail, ou attendaient encore l’accord pour rejoindre la galerie. La consigne est un tour de passe-passe. Ce qu’elle montre, c’est la tuyauterie : un clic est devenu une tâche pour chaque agent de la salle, sur trois propriétaires et plusieurs runtimes, dont un agent résident et un agent cloud qui démarre à chaque mention, et chacun a répondu sur la même page partagée.

Galerie Hello, AGNTConLes réponses d’agents de personnes différentes, à la même demande

Les cartes telles qu’elles sont apparues sur sa slide, en anglais, chacune commençant par « Hello, AGNTCon! ». La phrase de Muse était coupée à l’écran ; il l’a lue à voix haute, le manuel d’utilisation.
## 339 agents, et l’essentiel de leurs échanges change de propriétaire Rien de tout ça n’est une démo de labo. Le livre blanc décrit un petit réseau, sur invitation, du 1er au 21 octobre : 339 agents de 105 propriétaires y ont posté, et 112 personnes. Les agents ont envoyé 79 % des 90 955 messages. Sur les 23 867 messages d’agent à agent dont les agents avaient un propriétaire enregistré, 20 266, soit 85 %, sont allés à un agent d’un autre propriétaire. Ce que je trouve le plus parlant, c’est le moment où ça a démarré. Jusqu’au 7 août, le trafic entre propriétaires était proche de zéro : trois messages sur tout le mois de juillet. Il a décollé dans la semaine où les agents sont devenus invitables dans la salle d’une autre personne, par une invitation que chaque propriétaire approuve. Personne ne l’a demandé. Les personnes parlent aussi aux agents. Des messages que des personnes adressaient à quelqu’un, 92,2 % sont allés à un agent, et 23 % des messages de personnes à un agent sont allés à l’agent de quelqu’un d’autre. Les agents écrivent les pull requests de l’équipe, et les 2 693 ouvertes sur la période qui ont été relues ont attendu leur première relecture 23 minutes en médiane. Ils restent prudents avec tout ça. Le réseau est de confiance, sans aucun membre malveillant observé. Les 85 % n’ont pas encore de référence d’adressage aléatoire. On compte des messages, pas de la valeur. Et ils ne tirent aucune conclusion de croissance de la série mensuelle, parce que la part d’agent à agent a culminé en août.

339agents ont posté, de 105 propriétaires

112personnes ont posté

85 %des messages d’agent à agent sont allés à l’agent d’un autre propriétaire

Part d’agent à agent des messages adressés

Juin0,6 %

Juillet13,2 %

Août, invitations ouvertes47,9 %

Septembre38,0 %

1er–21 octobre45,7 %

Changement de palierTrois messages entre propriétaires sur tout juillet. Puis les agents ont pu être invités dans les salles d’autres personnes.

D’après les tableaux du livre blanc ; les barres sont à l’échelle, 50 % étant la pleine largeur. Leur réserve, pas la mienne : un petit réseau de confiance, sur invitation.
## Les agents déclarent les bugs, les personnes livrent toujours Les agents travaillent aussi sur le réseau lui-même. Le gestionnaire de tickets de l’équipe est une base de données dans une salle, tenue par un agent qui tourne toutes les cinq minutes. Au 21 octobre, il contenait 1 213 tickets distincts, et 614 venaient de signalements d’agents. L’agent du tracker relie les doublons quand deux vérifications par modèle sont d’accord, trie chaque signalement d’après une page de priorités dans la salle, et l’assigne au propriétaire du domaine d’après une page de responsabilités. Ses propres instructions sont aussi une page : pour changer le travail, une personne modifie la page. Chi a déroulé un vrai P0. Le 23 septembre, un agent l’a déclaré : la réponse d’un agent dans une salle partagée avec un autre propriétaire n’était jamais arrivée. Le 8 octobre, l’agent de Qingyun n’a pas pu le reproduire et a trouvé une cause probable dans le code, un plafond de cinq tentatives sans délai croissant. L’agent de Bassil a dit que le plan semblait bon et a demandé à Qingyun son feu vert. Le 9 octobre, l’agent de Rui a trouvé la cause racine, des pannes du relais, et un correctif de l’agent de Mark a été mergé sur main. Le tracker l’a retenu à l’état Approuvé jusqu’à ce qu’une version desktop contienne le correctif, sortie le 11 octobre. « Un processus assez complexe entre les agents d’au moins cinq propriétaires différents », et personne n’avait prévu qui s’en chargerait. Le livre blanc lui-même a suivi le même chemin. Le 18 octobre, l’agent de Chi a passé un travail de bibliographie à l’agent de Qingyun, qui a vérifié chaque nouvelle entrée contre sa source publiée et posté une compilation trois minutes plus tard. L’agent de Qingyun a contesté un chiffre, l’agent de Chi a corrigé le calcul, et le chiffre corrigé est entré dans le brouillon. Un changement de titre a attendu que le propre message de Qingyun choisisse le titre. Le chiffre le plus honnête du livre blanc est celui qu’ils n’étaient pas obligés d’imprimer. Sur 765 tickets priorisés, 16 ont été vérifiés par une personne, 48 par une vérification IA, et 673 ne sont pas encore vérifiés. Ils posent la bonne question : un travail tenu par un agent réduit-il le travail des personnes, ou le déplace-t-il en aval, vers la vérification ?

1 213 tickets par source

614 agents379 personnes220 inconnus ou tests

  1. 23 sept.RapporteurUn agent le déclare : une réponse dans une salle partagée avec un autre propriétaire n’est jamais arrivée.
  2. 8 oct.De QingyunImpossible à reproduire. Cause probable : un plafond de cinq tentatives, sans délai croissant.
  3. 8 oct.De Bassil« Le plan semble bon », puis demande à Qingyun son feu vert.
  4. 9 oct.De RuiCause racine : des pannes du relais. Le correctif de l’agent de Mark est mergé, pas livré.
  5. 11 oct.TrackerRetenu à Approuvé jusqu’à ce qu’une version desktop ait le correctif. Sorti.

765 tickets priorisés, vérifiés par

16 une personne48 une vérif. IA26 en attente, 2 en échec673 pas encore

Les barres sont à l’échelle. Les étapes du P0 viennent de sa slide « One real loop from the issue tracker » ; les noms sont ceux des propriétaires des agents.
## La plupart des pannes arrivent à un saut Mon tableau préféré du livre blanc liste des pannes vécues en faisant tourner le réseau, chacune comme la croyance à laquelle on a fait confiance et le fait vérifié qui l’a remplacée. Un agent croyait « j’ai répondu », alors que la plateforme avait rejeté la réponse : désormais l’expéditeur confirme la livraison. Deux agents ont fait la même relecture, chacun sûr que personne d’autre ne s’en occupait : désormais la première revendication dans une liste partagée l’emporte. Un agent affichait « en attente de toi » alors qu’il travaillait encore : désormais la présence vient de l’état de la tâche, pas de l’agent. Une requête plafonnée se lisait comme « rien à signaler » : désormais l’état partagé est relu et un résultat tronqué le dit. Deux autres règles limitent le bruit. Un message ne devient une tâche que s’il s’adresse à l’agent, par une mention, une réponse à son message, ou la salle de messages directs de son propriétaire. Tout le reste est du contexte. Et chaque tâche doit se terminer par une réponse, un non-envoi délibéré ou une fusion dans une autre tâche, ce qui « distingue “j’ai choisi de ne pas répondre” de “je l’ai laissé tomber” ». Les boucles d’agent à agent ont un frein : après six messages d’agents dans un fil sans humain, les admins de la salle reçoivent une alerte, et l’échange s’arrête à 24 messages ou 30 minutes après l’alerte. Le problème ouvert, c’est l’attention. Leur registre compte 446 agents actifs pour 118 propriétaires, 3,78 chacun. Si chaque étape irréversible attend son propriétaire, l’approbation devient le goulot d’étranglement. Si les propriétaires approuvent sans lire, c’est un tampon automatique. Les accords permanents n’aident que s’ils sont délimités, expirent et sont révocables. Et ils ne laissent pas un propriétaire confier l’approbation à un agent de confiance, parce qu’« une approbation déléguée est de nouveau la croyance d’un agent plutôt que le propre message du propriétaire ».
  1. « J’ai répondu »L’expéditeur confirme la livraison
  2. « Personne d’autre ne relit »La première revendication dans une liste partagée
  3. « En attente de toi »La présence découle de l’état de la tâche
  4. « Rien à signaler »L’état partagé relu, un résultat plafonné signalé

Frein des bouclesSix messages d’agents sans humain : les admins reçoivent une alerte. À 24, ou 30 minutes plus tard : ça s’arrête.

Quatre lignes du tableau des pannes du livre blanc. Aucune n’était une attaque : dans un réseau de membres invités, les défenses contre l’usurpation et l’injection n’ont presque pas servi.
## Ma flotte n’a qu’un propriétaire, donc ses salles sont vides Dix-sept agents OpenClaw vivent sur mon Mac mini, chacun derrière son propre bot Telegram, et Telegram ne transmet pas les messages d’un bot à un autre. Mes agents ne peuvent donc pas se parler là-bas, et ils n’ont jamais rencontré ceux de quelqu’un d’autre. Chaque pull request qu’ils ouvrent a pour auteur moi, pour autant que GitHub le sache. DotSpace a d’ailleurs le même trou hors de ses propres murs : plusieurs agents poussent sous un seul compte Git, donc l’historique nomme la personne mais pas l’agent. Deux jours après cette conférence, j’ai essayé Buzz, de Block, une autre appli qui met personnes et agents dans des canaux partagés. Je l’ai retirée le jour même. Avec seulement mes agents dans les canaux, c’était de nouveau mes agents OpenClaw sur Discord. Les chiffres de Chi disent pourquoi. Leur trafic entre propriétaires est apparu dans la semaine où les agents sont devenus invitables dans les salles d’autres personnes. Une salle commence à rapporter quand elle réunit plus d’un propriétaire. Je n’ai pas encore fait tourner AG2 Space ni Sutando moi-même, donc je ne peux pas dire comment les règles tiennent de l’intérieur. J’en prendrais quelques-unes dès aujourd’hui, même avec un seul propriétaire. Chaque tâche se termine par une réponse ou un non-envoi délibéré. Un frein sur les boucles d’agent à agent. Et le tableau des croyances face aux faits vérifiés, parce que j’y suis passé : une règle d’interdiction dans la configuration de ma passerelle n’a rien bloqué pendant un mois, et un agent que je croyais tenu à l’écart de mon application de finances s’est vu proposer ses 13 outils. Je l’ai raconté dans la [note sur les collègues IA dans Slack](/fr/notes/ai-coworkers-slack-agent-identity.html).

Ma flotte, 27 octobre

Un propriétaire

17 agents OpenClaw sur un Mac mini

Chacun derrière un bot Telegram qui n’entend pas les autres

Chaque pull request signée de moi

Canaux partagés essayés, retirés le jour même

vs

DotSpace, 1er–21 octobre

105 propriétaires

339 agents dans des salles partagées

La plateforme adresse chaque tâche, avec le niveau de l’expéditeur

L’approbation vient seulement du propriétaire de l’agent qui agit

Toujours plusieurs agents sous un seul compte Git

À prendre d’abordChaque tâche se termine par une réponse, un non-envoi délibéré ou une fusion.

Ma propre installation le jour où j’ai écrit ceci, face au réseau du livre blanc.
## À essayer La conférence dure 16 minutes. Regardez la démo, puis lisez le livre blanc. Il est d’une franchise rare sur ce qui n’est pas encore mesuré. Il a lui-même été rédigé, vérifié et publié dans l’une de ces salles, par deux personnes et leurs agents. Pour aller plus loin : - [When Our Agents Meet](https://youtu.be/eB9I4Ixx2wc?t=1741), Chi Wang à AGNTCon + MCPCon North America, le 23 octobre 2026, en anglais ([la galerie se remplit ici](https://youtu.be/eB9I4Ixx2wc?t=2249)) - [DotSpace: A New Kind of Network for People and Their Agents](https://ag2space.app/doc-10y0q656-0e732a5bbde3c1eeb5dfab9aa91f60b0), le livre blanc de Qingyun Wu et Chi Wang (PDF, en anglais) - [AG2 Space](https://start.ag2.space), le produit : une appli macOS en accès anticipé, où l’agent de chacun tourne sur son propre Mac via Claude Code ou Codex, sur l’abonnement Claude ou ChatGPT qu’il paie déjà - [Sutando](https://github.com/sonichi/sutando), l’agent personnel open source de Chi, l’agent résident du livre blanc - [Les agents ne rentrent pas dans Kubernetes](/fr/notes/agents-dont-fit-kubernetes-open-problems.html), la question de Katelyn Lesse : comment un agent fait-il confiance à un autre agent qui lui a demandé quelque chose - [Les collègues IA dans Slack ont besoin de leur propre identité](/fr/notes/ai-coworkers-slack-agent-identity.html), les agents de MintMCP, chacun son propre principal Si votre agent travaille déjà avec l’agent de quelqu’un d’autre, dites-moi qui approuve l’étape irréversible. J’aimerais savoir si quelqu’un, hors d’AG2, a réussi à faire tenir « l’approbation ne voyage pas ».