Google stacks APIs, MCP and A2A for enterprise AI

Google organises its enterprise AI offering into three layers that do not replace each other: APIs to reach the systems already in production, MCP so a model can invoke tools, and A2A so an agent can delegate work to another agent. That is how Techzine Global describes the architecture the company is taking to its corporate customers.

The distinction is not cosmetic. A large part of the market sells the three acronyms as if they were interchangeable and they are not: each one solves a different problem and each one fails in a different way. Anyone building integrations for enterprises notices it in the first week of a project.

Three layers that do not compete

The API layer is the oldest and the least glamorous. It is where the ERP, the CRM, the billing system and the banking core live, and nobody is going to rewrite those so they can talk to a model. Google has spent years working that ground with Apigee and the argument is still the usual one: governance, quotas, authentication and traceability. An agent without that layer underneath has nothing to call.

MCP sits on top. The Model Context Protocol, published by Anthropic at the end of 2024 and adopted today by much of the industry, standardises how a model discovers and uses external tools: an MCP server exposes tools, resources and prompts, and any compatible client consumes them without writing a bespoke connector. The specification lives at modelcontextprotocol.io. Google folding it into its corporate pitch confirms something that was already visible: MCP stopped being one vendor's business.

A2A (Agent2Agent) is the third piece and the youngest. Google introduced it in April 2025 with around fifty partners and later handed it over to the Linux Foundation. It covers a gap MCP does not touch: what happens when the counterpart is not a deterministic tool but another agent, with its own state, its own permissions and its own opacity. That calls for capability discovery, task negotiation and a record of who asked what of whom.

Why it matters for integrators

The practical reading is that asking whether you have to choose between MCP and A2A is the wrong question. In a real integration the three layers coexist: the agent uses MCP to query a CRM through a governed API, and only turns to A2A when it needs another domain, another team or another vendor to execute something it does not control.

It is worth being honest about the maturity of each level. REST APIs have been in production for more than a decade and their security patterns are settled. MCP has a broad ecosystem and a fast moving specification, with authorisation as the part that has changed most in the last year. A2A is still pilot territory: few teams have two agents from different vendors negotiating tasks in production with serious auditing.

For a technical lead the consequence is about order, not technology. Before connecting agents you need the API inventory, per service permissions and logs. A poorly scoped MCP server turns a product problem into a security problem: if it is not designed carefully, it ends up granting read and write access with the identity of the process that runs it and not that of the end user.

What we see on projects

In the integrations we have built, most of the effort still sits below the protocol: normalising data, scoping permissions, deciding which operation is reversible and which one requires human confirmation. The agent layer gets the headlines and the API layer gets the hours.

The three layer approach strikes us as correct and fairly unsurprising, which is exactly what you want from an enterprise architecture. The interesting question is not whether MCP and A2A will coexist, but how many organisations have their API layer tidy enough for the conversation about agents to make any sense.