Feature Request: Enable Agent-to-Agent Communication for Collaborative Workflows

Title: Feature Request: Enable Agent-to-Agent Communication for Collaborative Workflows

Is your feature request related to a problem? Please describe.

Yes. The current subagent architecture in Claude Code is excellent for delegation—handing off a self-contained task to a specialist and getting a result. However, it falls short for tasks that require true collaboration and iterative feedback between agents. This creates two primary problems:

1. Lack of Iterative Feedback Loops: Complex software development is rarely a linear process. For example, a common workflow is a dev-test-fix cycle. Currently, if I have a "Developer Agent" and a "Tester Agent," the workflow is cumbersome:

• The Developer Agent writes code.
• The user (me) must manually instruct the Tester Agent to test it.
• If tests fail, the Tester Agent reports back to me.
• I then have to copy the failure details, re-engage the Developer Agent, and provide the context for the fix.

This manual intervention breaks the autonomy of the system and makes it impossible to assign a high-level goal like "Implement and test feature X until it passes all acceptance criteria."

1. Destructive Interference in Parallel Work: When tackling a large epic, the natural approach is to use multiple agents in parallel. However, these agents are unaware of each other's existence or work-in-progress.

• Scenario: I assign Agent A to build an API endpoint and Agent B to build a related frontend component. Both are working in the same codebase.
• Agent A adds api/new-endpoint.ts.
• Agent B, when attempting to build or test its own work, sees api/new-endpoint.ts as an unexpected file not relevant to its immediate task.
• To "fix" its local build environment, Agent B might decide to run rm api/new-endpoint.ts, destroying Agent A's work.

This forces users into complex workarounds like Git Worktrees, which provide isolation but prevent true collaboration on a shared context.

In short, agents currently operate as isolated contractors. We need them to operate as a cohesive, communicative team.

Describe the solution you'd like

I propose introducing a first-class system for agent-to-agent communication. This could be implemented in layers, from a simple messaging API to a more advanced collaborative framework.

Level 1: A Core Messaging Bus
An internal API that allows a running agent (or subagent) to send a message to another named agent.

• API: A new tool or internal function like sendMessage(targetAgent: string, message: object).
• Example: A tester-agent could execute sendMessage('developer-agent-1', { type: 'TEST_FAILURE', file: 'auth.ts', line: 42, error: 'NullPointerException' }).
• The developer-agent-1 would receive this message in its context and could be prompted to act on it.

Level 2: A Shared Dynamic State (or "Whiteboard")
A transient, shared key-value store or context space that is accessible to all agents within a single "team" or session. This would solve the parallel work problem.

• How it works: Agents could post their status or discoveries to the whiteboard.
• Example:
• Agent A: sharedState.add('files_in_progress', 'api/new-endpoint.ts')
• Agent B: const inProgress = sharedState.get('files_in_progress'); Before cleaning up its directory, Agent B would know to ignore files that other agents are actively working on.

Level 3: A "Team" or "Squad" Abstraction
A higher-level construct to formalize agent groups. When initiating a task, a user could assign it to a pre-configured team of agents.

• Configuration: A user could define a frontend-team consisting of a react-developer agent, a css-stylist agent, and a cypress-tester agent.
• Invocation: claude --team=frontend-team "Build a new settings page with these form fields."
• The team would then autonomously coordinate using the messaging bus and shared state to complete the task.

Describe alternatives you've considered

I am aware of and have used the following workarounds, which highlights the need for a native solution:

1. Manual User Orchestration: As described above, the user acts as the communication bus. This is slow, error-prone, and doesn't scale.

1. File-Based Mailboxes: Having agents write status updates or messages to a shared communication.md file. This is clunky, requires agents to constantly poll the file, and is subject to race conditions.

1. Git Worktrees: This is the best current solution for preventing destructive interference in parallel work. It provides isolation. However, it does not enable collaboration. The agents remain unaware of each other.

1. Claude Code SDK: It is technically possible to build a custom orchestration script using the SDK that manages multiple agent processes and pipes I/O between them. This is extremely powerful but requires the user to become an expert in building agentic systems, which defeats the purpose of having a seamless, out-of-the-box tool. The proposed feature is about bringing this advanced capability into the core product for all users.

Additional context

Implementing this feature would be a transformative step for Claude Code, evolving it from a world-class "AI pair programmer" into a true "AI software development team in a box." It would unlock the ability to tackle much larger, more complex, and long-running tasks with a higher degree of autonomy.

Imagine being able to give Claude Code a JIRA epic and have a team of agents autonomously design the architecture, divide the work, implement features in parallel, test each other's code, and finally merge a complete, working feature branch. This is the future of agentic software development, and direct agent communication is the foundational technology required to get there.

Thank you for considering this. Your work on subagents has already laid an amazing foundation, and I believe this is the logical and most impactful next step.