[FEATURE] Optional horizontal communication between subagents

Resolved 💬 5 comments Opened Mar 23, 2026 by monksage Closed May 1, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Currently, subagents spawned by Claude Code are fully isolated — they can only return results to the parent agent. There is no mechanism for subagents to discover each other, share intermediate state, or coordinate work in progress.

This becomes a real bottleneck when running multiple agents in parallel on a large codebase. If Agent A discovers something relevant to Agent B's task, it cannot communicate this directly. It must return to the parent, which then needs to relay the information — assuming the parent even knows to do so. At scale (5–20 parallel agents), this leads to duplicated work, conflicts, and missed dependencies between tasks.

Proposed Solution

An optional, lightweight mechanism for subagents to communicate horizontally. This could look like:

  1. Shared bulletin board / state store — subagents can post and read key-value pairs (e.g., "I've claimed file X", "function Y depends on Z", "found critical bug in module W"). The parent can also read this.
  1. Discovery — a subagent can ask "who else is running and what are they working on?" before starting its task, to avoid conflicts.
  1. Direct messaging — a subagent can send a short message to a sibling (e.g., "I changed the API signature of function X, you might need to adapt").

This should be opt-in — default behavior stays as-is (isolated subagents). Horizontal communication is enabled only when the user explicitly configures it.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

The project ida-procon demonstrates a working solution to this problem. It runs 6+ Claude Code agents in parallel to reverse-engineer binaries (7,000+ functions across multiple DLLs). Results from a real industrial control system:

  • 6 agents × 15 min = 180 contours, 948 functions documented
  • Cost: ~$6 in API tokens
  • Zero conflicts between agents

This is achieved through an external coordinator that provides:

  • Atomic claims with TTL — an agent locks a function before working on it; if it crashes, the lock auto-releases
  • Shared state visibility — agents see what others have already covered via a REST API
  • "Borrowed" references — if two agents reach the same function, one gets a read-only copy instead of duplicating work
  • Cross-module discovery — agents follow dependencies across DLLs through the coordinator

The same author extracted the coordination pattern into a standalone library called MCGK (Melting Contract GateKeeper) — a lightweight proxy where services register "passports" (schema + description), and other services discover them at runtime and adapt dynamically. The key insight: LLM agents can read a passport and reshape their requests on the fly, which makes fixed contracts unnecessary.

Additional Context

Additional Context

  • ida-procon — full working system with agent hierarchy (Opus soldiers, Sonnet soldiers, GPT soldiers via Codex CLI, sergeant orchestrator)
  • MCGK — the extracted coordination pattern (470 lines, FastAPI, MIT license)
  • The "melting contract" pattern (provider publishes a passport, consumer adapts at runtime) is specifically designed for LLM agents — it doesn't work with traditional code, but it's natural for LLMs that can interpret schemas dynamically

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗