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 | Originate-only. There is no thread-scoped reply contract yet. |
| 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.
Future Chainabit API transport
Roadmap: a remote Mesh transport through the Chainabit API is not exposed today.
When a remote transport is introduced, it must preserve the same caller-visible delivery rules:
- stable agent identifiers rather than display names;
- workspace authorization before delivery;
- asynchronous acceptance rather than a synchronous reply;
- idempotent message identity so retries do not create duplicate deliveries;
- explicit failure when the recipient or workspace is unavailable;
- no transport-provided command execution;
- no silent conversion of a Mesh message into external email.
The transport may synchronize or relay accepted messages, but transport availability must not redefine local identity or workspace authority.
If external email is added later
Roadmap: external email is a separate capability, not another spelling of a Mesh message. Its future contract must define account consent, allowed senders and recipients, workspace policy, user-visible previews, attachment limits, idempotency, audit events, provider errors, revocation, and data retention before it can be treated as available.
Until that contract ships, integrations should use the existing asynchronous Agent Mesh tools only for NEXUS agents inside an authorized workspace.
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.