Mail & Counters
The badge counts what's still waiting, not whether mail exists
A pane hosting an agent shows a small tray badge in its header once anything is queued for that agent. It renders a number, not a checkmark or a boolean dot — a boolean "you have mail" hides the one thing that actually decides whether you act now or wait for the agent's next run anyway: how much is backed up. The badge saturates once the count passes a small threshold, showing something like "9+" rather than letting a long number push the rest of the header out of shape, and it disappears entirely once nothing is waiting — there is no "0" state shown.
Hovering it states both the count and the delivery contract together, in one line — something like "3 messages waiting for next run — click to review." If any earlier messages were dropped because the mailbox was full before you reviewed it, the same tooltip says so alongside the current count, rather than silently discarding them without a trace.
Opening it
Clicking the badge opens a popover listing what's queued — sender and message text, oldest to newest. A single Insert action drains the whole popover at once and types the combined contents straight into that agent's live shell, exactly as if you had typed it yourself. There's no per-message insert; it's all-or-nothing, matching the fact that the agent will see all of it on its next turn regardless of whether you insert it early.
A mailbox has a limit
NEXUS does not queue an unbounded number of messages for an agent that never comes back to check. Once a mailbox is full, further messages are dropped rather than silently accepted and never delivered — and the drop is counted and surfaced, alongside whatever is still actually waiting, rather than disappearing without a trace. If you're seeing a dropped-message count climb, the fix is upstream of the mailbox: the recipient isn't taking enough turns to keep up with what's being sent to it.
A richer per-agent inbox
Beyond the pane-header badge, right-clicking an agent node on the Neural Map and choosing Mesh Inbox opens a dedicated view of that agent's mail: every message with an explicit status — unread, read, or archived — a relative timestamp, and two actions per message. Archive hides a message from this inbox without deleting it from the Room or Neural Map's own history, so archiving is tidying, not destruction. A reply field lets you compose a response and send it — as its own new message from that agent back to the original sender, the same origination semantics as any other send, not a thread-linked reply the mesh correlates for you. See Delivery Semantics for why that distinction matters.
What an agent itself can see
None of this is available to a connected agent as a documented tool call. The agent_* family lists reachable peers and originates messages; nothing in it lets an agent query its own queued mail depth over MCP. The badge, the popover, and the Mesh Inbox are all surfaces for a human watching the workspace, not something a connected agent can introspect about itself through nexus-mcp.
Where to go next
- Delivery Semantics — why the count exists at all: delivery is next-turn, never immediate.
- Sending Messages — the two ways a message gets into this mailbox in the first place.
- Neural Map: Context Actions — the right-click path to an agent's Mesh Inbox.