MCP, A2A, and the Year Choice Stopped Being Theoretical

For most of the last two years, the Choice pillar of The Context Advantage was the hardest to argue for. Context had visible failures — hallucinations you could screenshot. Control had regulatory pressure — audits you could not skip. Cost had a bill. But Choice was theoretical. 'Stay portable' sounded like advice from someone who had never actually had to ship anything by Friday.

In 2026, Choice stopped being theoretical. Anthropic's Model Context Protocol quietly became the de facto way to describe tools and context to an agent, and every major provider now either supports it or is embarrassed by not supporting it. Google's Agent-to-Agent protocol did the same thing for cross-agent communication. Open-weights models — Llama 4, DeepSeek's latest, Qwen 3, Mistral's newest — reached a point where 'the open one is good enough' stopped being a punchline and started being a purchase decision.

The consequence is simple and enormous. For the first time in the agentic era, the interfaces that used to be vendor-specific are now specs. Which means portability is no longer an aspiration. It is an implementation. And the organizations that build against the specs, not the SDKs, are quietly acquiring the single biggest strategic asset an enterprise can have in a moving market: the freedom to change their mind.

This essay is a slow read of what actually changed, why the open-protocol moment matters more inside a regulated enterprise than inside a lab, and what a platform team should be building this quarter to convert the moment into leverage.

Model Context Protocol is a standard way for an agent to discover, describe, and call tools, and for those tools to describe themselves back. Before MCP, every agent framework had its own tool schema. Migrating from one to another meant rewriting every integration. With MCP, a tool is a tool — described once, called from anywhere. The provider becomes swappable in the same way a database driver became swappable when JDBC arrived.

That analogy is deliberate. Before JDBC, every application was welded to its database vendor. After JDBC, the database became a decision you could revisit. Not free — you still had to know what you were doing — but no longer a marriage. MCP is doing the same thing for the tool surface of agents. A2A does the same thing for agent-to-agent handoffs. The open-weights wave does it for the model itself.

Three protocols. Three swaps. Three degrees of freedom your architecture did not have last year. Chapter 18 of the book — Open Formats — was written before any of this shipped, and the argument holds up better today than it did the day we wrote it: the enterprises that will look brilliant in three years are the ones that expressed their AI stack in open formats, and paid the small ongoing tax of doing so.

Every time an open-weights model gets closer to frontier quality, the industry has the same predictable debate. Is it as good? Not quite. Is it good enough? For which task? Should we self-host? What does that cost? The debate misses the point.

The strategic value of a strong open-weights model is not that you will run it. It is that you could run it. That option, held credibly, changes every conversation you have with every proprietary provider you use. Pricing conversations. SLA conversations. Data-residency conversations. Roadmap conversations. The moment a vendor knows you have a tested, drilled fallback to an open model you could deploy in your own environment, your negotiating position permanently improves.

The teams doing this well are not necessarily self-hosting today. They are keeping the muscle. They have a tested pipeline that can take a workload, ship it to an open-weights model on their own infrastructure, evaluate it against the proprietary baseline, and produce a real cost and quality delta. Not in theory. In production. Once a quarter. That is the discipline Chapter 20 — Fallback and Exit — argues for, and 2026 is the year it stopped being paranoia and started being planning.

The predictable mistake in a protocol moment is to adopt the protocol at the surface and violate it underneath. The team announces 'we're MCP-compliant', ships a thin MCP adapter around a deeply provider-specific stack, and calls it portability. Six months later, when the migration actually has to happen, the adapter turns out to have been a stage set. The real coupling — memory format, evaluation harness, retrieval contracts, prompt style, tool descriptions tuned to one provider's quirks — is still there, and it is still expensive.

This is why Chapter 19 — Portable Interfaces — spends most of its length not on the protocols themselves but on everything around them. A protocol is only as portable as the least portable thing behind it. If your evaluation harness only runs against one provider, you are not portable. If your memory format assumes one runtime's semantics, you are not portable. If your tool descriptions have been quietly tuned to one model's parsing behavior, you are not portable. The protocol is the wrapper. The discipline is the product.

The other predictable mistake is treating Choice as a procurement exercise. Procurement teams love portability in the abstract because it strengthens their negotiating hand. Engineering teams often quietly resent portability because it feels like a tax that slows down real work. Both are partially right, and both miss the actual answer: portability is an engineering discipline, budgeted like reliability, measured like latency, owned by a named person on the platform team. If nobody owns Choice, nobody has Choice.

The reason the current moment matters more than any single protocol is that the three protocols compose. MCP standardizes the interface between an agent and its tools. A2A standardizes the interface between agents. Open weights standardize the interface between your workload and the model that serves it. Stack those three, and the entire agent architecture becomes a graph of swappable components — model, agent, tool, another agent, another model, another tool — connected by contracts instead of SDKs.

This is the architecture Chapter 21 of the book — Multi-Model Routing — was pointing at all along. You do not just get to choose a model. You get to choose different models for different subtasks, different agents for different roles, different tools for different environments, and to reconfigure the graph as the market moves. The plumbing is finally caught up with the ambition.

The organizations that will look prescient are the ones that build the graph now, on top of the protocols, even if the initial graph has only one node per slot. The graph is the strategic asset. Adding a second option to any slot is then an afternoon of work, not a project.

It is worth naming the misunderstanding that follows every Choice conversation. Choice is not anti-vendor. It is not a refusal to buy proprietary models. It is not a moral stance about openness. It is insurance.

You buy insurance not because you dislike your house, but because you cannot predict which part of it will need repair. You architect for Choice not because you dislike your current model provider, but because you cannot predict which provider will have the best model, the best price, the best regulatory posture, or the best uptime in the market you will actually be operating in eighteen months from now. Insurance you never claim on is not wasted. It is the reason you slept.

The premium is small when the protocols exist. That is what makes 2026 different from 2025. The cost of being portable used to be significant custom work. Now it is a discipline of picking the interfaces you use. Any organization that pays the small premium acquires an option worth a lot more than the premium the first time the market moves — and the market will move.

Here is the sequence to actually capitalize on this year, distilled from Part 5 of the book.

First, express every tool your agents use as MCP. Even the internal ones. Especially the internal ones. This does one important thing: it forces you to describe your tools in a way that is not specific to any one agent framework, which almost always surfaces coupling you did not know you had. The tools get better even before you swap anything.

Second, build one production pipeline that can serve a real workload from an open-weights model on your own infrastructure. Not the whole product. One workload. Keep it running. Update it when new open models release. That pipeline is your insurance policy in executable form.

Third, run your evaluation harness across at least two providers. If your evals only work against one provider's API, they are not evals. They are a review of one vendor. Portable evals are the quiet backbone of every Choice-serious platform.

Fourth, name a portability owner on the platform team. One person. Their job is to say no to convenient couplings and yes to boring abstractions. Without this role, Choice is nobody's job, and it is exactly nobody's job that will bite you.

Fifth, revisit your architecture the day A2A goes generally available in your provider of choice, and every time a new open-weights model crosses your quality threshold. Treat those events like security releases — scheduled review, real update, tested change. That is how a moving protocol landscape becomes a durable advantage instead of a treadmill.

Where this lives in the book — direct links:

→ Chapter 4 — The 4 C's Framework: /context-advantage/book/chapter-4

→ Chapter 18 — Open Formats: /context-advantage/book/chapter-18

→ Chapter 19 — Portable Interfaces: /context-advantage/book/chapter-19

→ Chapter 20 — Fallback and Exit: /context-advantage/book/chapter-20

→ Chapter 21 — Multi-Model Routing: /context-advantage/book/chapter-21