On April 9, 2025, Google announced Agent2Agent (A2A), an open protocol for letting AI agents from different vendors discover and delegate work to one another. It landed in the middle of a louder, longer wave: weeks earlier, OpenAI publicly committed to Anthropic's Model Context Protocol (MCP), the open standard for connecting models to tools and data. For anyone evaluating AI agents in 2025, two announcements in two weeks told the same story—the agent world is converging on shared standards, and the buyers who understand the emerging stack will avoid expensive lock-in that the buyers who don't will walk straight into. As CTO at Softechinfra, I spend most of my architecture reviews on exactly this question: which parts of an AI system should we build on a standard, and which can we afford to keep proprietary. This piece lays out the interoperability stack as a durable mental model—what each layer is for, how A2A and MCP fit together rather than compete, and a procurement checklist you can still use long after today's protocol versions are history.
Why Standards Suddenly Matter for Agents
Until recently, every AI integration was bespoke. If you wanted your model to read a customer record, call an internal API, or hand a task to another system, an engineer wrote glue code for that one pairing. With N tools and M models, you trended toward N×M custom integrations—each one a maintenance liability and a quiet bet that neither side would ever change.
That math is exactly why the industry standardized other connection layers decades ago. USB replaced a drawer of proprietary cables. HTTP let any browser talk to any server. The internet's economic lesson is consistent: standard interfaces collapse N×M integration cost into N+M, and the value moves up to whoever builds the best thing on top of the standard. Agents are now hitting the same inflection point, which is why a connector standard and an agent-to-agent standard both crystallized in early 2025.
For a buyer, this is not academic. The difference between an AI vendor that speaks an open protocol and one that ships a closed integration is the difference between a component you can swap and a dependency you are married to. We covered the broader risk in our AI vendor lock-in guide; protocols are the most concrete lever you have to keep your options open.
The Interoperability Stack, Layer by Layer
It helps to picture an agent system as four layers. The model reasons; the tool layer connects that reasoning to the outside world; the agent-coordination layer lets multiple agents collaborate; and the orchestration layer is your own application logic stitching it together. Standards are emerging at the two middle layers—and those are the two worth getting right.
| Layer | Job | Emerging standard | What you risk without one |
|---|---|---|---|
| Model | Reasoning and generation | Provider APIs (own abstraction) | Rewrites on every model switch |
| Tool / context | Connect one agent to tools and data | MCP | N×M custom connectors |
| Agent coordination | Let agents delegate to each other | A2A | Single-vendor agent silos |
| Orchestration | Your workflow and business logic | Your own code | (stays proprietary by design) |
The Tool Layer: MCP
MCP standardizes the conversation between one agent and the resources it needs—files, databases, internal APIs, search. Instead of writing a custom adapter for every model-to-tool pairing, you expose a tool once as an MCP server, and any MCP-aware client can use it. Build the connector to your CRM a single time, and it works whether the brain on the other end is one provider's model today and a different one next quarter. We unpacked the protocol itself in our MCP guide; the durable takeaway is that the connector layer is now a commodity you should not be paying to rebuild per vendor.
The Coordination Layer: A2A
A2A solves a different problem. Once you have multiple capable agents—maybe a scheduling agent from one vendor, a billing agent from another, an internal support agent of your own—how do they hand work back and forth? A2A defines how an agent advertises what it can do (a capability card), how another agent discovers and invokes it, and how they exchange tasks and results in a common envelope. It is the difference between agents that live in vendor silos and agents that form an ecosystem.
The clean way to hold the two in your head: an A2A agent can itself be an MCP client. Coordination and tool-access are complementary layers, not rivals. A robust system uses both—A2A so agents can collaborate across boundaries, MCP so each agent can reach its tools without bespoke wiring.
Why This Reduces Lock-In for Buyers
The commercial payoff of standards is optionality, and optionality is worth real money. Three concrete shifts:
Swap without rewrites
When the model layer sits behind your own abstraction and tools speak MCP, changing model provider is a configuration change, not a quarter-long migration.
Mix best-of-breed
A2A lets you combine a specialist agent from one vendor with your own internal agents instead of buying one suite and accepting every weak module in it.
Negotiate from strength
A credible ability to leave is the only leverage that survives contract renewal. Standards make leaving credible, which improves the deal you get even if you never exercise it.
None of this means standards are free. They add an indirection layer, they evolve, and an early protocol version will have rough edges. But the cost of adopting a standard is bounded and one-time; the cost of bespoke lock-in compounds with every integration you add. That asymmetry is the whole argument.
A Procurement Checklist That Outlives the Protocols
Protocol names and versions will keep changing. The questions you should put to any AI agent vendor will not. Run a prospective platform through this before you sign:
- Does it expose its tool connections over an open standard like MCP, or only through a proprietary plugin system you cannot reuse elsewhere?
- Can its agents interoperate with agents you did not buy from the same vendor—does it speak an open coordination protocol such as A2A?
- If you leave, what comes with you—your prompts, your tool definitions, your evaluation data, your conversation logs? Get the export path in writing.
- Is the model choice swappable behind an abstraction, or is your workflow hard-wired to one provider's API shape?
- Who owns the data the agents read and produce, and where is it stored and processed?
- Does the contract let you run a parallel pilot on an alternative before committing, so the swap cost is something you have actually measured?
A "no" on the first four is not automatically disqualifying—sometimes a closed system is the right call for a narrow, short-lived need. But every "no" is a future cost you should price into the decision today, not discover at renewal.
How We Apply This in Practice
On our own builds we treat the model as the most replaceable component in the system, precisely because it changes fastest. On TalkDrill, our in-house English-speaking practice app (see the build), the speech and conversation logic sits behind an internal interface so the underlying model is a swappable dependency rather than a foundation we have poured concrete around. The same discipline runs through our AI automation engagements: tools exposed over a standard connector layer, model access behind a thin abstraction, and orchestration kept in our own code where the real business value lives.
That orchestration layer is the part worth keeping proprietary. Standards commoditize the plumbing—the connectors and the agent handshakes—so your differentiation can move up to the workflow logic, the domain rules, and the evaluation suite that make the system actually good at your job. We build agent and tool-calling systems on this principle for client work; you can see the tool-calling foundations in our agent SDK and tool calling guide.
What to Do This Quarter
You do not need to adopt a protocol this week to benefit from this shift. You need to stop signing away your optionality. Three moves cost almost nothing and pay off for years:
- Inventory your AI dependencies. List every place an agent touches a tool, a data source, or another system. Mark each as standard-based or bespoke. The bespoke ones are your future migration bill.
- Put the model behind an abstraction. If your code calls a provider's API directly in twenty places, that is twenty edits per model change. One adapter turns it into one.
- Add the protocol questions to procurement. Make the checklist above part of every AI vendor evaluation, so interoperability is a decision you make on purpose rather than a constraint you inherit by accident.
The specific protocols announced this spring will mature, get revised, and eventually be taken for granted the way HTTP is. The principle underneath them is the one to internalize: in a fast-moving field, the architectures that win are the ones that assume every component will be replaced, and make replacement cheap. Standards are how you buy that cheapness. Treat A2A and MCP not as products to chase but as evidence that the agent layer is finally becoming something you can build on without betting the company on a single vendor's roadmap.
Building AI Agents Without the Lock-In?
We design agent and automation systems on open, swappable foundations—standard connectors, model-agnostic abstractions, and orchestration you own. Let's architect yours to last.
Talk to Our AI Team →
