MCP, A2A, ACP — Three Protocols, Three Jobs, One Architecture Decision You Can't Ignore
The agent ecosystem now has three protocols. Each solves a different problem at a different layer of your stack. Confusing them isn't a technical debt. It's a design mistake.
Welcome back to Build with AI.
In our last edition we covered context windows and memory architecture — why stuffing transcripts into context is a design mistake, and how to build a proper retrieval layer instead. The response made one thing clear: developers are hungry for the mental model fix, not just the implementation.
This week, we fix another one.
If you’ve been building with AI agents in 2026, you’ve seen three acronyms everywhere: MCP, A2A, ACP. You’ve probably read that they’re “complementary.” You’ve probably also spent an afternoon in spec docs trying to figure out what that actually means for your architecture.
Here’s what most of that content doesn’t say: they solve completely different problems at completely different layers of your stack. Treating them as alternatives — or worse, picking one and ignoring the others — is how teams end up with agents that can use tools but can’t talk to each other, or agents that coordinate beautifully in isolation and fall apart the moment a third-party system is involved.
In this edition:
The three-layer protocol stack — what MCP, A2A, and ACP each do, where they live, and why the “which one should I use” question is usually the wrong question
How to implement the two-layer stack most production teams actually need right now — MCP for tools, A2A for agent coordination
What’s worth paying attention to in AI this week
The Mental Model — Your agent stack now has a protocol layer. Here’s how it’s structured.
Six months ago, MCP was the only protocol most AI engineers needed to know. That’s no longer true.
The agent ecosystem has matured fast enough that three distinct protocols now exist — each solving a different problem at a different layer of your stack. The confusion isn’t that developers don’t understand the protocols. It’s that they’re comparing things that aren’t in competition.
Here’s the one-line version of each:
MCP — how your agent talks to tools
A2A — how agents talk to each other
ACP — how agents message each other when you want REST and nothing else
Conflating any two of these is like asking whether HTTP or SQL is better. They operate at different layers. You don’t choose between them — you choose which combination your architecture needs.
MCP: the tool layer
Model Context Protocol, launched by Anthropic in late 2024 and now governed by the Linux Foundation, is the foundational layer. It gives agents structured, authenticated access to external tools — databases, APIs, file systems, third-party services. Think of it as the USB-C standard for AI: one protocol, every tool.
MCP is why your agent can query a database, send a Slack message, and read a PDF without you writing bespoke integration code for each. It’s the layer every team needs first, and for most single-agent applications, it’s the only layer they’ll ever need.
The numbers reflect this. MCP hit 97 million monthly SDK downloads and 10,000+ deployed servers by its first anniversary. OpenAI, Google, Microsoft, and AWS all adopted it. It is, at this point, infrastructure.
A2A: the coordination layer
Agent-to-Agent protocol, created by Google and donated to the Linux Foundation in June 2025, solves a different problem entirely. Not how an agent uses tools — but how agents hand off tasks to each other across systems, vendors, and organisational boundaries.
A2A hit v1.0 in April 2026. That matters because it’s no longer a directional bet — it’s a real implementation target. The protocol defines how agents discover each other, negotiate capabilities, exchange messages, and track task state across a handoff. Think of it as HTTP for agent coordination: a universal communication layer that doesn’t care what framework or vendor built the agent on either end.
When do you need it? When your architecture has multiple autonomous agents that need to delegate to each other — especially across vendor or service boundaries. A single agent connected to ten MCP servers doesn’t need A2A. An orchestrator agent handing off a compliance check to a specialist agent built by a different team on a different framework does.
ACP: the lightweight alternative
Agent Communication Protocol, developed by IBM and now under the Linux Foundation, covers similar ground to A2A but with a different design philosophy. Where A2A uses JSON-RPC 2.0 over HTTP and SSE, ACP is REST-native — it uses patterns most backend developers already know. No new transport to learn, no SSE to manage.
ACP is the right choice when your team wants inter-agent messaging without the overhead of adopting a new protocol stack. It’s particularly well-suited to controlled environments where all agents are within your own infrastructure. For cross-vendor or cross-organisation coordination, A2A’s richer capability negotiation is worth the added complexity.
The decision framework
You don’t need all three. Most teams need one or two, depending on where they are in their agent architecture:
Single agent, multiple tools → MCP only. This is the majority of teams right now.
Multiple agents, same infrastructure → MCP + ACP. Lightweight coordination without protocol overhead.
Multiple agents, cross-vendor or cross-org → MCP + A2A. The two-layer stack that enterprise teams are converging on.
All three → Only when you have internal agent messaging (ACP), cross-vendor coordination (A2A), and tool access (MCP) as distinct requirements. Rare, and usually premature.
The shift isn’t complicated. But it requires treating the protocol layer as an architectural decision you make deliberately — not something you bolt on when your single-agent system starts failing at scale.
In The Build, we implement the two-layer stack most production teams actually need: MCP for tool access, A2A for agent coordination, with a concrete handoff pattern you can drop into your own architecture.
The Build — Implementing the two-layer stack: MCP for tools, A2A for agent handoff
Most teams don’t need all three protocols. They need two: MCP to give agents access to tools, and A2A to let agents hand off tasks to each other. This is the stack we’re building — an orchestrator agent that uses MCP to query a database, and delegates a specialist task to a second agent via A2A.
Stack: Node.js, the MCP SDK, and the A2A client library. The pattern is framework-agnostic — the same architecture works with LangChain, LlamaIndex, or a bare OpenAI client.
The architecture before writing a line of code
Two agents. One job each.
Orchestrator agent — receives the user’s request, uses MCP to access tools (database, APIs, file system), decides when a task is outside its own capability, and delegates via A2A.
Specialist agent — exposes an A2A-compliant endpoint, receives delegated tasks, executes them, and returns structured results to the orchestrator.
The handoff is the critical piece. The orchestrator doesn’t call the specialist directly — it sends an A2A task, waits for a response, and incorporates the result into its own context. The specialist has no knowledge of the orchestrator. They’re decoupled by design.
Step 1 — set up MCP tool access for the orchestrator
Install the MCP SDK and define your tool server. This example connects the orchestrator to a database tool.
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
async function createMCPClient() {
const transport = new StdioClientTransport({
command: 'node',
args: ['./tools/database-server.js']
});
const client = new Client(
{ name: 'orchestrator', version: '1.0.0' },
{ capabilities: { tools: {} } }
);
await client.connect(transport);
return client;
}
async function queryDatabase(mcpClient, query) {
const result = await mcpClient.callTool({
name: 'query_database',
arguments: { sql: query }
});
return result.content[0].text;
}Your MCP tool server defines what the orchestrator can access. Keep each server focused — one server per domain (database, file system, external APIs). Don’t build a monolithic MCP server that does everything. The same principle applies here as with microservices: small, bounded, replaceable.
Step 2 — build the specialist agent’s A2A endpoint
The specialist exposes two endpoints: an agent card (capability discovery) and a task handler. A2A requires both.
import express from 'express';
import Anthropic from '@anthropic-ai/sdk';
const app = express();
app.use(express.json());
const anthropic = new Anthropic();
// Agent card — tells the orchestrator what this agent can do
app.get('/.well-known/agent.json', (req, res) => {
res.json({
name: 'compliance-specialist',
version: '1.0.0',
description: 'Runs compliance checks on structured data',
capabilities: {
streaming: false,
pushNotifications: false
},
skills: [
{
id: 'compliance_check',
name: 'Compliance check',
description: 'Validates data against regulatory requirements',
inputModes: ['application/json'],
outputModes: ['application/json']
}
]
});
});
// Task handler — receives delegated tasks from the orchestrator
app.post('/tasks/send', async (req, res) => {
const { id, message } = req.body;
const userMessage = message.parts
.filter(p => p.type === 'text')
.map(p => p.text)
.join('\n');
const response = await anthropic.messages.create({
model: 'claude-sonnet-4-6',
max_tokens: 1000,
system: `You are a compliance specialist.
Analyse the provided data and return a structured
compliance report. Be specific about violations
and recommendations.`,
messages: [{ role: 'user', content: userMessage }]
});
res.json({
id,
status: { state: 'completed' },
artifacts: [{
name: 'compliance-report',
parts: [{
type: 'text',
text: response.content[0].text
}]
}]
});
});
app.listen(3001, () => {
console.log('Specialist agent running on port 3001');
});Step 3 — build the orchestrator’s A2A client
The orchestrator decides when to delegate. The decision logic is straightforward: if the task requires specialist capability, send it via A2A. Everything else, handle locally with MCP tools.
import { v4 as uuidv4 } from 'uuid';
async function delegateToSpecialist(specialistUrl, taskData) {
const taskId = uuidv4();
const response = await fetch(`${specialistUrl}/tasks/send`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
id: taskId,
message: {
role: 'user',
parts: [{ type: 'text', text: JSON.stringify(taskData) }]
}
})
});
const result = await response.json();
if (result.status.state !== 'completed') {
throw new Error(`Task ${taskId} failed: ${result.status.state}`);
}
return result.artifacts[0].parts[0].text;
}
async function orchestrate(userRequest, mcpClient) {
// Step 1: use MCP to fetch the data needed
const data = await queryDatabase(
mcpClient,
`SELECT * FROM transactions WHERE date > NOW() - INTERVAL '30 days'`
);
// Step 2: decide whether to delegate
const needsComplianceCheck = userRequest
.toLowerCase()
.includes('compliance');
if (needsComplianceCheck) {
// Step 3: delegate via A2A
const report = await delegateToSpecialist(
'http://localhost:3001',
{ request: userRequest, data: JSON.parse(data) }
);
return report;
}
// Handle locally if no specialist needed
return data;
}Step 4 — wire it together
async function main() {
const mcpClient = await createMCPClient();
const userRequest =
'Run a compliance check on last month\'s transactions';
const result = await orchestrate(userRequest, mcpClient);
console.log('Result:', result);
await mcpClient.close();
}
main().catch(console.error);What this architecture gives you
Three things that matter in production:
Decoupled specialists. The compliance agent doesn’t know who called it. You can swap it out, version it independently, or replace it with a third-party A2A-compliant service without touching the orchestrator.
Clean capability boundaries. MCP handles tool access (what the agent can read and write). A2A handles task delegation (what the agent can ask another agent to do). Mixing these responsibilities into one layer is how architectures become unmaintainable.
Protocol-level interoperability. Because A2A is an open standard, your specialist agent can receive tasks from any A2A-compliant orchestrator — not just yours. That’s the difference between integration and infrastructure.
The decision your architecture needs to make explicitly
One question that comes up when building this: how does the orchestrator decide when to delegate versus handle locally?
Don’t use an LLM call for this decision — it’s slow and expensive for a routing problem. Use deterministic rules first: keyword matching, task type classification, input schema validation. Only reach for an LLM-based router if your routing logic is genuinely complex and rules-based approaches fail. Most teams over-engineer the routing layer and under-engineer the handoff contract.
The full two-layer stack — MCP tool access, A2A task delegation, deterministic routing — is around 120 lines of working code. The architecture decisions above are harder than the code. Get the boundaries right and the implementation follows.
The Radar
01. A CVSS 9.8 vulnerability just dropped in an MCP integration — and it changes how you think about tool access.
MCP is infrastructure now. And infrastructure gets attacked. A critical vulnerability was disclosed in May 2026 in an MCP integration — the kind of severity score that means remote code execution is on the table. The practical implication for teams building on MCP: your tool servers are now an attack surface, and the default assumption that MCP integrations are internal and therefore safe is wrong. Two things to do now: audit every MCP server you’re running for authentication gaps, and treat your tool server permissions the same way you’d treat database credentials — least privilege, scoped access, rotated regularly. The protocol is solid. The implementations are where the risk lives.
Read it here: MCP Security Vulnerability Disclosure — May 2026
02. A2A hit v1.0 in April — which means agent-to-agent handoffs are now a real implementation target, not a directional bet.
For the past year, A2A has been something teams watched but didn’t build on. The 0.3 preview spec was unstable enough that production commitments felt premature. That changed in April 2026. V1.0 means a stable spec, committed SDK support, and — most importantly — enterprise vendors treating it as infrastructure. SAP has integrated A2A into its Joule AI assistant, which runs ERP systems for the majority of the Global Fortune 500. When SAP commits to a protocol, it becomes the de facto standard for enterprise agent coordination across finance, supply chain, and procurement. If you’ve been waiting for A2A to stabilise before building on it, the wait is over.
Read it here: A2A Protocol v1.0 Release — Linux Foundation
03. Half of all enterprise agents still can’t talk to each other — and that’s now a competitive gap, not just a technical debt.
The average enterprise runs 12 AI agents. Half of them operate in complete isolation. That number comes from Salesforce’s 2026 Connectivity Benchmark Report, and it reframes the protocol conversation entirely. The teams asking “should we implement A2A?” are already behind. The right question is “how quickly can we retrofit coordination into our existing agent architecture?” The answer, for most teams, is: faster than you think, if you start with the two-layer stack from this edition’s Build section and add A2A to the agents that actually need to delegate tasks. Don’t boil the ocean. Pick one handoff that matters and make it protocol-compliant first.
Read it here: Salesforce 2026 Connectivity Benchmark Report
AI Tools of the Week
MCP Inspector: Debug your MCP servers visually
The tool you wish existed the first time an MCP server silently failed. MCP Inspector is an open-source visual debugger that lets you connect to any MCP server, browse its available tools, fire test calls, and inspect the raw request/response cycle — all without writing a line of code. Think of it as Postman for MCP. If you’re building the two-layer stack from this edition, this is the first thing to install before you write a single tool server. Catching a malformed tool schema in Inspector takes thirty seconds. Catching it in production takes thirty minutes and a lot of logs.
Agentboard: Observability for multi-agent systems
The missing monitoring layer for teams running more than one agent in production. Agentboard traces task flows across agents, visualises A2A handoffs, and surfaces latency and failure points in multi-step pipelines. The dashboard shows you which agents are doing the most work, where tasks are stalling, and which handoffs are failing silently — the exact failure modes that are invisible when you’re logging individual agents but not the coordination layer between them. Free tier covers up to 5 agents and 10,000 traces per month. Worth connecting before your agent count grows past the point where mental models stop working.
Zep: Temporal knowledge graph for agent memory
Worth calling out again in this context: as your agent architecture grows from one agent to many, memory becomes a coordination problem, not just a storage problem. Which agent remembered what? Which facts are still valid? Zep’s Graphiti engine stores fact validity windows rather than timestamped snapshots — it knows that a fact was true until a certain point, not just that it was stated at a certain point. In a multi-agent system where different agents update the same knowledge base at different times, that distinction prevents an entire class of stale-context bugs. If the memory edition two weeks ago convinced you to build a retrieval layer, Zep is the right tool for the coordination layer that comes next.
Betterclaw: Managed agent infrastructure with MCP and A2A built in
The managed option for teams that want the two-layer stack without running the infrastructure themselves. Betterclaw handles MCP server provisioning, A2A endpoint routing, agent identity, and capability discovery out of the box — the four things that take the most setup time when you build the stack from scratch. Verified skills, encrypted secrets, and a free-forever tier make it a reasonable starting point for smaller teams validating the architecture before committing to a self-hosted setup. If the Build section felt like a lot of moving parts, start here and work backwards to understand what you eventually want to own.
If you made it this far, your agent architecture now has a protocol layer — and you understand why it exists.
Most teams shipping agents in 2026 are still treating MCP as the whole story. They’ll hit the coordination ceiling eventually: agents that can use tools but can’t talk to each other, architectures that scale to three agents and then become unmaintainable, integrations that break every time a third-party vendor changes their API. You just opted out of that trajectory.
You have the mental model — three protocols, three layers, three different jobs. You have the implementation — MCP for tool access, A2A for task delegation, deterministic routing between them. And you have the decision framework for knowing which combination your architecture actually needs, today, without over-engineering.
If this edition changed how you think about agent interoperability — forward it to the engineer on your team who’s still asking “MCP or A2A?” They’re asking the wrong question. Now you can tell them why.
See you next week.
Charu Mitra Dubey
Editor-in-chief, Build with AI