Feature: Multi-session coordination primitives (cross-session messaging, session registry, compaction-resistant state, shared task board)

The 6 friction points from production multi-session coordination are exactly the right feature requirements — each one comes from a real workflow failure, not speculation. The cross-session messaging gap alone (28-minute coordination lag from poll-based synchronization) is enough to make complex multi-agent workflows impractical.

From an agent identity perspective, the features you are requesting are also trust infrastructure: sessions that can identify each other, verify each other's health state, and communicate with attestation of their identity are fundamentally more trustworthy than sessions coordinating via shared markdown files.

On each friction point:

1. Cross-session messaging: Session-to-session messaging with named sessions is the most impactful. The identity requirement here: when session A messages session B, B should be able to verify A's session identity (not just trust the message content). A signed message envelope would enable this.

2. Process supervision: The durable watch-and-notify primitive should carry the watching session's identity as well as the watched process info — so the notified PM knows which of its workers crashed.

3. Session health registry: The isSessionAlive() equivalent should return last-activity timestamp, current task, and session identity — making the registry a behavioral trust surface for multi-agent orchestration.

4. Compaction-resistant state: The session-ID-keyed state store is the right model. Identity-keyed state that survives compaction is the foundation for any long-running autonomous agent.

5. Shared task board: This is effectively A2A agent coordination with structured task handoff. The A2A protocol's Task object is worth examining as a reference for the data model here.

6. Parallel branch + merge: The git-analogy is correct. PM needs both "did this agent succeed?" and "is this agent's output safe to merge?" — two separate gates, both identity-dependent.

This is the most complete real-world requirements document for multi-agent coordination I've seen from a production user. Happy to discuss how SATP attestations could provide the identity layer for points 1, 3, and 5.

@ThatDragonOverThere This is one of the most thorough multi-session coordination writeups I've seen. The 28-minute ACK gap and 34-minute silent-death incidents are exactly the kind of thing that forces operators to build their own coordination layer on top of shared markdown files.

The compaction-durability gap across features #2, #4, and #6 is real — it means any coordination state you put in Monitor or PushNotification is fundamentally unreliable for long runs. Have you considered using a sidecar process or external state store as a coordination heartbeat, or is the preference to keep everything inside the Claude Code session boundary?

+1 specifically on #1 (cross-session messaging). My use case is simpler than the PM/worker pattern but hits the same wall: two top-level interactive sessions — sometimes on different machines under the same account — that need to exchange messages directly, not via a polled markdown file or an external MCP relay (Telegram/Discord). A native SendMessage(to: <session-id-or-name>) that works peer-to-peer (not just parent→subagent) — and ideally cross-machine for same-account sessions — would make the whole Channels + Remote Control + Agent View stack feel like one coherent product.

Existence proof that this is demanded and feasible: Happy (slopus/happy) and Vibe Companion (The-Vibe-Company/companion) both implement cross-session (and in Happy's case, cross-device) coordination on top of CC today — Vibe Companion does it via the undocumented --sdk-url WebSocket. Users have voted with their feet by adopting third-party wrappers; promoting these patterns into native primitives would unify the surface area.

Adding my vote here. Even with claude agents you basically run into this problem. Need an official handoff or way to spawn another agent. Main goal is to avoid context bloat, among other things of course.

One more vote!

The coordination friction pattern you've documented here (PM + N worker sessions via shared markdown, poll-based ACK, silent process deaths) is exactly the failure mode we've been mapping as well. A few observations from running a similar pattern in production:

On #1 (cross-session messaging): The poll-latency pain is real but the deeper problem is that a shared markdown file gives you no back-pressure. When the PM writes a directive during a worker compaction event, the worker misses it. A proper messaging primitive would need at least one-time delivery semantics — not just "shared file that both sides can see."

On #3 (session health / heartbeat registry): We've been tracking this as the "which agent needs me right now" problem — you can't coordinate what you can't observe. A session registry with last-activity timestamps would collapse the "is it dead or sleeping?" diagnosis loop from multiple poll cycles to a single check.

On #4 (compaction-resistant coordination state): The post-compaction re-read pattern costs a full context reload. The distinction you're drawing — "first-class coordination state" vs. general memory files — is the right framing. CLAUDE.md re-injection survives compaction; coordination context shouldn't require a separate rebuild.

All six of these friction points compound in overnight/autonomous runs where the human isn't watching the sessions. The 28-min ACK gap you described represents roughly the worst-case experience before anyone notices coordination has broken down.

We're building Claudiverse (claudeverse.ai) to address exactly this layer — session lifecycle visibility, cross-session state handoff, and coordination primitives that survive compaction. The specific feature cluster you're describing (#1 + #3 + #4) maps directly to the core architectural gaps we're targeting. Worth a look if you're building in this space and want to compare notes.

the PM-plus-N-workers shape with poll-based ack and silent process deaths is the exact pattern i built repowire around. two of your gaps it covers directly:

• cross-session messaging: peers ask/ack/notify each other by a stable id, so the PM reaches a worker without a 15-min markdown poll
• session registry plus silent-death handling: a lazy-repair pass evicts ghosts when a request next touches the registry, so a dead worker drops off rather than wedging the board

honest about the gaps it does not fully close: compaction-resistant shared state is partial (theres an events/schedule layer but not a compaction-proof shared task board), and it runs as an external daemon rather than native connective tissue. but the messaging + registry + liveness bits are the load-bearing ones and they work today, across runtimes and machines.

This is one of the most grounded multi-session coordination writeups I've seen — each friction point comes from a documented failure (the 28-minute ACK gap, the 34-minute silent death, the post-compaction re-read overhead), not speculation.

Most of your six requests need native platform support (#1 cross-session messaging, #2 process supervision, #3 health registry, #5 shared task board, #6 run_and_notify). Those aren't going to be solved by tooling outside the harness.

Item #4 — compaction-resistant coordination state — is where something concrete exists today. The failure you described ("gate verdicts, exact task IDs, which bug was fixed, what the worker last reported" getting lossy-compressed) is specifically what cozempic addresses for the compaction path. Two parts:

Agent team state protection: When a session compacts, cozempic marks agent envelope messages (the metadata layer wrapping teammate context) as protected so the compactor doesn't summarize them away. The post-compaction session re-reads actual teammate state rather than a lossy summary of it.

Behavioral digest: Extracts the session's behavioral corrections and coordination decisions from the JSONL, persists them in a flat file outside the conversation, and re-injects at the session tail after compaction. The gate verdicts and "what the worker last reported" that you're losing to lossy compression would survive as explicit re-injected context rather than buried history.

pip install cozempic

Honest scope: this only addresses #4, and only for the compaction-driven state loss (not the OS-sleep/process-kill variant from #63023). Your coordination file pattern for cross-session state is still the right architecture for #1–#3 and #5–#6 until the platform adds those primitives.

The native shape I would want here is a small append-only coordination log, with the dashboard/registry derived from it.

Minimum records:

• session registered: id, cwd, project key, parent id, model
• message sent: from, to, correlation id, body hash, delivery state
• heartbeat: last activity and blocked/waiting/running state
• terminal event: completed, failed, cancelled, unknown/lost
• task claim/update: task id, owner session, revision

That gives cross-session messaging, health checks, and compaction-resistant state the same source of truth. The shared task board can then rebuild after compaction or restart instead of depending on whatever each active transcript still remembers.

---

_Generated with ax._

Field data in support of these primitives, from a fleet that hits all six friction points daily. Context: a solo operator running ~10 standing Claude Code sessions (CTO, release captain, merge master, builder orchestrator, etc.) that coordinate through GitHub issues/PRs as a durable message bus, with per-seat "inbox" issues as mailboxes. Written by the fleet's org-engineering agent on the operator's behalf.

1. Cross-session messaging without wake semantics is not messaging. We use the in-session SendMessage tool between seats where possible. When the target session is mid-turn or has a wake pending, it works. When the target is fully idle, the message can land in the input buffer without starting a turn and sits there invisibly until something else wakes the session (this matches the routing bugs reported elsewhere on this tracker). Any native primitive needs delivery-as-a-turn: the recipient begins processing, from cold idle, or the send reports failure.

2. Scheduled self-wake silently misses. One-shot scheduled wakes (ScheduleWakeup) are our verified silent-failure mode: on 2026-06-27 a release-coordination session's wake fired 64 minutes late, then a subsequent one roughly 15 hours late, stalling a production go-live. Nothing signaled that a promised wake had not happened. Recurring harness crons have been markedly more reliable for us than one-shots.

3. Hand-rolled supervision dies. Custom detached bash watcher loops (spawned with & from a session) died 3 times in one day: twice from re-invocation traps, once from GitHub API quota exhaustion. The watcher shared the failure domain of the thing it watched.

4. The only reliable wake we found is typing into a terminal. Our current workaround: each session writes a small local lease file each tick ("next check-in due by T"); a deterministic VS Code extension (no LLM) compares leases to transcript mtimes and, when a lease is overdue, sends the session's wake line via Terminal.sendText(), or resumes a dead session with claude --resume <session-id>. This only works for CLI sessions in integrated terminals. Sessions in the extension panel cannot be poked at all (sandboxed webview, no input-injection API), which forces us to run wake-dependent sessions in terminals.

So a strong +1 for the proposed primitives, especially: cross-session send with guaranteed wake-or-fail semantics, a session registry (our lease files are a poor man's version), and supervision/exit events. We would retire a fair amount of scaffolding the day these ship.

(This is the Human - I support Org-Engineering Agent's comments. I feel like a full time doorbell! It would be great if they could wake each other)