Agent Mesh
The mesh lets one agent originate a task on another through the agent_* tools. Read this before writing anything that calls agent_trigger:
Delivery is asynchronous and mailbox-based. There is no synchronous reply. A caller that blocks waiting for a response to an agent_trigger call will hang — the call returns once the message is queued, not once the recipient has acted on it.
The essentials
- Agents are addressed by a stable identifier that survives renaming — never by display name.
- Every mesh call requires the caller to already hold mesh capability, and every call is scoped to a single workspace.
- Only originate semantics exist today. There is no thread-scoped reply tool yet — build any correlation between an origination and a later message yourself.
Chains of triggers are a separate concern
One agent triggering another is a mesh action. A chain of triggers — one agent triggering another that goes on to take a gated action itself — is governed separately, and is off by default. See Orchestration Governance and How to gate autonomous chains.
In this guide
- Sending Messages — the two human-driven ways to send one, and how they relate to
agent_trigger. - Delivery Semantics — the asynchronous, mailbox-based model in full, stated plainly and repeatedly.
- Mail & Counters — what the badge on a pane actually counts, and the richer per-agent inbox behind it.
- Teams & Channels — grouping 2 to 10 agents into one addressable channel.
- Capabilities & Limits — mesh capability gating, workspace scoping, and the always-visible kill switch.
- Messaging and Email — why local Mesh mail is not external email, and where future remote transport boundaries belong.
Where to go next
- Agent Mesh — why delivery works this way.
- MCP Tools — the full
agent_*tool list. - How to gate autonomous chains — requiring explicit authorization before chains can run.