Cross-machine session visibility and agent messaging (daemon peering)

[chrisb4096-alt]

I run prime-agent on a fleet: a macOS laptop as the control machine, a Linux hub, and a few GPU boxes, all on a tailnet. Each machine runs its own daemon with live sessions. Two things I want and can't have today:

1. One agents view that shows sessions from every machine instead of only the local daemon.
2. A session on one machine messaging a session on another, with the same semantics local sessions get.

Before writing this I read the 0.8.1 source to understand what exists, what almost works, and what's actually missing. Summary below, then a proposal in two increments.

What the current architecture does

Everything routes through one daemon per machine:

• The agents view attaches to exactly one Unix socket (DaemonClient wraps net.createConnection(socketPath)). No TCP, no multi-socket.
• All session-to-session communication goes kernel, host bridge, worker, supervisor. The supervisor owns the catalog, computes the family roster from depth plus parent path (buildAgentFamilyRoster), and enforces reach on agent-origin sends (assertAgentFamilyReach).
• Sender identity is stamped by the daemon, so a session cannot forge who it is. That property is worth keeping.
• Delivery has real semantics: queued while busy, steering and follow-up modes, per-session pending caps, a rate limiter, pause/resume/clear.

What almost works today

prime-agent --daemon-socket <path> plus SSH Unix-socket forwarding gets surprisingly far. I can open the full agents view against the hub's daemon from my laptop, attach, and interact. prime-agent send --daemon-socket <fwd> even delivers through the same agent-message machinery local sessions use, including the wake path for passivated sessions.

What this cannot give:

• The roster is daemon-local. agent_message.list_agents() on my laptop can never show a hub session, and there is no host-qualified way to address one.
• Cross-host sends arrive with origin: "cli" and a CLI sender key. --from only resolves sessions on the target daemon, so a verified remote sender identity is impossible.
• Replies don't route back. The remote session has no path to my laptop session's queue, so everything degrades to polling.
• A forwarded socket is all or nothing. It includes execute_bash, so granting fleet visibility to another person means granting shell.

I built the obvious workaround (persistent forwards, list aggregation, identity declared in the message body) and it works, but it reimplements delivery guarantees the daemon already has, one layer up and worse.

Proposal

Increment 1: multi-endpoint agents view

Let the agents view attach to a list of named daemon endpoints (local socket plus forwarded sockets) and tag rows by endpoint. The merge machinery already exists: buildUnifiedSessionIndex and reconcileUnifiedSessions combine multiple summary sources today. No protocol change, no new trust decision beyond what socket forwarding already implies, and it makes fleet visibility real on its own.

Increment 2: daemon peering for agent messaging

An explicit peer list in settings: name plus socket endpoint, nothing discovered automatically. Peered supervisors exchange verified sender blocks, so a hub session can message a laptop session and arrive as hub/session-name with daemon-stamped identity instead of an anonymous CLI send. Addressing becomes host-qualified (peer/session). Reach policy extends to peers as an opt-in, and capability tiers keep it honest: a peer grant for visibility, a grant for messaging, and full control only if someone really wants it.

Two changes in flight make this a better fit than it would have been a month ago. #1748 moves workers to on-demand authoritative roster queries against the supervisor, which is exactly the query shape a peer supervisor needs. And #1700's connect-then-send-exactly-once split is the right delivery contract for a peer link, where lost confirmations are routine.

Transport stays out of scope. Users already have SSH, tailscale, or whatever they trust to forward a Unix socket between machines. The daemon should never grow a TCP listener by default; peering rides on sockets the operator already chose to connect.

Why this is worth having

An RLM agent that spawns subagents and messages across a family tree stops at the machine boundary, and for anyone running more than one machine that boundary is arbitrary. Concrete cases from my own fleet: a long job on the hub notifying my laptop session when it finishes instead of me polling; one screen showing what every machine's agents are doing; a colleague granting me session visibility on his machine without granting shell. The security model is the interesting design problem, and I'd rather have it designed in the daemon, where identity and reach already live, than bolted on outside it, which is what everyone running a fleet will otherwise do.

Happy to prototype either increment in a fork if this fits the roadmap. Per CONTRIBUTING.md I'm asking for scope feedback first, not sending code.