Model Context Protocol (MCP) is all through my LinkedIn feed these days. Many SaaS vendors with public APIs are providing a MCP interface to their services as well, allowing AI systems to more easily interface with them. MCP standardizes both authentication (OAuth based) and the format of remote procedure calls (JSON RPC based). But how do then Agent Context Protocol (ACP, led by IBM) and Agent to Agent (A2A, led by Google) fit in as well?

Agents and Tools

First a bit of terminology that I like (not universally agreed upon). 

• Local Agents: There are a number of agentic frameworks out there that allow problems to be decomposed into smaller agents. But they all run in the same code base as a single program. I call agents in these frameworks “local agents”.

• Local Tools: Local agents can call “local tools”, code that is in the local code base. Tools generally don’t have intelligence – they carry out specific requests, like looking up customer data from a customer database.
• Remote Tools: MCP allows tools to be called remotely (over HTTPS), in a standard way. MCP provides standardization around how to talk to the remote service.

Does this use of local and remote sound a bit like breaking up a large code base into microservices? Yup! And for large organizations, this decoupling is just as useful for agent-based applications as more traditional applications. That is, creating remote tools is useful for horizontal scaling, incremental deployments, and allowing teams working on different parts of the code base to release code independently.

So in my mind, MCP is useful for two use cases:

• It allows agents to talk to tools created by third parties
• It also allows large internal agent based applications to be decomposed, like using microservices on traditional projects

ACP vs A2A

So what about ACP and A2A? Rather than connecting agents to remote tools, these protocols are for agents to make requests of remote agents as part of a distributed agent architecture. These are agents running in different codebases, often built with a different technology stack. So how do ACP and A2A differ?

The goal of ACP is to extend MCP to agent collaboration. As such, it uses the same OAuth for authentication and JSON RPC for making requests. That has the attraction of consistency in projects.

A2A takes a different approach. When you use a ChatGP, Gemini, etc client, you submit requests as text with other attached media. A useful analogy is an email with attachments and MIME encoding. Internally these are encoded using “Parts”. ACP continues to use JSON RCP for interactions between agents (functions with methods with and return values of various types). A2A on the other hand uses the Parts approach. 

One benefit of the A2A separation is it avoids tight coupling: instead of strict APIs, agents send requests as text with attachments. The destination is responsible for interpreting the request. Responses are similar – they can contain multiple attachments, such as images and files.

Agentic Enterprise AI Apps

Which is better? I suspect it will depend on the type of application. In my personal experience I think about breaking large problems into smaller problems. I have a clear idea of the role each agent will play. As such, the ACP approach (or even using MCP where a remote tool might be constructed with agents on the inside) makes sense to me. I like to be clear about the data to flow between the agents. A2A seems like it may be more useful in more dynamic environments, where you do not know in advance what requests are likely to be made. 

For example, a RAG flow might be:

• Agent 1 looks at the user’s request and augments it, adding additional detail.
• The text is then used to search a knowledge base.
• Agent 2 then summarizes knowledge from the trusted knowledge base to answer the user’s query.
• Agent 3 checks the answer quality before returning to the user, forcing a retry of the previous steps if the response is not to its liking.

For this case, for each step I know what each step should be, what the inputs it should have, what the outputs should be. Each agent has a specific role to play. Because the flow is well understood and stable, ACP might be a better choice.

But consider another example. Consider a chat interface available for a CEO to use. The organization has a number of agents, each growing in ability over time as teams deploy new versions. The CEO has ad hoc questions they want answers to. The CEO frequently makes novel requests never seen before. In this case, a planning agent may look around at what agents are available, then pass off requests to the various agents. Maybe each agent is asked to write a section of a report (budget analysis, customer feedback analysis, whether different internal projects are on track or not, etc). The goal is not to execute the same code path over and over again. Rather, the power of the system is the ability to respond to novel and unique requests. It feels like A2A may be more suitable to these sorts of problems.

Too Many Standards?

To wrap up, is it a problem having multiple standards? To me, no. Neither protocol is that complicated to implement. The field is new enough that people are still discovering how all these different parts fit together. In my eyes:

• The recent AI rush started with LLMs – one of the low level “programming” units. 
• Agent frameworks were the next step – adding programming language-like “functions” so big problems can be decomposed into smaller ones. But it’s within a single local code base.
• Now MCP, ACP, and A2A are moving agents to the equivalent of microservices – allowing distribution of applications across servers.

But it would be wrong to end there. These remote protocols are more than just repeating history for agent architectures. They are making remote services, provided by SaaS services, much more easily accessible to users. Integration was possible before using published APIs, but with standardization of protocols it becomes feasible for users in a chat session to explain what they want, the LLM to propose multiple services available, and to start integrating with them – all without the user having to have a single line of code written. That is going to open up all sorts of interesting possibilities.

UPDATE: I came across this blog post on LinkedIn after posting the above, which talks about “AI workflows” vs “AI agents” which might be part of the ACP vs A2A discussion: https://www.linkedin.com/posts/akantjas_automation-ai-workflow-or-ai-agent-to-activity-7318265649863045120-TKTL