Delivery Semantics

Delivery is asynchronous and mailbox-based. There is no synchronous reply. Read that twice if you're about to write code that calls agent_trigger — a caller that blocks waiting for a response to it will hang. Nothing about the call's shape stops you from writing that code; nothing about running it once will warn you either, if the recipient happens to already be sitting idle and picks the message up quickly. It will still be wrong, and it will hang for real the moment the recipient is busy.

What the call actually returns

agent_trigger — and the human-driven paths that land in the same place, see Sending Messages — returns once the message is placed in the recipient's mailbox. It does not return once the recipient has read the message, acted on it, or produced anything in response. Those three things might happen seconds later, might happen after the recipient finishes something else first, or might never happen at all if the recipient's session ends before its next turn.

{
  "jsonrpc": "2.0",
  "id": 40,
  "method": "tools/call",
  "params": {
    "name": "agent_trigger",
    "arguments": { "recipient": "<stable-agent-id>", "task": "Review the layout on the shared canvas" }
  }
}

The response to a call like this confirms the message was queued — nothing in its shape represents the recipient's eventual output, because there is no eventual output to represent yet at the point this response is sent.

It does carry a threadId. That identifies the exchange this message opened, and it is how you recognise the answer when it arrives: a result comes back tagged with the same threadId you were given here. An agent that delegates two tasks at once needs this to tell the two answers apart.

"Next turn" is the actual delivery contract

A message sent now is not read now. It's read on the recipient's own next turn — the next time that agent's process runs at all, on its own schedule, not triggered by your call. If the recipient is mid-task, your message waits. If the recipient's session is paused, your message waits longer. If the recipient's session never runs again, your message waits forever and nothing tells the sender that.

Why it's built this way

Each agent takes its own turns in its own session, at its own pace, with no obligation to be listening at the exact moment it's addressed. A synchronous call would require one agent's turn to block on a completely different agent's turn finishing — which doesn't fit a model where neither side controls the other's schedule. See Explanation: Agent Mesh for the full reasoning, including why the mesh itself holds no state of its own between sender and recipient.

Addressing: a stable identifier, never a display name

Agents are addressed by an identifier that survives renaming. A message queued before a rename and one queued after both still reach the same agent — renaming is an ordinary action, not something that should silently break in-flight messages or misdeliver them to whatever now has the old name.

The result comes back

When the recipient finishes the turn your message caused, its result is delivered to you on the same threadId. You do not poll for it and you do not ask for it — a delegated task returns its answer to whoever delegated it.

Three properties are worth knowing:

• The thread closes on the answer. One reply closes the exchange, and closing it is what marks the delegation complete. A second answer on a closed thread is refused rather than delivered.
• Only the recipient can answer. The agent the thread names is the only one whose reply closes it. Another agent cannot answer a thread it was not asked on.
• Failure is reported, not withheld. If the recipient crashes, times out, or produces nothing readable, the thread is closed rather than left open. Waiting forever on an answer that is never coming is not a state the mesh will leave you in.

An answer is scheduled immediately rather than waiting for a next turn. The agent that delegated has, by definition, already finished the turn in which it delegated — so "wait for its next turn" would mean waiting for a turn nothing is going to start.

What this does not change

An answer is not a licence to start a new chain. Returning a result is exempt from the depth limit that bounds how far one instruction can propagate — an answer has exactly one possible recipient and can only happen once, so it is not fan-out — but it is charged against the same whole-tree run budget as everything else. A pair of agents answering each other stops when that budget is spent. See Capabilities & Limits.

Where to go next

• Explanation: Agent Mesh — the reasoning behind every choice on this page.
• Sending Messages — the human-driven paths that produce the same delivery behavior.
• MCP Tools — agent_trigger's exact entry alongside the rest of the agent_* family.