Multi-Agent Orchestration for Coding: Inter-Agent Protocols and Parallel Workflows (2026)

The Protocol Problem

Running multiple agents is not orchestration. Orchestration requires structured communication: agents discovering each other's capabilities, passing typed messages, synchronizing shared state, and resolving file conflicts without human intervention.

Without a protocol, agents duplicate work. They overwrite each other's files. They lose context that another agent already found. Cognition measured that single agents spend 60% of their time searching for context. Multiple uncoordinated agents multiply that waste, not reduce it.

Two protocols are converging as the standard. Google's Agent-to-Agent protocol (A2A) handles agent discovery and task delegation through JSON-RPC over HTTP. Anthropic's Model Context Protocol (MCP) handles tool sharing and context access. A2A is how agents find and talk to each other. MCP is how agents access shared capabilities. Together they form the two layers of multi-agent coordination.

Claude Code's Communication Stack

Claude Code Agent Teams implement a three-tool communication system. Unlike generic agent frameworks, this stack is purpose-built for coding: tasks map to code changes, worktrees provide file isolation, and messages carry enough context for teammates that never saw the original conversation.

{
  "id": "task-001",
  "description": "Refactor auth middleware to use JWT validation",
  "status": "in-progress",
  "owner": "security-reviewer",
  "blocks": ["task-003"],
  "blocked_by": [],
  "created_at": "2026-03-10T10:00:00Z"
}

Teammates do not inherit the lead's conversation history. Whatever context a teammate needs, the lead must provide in the spawn prompt or CLAUDE.md. This is the most common mistake in multi-agent setups: spawning agents without sufficient context, then wondering why they produce irrelevant code.

The Google A2A Protocol

A2A standardizes how agents discover and communicate with each other across platforms and vendors. The protocol has three core concepts: Agent Cards for capability discovery, Tasks as the unit of work, and Messages for structured communication.

{
  "name": "code-reviewer",
  "description": "Security-focused code review agent",
  "url": "https://agents.example.com/reviewer",
  "skills": [
    { "id": "security-audit", "name": "Security Audit" },
    { "id": "dependency-scan", "name": "Dependency Scanning" }
  ],
  "authentication": {
    "type": "bearer",
    "tokenEndpoint": "https://auth.example.com/token"
  }
}

Tasks progress through defined states: submitted → working → input-required → completed | failed | canceled. Messages contain typed parts: TextPart for plain text, FilePart for binary data (inline bytes or URI reference), and DataPart for structured JSON like form data or schemas.

Communication uses JSON-RPC over HTTP. A client agent retrieves remote Agent Cards to find agents with matching skills, then sends tasks through the /tasks/send endpoint. Over 50 technology partners have adopted A2A, including Atlassian, Salesforce, SAP, MongoDB, and Google's own Vertex AI.

MCP as Orchestration Layer

Model Context Protocol is not an agent framework. It is the integration layer that gives agents access to tools, APIs, and data sources through a standardized interface. In multi-agent setups, MCP means any agent on the team can access any tool without custom integrations per agent.

Codex CLI demonstrates the pattern. It exposes itself as an MCP server with two tools: codex() for starting tasks and codex-reply() for steering running agents. The OpenAI Agents SDK orchestrates multiple Codex instances through this protocol, with each agent inheriting the parent's sandbox policy.

# Start Codex CLI as an MCP server
codex --mcp

# Exposes two tools:
# codex()      - start a new coding task
# codex-reply() - steer a running agent

# Agents SDK orchestrates multiple instances
# Each agent inherits parent's sandbox policy
# State persisted in SQLite

The power of MCP in multi-agent orchestration: when a new tool is added to the MCP server, every agent in the team can use it immediately. No per-agent configuration. No custom integrations. The tool catalog is shared, and agents discover available tools through the protocol.

How OpenCode Does Parallel Workflows

OpenCode ported Claude Code's agent teams architecture with three significant improvements to the communication protocol. The differences reveal what matters in practice.

The JSONL format is the important detail. Each message is one appended line. No file locking, no read-modify-write cycles. Under high message volume (5+ agents chatting frequently), this eliminates the race conditions that plague JSON array storage.

// team_inbox/<projectId>/<teamName>/<agentName>.jsonl
{"id":"msg-001","from":"security-reviewer","text":"Found SQL injection in auth.ts:42","timestamp":"2026-03-10T10:05:00Z","read":false}
{"id":"msg-002","from":"test-agent","text":"Confirmed. Writing regression test.","timestamp":"2026-03-10T10:05:30Z","read":false}

Auto-wake solves a problem Claude Code users encounter: the lead agent sitting idle while teammates work. In OpenCode, when a teammate sends a message to an idle lead, the system automatically restarts the lead's prompt loop. No polling delay. No missed messages.

The multi-provider capability is unique. A single team can run GPT-5.3 Codex for fast edits, Gemini 2.5 Pro for research, and Claude Sonnet 4 for architecture, all coordinating through the same message bus. Each model plays to its strengths.

The Planner-Worker-Judge Pattern

This architecture is converging across every major coding tool. The names differ but the pattern is identical: one agent plans, multiple agents execute, one agent evaluates.

The judge role is what separates orchestration from parallelism. Without evaluation gates, you get faster output but not better output. The judge ensures quality scales with speed. Cursor has validated this at scale with hundreds of concurrent agents running for weeks on codebases exceeding 1M lines of code.

# CLAUDE.md configuration for planner-worker-judge
# The lead (planner) uses delegate mode:
# it can only coordinate, not implement.

Create an agent team with delegate mode:

- Planner (you): decompose the migration into tasks.
  Assign file ownership. Track dependencies.

- Worker 1: owns src/api/ and src/db/migrations/.
  Implement schema changes and API endpoints.

- Worker 2: owns src/components/ and src/app/.
  Implement frontend changes after API is ready.

- Judge: reviews all changes after workers complete.
  Run tests, check types, flag regressions.
  Reject and reassign if quality gates fail.

Tool-by-Tool Protocol Comparison

Every tool implements multi-agent differently. The comparison that matters is not the feature list but the communication protocol: how agents pass information, how tasks are shared, how agents discover each other, and how state stays synchronized.

The divergence is in state synchronization. Claude Code and OpenCode use files on disk. Codex uses SQLite. Cursor uses remote cloud state. The tradeoff: file-based state is inspectable and debuggable but slower to query. Database-backed state is faster to query but opaque. Cloud state scales but adds latency.

Real Speedup Numbers

Multi-agent speedup is not theoretical. Multiple studies and internal evaluations report concrete numbers.

The M1-Parallel framework achieves 1.8x speedup compared to single-agent baselines while maintaining the same task completion rate. With early termination, speedup increases to 2.2x while preserving accuracy. These numbers hold because the framework avoids the coordination overhead that drags down naive parallelism.

Anthropic's internal evaluation found that a system with Opus 4 as lead and Sonnet 4 as supporting subagents outperformed single-agent setups by over 90%. The improvement scales with token usage and the ability to spread reasoning across independent context windows. The key qualifier: tasks must be parallelizable. Tightly coupled sequential work does not benefit.

In enterprise deployments, a large bank achieved over 50% reduction in development time using multi-agent code modernization. Content workflow benchmarks show a 36% speed improvement (6:10 down to 3:56 for a standard pipeline). Five briefs processed in 19 minutes vs. 30 minutes single-threaded.

Building Your Own Orchestration Layer

If the built-in tools don't fit your workflow, you can build a custom orchestration layer. Three architectural decisions determine whether it works.

# 1. Create worktrees for each agent
git worktree add .agents/worker-1 -b agent/worker-1 HEAD
git worktree add .agents/worker-2 -b agent/worker-2 HEAD

# 2. Initialize JSONL mailboxes
mkdir -p .agents/inbox
touch .agents/inbox/worker-1.jsonl
touch .agents/inbox/worker-2.jsonl

# 3. Task file with dependencies
cat > .agents/tasks/task-001.json << 'EOF'
{
  "id": "task-001",
  "description": "Implement API endpoints",
  "owner": "worker-1",
  "status": "pending",
  "blocks": ["task-002"]
}
EOF

# 4. Run agents in parallel
claude --worktree .agents/worker-1 &
claude --worktree .agents/worker-2 &

Frequently Asked Questions

What is multi-agent orchestration in coding?

Multi-agent orchestration is the coordination of multiple AI coding agents through structured communication protocols. It goes beyond running agents in parallel. Orchestration includes agent discovery (A2A Agent Cards), structured message passing (JSONL mailboxes, JSON-RPC), task dependency management, and file isolation through git worktrees. Claude Code Agent Teams, Codex CLI, Cursor, Windsurf, and Grok Build all implement different orchestration protocols.

What is the difference between A2A and MCP protocols?

A2A (Agent-to-Agent) is Google's protocol for agent discovery and peer communication. Agents publish Agent Cards describing their capabilities and communicate through JSON-RPC over HTTP with structured task lifecycles. MCP (Model Context Protocol) is Anthropic's protocol for tool sharing and context access. A2A handles how agents talk to each other. MCP handles how agents access shared tools. They are complementary layers, not competitors.

What is the planner-worker-judge pattern?

The planner-worker-judge pattern is the dominant multi-agent architecture converging across coding tools. The planner decomposes tasks and manages dependencies. Workers claim tasks, execute in isolated git worktrees, and push changes. The judge evaluates output quality and decides whether to accept or retry. Each cycle starts fresh to combat context drift. Claude Code, Codex CLI, and Cursor all implement variants of this pattern.

How fast are multi-agent coding workflows compared to single-agent?

Studies show 1.8-2.2x speedup with parallel agents using early stopping and termination strategies. Anthropic's internal evaluation found multi-agent systems outperform single-agent by over 90% on parallelizable tasks. Enterprise deployments report over 50% reduction in development time. Speedup scales with task independence. Sequential dependencies reduce the benefit.

How do Claude Code Agent Teams communicate?

Claude Code uses a three-tool communication stack. TaskCreate stores tasks as JSON files with unique IDs, status tracking, ownership, and dependency graphs (blocks/blocked-by). SendMessage supports direct messages to a named teammate and broadcasts to all teammates. Each teammate runs in its own git worktree for file isolation. Tasks auto-unblock when dependencies complete.

How does OpenCode's multi-agent system differ from Claude Code?

OpenCode uses JSONL append-only files for message storage (O(1) writes vs. Claude Code's O(N) JSON array rewrites), event-driven auto-wake instead of polling, peer-to-peer mesh communication instead of leader-centric routing, and can mix models from different providers (GPT, Gemini, Claude) in the same team. Any teammate can message any other directly by name.