What I like about this piece is that it pushes back on the lazy habit of throwing every agent protocol into one bucket. That confusion is real. A lot of people talk about MCP, A2A, and ACP as if they’re competing answer choices for the same problem, when the article’s core point is closer to: they sit at different layers of the stack. That framing feels right to me.
The part that lands hardest is the separation between “give a model a tool” and “hand a job to another agent.” Those are different failure modes, different security stories, and different operational burdens. If you model a database query or a file read as an agent, you’re buying yourself ceremony for no good reason. I think the article is on solid ground there. In practice, plenty of teams are already over-agentifying simple integration points because “agent” sounds modern. It often just makes things harder to reason about.
MCP, as described here, reads like the boring but necessary layer: capability access, structured context, tool calls, lifecycle plumbing. That’s not exciting, but it’s exactly where a lot of production systems need discipline. I also appreciate the warning against using synchronous tool calls for jobs that are clearly long-running or need approval. That’s the kind of thing people only learn after they’ve got stuck requests, weird retries, and a pile of ambiguous state.
The ACP section is where I’m a little more cautious. The article treats it as historical context and says it merged with A2A under the Linux Foundation, with development winding down. I’m taking that at face value because that’s what the source says, but I’d want to verify the migration story before treating it as settled infrastructure advice. Protocol landscapes have a way of looking cleaner in writeups than they do in actual vendor support matrices.
What I’d actually try, if I were building something with Claude or another host agent, is the split the article hints at: MCP for tools and data, A2A only when another agent truly owns part of the work. That keeps the contract honest. It also forces you to answer the unpleasant questions early: who is authorized, who retries, what gets traced, what is idempotent, and where human approval interrupts the flow. The article is strongest when it stops talking about protocol labels and starts talking about those operational edges.
I do think one thing is missing: how often teams will misclassify something as delegation when they really just need a service endpoint with a nicer schema. That might be the most common trap here. A “remote agent” can be a smart abstraction, but it can also become a vague excuse for not designing a normal API.
Reference: MCP vs A2A vs ACP: How AI Agents Talk to Each Other
