[FEATURE] Multi-agent collaboration across machines (Agent-to-Agent protocol)

[MarioK1975]

Preflight Checklist

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

Problem Statement

Modern software is rarely a single codebase. Microservices, headless CMS + consumer apps, IoT platforms — real-world systems consist of multiple repositories on multiple machines that must work together through shared APIs, webhooks, and data contracts.

Claude Code is excellent at working within one codebase. But it has no concept of "the other side."

When two Claude Code instances work on interconnected systems simultaneously, they are completely blind to each other. Every interface change, every schema decision, every API contract must be manually relayed by the developer — who becomes a slow, error-prone message broker between two AI agents that could otherwise coordinate at machine speed.

This isn't an edge case. It's the reality for:

• Microservice architectures (each service = separate repo, separate machine)
• Headless CMS + frontend apps (CMS on server A, consumer apps on server B)
• IoT/embedded + cloud (device firmware on one machine, cloud backend on another)
• Platform teams (API team + multiple consumer teams working in parallel)

The irony: we use Claude Code because it's fast and autonomous. But the moment a project spans two machines, the human becomes the bottleneck again.

Proposed Solution

An Agent-to-Agent protocol built on top of MCP, enabling:

1. Shared Workspace / Channel: Multiple Claude Code instances join a shared collaboration channel (via MCP server or similar). They can see what each agent is working on, what files were changed, and what decisions were made.

2. Real-time Messaging: Agents can send structured messages to each other:

   • "I changed the webhook payload format — here's the new schema"
   • "I need an endpoint at /api/events returning this JSON structure"
   • "My side is ready for integration testing"

3. Spec Negotiation: Agents can propose and agree on shared interfaces (API specs, data models, event formats) before implementing independently in parallel.

4. Conflict Awareness: When both agents touch shared definitions (e.g., a TypeScript type exported by one and imported by the other), they coordinate rather than diverge.

Alternative Solutions

• Shared MCP Knowledge Base (current workaround): A custom MCP server that both machines access via SSH. Agents store and retrieve project knowledge asynchronously. This works for background context but lacks real-time coordination — Agent A doesn't know Agent B just changed an interface.

• Human as Message Broker: The developer manually copies context between sessions ("On the other machine, Claude just built X, now build Y to match"). This works but is slow and defeats the purpose of AI-assisted development.

• Single Machine, Multiple Repos: Running everything on one machine loses the benefit of parallel execution and doesn't match real-world team setups where systems run on different infrastructure.

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

A typical multi-system project with Claude Code on two machines:

System	Stack	Machine	Purpose
Backend API	Python (FastAPI)	Mac 1	API + business logic
Headless CMS	Strapi/Contentful	Mac 2	Content management
Consumer App	Next.js	Mac 2	End-user frontend

The CMS is the single source of truth for content (events, menus, schedules, media). The backend API consumes this data and serves it to displays, apps, and other endpoints.

Both systems are being actively developed by separate Claude Code instances. The CMS has content types with channel controls (which content goes to which consumer). The backend has webhook receivers and rendering endpoints. Custom API routes are being built on both sides.

But the two agents can't coordinate. When the CMS agent adds a field to a content type, the backend agent doesn't know. When the backend agent needs a specific JSON format, it can't tell the CMS agent. The developer must Alt-Tab between terminals, copy schemas, and explain context that both agents already have — just in separate, isolated sessions.

Current workflow (slow):

1. On Mac 2: "Claude, build the content types for events"
2. Wait for completion
3. Switch to Mac 1: "Claude, the CMS now has events at this URL with this schema — build the webhook receiver"
4. If the schema needs adjustment, go back to Mac 2 and relay the change
5. Repeat for every interface point — events, menus, schedules, media sync...

Desired workflow (fast):

1. Both Claude Code instances join a shared channel
2. Developer: "Build the event system — CMS manages events, backend renders them for displays and apps"
3. Agent on Mac 2 proposes the event schema and API endpoint
4. Agent on Mac 1 reviews, suggests adjustments (e.g., "I need startTime and endTime as ISO strings, not Unix timestamps, and a duration field")
5. Both agents agree on the interface and implement their sides in parallel
6. They notify each other when ready for integration testing
7. Developer focuses on product decisions, not on being a relay

This would turn hours of back-and-forth into minutes of autonomous collaboration.

Additional Context

• MCP as foundation: The MCP (Model Context Protocol) infrastructure is already there. We're already using shared MCP servers (accessed via SSH from both machines) for persistent knowledge storage. The missing piece is real-time agent-to-agent communication on top of MCP.

• Not just "more context window": This isn't about making one agent smarter — it's about enabling genuine multi-agent teamwork where each agent owns a codebase and they coordinate through shared protocols, just like human developers do.

• Real production use: This isn't theoretical. We're running this kind of multi-system setup in production today, actively building interconnected services on two separate machines. The coordination overhead between Claude Code sessions is our biggest bottleneck.

• Scaling beyond two: The same pattern applies to microservice architectures, monorepo teams, or any scenario where multiple related systems need coordinated development. Imagine 3-4 Claude Code agents each owning a service, negotiating APIs, and implementing in parallel.

• Security consideration: Agent-to-agent communication should be opt-in, authenticated (perhaps via shared MCP server credentials), and the human should be able to observe/approve cross-agent decisions before they're implemented.

[github-actions]

Found 3 possible duplicate issues:

1. Cross-Instance Communication Between CLAUDE Sessions for Remote Testing and Faster Fix Deployment #27601
2. [Feature Request] Cross-repository session communication for multi-repo workflows #20559
3. Feature Request: Inter-agent message injection — allow external processes to send prompts to a running Claude Code session #27441

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[MarioK1975]

Not a duplicate — this addresses a different layer of the problem.

I've reviewed the linked issues, and while they're all related to multi-agent communication, they solve different parts of the stack:

#27601 focuses on remote debugging — sending error logs from a production server back to the dev machine. That's a specific DevOps workflow.
#27441 focuses on message injection infrastructure — sockets, pipes, APIs to push prompts into a running session. That's the transport layer.
#20559 is closest, but focuses on cross-repo code sync — "I changed this file, update your imports." That's reactive coordination.
This issue (#28300) is about the workflow layer on top: Two agents that don't just pass messages, but negotiate shared interfaces before implementing. Agent A proposes an API schema, Agent B reviews it and requests changes, they agree, then both implement their sides in parallel. The developer makes product decisions — the agents handle the coordination.

Think of it this way:

#27441 = "How do I send a message to another session?" (plumbing)
#20559 = "How do I notify another session about my changes?" (events)
#28300 = "How do two agents collaborate like a team?" (workflow)
These are complementary, not duplicates. The injection API from #27441 could be the transport. The cross-repo awareness from #20559 could be the trigger. But neither describes the collaboration protocol — spec negotiation, interface agreement, parallel implementation, integration readiness signaling.

I'm happy to consolidate if there's a preferred umbrella issue, but I'd argue this adds a distinct perspective that the others don't cover. I've upvoted all three related issues.

[tiagogbarbosa]

+1

[ThinkOffApp]

This is exactly the problem we hit running 7-10 agents across a MacBook, Mac mini, and Galaxy Watch. Cross-machine agents are blind to each other's context and user state.

We open-sourced user-intent-kit to solve the intent/state layer: https://github.com/ThinkOffApp/user-intent-kit

It gives every device a shared view of what the user is doing (coding, in a meeting, walking) and what they prefer (response style, notification urgency). Devices push state updates, agents read before acting. Built on LWW per-device slots, CRDT merge planned.

Already integrated with our agent coordination platform Groupmind (https://groupmind.one) which provides rooms, scratchpads, and a live intent dashboard. Also shipping adapters for Swift (Apple Watch/iOS) and Zig (ClawWatch wearable runtime). Works alongside IDE Agent Kit for cross-machine agent communication.

[sk7n4k3d]

Real-world use case: Mobile app + ML training coordination

I'm building Alfred, a personal AI assistant Android app (Kotlin, 81 tools, wake word detection, agent system). My workflow involves two Claude Code instances running simultaneously:

• Instance A (my main machine): Android development — writing Kotlin, building APKs, deploying to phone, reading device logs, fixing bugs
• Instance B (GPU server): ML model training — training a custom OpenWakeWord model (ONNX), validating accuracy, exporting weights

What happens today

I am literally the human message bus between the two instances:

1. Instance B trains a wake word model, reports: "Model ready: 97% accuracy, 736KB, deployed to assets/"
2. I copy-paste this to Instance A
3. Instance A integrates it, builds, deploys to phone, reads logs: "False positives at 0.87-0.93 on background noise"
4. I copy-paste the diagnosis back to Instance B
5. Instance B retrains with more negative samples
6. Repeat 4-5 times

Each round trip takes 2-3 minutes of manual copy-paste instead of happening instantly. The instances work on the same git repo but can't see each other's work or communicate.

What I need

Instance A (code):  "The model produces false positives at 0.87-0.93 
                      on background noise. Here are the raw device logs. 
                      Retrain with these criteria: [...]"
                              ↓ (automatic)
Instance B (ML):    "Understood. Retraining with real device audio as 
                      negatives. New model exported to assets/. 
                      Validation scores: positives 0.99, negatives 0.003"
                              ↓ (automatic)  
Instance A (code):  "Building and deploying with new model..."

Concrete requirements

1. Shared project context: Both instances should see the same CLAUDE.md, memory files, and git state
2. Direct messaging: Instance A should be able to send a message to Instance B (and vice versa) without human relay
3. File-level coordination: When Instance B writes a file (hey_alfred.onnx), Instance A should be notified
4. Asymmetric roles: Instance A has Android SDK + ADB access, Instance B has GPU + training frameworks. They don't need the same tools, just communication.

This is not theoretical — I spent an entire evening being the relay between two Claude instances that could have coordinated autonomously. The Agent SDK's multi-agent support is a start, but it doesn't work across separate Claude Code sessions on different machines.

[maliang-agent]

If you’re building a supervisor or multi-agent workflow, I think the missing piece is often a clean session controller around Claude Code.

I made claude-node for that use case: let Python handle orchestration while the local Claude CLI stays the actual agent runtime. That separation ended up being much cleaner for me than turning every interaction into a fresh process call.

Sharing in case it helps:
https://github.com/claw-army/claude-node

[kumaakh]

We hit this exact wall and ended up building Apra Fleet as an open-source MCP server to solve it.
The core insight from our design: the missing piece isn't A2A messaging - it's a shared orchestration layer that one agent talks through to dispatch work to others and get results back, while handling session continuity, file transfer, and credential provisioning automatically.
In practice it looks like this - your Mac 1 agent (the PM) tells Fleet: "execute this prompt on the CMS machine", Fleet SSHes in, starts/resumes a Claude session there, runs the work, streams the result back. The two agents never need to know about each other's interface - the orchestrator handles handoff.
The scoped git auth point you raised is also addressed - we mint short-lived tokens (1hr) per machine via GitHub App rather than sharing PATs, so each agent only gets repo access to what it needs.
Still very early (v0.1.4), but might be useful to try against your CMS + backend setup