MCP Won. A2A Is Next. Here's Your Build Order.
On April 3, 2026, Microsoft shipped Agent Framework 1.0. MCP support was live. A2A was listed as "coming soon." That one detail settled a debate that's been running since 2024.
Not with a manifesto. Not with a protocol war. With a shipping decision by a team that has to maintain the thing and stake a real roadmap on it.
If you've been watching the MCP vs A2A conversation and waiting for a clear answer: this is it.
The 22 Days That Settled It
The "which protocol should I build on" question dragged through 2025 because the answer kept shifting. MCP had Anthropic behind it but felt like a vendor-controlled spec. A2A had Google, but without broader industry buy-in, it read as a competing standard rather than a complementary one. Builders hedged. Architecture reviews went in circles. Projects stalled waiting for someone to make the call.
Then three things happened inside 22 days.
March 12: A2A hit v1.0 with a formal Technical Steering Committee - AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. Not a preview, not a proposal. A ratified version with production-grade additions: gRPC transport binding, signed Agent Cards for cryptographic agent identity, multi-tenancy support, and a clean migration path from v0.3. IBM's ACP protocol merged into A2A in August 2025, so what was a three-way split is now definitively two protocols.
March 20: Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation. AWS, Google, Microsoft, and OpenAI all joined as co-governors. Anthropic retained no veto over the spec roadmap, no control over versioning, no leverage over certification. MCP became neutral infrastructure, not an Anthropic product.
April 3: Microsoft shipped Agent Framework 1.0. MCP live. A2A on the roadmap.
That sequence is not a coincidence. It's a build order.
The Two-Layer Model, Plainly
MCP and A2A solve different problems. Once you see that, the "vs" framing falls apart completely.
MCP is the agent-to-tool layer. It's how an agent connects to a database, calls an API, reads a file, runs a search, or uses an external service. MCP gives your agent hands.
A2A is the agent-to-agent layer. It's how agents delegate to each other, coordinate on tasks, and split work across specializations. A2A gives your agents colleagues.
Using both is not complexity for its own sake. It reflects how real work actually gets done. You need tools to do the work. You need coordination to do more work, faster, with better results across a larger set of tasks.
Here is what the full stack looks like in practice. An agent receives a task. It queries a skills directory via MCP to find the right tools for the job. Once it knows what's available, it delegates a research subtask to a specialized agent via A2A. That specialized agent uses its own MCP connections to run the research. Results come back up the chain, synthesized, and delivered.
That's not a theoretical architecture. That's what ships when you have both layers ready.
The reason this was confusing for two years: most developer content was either "here's MCP" or "here's A2A" in isolation. Nobody was saying clearly that the choice was always both, in sequence. The convergence events of March-April 2026 didn't create a new decision - they answered one that had been sitting open.
Why Governance Matters More Than Most Builders Realize
Here's the part that most technical coverage got wrong: the governance moves are the real signal, not the product announcements.
When Anthropic donated MCP to the Linux Foundation's AAIF in March, the practical effect was this: the "we don't want to depend on Anthropic's roadmap" objection at enterprise organizations disappeared. Every major AI lab now has a seat at the governance table. AWS, Google, Microsoft, and OpenAI are co-governing the same spec. That is the condition under which enterprise infrastructure teams commit to a protocol at scale.
The enterprise adoption blocker for MCP in 2024 and 2025 was not technical. It was governance. Security teams don't greenlight infrastructure where a single vendor controls the roadmap. Legal teams don't approve contracts that depend on a protocol that one company can change unilaterally. Those reviews killed MCP adoption at large organizations even when the engineering teams wanted it and understood the technical case.
The AAIF transfer didn't fix a technical problem. It fixed an organizational one.
The A2A steering committee membership - AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, ServiceNow - is the same play. Look at that list and count how many Fortune 500 companies already have approved vendor relationships with at least three of those names. A2A walks into an enterprise procurement review with pre-cleared governance documentation. That's not an accident.
First MCP Dev Summit North America ran in New York on April 2-3, with 95+ sessions under the AAIF umbrella. The same week Microsoft shipped Agent Framework 1.0. The timing was deliberate. The governance infrastructure was done. The developer tooling followed.
For builders making protocol decisions right now: neutral infrastructure governed by a Linux Foundation entity is something you can put in a security review. Something you can put in an architecture proposal that has to get approved three levels above engineering. Vendor-controlled protocols are a harder conversation. That conversation just got a lot easier on both sides.
Microsoft's 1.0 Tells You the Build Order
Microsoft Agent Framework 1.0 did something most coverage missed: it was honest about the sequencing.
MCP support was complete and live at launch. Available for .NET and Python. MIT-licensed. The framework unified Semantic Kernel and AutoGen into one canonical SDK with a long-term support commitment. That is a production signal, not a preview signal.
A2A support was listed as "coming soon." Not live, not experimental, not available in beta. On the roadmap.
Read that at face value. The team that shipped this has to maintain it. They made MCP live because MCP is production-ready and the tooling is mature. They listed A2A as coming soon because the integration isn't complete yet. That's honest engineering communication.
Here's what that means for your decisions:
Build the MCP layer now. Get your agents connected to the tools they need. Build your tool schemas, wire your services, ship that integration. The A2A layer becomes available as Microsoft's SDK and the broader A2A ecosystem mature - realistically later in 2026.
Your MCP work doesn't become obsolete when A2A arrives. It becomes the tool layer that sits underneath the agent coordination layer. The two layers are additive. You're not choosing between them. You're sequencing them.
MCP is live in production-grade tooling from the most enterprise-credible AI developer on the planet. A2A is on the roadmap. The build order writes itself.
What This Means for Skills-Economy Builders
The MCP + A2A story has been covered almost entirely as a developer infrastructure question: runtime choices, protocol bindings, SDK options. That framing misses a large segment of builders who are actually doing this work and need a concrete answer.
Skills directories, AI tool platforms, BPO technology layers, and agent workflow marketplaces are the MCP layer made concrete. When a builder queries a skills directory to find a tool that can run a semantic search, connect to a CRM, or execute a workflow, that is MCP in practice. The directory is the registry. The skills are the tools. The protocol is the standard by which agents discover and use what's available.
Clelp's directory has 8,000+ skills. A significant portion of those are MCP-compatible tools that an agent can connect to, call, and return results from. When A2A enables an orchestrating agent to delegate a subtask to a specialized agent, that specialized agent's tool access comes through the MCP layer. That's where a skills catalog becomes infrastructure rather than just a browsing experience.
For builders on skills-economy platforms who wired MCP-compatible tools in 2024 and 2025: that work was not premature. The A2A layer doesn't replace what you built. It gives it reach. Orchestrated agents can delegate to specialized agents, and those specialized agents pull from a mature tool catalog via MCP. The foundation you built is the prerequisite, not the bottleneck.
There's also a workforce angle here that nobody is writing about. Contact center AI, BPO automation, and enterprise AI deployments are all agent stacks in practice. They all need the tool layer and eventually the coordination layer. The governance maturity that happened in March is exactly what procurement processes at large organizations need to move forward. The protocols just got safe to bet on for that category of builder, not just for startups.
Where to Go From Here
The sequence is clear. Build the MCP layer first. The A2A layer follows when the production tooling catches up, and your MCP work is the foundation it builds on.
Browse MCP-compatible tools on Clelp to see what's already available for your tool layer: https://clelp.ai/mcp-servers
If you're building agent infrastructure and want to understand where A2A fits your current stack: https://clelp.ai/
These are not parallel decisions. One comes first. Now you know which one.