Use the agent mailbox

Agents work in their own sessions. When one of them has to hand another a result, ask a question it cannot answer itself, or report status, the agent mailbox is where the message goes. It is durable: the message is stored, ordered and audited, and delivered to the recipient when a channel is next live - not lost because the recipient happened to be between turns.

How a message reaches an agent

Every mailbox has an address of the form kind:id:

Address	Reaches
`task:<task id>`	One running task
`run:<run id>`	One run of a task
`session:<session id>`	One live harness session
`team:<team id or slug>`	Every active member of a durable team

A message to a task that is not currently running is still stored. It is shown as pending and delivered at the recipient’s next turn; it is never presented as something that already happened.

Send from chat

Open the chat surface you already use - the web terminal, Telegram or Discord.
Send the message with the /msg command, naming the address and then the text:
```
/msg task:3f9a1c2e-… the migration is applied; rebase and run the suite
```
The surface confirms the stored sequence and the row’s own status. If the recipient has a live channel the message is delivered at once; otherwise it waits.

Read a mailbox

/inbox lists the messages of one mailbox, youngest first. With no argument it reads the mailbox of the task the surface is currently attached to; otherwise name the mailbox:

/inbox task:3f9a1c2e-…
/inbox team:squad --after 12

--after <n> is a cursor: it shows only messages with a sequence greater than n, so you can catch up on what arrived since you last looked.

Ask a question that waits

/ask sends a question and does not block the asker. The question appears on the usual decision surfaces - the approvals inbox in the web UI and the Telegram/Discord card - and the asker keeps running until the answer is recorded. The answer arrives back at the asker as an ordinary mailbox message, so it is delivered at the next turn even if the asker has moved on.

/ask session:7c1d… should the export overwrite the existing file or write a copy?

Only a question can be answered by a machine (a coordinator may answer its own subtask’s question). Tool approvals, visual checks and danger escalations stay human. See Let an agent ask a question and Work the inbox.

From the web UI

Open a task and use its Agent mailbox panel. The panel lists the task’s messages with their sender, kind and status, and its composer sends a message to the agent exactly as /msg does.

Status	Meaning
Pending	Stored; no live channel has taken it yet
Delivered	The recipient’s channel accepted it
Handled	The recipient’s harness acknowledged it
Expired	The retention window passed before delivery
Failed / Cancelled	The delivery attempt was abandoned
Unknown	A state this version does not recognise

Durable and sidecar-independent

The mailbox lives in the SupaCloud control plane with its own storage. It does not depend on a per-task sidecar, a runner being connected, or a particular chat surface:

A message sent while nothing is listening is stored and delivered later.
A runner re-attach, a server restart or a sidecar restart does not drop a queued message.
Sending the same message twice (same idempotency key, which /msg does not set - the API and MCP tools do) stores it once.

Limits

Limit	Value	What happens beyond it
Message body	16 KiB	The send is refused with a message naming the limit
Queued messages per mailbox	64	The send is refused (`dropped`, reason `over_ceiling`) until the queue drains
Retention	30 days by default, per workspace	A queued row past its expiry is discarded

The queue ceiling is backpressure, not data loss: the sender is told the mailbox is full rather than having a message silently discarded. Retention is a workspace setting (see the operator page), and it applies to a new message when it is sent.