From resources to functions to graphs to goals. How MCP, A2A, and ACP turn APIs from data pipes into capabilities that agents can discover, coordinate, and act on.
MCP, A2A, and ACP are not simply adding new protocols to the stack. They are reshaping how systems interact. And they demand a different way of thinking by raising a bigger question: what should software be able to ask of other software in the first place?
The paradigms that shaped how we build
Every major API paradigm changed the way architects and developers think about software interaction.
REST said: think in resources. A URL is a noun, an HTTP verb is an action. Stateless, predictable, web-native. It worked.
gRPC said: think in functions. Call a remote method as if it is local. Fast, strongly typed, built for high-throughput microservices.
GraphQL said: think in graphs. Let the client define exactly what it needs. No over-fetching. Flexible by design.
Each paradigm brought a better way to expose capabilities. Each improved how systems talk to each other. But underneath all of them sits one shared assumption:
The caller knows what it wants. And exactly that assumption is starting to break with AI in the loop.
AI changes the contract
Traditional APIs are built around predictability. A client requests a resource, calls a function, or queries a dataset. The interaction is explicit, largely predefined, and works well when flows are stable and the desired outcome is clear from the start.
AI changes that dynamic completely. An AI system does not simply call an endpoint and wait. It interprets context, weighs options, makes decisions, and takes action based on an intended outcome. That requires a different interaction model. One built not just around structure, but around intent.
The question shifts from: Which endpoint should I call? To: Which capability can help me achieve this goal?
That is a fundamentally different contract.
From requests to goals
Each paradigm changed how you think. This one changes what you say. Not “Give me this data.” But “Achieve this outcome.”
The shift looks like this:
REST →Think in resources
gRPC →Think in functions
GraphQL →Think in queries
MCP / A2A / ACP → Think in goals, plans, and intent
Before: “Give me this data.” A precise request. A defined response. The caller owns the logic.
Now: “Achieve this outcome.” The agent interprets, plans, coordinates. The caller declares intent.
That is a completely different contract. Strip it back and the transport layer looks familiar: HTTP, WebSocket, the usual suspects. But what runs over it has changed. The interaction layer on top is fundamentally richer, designed for agents that reason, plan, and coordinate across tools and services.
From interoperability to shared intent
Previous protocols got systems talking the same language. MCP and friends go further, aligning systems around a shared goal rather than a shared syntax.
In an AI-native landscape, systems need more than a valid request and a valid response. They need enough context to understand which capability exists, when to use it, how to use it and what outcome it contributes to.
That is where MCP, A2A and ACP enter the conversation.
1. Model Context Protocol (MCP): making capabilities usable for agents
An AI agent discovers what tools are available and decides how to use them at runtime, without hardcoded integrations. Not a function call but a negotiation: you declare the goal, the agent finds the way.
Just as SDKs make APIs easier for developers to consume. They wrap endpoints in developer-friendly abstractions, combining multiple API calls, and hiding protocol complexity without changing the underlying APIs. MCP plays a similar role for AI agents.
SDKs make APIs usable for developers. MCP makes APIs and capabilities usable for agents.
MCP does not replace good APIs. It exposes existing capabilities in an agent-friendly way: as tools, resources, prompts, descriptions, schemas, and contextual information that help an AI system understand what it can do, when to use it, and how to call it.
In that sense, SDKs translate APIs into developer ergonomics, while MCP translates APIs and system capabilities into agent ergonomics. If you already have a solid API platform, you already have a strong foundation for MCP.
2. Agent-to-Agent (A2A): turning agents into collaborators
One agent delegates to another, specialist agents collaborate, and tasks get decomposed, routed, and reassembled without a central orchestrator holding the map.
While MCP turns systems into usable tools for an agent. A2A turns agents into collaborators for each other.
API exposes system capability. SDK exposes that capability to developers. MCP exposes that capability to agents. A2A exposes agent capability to other agents.
3. ACP and the emerging protocol landscape
MCP and A2A are part of a broader shift toward agentic interaction protocols.
ACP (Agent Communication Protocol, now part of A2A), or similar agent coordination patterns depending on the context, points in the same direction: a world where autonomous systems need to exchange more than requests and responses.
They need to exchange tasks, goals, capabilities, constraints, status and context.
The exact standards may still evolve. The tooling is not fully mature yet. But the mental model is already here.
We are moving from systems that expose endpoints to systems that expose capabilities.
And from capabilities that are manually orchestrated to capabilities that can be discovered, interpreted and coordinated by agents.
That is the real shift.
The mental upgrade: three things architects need to unlearn
This is not just a technical upgrade. It is a mental upgrade. Architects need to rethink some of the assumptions that shaped integration design for the last two decades.
Map every API call upfront
Define the intent. Let agents discover and assemble the path within clear architectural boundaries.
Central controller owns the flow.
Distributed coordination between autonomous agents.
Stateless by default.
Memory, context, and task continuity across sessions.
This is not about adopting a new tool. It is about rethinking what systems are capable of. The architectures you design today will either accommodate agents that act, reason, and collaborate, or they will become a ceiling.
The protocol layer just became strategic
Choosing between REST and GraphQL was a question of data access patterns. Choosing MCP over a traditional API is a question of something deeper: How much autonomy do you give your systems, and how much coordination you are willing to design for?
That makes the protocol layer strategic. Not because every organization needs to jump on every new protocol immediately. But because the interaction model is changing.
Developers who understand this now will have a head start. Not because the tooling is ready. It is not. But because the mental model is the hard part. And the mental model is already here.
MCP, A2A, and ACP do not solve the same problem REST solved. They answer a different question entirely: How do intelligent systems work together toward a shared goal?
That is the question enterprise architects will be asking for the next years.
The digital world is being reshaped by AI, and that makes it difficult to understand the implications it has on security. AI agents interpret intent, reason over context, plan next steps, and execute actions across tools and systems without a predetermined script. That autonomy forces a different security mindset.
