A few weeks ago I wrote about replacing MCPs with skills and scripts. Someone pushed back in the comments with one exception I couldn’t wave away: agent to agent communication has no CLI. I pointed them at Agent Communication Protocol and moved on, but the question stuck, and I’ve spent some time since looking at A2A properly.
The gap I’d papered over
In the skills post I argued that for most tool connection, a skill file plus a script beats an MCP server. Less context tax, less cost, lighter workflow. I still think that’s true for tools.
But the commenter was right about one thing. My answer for agent coordination was “just use markdown files.” One process writes to a known location, the next one picks it up. I’ve done that. It works. It also falls apart the moment you have more than two agents, or need to know who’s waiting on whom, or want a proper audit trail of what ran when.
When I said “not yet, but we will see in time” in the thread, I was being honest about the limits of my own pattern, not endorsing it as the answer. Markdown handoffs work for a quick hack. They’re not a protocol.
What MCP is for
MCP, the Model Context Protocol, connects a model to its tools and resources. Tools, resources, prompts. That’s the scope. It’s the layer that lets your agent talk to Jira, read a file, or call an API.
It was never designed for agents talking to each other. Stretch it into that role and you lose the things you want when agents coordinate: lifecycle management, discovery, async streaming, the ability to pause mid-task and ask for input. MCP gives you none of that. You’d be rebuilding it yourself on top of a tool connection protocol.
Using MCP for agent to agent communication is reaching for the wrong layer.
What A2A is
ACP, the Agent Communication Protocol, was IBM’s open standard for agent to agent comms. It’s now merged into Google’s Agent2Agent protocol, A2A, under the Linux Foundation. Same concepts and REST API, one standard instead of two competing ones.
What surprised me looking at the samples repo is how concrete it is. Each agent runs as its own standalone server on its own port, framework-agnostic. There are samples for Google ADK, LangGraph, CrewAI, LlamaIndex, Semantic Kernel, Marvin, AG2. The same agent can be called from any client that speaks A2A, regardless of what framework it was built with.
a2aproject/a2a-samplesI’d been thinking about agent coordination as something you orchestrate yourself, either manually or with a separate layer you control. A2A is built for a different shape: an agent you call and trigger automatically, that lives somewhere else, that another system discovers and talks to over a standard interface. It’s a remote procedure call with lifecycle and state, and it streams as the agent works. You’re not leaving a file for another process to pick up.
Where I land now
My markdown handoff pattern is still the right answer for the simple case. Two agents, one hop, you control both ends. Write the file and move on, no protocol needed.
The moment you have multiple agents, or agents you don’t control, or long-running tasks that need to pause and resume, or you want to swap one agent out for another without rewriting the integration, you want a real protocol. A2A looks like the one the industry is settling on.
I haven’t built anything with A2A yet, just read through the docs and poked around the samples repo. That’s more than I’d done when I waved it off in the comment thread, but not enough to tell you how it holds up in production.
The skills-over-MCPs argument still holds for tools. It doesn’t hold for agent to agent. That was the gap, and I missed it in the original post.
The bottom line
There are three layers here and I’d been quietly conflating them. Skills handle the workflow logic, the how and when. MCP is what connects a model to its tools. A2A is the layer for agents talking to other agents. Using MCP for agent communication is reaching for the wrong layer, and so is using a markdown file once the coordination gets real.
I don’t know yet whether A2A is the protocol that wins. But it’s the one I’d be looking at seriously if I were building multi-agent systems today, which, given where the comment thread went, I might be soon.