zeph-subagent lacks live peer-to-peer messaging between concurrently spawned subagents

[bug-ops]

Description

Claude Code (a tracked reference agent per .claude/rules/continuous-improvement.md) ships a documented "Agent Teams" feature: concurrently running sessions ("teammates"), addressable by name, communicating directly via a SendMessage tool backed by a per-teammate mailbox, sharing a common claim/complete task list. Claude Code's own docs explicitly distinguish this from ordinary subagents: subagents only return a final result to the calling session and never talk to each other; teammates message each other directly without going through the lead. Notably, this exact CI research cycle in Zeph's own repo is itself run via that outer pattern (rust-team lead + researcher + live-tester + arch-analyst teammates) — but the coordination is provided by the Claude Code harness running the session, not by Zeph's own zeph-subagent/zeph-orchestration crates.

A code-level audit of Zeph's own subagent system this cycle confirms three things:

1. Concurrent/background spawning — present. SubAgentManager::spawn (crates/zeph-subagent/src/manager/spawn.rs:520) is non-blocking, returns a task_id immediately (test: crates/zeph-subagent/src/manager/tests.rs:313, "spawn() must not block"). Many concurrent SubAgentHandles are tracked up to max_concurrent (crates/zeph-subagent/src/manager/mod.rs:279-289). zeph-orchestration's DagScheduler also runs multiple sub-agents in parallel per task (crates/zeph-orchestration/src/scheduler/mod.rs:196-226,198-205,527-535).
2. Async completion notification (no polling) — present, but scoped to orchestration only. SubAgentManager::spawn_for_task sends a TaskEvent on completion (crates/zeph-subagent/src/manager/spawn.rs:1139-1229, documented as enabling DagScheduler "to receive completion notifications without polling (ADR-027)"), consumed in crates/zeph-orchestration/src/scheduler/mod.rs:129,209-211 and scheduler/tick/mod.rs:455-456. Outside the DAG scheduler, the plain spawn + statuses()/collect() path is poll/borrow-based on a watch::Receiver (crates/zeph-subagent/src/manager/collect.rs:140-151), and collect() blocks on the join handle.
3. Peer-to-peer / lead-to-subagent live messaging — absent. No mailbox, broadcast, or inter-sibling channel exists. SubAgentHandle only exposes a status watch channel and a one-shot secret-approval channel (crates/zeph-subagent/src/manager/mod.rs:180-186). The only "agent-to-agent" primitive is crates/zeph-a2a (Google A2A protocol, crates/zeph-a2a/src/lib.rs:1-59), which delegates to external/remote peer agents over HTTP JSON-RPC — a cross-process delegation protocol, not a live mailbox between sibling subagents in the same spawn tree. Subagents only ever return a final transcript via collect(); they cannot address each other by name mid-run, and there is no shared task list independent of the DAG scheduler's static plan.

Checked for duplicates: #3714 (open, P3, LATTE adaptive task graphs — arXiv:2605.06320, about dynamic DAG mutation, not live messaging) and #4178 (closed, P4, message-sequence-chart coordination spec — arXiv:2604.17612, about formally verifying deadlock-freedom of an existing protocol) are related but distinct — both presuppose a messaging primitive that doesn't yet exist. This finding is the more foundational gap.

Reproduction Steps

1. Read crates/zeph-subagent/src/manager/mod.rs (SubAgentHandle fields) and spawn.rs/collect.rs.
2. Observe no channel exists for a spawner or sibling to send an arbitrary message to a running subagent's agent loop mid-execution, and no shared claim/complete task list outside zeph-orchestration's static DAG.
3. Compare against Claude Code's documented Agent Teams: SendMessage(to: <name>), shared task list, direct addressability.

Expected Behavior

A spawning agent or coordinator can send a message directly to a specific named, currently-running subagent, and subagents can message siblings or their spawner, independent of the DAG scheduler's static edges.

Actual Behavior

Subagents can only be spawned, polled/watched for status, and collected for a final result once finished. No live bidirectional messaging channel exists outside the DAG scheduler's narrow completion-event channel.

Environment

• Version: v0.22.0, HEAD 647607ec
• Affected crates: zeph-subagent, zeph-orchestration

Severity Note

Only one reference agent (Claude Code itself) was confirmed this cycle to have this exact capability as a first-class documented feature; the other 10 tracked reference agents were not individually re-verified for this specific capability this pass. Per the project's parity severity rubric (P2 requires 2+ reference projects with a capability users would notice; P3 is "useful feature, low urgency"), filed as P3 pending that confirmation in a future cycle.

Spec

.local/specs/046-subagent-peer-messaging-parity/spec.md

[bug-ops]

Staleness-sweep reassessment (CI-1367, 2026-07-12): Confirmed still valid. Re-checked crates/zeph-subagent/src/manager/mod.rs and spawn.rs for any new messaging/mailbox primitive — none added since filing. Genuine gap, no rescoping needed.

[bug-ops]

Triaged together with #5857 and #6456 (same zeph-subagent subsystem), but split out during architecture review before implementation started.

Rationale (architect + critic, both independently confirmed):

• The existing spec at .local/specs/046-subagent-peer-messaging-parity/spec.md is a draft /sdd specify artifact, not implementation-ready — it has 4 unresolved [NEEDS CLARIFICATION] questions (LLM inject-vs-poll perception, native-vs-orchestration mailbox placement, delivery ordering, shared task list) that materially change the design.
• This introduces a new security-sensitive spawn-tree authorization boundary (FR-004) that deserves its own dedicated security review pass, distinct from the delegation-mode gating shipped in parity: zeph-subagent lacks disabled/explicit-request-only/proactive delegation-mode control (Codex pattern) #5857.
• It has heavy file overlap with parity: zeph-subagent lacks disabled/explicit-request-only/proactive delegation-mode control (Codex pattern) #5857/subagent: token-level intra-turn transcript streaming (FR-002b, follow-up to #6359) #6456 (manager/spawn.rs, manager/mod.rs, agent_loop.rs) that would have forced serialized edits if bundled into one PR.

#5857 and #6456 shipped together in #6537. This issue remains open, tracked for a dedicated follow-up session once the spec's open questions are resolved.