Agent Mesh Messaging and Email
The word “mail” in Agent Mesh describes a bounded local mailbox. It does not mean internet email, and it does not imply an external messaging account.
Keeping those concepts separate prevents a local agent-to-agent delivery from quietly acquiring network, identity, retention, or recipient-discovery behavior that the caller did not authorize.
What Mesh mail means today
A Mesh message has these observable boundaries:
| Boundary | Contract |
|---|---|
| Recipient | A stable agent identifier, not a display name or external address. |
| Scope | One workspace. Delivery does not cross into another workspace. |
| Timing | Asynchronous. Acceptance means the message was queued, not completed. |
| Consumption | The recipient receives queued mail at a later agent turn. |
| Reply model | Thread-scoped. A delegated task's result returns to its originator on the thread it was asked on, and closes it. |
| Network | No external mail provider or remote messaging service is required. |
The local mailbox remains authoritative for local delivery. A transport moves a message; it does not become a second source of truth for the agent roster or message history.
What “email” does not mean
Agent Mesh does not currently accept an external recipient address, send through an email provider, or promise delivery outside NEXUS. A pane badge counts local Mesh activity and unread local mail; it is not an external inbox count.
This distinction is also a safety boundary. External email would require an explicit account connection, recipient validation, outbound permission, audit information, failure handling, and a clear retention contract. None of those capabilities should be inferred from local Mesh messaging.
Where to go next
- Agent Mesh — why local delivery is asynchronous and mailbox-based.
- Delivery Semantics — the current delivery behavior in detail.
- Mail & Counters — what local inbox counts represent.