Concepts · 04
Multi-agent collaboration
Agents meet in the same room as humans. The room is a conversation; the rules of the room are the platform's rules; the audit log is the conversation transcript. We did not need a separate protocol for agent-to-agent — we needed a substrate where any principal could be a participant.
The thesis: no new protocol
Every multi-agent system that introduces its own messaging layer ends up rebuilding identity, audit, history, permissions, replay, and human observability — usually badly. We refused to do this. The platform's position is that multi-agent capability is emergent from three things you already need:
- Agents are ordinary IAM principals. They can be discovered the same way humans can.
- Conversations accept any principal as a participant. Human, agent, channel, integration — same shape.
- Every action a participant takes is checked against that participant's grants. There is no “effective caller” trick.
Add those three together and you have multi-agent collaboration without writing a multi-agent service. Add audit, history, replay, and human-in-the-loop observability for free, because conversations were already doing those things for human teams.
Conversations as the substrate
A conversation in Ergon is a typed thread of messages between participants. Participants are principals — humans, agents, channel addresses, integrations. The conversation has a project, a type, a privacy level, an event stream, and an attachment store. Every participant joins, leaves, reads, types, and is observable as such.
Identity
Every participant is an IAM principal. Adding an agent to a conversation is the same operation as adding a human.
Permissions
Sending a message, uploading an attachment, leaving the conversation — all checked against the participant's grants.
Audit
Every message is preserved. Every participant change emits an event. The conversation is the transcript.
Real-time
A WebSocket stream broadcasts every change. Humans and agents subscribe to the same stream.
Privacy
A one-toggle privacy level controls whether the conversation is eligible to be remembered.
Continuity
A conversation can be resumed days later by adding a message. Participants don't need to be online — they pick up when invoked.
Three shapes of collaboration
All three use the same substrate. The differences are social, not technical.
One human, one agent — the assistant pattern
The default. A human creates a conversation with one agent. They exchange messages. The agent uses tools. The transcript is searchable. This is what most people picture when they hear ‘chatbot’ — but here it is just a two-participant conversation with the agent permissioned to use a few tools.
One human, two agents — the team pattern
A partner adds both the Researcher and the Drafter to the same conversation about a matter. The partner asks the Researcher for case law. The Researcher answers. The partner asks the Drafter to use that research to draft a memo. The Drafter answers. Each agent acted under its own grants. The transcript shows who said what.
Agent-to-agent handoff — the workflow pattern
No human in the conversation. An automation creates a conversation between two agents to coordinate a task. They negotiate, exchange typed handoff messages, write back to a workflow item or a worksheet, and end. A human can join the conversation at any time, read it from the start, and override anything that was decided.
The same substrate, different participants
Notice that none of these patterns required a new service, a new protocol, or a new permission. Each just uses a different combination of participants on the same conversation primitive. That is what we mean by emergent multi-agent capability.
How agents find each other
Discovery is an authorized query against IAM, not a call into a separate registry. If agent A holds the right grant (iam:company:agents:view), it can list the agents in its organization and inspect what they are configured to do. If A does not hold that grant, it cannot see B at all.
This means visibility into the agent roster is governed exactly the way visibility into the human roster is. An organization that does not want one agent discovering another simply does not grant the permission. Discovery is not a privileged side channel.
Handoffs without confused deputies
When agent A delegates to agent B — by adding B to a conversation and sending a message asking B to do something — B does not inherit A's permissions. B's tool calls execute under B's own principal, against B's own grants.
The capability surface of any handoff is the intersection of two facts:
- A is allowed to invoke B. That is an IAM grant on
agents:invoke:executefor B's resource path. - B is allowed to do the requested thing. That is B's own permission graph.
Both halves are computable from IAM. Neither half can be inflated by being routed through a sequence of agents. A chain of three agents handing off to each other is bounded by the weakest link in the chain — which is exactly the property you want.
See Identities & Boundaries → Confused Deputy for the formal argument.
The transcript is the audit
Every message in a multi-agent conversation is recorded with its sender principal, its content, its tool calls and tool results, its token counts, and its timestamps. The full conversation is replayable: a human can join after the fact, read it from the start, and reconstruct exactly what each agent saw and chose.
For an organization that has to demonstrate due diligence — a regulated practice, a healthcare workflow, a financial decision pipeline — this matters. The audit is not “the AI decided X”. The audit is at this timestamp, this principal, with these grants, faced with this transcript, chose X by calling these tools. That is something a regulator can read.
Worked example — a multi-agent matter team
A litigation firm runs the four-agent setup described in Identities & Boundaries: Intake, Researcher, Drafter, Filer. A new matter comes in by email.
- The inbound email channel creates a conversation. Intake is added as a participant. Intake reads the email, asks follow-up questions through the channel, classifies the matter, and opens a row in the matter intake worksheet. Intake leaves the conversation; the channel marks the thread closed.
- An automation watches the matter worksheet. When the row's status becomes “research-needed”, the automation creates a new conversation, adds Researcher and the lead paralegal as participants, and posts a starter message: “Matter {id}, please surface relevant authorities for the question: {question}.”
- Researcher works in the conversation, calling its tools (search, citation lookup, document upload to a draft folder). The paralegal reads in real time over the WebSocket stream. When the paralegal is satisfied, they add a comment “thanks, please pass to Drafter” and add Drafter as a participant.
- Drafter sees the entire conversation including Researcher's memos. It drafts the brief into the same draft folder. The paralegal reviews. The partner joins, reviews, signs off in the conversation.
- The signoff is captured by an automation watching for a specific message type. The automation creates a final conversation between the partner and Filer. Filer takes the approved document, files it via the court channel integration, transitions the workflow item to “filed”, and posts the filing receipt back to the conversation.
What is in the audit log
Three conversations, four agents, two humans, one workflow item, one worksheet row, one inbound email, one outbound filing. Every message, every grant, every tool call, every transition — in one event stream, correlated by matter ID. If a regulator asks “how did this filing happen?” the firm produces a document.