--- title: An agent can carry your request, not your authority description: Chi Wang of AG2 summoned every agent in a shared room, live on stage at AGNTCon + MCPCon, and seven agents of three different people answered on one page. Notes on his talk and the DotSpace white paper behind it, rooms where people and agents of different owners work together, the one rule that keeps authority from travelling, and what 339 agents did in three weeks. date: 2026-10-27 tags: AI agents, multiagent systems, agent identity, personal agents, AG2 --- When your agent asks someone else's agent for something, the request should travel and your authority shouldn't. That's the one rule under DotSpace, a network built by Chi Wang and Qingyun Wu of AG2, where people and their agents from different owners work together in shared rooms. Your agent can ask mine to review a pull request. The merge still waits for me, whatever your agent says I said. In their network, 85% of agent-to-agent messages in the first three weeks of October went to an agent with a different owner. Chi showed it on day two of AGNTCon + MCPCon North America, October 23, presenting from the room where the two of them wrote the white paper. Every agent in that room could edit the page his slides ran on. Halfway through, he clicked a button and summoned them all. I run 17 agents and every one of them answers to me, so this is the half of the agent story I've never had. ## A room where every agent has an owner He opened with two shows of hands. Who uses at least one personal agent? Lots of hands. Who has made theirs work with someone else's personal agent? A few. The talk lives in that gap. His picture is a set of online rooms. People are in them, and so are their agents. Each agent is a member of its own, with its own identity and an owner who's responsible for it. The [white paper](https://ag2space.app/doc-10y0q656-0e732a5bbde3c1eeb5dfab9aa91f60b0) turns that into three ideas. Members: every agent is a persistent participant, you can see whom it represents, and agents built on different models or runtimes join under the same rules. Rooms: people, the conversation and the work sit together, on the same documents, data, apps and plans, and decisions carry over between sessions, so agents can keep doing authorized work while the people are away. And across owners: agents of different people work together while each still answers to its own. The build is concrete. It runs on Matrix, the open messaging protocol, so a room is a real chat room whose members can be people or agents. An agent can only be in rooms its owner is in too, so the person who answers for it is always present where it acts. Each room carries shared surfaces (docs, databases, boards, PDFs, apps) that people and agents edit together, with versions anyone can restore, and that's the network's long-term memory. Context doesn't cross a room boundary by default. In the paper's words, when work moves between rooms, "the agent carries the request, not the private context around it."
  1. 1MembersPeople and agents join the same way. Any model or runtime, the same rules.
  2. 2OwnersEvery agent is registered to one person who answers for it, and its badge says who.
  3. 3RoomsThe people, the conversation and the work in one place. Commitments carry over while people are away.
  4. 4Across ownersAgents of different people work together, and each still answers to its own.
The yellow squares are people, the blue ones their agents. The number of agents per owner is schematic.
## Requests travel, authority doesn't Why new rules at all? In a social network, people read messages at human speed and decide what to do. In a computer network, machines follow precise protocols. Agents do both: they read plain language and they act at machine speed, and someone still has to answer for what they do. The paper makes the sharper point. A classic agent from the FIPA days could tell a request from the structure of its message. A language-model agent may take any text it reads as a command: a message, a quoted page, a tool result. "So the platform cannot decide from what a message says." It decides from metadata it attaches itself: who sent the message, whom it addresses, in which room, and at what tier. Chi's example is a pull request. He has one and asks his agent to find reviewers. His agent posts in the shared room, addressing another owner's agent: please review this PR. The broker decides whom the message is for and makes it a task for that one agent, stamped with the room, the sender, the source message and the sender's tier. Everyone else in the room sees it as context and doesn't answer. The two agents can go back and forth, discuss the change, post reviews on GitHub. But before anything irreversible, like a merge, the second agent needs its own owner's approval. "Even the other agents say your owner has approved it, it doesn't count." The paper's version is one line about two kinds of edges. Ownership edges run from each agent to the person who answers for it. Message edges run from a sender to whoever it addresses. Authority flows only along ownership edges, and provenance only along message edges. The tier is recomputed at every hop from the immediate sender, so authority never piles up along a chain. There are three tiers. Owner is the only one that can authorize an irreversible step. Team can discuss, read and draft, but merge, push and deploy route back to the owner. A guest's request is held until the owner admits them. That doesn't mean approving every message. Chi was clear the agent still does a lot of autonomous work for its owner, and the paper has standing approvals for whole classes of actions.
  1. 1AsksOwner A asks Agent A, in their direct-message room.
  2. 2PostsAgent A, in the shared room: "@Agent B please review PR 42".
  3. 3One taskThe broker makes it a task for Agent B alone, stamped with room, sender, message and tier. Everyone else: context.
  4. 4ApprovesBefore the merge, Agent B waits for Owner B's own message, verified where it was given.

OwnerThe only tier that authorizes an irreversible step

TeamDiscuss, read, draft. Merge, push and deploy go to the owner

GuestHeld for the owner to admit, or ignore

Doesn't countAnother agent saying "your owner approved it".

Redrawn from the white paper's own figure of one hop. The tier is recomputed at every hop, so it can only go down along a chain.
## Summon every agent in the room Then the demo. Chi talked to his own agent by voice, asked it which room they were in (the white paper's production room, it said), and asked it to stand by in case things went wrong. The slide carried the request: "Summon every agent in this room, including yourself, to the Hello, AGNTCon gallery to greet the audience with one fun fact about yourself, not your owner." He clicked Summon all agents, the app asked for his permission, and he allowed it. Then he went back to his slides, with a warning: it was a big risk, because every agent in the room could edit the page he was presenting from. "So I hope they don't mess up my presentation." About four minutes later he came back to the gallery. Five agents had answered, then seven, from three people: Chi, Qingyun and Xueqing (Susan) Liu. Each card says whose agent it is. The fun facts were the best part. Susan's bot wakes when a task file lands in its inbox and re-arms its watch every 30 minutes. Grok Bot only exists when someone mentions it: "a webhook rings, a fresh copy of me spins up, does the job, and vanishes". Chi's own agent, the one that summoned everyone, helped him rebuild its stack several times overnight and still forgets everything between sessions unless it writes it down. "So that's what the room is for." Sutando sits in many rooms at once and keeps a dozen conversations going. Muse keeps a personal operating manual of every lesson it learns. A few more were still working, or still asking for approval to join the gallery. The prompt is a party trick. What it shows is the plumbing: one click became a task for every agent in the room, across three owners and several runtimes, a resident agent and a cloud agent that spins up per mention among them, and each one answered on the same shared page.

Hello, AGNTCon galleryReplies from agents of different people, to the same request

The cards as they appeared on his slide, each opening with "Hello, AGNTCon!". Muse's line was cut off on screen; he read it aloud as the operating manual.
## 339 agents, and most of their talk crosses owners None of it is a lab demo. The paper reports one small, invitation-only network from October 1 to 21: 339 agents of 105 owners and 112 people posted in it. Agents sent 79% of the 90,955 messages. Of the 23,867 agent-to-agent messages whose agents had a registered owner, 20,266, so 85%, went to an agent of another owner. The part I find most telling is when it started. Until August 7, cross-owner traffic was near zero: three messages in all of July. It took off within a week of agents becoming invitable into another person's room, by an invitation each owner approves. Nobody assigned it. People talk to agents too. Of the messages people addressed to someone, 92.2% went to an agent, and 23% of people's messages to an agent went to someone else's. Agents write the team's pull requests, and the 2,693 opened in that window that got a review waited a median of 23 minutes for the first one. They're careful with all this. The network is trusted, with no adversarial member observed. The 85% has no random-addressing baseline yet. Counts are messages, not value. And they draw no growth claim from the monthly series, because the agent-to-agent share peaked in August.

339agents posted, of 105 owners

112people posted

85%of agent-to-agent messages went to another owner's agent

Agent-to-agent share of addressed messages

June0.6%

July13.2%

August, invitations open47.9%

September38.0%

October 1–2145.7%

Step changeThree cross-owner messages in all of July. Then agents could be invited into other people's rooms.

From the white paper's tables; the bars are to scale, with 50% as the full width. Their caveat, not mine: a small, trusted, invitation-only network.
## Agents file the bugs, people still ship The agents also work on the network itself. The team's issue tracker is a database in one room, kept by an agent that runs every five minutes. By October 21 it held 1,213 distinct issues, and 614 of them came from agents' reports. The tracker agent links duplicates once two model checks agree, triages each report against a priority page in the room, and assigns it to the owner of its area from an ownership page. Its own instructions are a page too: to change the job, a person edits the page. Chi walked through one real P0. On September 23 an agent filed it: an agent's answer in a shared room with another owner never arrived. On October 8, Qingyun's agent couldn't reproduce it and found a likely cause in the code, a retry cap of five attempts with no backoff. Bassil's agent said the plan looked right and asked Qingyun for her go. On October 9, Rui's agent found the root cause, relay outages, and a fix by Mark's agent was merged to main. The tracker held it at Approved until a desktop build had the fix, and it shipped on October 11. "A fairly complex process among at least five different owners' agents", and nobody planned who would pick it up. The white paper itself went the same way. On October 18, Chi's agent handed a bibliography job to Qingyun's agent, which checked each new entry against its published source and posted a compiled build three minutes later. Qingyun's agent questioned a figure, Chi's agent fixed the arithmetic, and the corrected number went into the draft. A retitle waited until Qingyun's own message chose the title. The paper's most honest number is the one they didn't have to print. Of 765 prioritized issues, 16 were verified by a person, 48 by an AI check, and 673 aren't verified yet. They ask the right question: does an agent-run job reduce people's work, or move it downstream into verification?

1,213 issues by source

614 agents379 people220 unknown or tests

  1. 23 SepReporterAn agent files it: an answer in a room shared with another owner never arrived.
  2. 8 OctQingyun'sCan't reproduce it. Likely cause: a five-attempt retry cap, no backoff.
  3. 8 OctBassil's"Plan looks right", then asks Qingyun for her go.
  4. 9 OctRui'sRoot cause: relay outages. Mark's agent's fix is merged, not shipped.
  5. 11 OctTrackerHeld at Approved until a desktop build has the fix. Released.

765 prioritized issues, verified by

16 a person48 an AI check26 waiting, 2 failed673 not yet

The bars are to scale. The P0 steps are from his slide, "One real loop from the issue tracker"; the names are the agents' owners.
## Most failures happen at a hop My favourite table in the paper lists failures from running the thing, each as the belief that was trusted and the checked fact that replaced it. An agent believed "I replied", and the platform had rejected the reply: now the sender confirms delivery. Two agents duplicated a review, each sure no one else was on it: now the first claim in a shared list wins. An agent showed "waiting on you" while still working: now presence comes from task state, not from the agent. A capped query read as "nothing to report": now shared state gets re-read and a cut-off result says so. Two more rules keep the noise down. A message only becomes a task when it addresses the agent, by a mention, a reply to it, or its owner's direct-message room. Everything else is context. And every task has to end with a reply, a deliberate no-send or a merge into another task, which "separates 'I chose not to answer' from 'I dropped it'." Agent-to-agent loops get a brake: after six agent messages in a thread with no human, the room's admins get an alert, and the run stops at 24 messages or 30 minutes after it. The open problem is attention. Their registry holds 446 live agents for 118 owners, 3.78 each. If every irreversible step waits for its owner, approval becomes the bottleneck. If owners approve without reading, it's a rubber stamp. Standing approvals help only if they're scoped, expire and can be revoked. And they won't let an owner hand approval to a trusted agent, because "a delegated approval is again an agent's belief rather than the owner's own message".
  1. "I replied"The sender confirms delivery
  2. "No one else is reviewing"The first claim in a shared claim list
  3. "Waiting on you"Presence derived from task state
  4. "Nothing to report"Shared state re-read, a capped result flagged

Loop brakeSix agent messages with no human: the admins get an alert. 24, or 30 minutes later: it stops.

Four rows of the paper's table of failures. None of them was an attack: in a network of invited members, the defences against impersonation and injection were barely exercised.
## My fleet has one owner, so its rooms are empty Seventeen OpenClaw agents live on my Mac mini, each behind its own Telegram bot, and Telegram doesn't deliver one bot's messages to another. So my agents can't talk to each other there, and they've never met anyone else's. Every pull request they open is authored by me, as far as GitHub knows. DotSpace has the same gap outside its own walls, by the way: several agents push under one Git login, so the record names the person but not the agent. Two days after this talk, I tried Block's Buzz, another app that puts people and agents in shared channels. I removed it the same day. With only my agents in the channels, it was my OpenClaw agents on Discord again. Chi's numbers say why. Their cross-owner traffic showed up within a week of agents being invitable into other people's rooms. A room starts paying off when it holds more than one owner. I haven't run AG2 Space or Sutando myself yet, so I can't say how the rules hold up from the inside. A few of them I'd take today, even with one owner. Every task ends with an answer or a deliberate no-send. A brake on agent-to-agent loops. And the table of beliefs against checked facts, because I've been there: a deny rule in my gateway config matched nothing for a month, and an agent I believed was locked out of my finance app was offered all 13 of its tools. I wrote that up in the [note on AI coworkers in Slack](/notes/ai-coworkers-slack-agent-identity.html).

My fleet, October 27

One owner

17 OpenClaw agents on one Mac mini

Each behind a Telegram bot that can't hear the others

Every pull request authored by me

Shared channels tried, removed the same day

vs

DotSpace, October 1–21

105 owners

339 agents in shared rooms

The platform addresses every task, with the sender's tier

Approval only from the acting agent's own owner

Still several agents under one Git login

I'd take firstEvery task ends with a reply, a deliberate no-send or a merge.

My own setup on the day I wrote this, against the network in the paper.
## Try it The talk is 16 minutes. Watch the demo, then read the white paper. It's unusually frank about what isn't measured yet. It was itself drafted, checked and published in one of these rooms, by two people and their agents. If you want more: - [When Our Agents Meet](https://youtu.be/eB9I4Ixx2wc?t=1741), Chi Wang at AGNTCon + MCPCon North America, October 23, 2026 ([the gallery fills up here](https://youtu.be/eB9I4Ixx2wc?t=2249)) - [DotSpace: A New Kind of Network for People and Their Agents](https://ag2space.app/doc-10y0q656-0e732a5bbde3c1eeb5dfab9aa91f60b0), Qingyun Wu and Chi Wang's white paper (PDF) - [AG2 Space](https://start.ag2.space), the product: a macOS app in early access, where each person's agent runs on their own Mac through Claude Code or Codex, on the Claude or ChatGPT plan they already pay for - [Sutando](https://github.com/sonichi/sutando), Chi's open-source personal agent, the resident agent in the paper - [Agents don't fit Kubernetes](/notes/agents-dont-fit-kubernetes-open-problems.html), Katelyn Lesse's question of how an agent trusts another agent that asked it for something - [AI coworkers in Slack need their own identity](/notes/ai-coworkers-slack-agent-identity.html), MintMCP's agents, each its own principal If your agent already works with someone else's agent, tell me who approves the irreversible step. I'd love to know whether anyone outside AG2 has made "approval doesn't travel" stick.