MCP, A2A, and the Protocol Questions to Put in Your Next AI Contract

Something unusual happened in agent infrastructure over the last eighteen months: the standards question got settled before the market did.

Normally you get five years of competing formats, a consortium war, and a winner that emerges once everyone is exhausted. Instead, the Model Context Protocol became the common way to expose tools and data to agents, A2A became the common way for agents to delegate to each other, both ended up under Linux Foundation governance, and every major model provider adopted them. MCP has been downloaded on the order of a hundred million times and there are well over eighteen thousand community-indexed servers.

For a buyer this is good news that comes with a specific trap, and the trap is what I want to talk about.

What each protocol is for

Keeping this short, because the useful part is the implications.

MCP is the interface between an agent and the things it uses: your database, your document store, your CRM, an internal API. You expose a system once as an MCP server, and any MCP-speaking agent can use it. It is roughly what ODBC was for databases, or what USB was for peripherals: a boring standard whose value is that everything speaks it.

A2A is the interface between agents. When a coordinating agent hands a subtask to a specialist agent, possibly one running in a different system or operated by a different vendor, A2A defines how they discover each other, describe what they can do, and pass work and results back and forth.

The pair covers the two directions an enterprise agent architecture has to move in: down into your systems, and sideways into other agents.

There is a third layer worth being aware of, though it is less settled: the commerce and payment protocols that let agents transact. ACP for checkout, AP2 for payment authorisation with cryptographic proof of consent, and a few competing efforts around them. If your agents will ever spend money, that layer will matter to you, but it is moving faster and I would not write it into a contract yet.

Protocol support is not the same as portability

Here is the trap. A vendor can be fully MCP-compliant and still leave you unable to leave.

The reason is that the protocol standardises the interface, not the assets. Your agent platform accumulates things over a year of use that are more valuable than the code: the tool definitions you refined through twenty iterations of getting them right, the evaluation sets built from real production cases, the traces of every run, the prompts that encode how your business actually makes a decision, the approval policies, the memory or context store the agents draw on.

None of that is covered by the protocol. If those assets live in a vendor's proprietary format, you can swap the model provider trivially and still be completely stuck, because rebuilding your evaluation set from scratch is six months of work and rebuilding institutional knowledge encoded in tool descriptions is worse.

I would put it this way to a procurement team: the protocol protects your plumbing. Your contract has to protect your accumulated judgment.

The four clauses

These are the ones I would push for, in rough order of how much they matter.

Standards conformance, named and versioned. The vendor supports MCP and A2A at a specified version, and commits to supporting current versions within a defined window of their release. Vague commitments to "open standards" are worth very little. Naming the protocol and a version turns it into something you can hold them to.

You own the tool definitions and configurations. Everything you author, tool schemas, prompts, policies, routing rules, is your property and exportable in a documented, non-proprietary format. This one sounds obvious and is frequently absent, and it is the clause that determines whether a migration takes two weeks or two quarters.

Trace and evaluation data export, on demand and in bulk. Full run traces, in a documented schema, available in bulk without a professional services engagement, throughout the contract and for a defined period after termination. Your eval set is your most valuable AI asset and it is made of traces. A vendor who will give you a dashboard but not the underlying records is keeping the thing you need most.

Notice on proprietary extensions. Vendors extend standards. That is often legitimate and sometimes genuinely useful. What you want is disclosure: if a feature depends on a proprietary extension rather than the base protocol, you get told, so you can make a deliberate choice about how much of your architecture rests on it. Undisclosed extension is how organisations discover at renewal that 40% of their configuration does not port.

A fifth, if you have leverage: a defined migration assistance obligation on termination. It is not usually granted in full, but even a limited version changes the tone of a renewal conversation.

What this means for how you build

There is an internal architecture consequence to all of this that is worth more than any contract clause.

Own the tool layer yourself. Expose your systems as MCP servers that you operate, in your infrastructure, under your identity model. Let vendor agents and your own agents consume them as clients.

This inverts the usual dependency. Instead of a vendor holding the connections into your estate, you hold them, and the vendor is one consumer among several. Swapping vendors means pointing a different client at the same servers, which is a week rather than a quarter. It also means your access control lives in one place you control, which is the answer to a whole category of security review questions.

The same logic applies to evaluation. Keep your eval sets in your own repository, in a format you control, and run them against whatever platform you are using. If your evaluation lives inside a vendor's tooling, your ability to compare that vendor to an alternative is controlled by the vendor.

Neither of these is expensive to do at the start. Both are painful to retrofit, which is the usual shape of infrastructure decisions.

The question of how much this actually matters

Let me be fair to the other side of the argument, because I do not think lock-in avoidance should be pursued to the point of paralysis.

There is a real cost to insisting on portability everywhere. You give up features that only exist as extensions. You spend engineering time on abstraction layers that may never be exercised. I have seen teams build elaborate provider-agnostic architectures and then never change providers, having paid the abstraction tax for nothing.

My rule of thumb is to be strict about the assets and relaxed about the runtime. Being locked into a vendor's orchestration runtime is annoying and survivable, because runtimes are replaceable in weeks if your definitions and data are portable. Being locked out of your own traces and evaluation sets is genuinely serious, because those took a year to accumulate and cannot be recreated.

So: fight hard on export rights and ownership of what you author. Do not fight over which framework the vendor uses internally.

Where the standards go next

A quick note on direction, held loosely because this moves.

The tool layer is settled enough to build on. MCP is not going away and the ecosystem around it is large enough to have its own gravity.

The agent-to-agent layer is settled in principle and messier in practice. Discovery, capability description, and trust between agents operated by different organisations are all areas where the specification is ahead of the deployed reality. If your architecture depends on cross-organisational agent delegation today, expect to do integration work that the protocol implies should be automatic.

The commerce layer is genuinely unsettled, with several protocols competing and consolidation likely. If agents buying things is on your roadmap, follow it, but do not build deep dependencies yet.

And the layer that nobody has standardised, which I suspect will matter most, is shared context: how agents from different systems agree on what a customer, an order, or an account actually means. Protocol compliance gets agents talking. It does not get them agreeing, and semantic mismatch between systems is where multi-agent architectures quietly produce wrong answers.

The short version for a procurement conversation

Ask which protocols and which versions. Ask whether any feature you are being shown depends on a proprietary extension. Ask to see a bulk trace export, live, on the call. Ask what format your tool definitions are stored in and whether you can have them.

Then build your tool layer yourself, keep your evaluation data in your own repository, and let the vendors compete for the orchestration on top.

The standards war being over is genuinely good for buyers. It just moved the lock-in somewhere less obvious, and the contract is where you deal with that.

We build MCP tool layers and portable agent architectures for exactly this reason, usually for teams who have already been locked in once. If you want a second opinion on an architecture or a contract before you sign, get in touch.