MCP vs A2A vs AGENTS.md: Which Layer Does What in 2026?

If AI agents feel harder to evaluate in 2026 than they did a year ago, you are not imagining it. The conversation has moved beyond “which model should I use?” and into which layer solves which part of the stack. Google’s March 2026 guide to agent protocols laid out how quickly the landscape has expanded, while the Linux Foundation’s April 2026 update on A2A showed how fast adoption is moving from theory into production. For teams building real systems, MCP vs A2A is now a practical architecture question, not just another acronym debate.

This article intentionally focuses on MCP, A2A, and repo instruction files because those are the layers most developers are running into first. Google’s broader protocol landscape also includes things like UCP, AP2, A2UI, and AG-UI, but the goal here is to make the most common implementation decisions easier to reason about, not to catalog every emerging standard.

Why AI agent layers matter now

The biggest shift in agent tooling is that vendors are starting to converge on clearer layers instead of shipping everything as one proprietary bundle. In Google’s Developer’s Guide to AI Agent Protocols, MCP, A2A, UCP, AP2, A2UI, and AG-UI are presented as different pieces of the same broader problem: how agents access tools, communicate, transact, and render interfaces.

That matters because production teams do not just need a smart model. They need a system that can:

• reach tools and data sources reliably
• coordinate across multiple agents or services
• obey repo-specific instructions and constraints
• run in a controlled execution environment
• stay governable as more teams adopt it

That is why this topic is getting traction now. OpenAI now exposes an MCP tool in the Responses API, Anthropic positions Claude Code as an agentic coding system that works across files and tools, and A2A has crossed 150 supporting organizations. The ecosystem is not settling down. It is becoming layered.

What MCP does

MCP, or Model Context Protocol, is the tool-and-context layer. Its job is to give an agent a standard way to discover tools, call them, and work with external context without every integration becoming a custom one-off.

In practice, MCP is what you reach for when your agent needs to:

• query internal APIs
• search documentation
• inspect databases
• interact with product catalogs or ticket systems
• call external services through a consistent interface

OpenAI’s official docs describe the MCP tool as a way to connect models to both remote MCP servers and connectors in the Responses API. That is an important signal because it means MCP has clearly moved beyond demo-only usage and is now part of mainstream implementation paths.

If you have already worked through a custom server setup, this should feel familiar. Our guide on building custom MCP servers covers the part many teams hit first: getting a coding agent to access real domain data instead of only what fits in a prompt.

MCP is not agent-to-agent coordination

This is where teams get tripped up.

MCP can give an agent access to tools and data, but it does not solve every orchestration problem by itself. If one agent needs to ask another agent to do work, hand off a task, or negotiate across multiple specialized agents, you have moved beyond basic tool access.

That is where A2A enters the picture.

What A2A does

A2A, or Agent2Agent, is the coordination layer. It is designed for situations where one agent needs to communicate with another agent securely and predictably.

Google announced A2A in April 2025, and the project was later contributed to the Linux Foundation. In April 2026, the Linux Foundation reported that A2A had passed 150 supporting organizations and was already seeing enterprise production use.

That makes A2A relevant when your architecture includes:

• a planner agent delegating work to specialist agents
• separate vendor or department agents that need to collaborate
• cross-system workflows where no single agent owns the whole task
• agent handoffs that need stronger structure than ad hoc prompt passing

A2A is not a replacement for MCP

A2A and MCP solve different problems.

• Use MCP when an agent needs tools, context, or external data.
• Use A2A when agents need to talk to each other as agents.

A good mental model is this:

1. An agent uses MCP to reach a tool or service.
2. That same agent may use A2A to delegate part of the workflow to another agent.
3. Both can coexist in the same production system.

So the question is not really “MCP or A2A?” It is usually “Where does each one belong in the stack?”

Where AGENTS.md and CLAUDE.md fit

This is the part that creates the most confusion because AGENTS.md and CLAUDE.md are not network protocols at all.

They are instruction layers.

Anthropic’s docs describe CLAUDE.md files as Markdown files that give Claude persistent instructions for a project, personal workflow, or organization. GitHub’s Copilot docs similarly state that you can create one or more AGENTS.md files in a repository, and that the nearest matching file in the directory tree takes precedence. GitHub also documents support for root-level CLAUDE.md and GEMINI.md, which reinforces the idea that repo instruction files are becoming a recognized layer in coding-agent workflows.

That means these files help answer a different question:

How should the agent behave inside this codebase or project?

They are ideal for encoding things like:

• setup and test commands
• coding standards and file organization rules
• preferred architecture patterns
• review checklists
• deployment constraints
• repo-specific warnings and “do not touch” areas

The AGENTS.md project describes the format as a simple, open way to guide coding agents, essentially a README for agents rather than humans.

AGENTS.md and CLAUDE.md are governance, not transport

This is the cleanest way to think about them:

• MCP tells the agent how to reach tools and context.
• A2A tells agents how to collaborate.
• AGENTS.md and CLAUDE.md tell an agent how to operate within your repository.

If you have already been experimenting with repo-level rules, our post on modular CLAUDE.md setups is the natural companion to this topic.

A quick comparison for builders

Layer	Best for	Not the right fit	Example
MCP	Tool access and external context	Multi-agent delegation by itself	A coding agent querying internal docs or APIs
A2A	Agent-to-agent coordination	Replacing your tool-access layer	A planner agent handing tasks to specialist agents
AGENTS.md / CLAUDE.md	Repo-specific behavior and rules	Network interoperability or remote tool execution	Telling an agent which commands, tests, and conventions to use

How the major platforms are converging

The reason this topic is becoming more important is that the big platforms are starting to line up around similar building blocks, even if they use different product names.

OpenAI’s docs now support MCP in the Responses API, and the company’s April 2026 Agents SDK update added native sandbox execution so agents can run code, manipulate files, and work inside controlled computer environments.

Anthropic’s Claude Code overview positions Claude Code as a coding agent that reads codebases, edits files, runs commands, and integrates with development tools. Its project memory model makes repo instructions first-class through CLAUDE.md.

GitHub, meanwhile, documents repository custom instructions through AGENTS.md support in Copilot, which helps normalize the idea that coding agents need explicit project guidance, not just access to a model.

The common pattern is becoming easier to spot:

• instructions for how the agent should behave
• tools and context for what the agent can access
• execution for what the agent can safely run
• coordination for how agents work together

That layered model is much more durable than chasing whichever one vendor feature is trending this month.

A simple decision framework for builders

When teams ask about MCP vs A2A, what they usually need is not a protocol history lesson. They need a build decision.

Choose MCP when your problem is tool access

Pick MCP when the main problem is that your agent needs to reach external systems in a standard way.

Examples:

• letting a coding agent query your internal docs or API schema
• connecting a support agent to your CRM, help desk, or billing tools
• exposing a database or workflow API to multiple agent clients

Choose A2A when your problem is delegation

Pick A2A when your architecture has multiple agents with distinct roles and they need a formal way to coordinate.

Examples:

• a planner agent handing work to a research agent and a coding agent
• an enterprise assistant routing tasks to department-specific agents
• cross-vendor agent workflows where message structure and trust boundaries matter

Choose AGENTS.md or CLAUDE.md when your problem is consistency

Pick repo instruction files when the biggest issue is that the agent does not understand how your project works.

Examples:

• it runs the wrong commands
• it ignores your testing standards
• it restructures files in ways your team hates
• it needs different rules in different parts of a monorepo

Use all three in serious systems

Many real deployments will use:

• AGENTS.md or CLAUDE.md for repo behavior
• MCP for tools and external context
• A2A for multi-agent coordination

That is not overengineering. It is just separating concerns cleanly.

Common mistakes when teams mix protocols

The fastest way to create confusion is to treat every new agent format like it solves the same problem.

Here are the most common mistakes:

Mistaking instruction files for interoperability standards

An AGENTS.md file can make an agent better inside your repo. It does not, by itself, solve tool access, remote actions, or agent-to-agent handoff.

Using MCP as a catch-all orchestration layer

MCP is powerful, but forcing it to stand in for multi-agent coordination usually creates brittle prompt-level workarounds instead of clear delegation patterns.

Skipping execution boundaries

As agent capabilities grow, execution matters as much as reasoning. OpenAI’s recent sandbox push is a sign of that. If your agent can write files, install dependencies, or run commands, you need an intentional execution boundary rather than hoping the prompt is enough.

Ignoring governance in coding workflows

Teams often wire up tools first and only later realize the agent keeps violating project norms. That is why repo instruction files matter so much, especially in larger teams and monorepos.

If governance is the missing piece in your rollout, our article on securing AI coding agent workflows is worth reading before you expand tool access.

What to implement first

If you are building right now, start in this order:

1. Add repo-level instructions with AGENTS.md or CLAUDE.md so the agent has local rules.
2. Add MCP for the most valuable tool and context integrations.
3. Add an execution boundary such as a sandboxed environment before expanding autonomy.
4. Add A2A only when you truly have multiple agents that need formal coordination.

This order keeps your rollout grounded in real value. Most teams benefit from better instructions and better tool access before they need a full multi-agent topology.

Where to go from here

The most useful way to think about MCP vs A2A is that they belong to different layers of the same emerging stack. MCP handles tools and context. A2A handles collaboration. AGENTS.md and CLAUDE.md handle project-specific behavior.

That separation is good news. It means the agent ecosystem is becoming easier to reason about, even as it gets more powerful.

If you are building coding-agent workflows in 2026, start by making your repository legible to the agent, then connect the right tools, then add coordination only where it actually earns its complexity. For a practical next step, read our guides on AI coding agents in 2026, custom MCP servers, and modular CLAUDE.md setups.