Provider-Agnostic Agents After MCP and A2A

On August 20, 2026, Google's A2A protocol joined the Linux Foundation's Agentic AI Foundation, which means the two protocols that matter most for agent plumbing now sit under the same neutral governance. MCP standardizes how an agent reaches tools and data. A2A standardizes how agents coordinate with each other. Both are now vendor-neutral.

That makes your integration layer genuinely portable. It does not make your agent portable, and the difference between those two sentences is most of the work.

What changed when A2A joined the Agentic AI Foundation?

The Agentic AI Foundation launched on December 9, 2025, anchored by three donated projects: Anthropic's Model Context Protocol, Block's goose, and OpenAI's AGENTS.md. Its platinum members are AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Membership has gone from roughly fifty at launch to more than 250.

A2A joining puts the last major piece of agent plumbing in the same house. The two protocols do different jobs, and the distinction is worth holding onto because vendors blur it constantly.

MCP is vertical. It is how one agent reaches a tool, a database, or a document store. You write an MCP server once for your CRM, and any MCP-speaking agent can use it.

A2A is horizontal. It is how one agent hands work to another agent, including agents that belong to a different company. That matters when your procurement agent needs to talk to a supplier's agent and neither side is going to hand over an API key.

What a business owner should take from the governance change is narrow but real: the odds that either protocol becomes a proprietary lever have dropped a lot. Neutral foundations are slow, and slow is the point. You can build on both without betting on a single vendor's roadmap.

What does provider-agnostic actually mean?

Three very different things get called provider-agnostic, and conflating them is how teams end up surprised.

Swapping the model means pointing at a different endpoint. That is genuinely a config change, and it is the version everyone imagines when they say provider-agnostic.

Swapping the behavior means everything downstream of that config change still working. It does not, usually. Models fail differently. One over-refuses on the edge cases in your domain, one is chattier in a way that breaks your parser, one holds up better across a long multi-step chain and worse on a single dense extraction.

Swapping the runtime means moving the whole harness: retries, timeouts, approval gates, observability, cost controls. This is the most work and gets discussed the least.

For the record on where we sit: we build across Anthropic Claude, Google Vertex AI Gemini, and OpenAI GPT, and we pick per project. That is a constraint decision, not a loyalty one, and we have written before about why lock-in is real and where it hides. This post is about the part that changed in August, which is which layers are now cheap enough to standardize on.

What still locks you in after the standards?

Four things, none of which a protocol touches.

Prompts and context engineering tuned to one model's failure modes. This is the expensive one. A production prompt is not a paragraph, it is an accumulated set of corrections for the specific ways one model gets your task wrong. Move providers and those corrections are now noise, and the new model's failure modes are undiscovered.

Evals written against one model's output shape. Your regression suite is the only instrument that tells you whether a swap was safe. If it was written around how one model phrases things rather than what a correct answer contains, it will pass a broken swap and fail a good one.

The harness. Retries, backoff, tool-call validation, human approval gates, tracing, per-task cost caps. Portable in principle. Rewritten in practice, because each provider's streaming semantics, tool-call format, and error taxonomy differ in small ways that add up.

Data readiness underneath all of it. If the records the agent reads are duplicated, stale, or scattered across four systems, no provider choice rescues that. This is where most agent projects actually stall, and it is provider-independent in the least comforting way.

Which layers are worth abstracting, and which are not?

Not everything deserves an abstraction. Every abstraction you add is a thing that can break, and speculative abstraction built before a second provider exists in production is usually just extra surface area.

Here is how we score the layers today, after the August governance change.

The pattern: standardize where a standard exists and where the work is write-once. Own the eval harness and the orchestration outright, because those are the things that let you leave later. Do not build a universal model wrapper on speculation.

The eval point deserves emphasis. Owning your evals is what converts a provider switch from a leap of faith into a measurable decision. It is the single highest-leverage thing a team can build before it needs it, and it is the piece most often skipped because it produces no demo. That principle sits at the center of our agent orchestration methodology.

Why does the spending data argue for optionality, not neutrality?

Because no lab is running away with it, so architecting around one is a bet you do not need to take.

Ramp tracks spending across more than 70,000 U.S. businesses. In July 2026, 43.5 percent paid for Anthropic subscriptions or tokens against 39.7 percent for OpenAI, with OpenAI growing faster so far in the third quarter. That is a close, moving market, not a settled one.

The wrong conclusion is that you should therefore stay neutral on everything. Full neutrality means building twice, testing twice, and tuning nothing well. It is a real cost paid continuously against a risk that may never materialize.

The better position is optionality: one provider per workload, chosen for a stated constraint, with the exit written down. Written down means a specific paragraph in your architecture notes saying what would trigger a move, which components would change, and roughly what it would cost. A team that can answer those three questions is not locked in, even while running entirely on one lab.

How do we pick a provider for a build?

The decisive constraint is rarely benchmark quality. Benchmarks cluster. Constraints do not.

Usually it comes down to compliance posture, latency at your actual payload size, cost per task at your real volume, or a capability only one lab ships today.

A concrete case from our own work: Smile PreVue generates photorealistic dental simulations from patient photos, which makes it a HIPAA-covered workload. The deciding factor was not image quality. It was the BAA and the healthcare compliance posture, and that is why the simulation runs on Google Vertex AI. A different lab might have produced comparable images. It would not have produced a signable agreement covering protected health information on the terms that project needed.

The questions we run, in order:

1. Is there a hard compliance or data-residency requirement? If yes, that usually decides it and the rest is confirmation.
2. What is the cost per task at realistic volume, not per token on a pricing page?
3. Does latency at our actual input size clear the product's threshold?
4. Does any lab ship a capability here the others do not?
5. If we had to move in six months, what specifically would we rewrite?

Question five is the one teams skip, and it is the one that keeps the answer honest. If nobody can answer it, the decision has not been made yet, it has been deferred.

Worth saying plainly: we make this call on products we operate ourselves and then live with the consequences, including the migrations. Firms like AE Studio work at a larger and more enterprise-facing scale than we do. Our edge is narrower and more specific, which is that we are on the hook for the choice after the recommendation.

Where to start

If you are building agents right now, the highest-value move after August is not a rearchitecture. It is putting your tool access behind MCP, owning your eval harness, and writing down the exit for whichever model you are running. That combination gets you most of the portability with none of the speculative abstraction.

If you want to work through that on a specific system, book a 60-minute consultation for $250, or tell us what you are building and we will tell you whether it is a build problem or a data problem.