Everyone is arguing about which model is best. That is the wrong argument.
The model is now a commodity. GPT-4, Claude, Gemini - they are all capable enough for most enterprise use cases. The gap between them is narrowing fast. What is not a commodity is the infrastructure that connects those models to the things they need to act on: your CRM, your knowledge base, your ticketing system, your customer data.
That infrastructure - the plumbing - is where AI programmes succeed or fail. And it is changing rapidly.
APIs: how AI got reach
For the first wave of enterprise AI, the answer was APIs. Everything has an API. Salesforce, ServiceNow, Zendesk, Genesys - all of them publish documented endpoints. Connect your AI model to those endpoints and suddenly it can do things: query customer records, create tickets, update statuses, trigger workflows.
APIs gave AI agency. For the first time, a language model was not just generating text - it was taking actions in real systems. That was transformative. It still is.
But API integration at scale is brutal. Every vendor has a different authentication scheme. Rate limits differ. Error formats differ. Pagination differs. A team deploying AI across a mid-sized enterprise might be managing integrations with thirty or forty different systems. Each one is custom. Each one breaks differently. Each one requires maintenance when the vendor updates their API.
The result is that most enterprise AI deployments spend the majority of their engineering effort not on the AI - on the plumbing.
MCP: the standard that changes everything
Model Context Protocol - MCP - is Anthropic's answer to the integration problem. It is an open standard that defines how AI models should connect to tools and data sources.
The idea is simple. Instead of every AI vendor building bespoke connectors to every enterprise system, you build an MCP server for your system once. Any MCP-compatible AI model can then connect to it using the same protocol. One integration, not thirty.
Think of it like HTTP for the web. Before HTTP, networks communicated using proprietary protocols - every connection was a custom job. HTTP standardised the interface. The web became possible. MCP is attempting the same standardisation for AI-tool connections.
The early uptake has been fast. Salesforce, Google Drive, GitHub, Slack, Postgres - MCP servers already exist for the systems most enterprises depend on. The open-source community is building more every week. Anthropic, OpenAI, and Google have all backed the standard. When your three largest model providers align on infrastructure, that is not a bet - it is the direction.
For enterprise AI buyers, this matters immediately. If your AI vendor's architecture is built on bespoke API integrations, you are accumulating technical debt that MCP-native architectures will not carry. That debt compounds. In three years, migrating off it will be painful.
A2A: the protocol that makes multi-agent systems work
MCP solves the tool connection problem. But the frontier has already moved.
The most capable AI systems being built today are not single models with tool access. They are networks of agents - specialised models working in parallel, handing off tasks to one another, combining their outputs into coherent results. A research agent queries multiple sources. A summarisation agent synthesises the findings. A drafting agent writes the output. A review agent checks it before delivery.
In a contact centre context: a triage agent classifies the enquiry. A knowledge agent retrieves the relevant policy. A resolution agent generates the response. A compliance agent checks it. A CRM agent logs the interaction. This happens in seconds. The customer sees none of it.
The engineering challenge is coordination. How do agents find each other? How does one agent hand off to another without losing context? How do you maintain security boundaries when an agent is acting on behalf of another agent rather than directly on behalf of a human?
This is the problem Google's Agent-to-Agent protocol - A2A - is designed to solve. Where MCP standardises how an agent connects to a tool, A2A standardises how agents connect to each other. It defines how agents advertise their capabilities, how they accept tasks, how they report progress, and how they return results in a form another agent can use.
Without a protocol like A2A, multi-agent systems are hand-wired. Each agent-to-agent connection is a custom integration. The system is brittle. Extending it means rewriting the orchestration logic. Debugging it is a nightmare because you cannot see where in the chain a failure originated.
With A2A, agents become composable. You build a capable compliance agent once. Any orchestration system that speaks A2A can call it. You update the compliance agent without touching the orchestration. The system can grow without the architecture collapsing under its own weight.
What this means if you are buying or building AI now
Three practical implications.
Ask your vendor about their integration architecture
Do not accept "we integrate with everything" as an answer. Ask specifically: are your integrations built on MCP, or are they bespoke connectors? Bespoke connectors are not wrong today - MCP adoption is not universal - but they are a liability. A vendor whose architecture is already moving toward MCP is one you will not have to replace in two years.
Do not over-engineer multi-agent systems yet
A2A is compelling and the direction is clear, but the tooling is still maturing. Most enterprise AI use cases do not yet require multi-agent orchestration. A single well-scoped agent with reliable tool connections delivers more business value - more reliably - than a complex agent network with fragile handoffs. Build toward A2A when the complexity genuinely demands it, not because the architecture looks impressive.
The model will matter less than the connections
In twelve months, every major enterprise platform will have a capable embedded AI model. The differentiation will not be which model you use. It will be what that model is connected to, how reliably those connections work, and how well your agents can compose. That is a data and integration problem, not a model selection problem.
The organisations that win will be the ones that invested in the plumbing - not the ones that spent three years arguing about which model was most impressive in a demo.
The bottom line
APIs gave AI reach. MCP is standardising how that reach is exercised. A2A is making it possible to compose multiple agents into systems that are more capable than any single model.
The infrastructure layer is not a technical concern for someone else to worry about. It is the strategic layer. Get it wrong and you will spend the next three years rebuilding integrations instead of delivering value.
Get it right and your AI programme is architecture that compounds - every new tool connection, every new agent, makes the whole system more capable rather than more fragile.
The models will keep improving. Focus on the plumbing.