The standardisation problem nobody saw coming
For most of 2023, the conventional wisdom about large language models was that they were impressive but bounded: they could read, summarise, draft and reason, but they could not act. By the end of 2024, that boundary had collapsed. Models could call tools, retrieve documents, edit files, control browsers, write and run code — and, increasingly, coordinate with other models. The agentic era had begun.
The agentic era did not, however, arrive with a manual. Each frontier vendor shipped its own approach to tool-use: OpenAI had function calling, Anthropic had tool use, Google had its own variant. Inside the open-source ecosystem, every framework — LangChain, LlamaIndex, CrewAI, AutoGen — invented its own conventions. The result was predictable: a Cambrian explosion of incompatible interfaces. An MCP-style joke circulated in late 2024: "we have n models talking to m tools, so naturally we needed n × m integrations."
Standardisation was overdue. By mid-2025, four distinct protocols had emerged to address the problem, each shaped by a different actor and a different philosophy. This article walks through them — what they are, what they solve, where they overlap, and how a sovereign platform like Gen4Travel picks among them in practice.
Two questions matter when you compare agentic protocols. One: what are the parties? (a model and a tool, or two agents). Two: who controls the trust relationship? (the host, the platform, or a third-party broker). The four protocols below answer those questions differently.
MCP — Model Context Protocol
The Model Context Protocol was introduced by Anthropic in November 2024 and rapidly became the de-facto standard for one specific problem: how should an LLM-powered host expose tools and data sources to its model in a uniform way?
The mental model is simple. Picture every external resource a model might need — a file system, a Postgres database, a GitHub repo, a JIRA tracker, your CRM — as a "server". An MCP-aware host (Claude Desktop, Cursor, an agent runtime) connects to one or more of these servers using a single protocol. The host learns what each server offers (capability discovery), composes those capabilities into prompts and tool calls, and routes the model's decisions back to the right server.
The genius of MCP is what it deliberately leaves out. It does not specify how agents talk to each other. It does not specify identity, billing, or trust between organisations. It restricts itself to the host↔server problem and solves it cleanly. The result: by mid-2025, hundreds of MCP servers existed for common systems — Slack, Notion, Sentry, Linear, Cloudflare, AWS, Filesystem, Git, SQL, Jupyter — and a developer could plug them into any MCP-aware host with no glue code.
What MCP looks like in practice
An MCP server exposes three things: tools (functions the model can call), resources (data the model can read, like a document or a table), and prompts (templated workflows the host can offer to the user). The wire format is JSON-RPC over either standard input/output (for local processes) or HTTP+SSE (for remote services). Everything is typed via JSON Schema, so the host always knows what it is dealing with.
Inside Gen4Travel, every consortium member exposes its bookable inventory and operational data via an MCP server. Accor's server exposes list_hotels, check_availability, book_room; SNCF exposes search_trains, rebook_journey, request_prm_assistance; ADP exposes get_terminal_status, request_mobility_assist. The orchestrator does not need to know whether those servers are written in Python, Go, or Java — only the protocol matters.
ACP — Agent Communication Protocol
If MCP solves the vertical problem (model-to-tool), the Agent Communication Protocol solves the horizontal one: how do autonomous agents talk to each other? ACP was developed by IBM Research as part of the BeeAI project and proposed as an open standard in 2025.
The motivating insight is that an agent is not just a function call. An agent is a process — it has a lifecycle (started, running, paused, completed), a memory, capabilities it advertises, and behaviour that emerges over time. Treating an agent as a tool would lose all of that. ACP therefore defines a richer protocol: agents register their capabilities, exchange typed messages with each other, maintain conversation state across many turns, and emit standardised audit events that downstream systems can replay.
Three properties matter
First, framework-agnosticism. An ACP-compliant agent built on LangGraph can talk to an ACP-compliant agent built on AutoGen with no glue code. This is the multi-vendor interoperability that an open agentic ecosystem needs.
Second, observability and replayability. Every ACP message carries metadata — who sent it, when, with what evidence, against which capability — and the orchestrator can be configured to log everything. When something goes wrong in production (and in agentic systems, things go wrong subtly), this log is the only artifact that lets you reconstruct what happened.
Third, graceful failure semantics. ACP standardises how agents express partial results, ask for help, and fail safely. When Gen4Travel's disruption agent realises it cannot find a viable rebooking, it does not silently produce a degraded result; it emits a structured ACP message back to the orchestrator that says "I tried these options, none worked, here is the best partial recommendation, escalate to human" — and the orchestrator routes accordingly.
A2A — Agent-to-Agent (Google)
Announced by Google in early 2025, A2A targets the same horizontal layer as ACP, but with stronger enterprise framing. Where ACP feels designed by researchers (clean semantics, REST-based, replayable), A2A feels designed by platform engineers solving cross-organisational federation: identity, authorisation, capability cards, discovery.
Think of A2A as the answer to: "agent A from company X needs to invoke agent B from company Y; how do they discover each other, how do they prove who they are, how does the user's consent flow across both organisations?" Capability cards (signed, distributable JSON documents describing what an agent can do and on which terms) are the protocol's distinguishing feature. They are designed to be indexable so a discovery service can route requests to the right agent without prior coordination.
The relationship between ACP and A2A is genuinely interesting. They cover overlapping ground; both communities have signalled willingness to converge on shared message envelopes. The practical question for builders today is not which one will win, but how to structure code so a future bridge between them stays cheap to add.
UCP and the long tail
Beyond the three above, several smaller initiatives have emerged. The Universal Context Protocol (UCP) tries to extend MCP's vocabulary to richer multi-modal context (images, audio, structured records) and to longer-lived sessions. The Open Agentic Schema Framework, championed by a coalition of European research labs, focuses on capability schemas (rather than wire formats), so any protocol can use them. Vendor-specific RPC schemes — Anthropic's tool use, OpenAI's function calling, Google's Gemini calls — continue to coexist with the open protocols and remain in production at scale.
The signal here is healthy: the design space is still being explored, and serious agent platforms must be designed for protocol churn. Picking a protocol today is not picking forever. Picking an architecture that can absorb protocol changes without rewriting business logic is.
| Protocol | Maintainer | Scope | Style | Maturity (2026) |
|---|---|---|---|---|
| MCP | Anthropic + open ecosystem | Host ↔ context server (tools, resources, prompts) | JSON-RPC over stdio or HTTP+SSE | Production — hundreds of servers |
| ACP | IBM Research / BeeAI | Inter-agent messaging, lifecycle, audit | REST, typed messages, replayable | Early adoption · stable spec |
| A2A | Google + coalition | Cross-organisational federation, identity | Capability cards + signed envelopes | Pilot deployments |
| UCP | Open ecosystem | Extends MCP for multimodal + sessions | JSON-RPC superset | Experimental |
What Gen4Travel chose, and why
Gen4Travel's architecture is deliberately layered to avoid betting on a single protocol. MCP is used for context exposure: every consortium member exposes its bookable inventory, schedules, entitlement data and operational signals through an MCP server. The orchestrator and its specialised agents consume those servers through a single transport, with capabilities discovered at runtime.
Above that, ACP is used for inter-agent coordination. The orchestrator is itself an ACP-compliant agent that dispatches sub-tasks — disruption analysis, accessibility planning, payment authorisation — to specialised ACP agents. Each sub-agent emits typed audit messages that the orchestrator persists; when a regulator asks "why did the system rebook this passenger on this flight?", the answer is two database queries away.
On top of both, the EONA-X data space provides the trust framework, consent ledger and Gaia-X-compliant data-sharing fabric that turns the protocols into a production-safe whole. Protocols define how messages are exchanged; data spaces define under what social contract they can be exchanged at all. A sovereign European agentic platform needs both layers.
Three pitfalls to avoid
If you are designing an agentic platform on top of these protocols, three pitfalls recur.
1. Treating protocols as products
A protocol is a contract, not a piece of software. The fact that an MCP SDK exists in your favourite language does not mean you should depend on it directly throughout your codebase. Wrap it. Define your own internal abstraction (we call it the capability layer in Gen4Travel) so that swapping MCP for a future successor is a port of one module, not a cross-cutting refactor.
2. Confusing transport with semantics
JSON-RPC, REST, gRPC — these are transport choices. They are interesting and important, but they are not the protocol. The protocol is the set of messages exchanged and their meaning. A team that obsesses over wire formats while leaving capability semantics fuzzy will end up with a system that is interoperable on paper and fragile in production.
3. Forgetting that agents are processes
An MCP tool call returns and ends. An ACP agent task can run for minutes, ask for help, request additional consent, partially fail, and resume after a human approval. If you implement your orchestration as a chain of synchronous calls, you have a chatbot, not an agent. Plan for long-lived, resumable tasks from day one — it is much harder to add later.
What to watch in 2026
Three developments will shape the protocol layer over the next twelve months. First, the convergence — or formal divergence — between ACP and A2A. The two communities have published positive signals; whether that translates into shared message envelopes will be the most consequential standardisation question of the year. Second, the maturity curve of MCP server ecosystems. We expect the count of production-grade MCP servers to multiply, and the quality bar to rise sharply, particularly around authorisation, rate-limiting and observability. Third, the entry of European institutions. Gaia-X-aligned bodies and ENISA have signalled interest in publishing a "European agentic interoperability profile" — essentially a sovereignty-aware overlay on the existing protocols. Gen4Travel is positioned to be one of its early test-beds.
Protocols are not the answer. They are the plumbing that makes the answer possible. The answer — a sovereign, multi-vendor, accountable agentic platform — also requires data spaces, identity infrastructure, regulatory alignment, and consortium-level governance. Gen4Travel was designed from day one to demonstrate, in production, that this whole stack composes.