Protocols in Production

Connectivity standards for AI agents are now all but settled.

The central question in agentic AI is no longer what models can do in isolation but how they connect to external tools and data sources, and to each other. Two open protocols have emerged as the standard answers to those two distinct problems.

MCP, which will be familiar to readers of AI Central, addresses the first by standardizing how an agent reaches tools and data. A second protocol, A2A, addresses the second by standardizing how agents discover and collaborate with each other. Both now sit under the Agentic AI Foundation at the Linux Foundation, and the MCP roadmap published last week offers a clear picture of what remains to be built.

The agentic toolbox

The Model Context Protocol solves a problem familiar to anyone building with AI agents: every new tool, data source, or service requires its own integration, and every model provider implements those integrations differently. MCP provides a standard interface between agents and the external systems they need to reach. An agent that speaks the protocol can discover what a server offers and call the server’s tools through a consistent layer, regardless of whether the agent runs on Claude, ChatGPT, Gemini, or an open-source framework. A single MCP server, once built, works across every major AI client.

The numbers suggest that this premise has landed. MCP crossed 97 million monthly SDK downloads across Python and TypeScript by February 2026, with more than 10,000 published servers covering developer tools, databases, and enterprise platforms. Anthropic, OpenAI, Google, Microsoft, and Amazon have all adopted it. Sixteen months after its initial release in November 2024, MCP is the default wiring for agent-to-tool connectivity.

Intelligent coordination

MCP gives an agent access to tools, but it has nothing to say about what happens when two agents need to work together. As organizations move from single-agent deployments toward systems in which specialized agents divide labor, a second connectivity problem emerges. These agents need to discover each other’s existence, advertise their capabilities, delegate tasks, and report results, all without exposing their internal reasoning or proprietary data. The Agent-to-Agent protocol, or A2A, is the open standard designed to address this layer.

A2A is built on three core concepts. An Agent Card is a JSON document that describes what an agent can do, what input it accepts, and where to reach it. It functions as a machine-readable capability résumé that other agents can retrieve and evaluate. Once an agent has found a peer through its card, interaction proceeds through a task-based model: the client agent creates a task, the remote agent processes it, and status updates flow back as the work progresses. Throughout this exchange, agents share only the context that the receiving agent needs to complete its assignment. Internal state, memory, and tool configurations remain private to each agent.

Google introduced A2A in April 2025, and the protocol quickly gained traction. IBM’s Agent Communication Protocol, which addressed similar problems, merged into A2A by August, consolidating what could have become a fragmented standards landscape into a single effort. Google donated the protocol to the Linux Foundation in June 2025, and version 0.3 shipped the following month with gRPC support and the ability to sign Agent Cards for authentication. More than 150 organizations now support the protocol, with AWS, Cisco, Microsoft, Salesforce, and SAP among the contributors.

The two protocols occupy distinct layers and are designed to work together. A customer-support agent might use MCP to pull a user’s account history from a database, then use A2A to hand the case to a billing agent with the authority to issue a refund. The billing agent, in turn, might use MCP to access a payments API and A2A to report the resolution. MCP provides the connection to tools and data, while A2A provides the connection between the agents that use them.

Standards enshrined

In December 2025, Anthropic, Block, and OpenAI co-founded the Agentic AI Foundation under the Linux Foundation. Google, Microsoft, AWS, Bloomberg, and Cloudflare joined as platinum members. Anthropic contributed MCP; Block contributed goose, its open-source agent framework; OpenAI contributed AGENTS.md, a format for giving coding agents project-specific instructions. Google donated A2A to the Linux Foundation separately in June 2025, six months before the AAIF’s formation, but both protocols now live under the same institutional roof.

This shift in governance is designed to address the adoption risk carried by protocols under the control of a single company. An enterprise that builds its agent infrastructure on a standard owned by one vendor is making a bet on that vendor’s continued commitment. The Linux Foundation, which stewards the Linux kernel, Kubernetes, and PyTorch, provides the kind of neutral governance that lowers this risk. Its involvement signals that the companies competing on AI models have agreed to collaborate on the plumbing beneath them.

Unfinished business

The MCP roadmap published on March 9 is organized around priority areas rather than release dates. Previous roadmaps tracked what would ship in the next spec version, but the current document identifies the problems that matter most and points to the Working Groups responsible for solving them. MCP’s November 2025 spec release was the last version produced by a small core team. The work that follows is distributed across contributor groups, each with its own timeline.

The first priority is transport scalability. MCP originally ran as a local process, communicating over standard input and output. The introduction of Streamable HTTP allowed servers to operate as remote services, which unlocked a wave of production deployments. Running those deployments at scale, however, has exposed a consistent set of problems. Stateful sessions conflict with load balancers, horizontal scaling requires workarounds that the protocol does not standardize, and no registry or crawler can discover what a server offers without establishing a live connection. The proposed solutions target both sides of the problem. The transport and session model would evolve so that servers can scale horizontally without holding state, and a standard metadata format would make server capabilities discoverable without a live connection.

The second and third priorities address internal growing pains. MCP’s Tasks primitive shipped as an experimental feature, and production use has since revealed specific gaps. The protocol lacks both retry semantics for transient failures and expiry policies for completed results. Such problems surface only once a feature is deployed under real conditions, and the roadmap treats them as expected refinements. The roadmap also targets a governance bottleneck. Every Spec Enhancement Proposal currently requires review by the full core-maintainer team, regardless of domain. The roadmap proposes a contributor ladder with a clear path from community participant to maintainer, and a delegation model that would allow trusted Working Groups to approve proposals in their own areas without waiting on a full core review.

Enterprise readiness is the final and intentionally least defined priority of the roadmap. Organizations deploying MCP are finding that the protocol was not originally designed to handle their requirements for audit trails, SSO-integrated authentication, gateway behavior, and portable configurations. The roadmap acknowledges these realities but refrains from prescribing solutions. Instead, it invites the organizations experiencing them to form a dedicated Working Group to solve their shared headaches. Most of the resulting changes are expected to land as extensions rather than core spec modifications, a design choice intended to keep the base protocol lightweight for everyone else.

The breadth of MCP’s adoption across providers, contributors, and production environments has made in-person coordination a natural next step. The first MCP Dev Summit North America takes place April 2–3 in New York, organized under the AAIF banner, with more than 95 sessions scheduled. The session topics track the roadmap’s priorities directly: conformance testing, security research, scalable agent system design, and deployment lessons from production environments.

Locked in for the long haul

The adoption question for agent connectivity protocols is largely settled. MCP handles tools and data, A2A handles agent-to-agent coordination, and both are governed by a foundation designed to outlast any single company’s interest in them. The roadmap’s four priorities describe the distance between a widely adopted protocol and a reliable one, and the engineering effort of the coming year is aimed at closing it.