Three protocols mostly carry the weight of agentic AI today. Each binds a different pair of things together. None of them is finished. All of them are mature enough that committing to them now is sensible. Picking the wrong one — or pretending they're interchangeable — produces an agent stack that works for one team and is unbuildable for the next.
Function calling — model to tool
The oldest of the three. A model emits a structured tool invocation — a name and a JSON object of arguments — instead of free text, and the runtime executes the tool and returns the result. OpenAI introduced this at scale in 2023; every major model provider supports a variant.
Function calling is in-process and model-specific. The schemas are defined per-deployment. Switching models means re-describing tools in the new model's preferred format. It works extremely well inside one stack. It does not, on its own, solve the problem of many models, many tools in a large organisation, where you have ten models in production and a hundred tools.
The right place for function calling: as the per-call mechanism inside an MCP-mediated tool layer, or as the simple primitive in small, single-team agents that don't need cross-team reuse.
MCP — many models, shared tools
The Model Context Protocol, open-sourced by Anthropic in late 2024 and adopted broadly through 2025–2026, separates the tool from the model. A tool is implemented as an MCP server with a standard description; any compliant model can call any compliant server. The win is composability and reuse — write a CRM tool once, use it from Claude, GPT, Gemini, or your local Llama.
What MCP gives you, in practice: a standard schema for tools (name, description, parameters, return); a transport (HTTP, with streaming where relevant); and a permission/scope model (what the agent can do with this tool). What it doesn't give you: a registry. A discovery protocol. Long-term thinking about identity. Those are still each enterprise's homework — and we cover the registry shape in Chapter 12.
The minimum sensible commitment in 2026: every tool you build for agents is wrapped as an MCP server (or trivially convertible to one). This costs little upfront and pays back the first time you swap a model or onboard a second one.
A2A — agent to agent
The youngest and most speculative of the three. Google's Agent-to-Agent specification (2025) defines how one agent discovers another, learns its capabilities, authenticates against it, and invokes it. The use case: a sales agent that needs a pricing question answered calls the pricing agent, which is owned by a different team, runs on a different stack, and exposes a small, contracted surface.
This is the future of inter-agent work, but the specifications are still maturing and the operational practices around them — discovery, identity, billing, audit — are deeply unfinished. The pragmatic 2026 advice: design your agents as if they will eventually be A2A endpoints (each has a clean capability description, scoped auth, a stable contract), but don't bet your programme on A2A interoperability across organisations until at least 2027.
Inside one organisation, the same job is often done with internal RPC or HTTP, and that's fine. The A2A discipline of capabilities and contracts is more valuable than the wire format.
How the protocols stack
A common shape: an agent built on an orchestrator (LangGraph, say) reasons in the model and emits function calls; the runtime translates those into MCP calls to a curated set of tools; some of those tools are themselves wrappers around other agents, called via A2A. Function calling is the per-step mechanic; MCP is the cross-model tool surface; A2A is the cross-agent surface. Each operates at a different scale.
Where this gets messy is identity. The user's identity, the agent's identity, the tool's identity, and the downstream agent's identity all need to flow through the call chain so that the audit log later answers "who did what, on whose behalf, with whose consent?". OAuth on-behalf-of and step-up authentication patterns are the current best answer. They work. They are also enough plumbing that most projects under-invest and pay for it during their first audit.
What to standardise on now
If you are starting today, three commitments will save you re-work later. Wrap every tool as MCP-compatible. The cost is small; the option value is large. Treat function-calling formats as a per-orchestrator detail. Don't write business logic that depends on the exact JSON your current model emits; abstract it. Design every agent with a clean capability description. Even if it never gets called via A2A, the description is a useful artefact for the registry, for evals, and for the eventual day when another agent does want to call it.
Three commitments. Not glamorous. Not vendor-specific. They will outlast any of the named platforms — and the named platforms will keep being named, in marketing decks, for as long as the music plays.