The HTTP Moment for AI Agents: How MCP, A2A, and OpenAPI Are Standardizing the Agentic Web
The autonomous AI agent market is projected to reach $35 to $45 billion by 2030, but a messy infrastructure problem is threatening to slow the ride. Every agent framework has its own conventions for connecting to tools, discovering capabilities, and coordinating with other agents. The result is a combinatorial explosion of one-off integrations that no team can afford to maintain. The good news: 2026 is shaping up to be the year that changes. A converging set of open standards and protocols (MCP, A2A, and OpenAPI) is forming a de facto stack for building agents that are genuinely discoverable, composable, and portable across platforms. If you are building agent infrastructure today, these are the standards you need to understand.
The N×M Problem: Why Fragmentation Is Killing Agent Adoption
Before any shared standards existed, connecting an AI model to an external tool meant writing a custom integration for that specific pairing. Scale that to a real-world organization with ten different models and a hundred tools and you have a thousand potential connectors to write, test, and maintain.
Anthropic framed this as the N×M problem, and it is a fair diagnosis. Every connector represents duplicated effort and duplicated risk: when the tool's API changes, every connector that touches it breaks. When a new model comes along, the entire web of integrations needs to be re-examined.
The analogy from networking history is apt. Before TCP/IP consolidated into the dominant protocol for the internet, competing network stacks (DECnet, SNA, AppleTalk) forced every vendor to implement separate adapters for each combination. The web only became the web when the application layer standardized on HTTP. AI agents are at a similar inflection point in 2026, and the industry is actively picking its winners.
The Protocol Landscape: Complementary Standards, Not a Standards War
The most common mistake when evaluating MCP, A2A, and the newer ACP and ANP protocols is treating them as rivals. They are not. They address different layers of the same problem.
Model Context Protocol (MCP) solves vertical integration: the connection between a model and the tools, data sources, and systems it needs to do its job. Anthropic released MCP in late 2024 and donated it to the Agentic AI Foundation (a Linux Foundation project co-founded with Block and OpenAI) in December 2025. That governance move was significant. It signaled that MCP is intended to be community-owned infrastructure, not a competitive moat.
An MCP server exposes resources and tools in a standard format that any compliant client (any agent runtime) can discover and call. Think of it as the USB standard for AI: once a device speaks USB, any host can talk to it.
Agent-to-Agent Protocol (A2A) solves horizontal coordination: how one agent delegates a task to another, transfers context on handoff, and queries what capabilities a peer agent exposes. Google released A2A in 2025 with more than fifty partners, including Salesforce, MongoDB, and ServiceNow. Where MCP is about model-to-tool communication, A2A is about agent-to-agent communication in a multi-agent pipeline.
Agent Communication Protocol (ACP) and Agent Network Protocol (ANP) round out the picture for enterprise multi-agent scenarios and large-scale decentralized coordination, though they have less ecosystem momentum at the moment. The foundational ideas in all of these protocols trace back to FIPA-ACL, the IEEE agent communication standards from the late 1990s and early 2000s, updated now for cloud-native, API-first architectures.
The practical takeaway for builders: design your agents to speak MCP for tool access and A2A for peer coordination. OpenAPI ties everything together as the contract layer.
OpenAPI: The Contract That Makes Agents Readable by Other Agents
If MCP and A2A define the communication channels, OpenAPI defines what agents actually say over those channels. The OpenAPI Specification (OAS) is a language-agnostic, machine-readable format for describing an API's endpoints, inputs, outputs, and authentication requirements. It was already the standard for human-facing API documentation; it turns out to be equally powerful as a machine-facing capability declaration.
Modern agent frameworks (LangChain, LlamaIndex, Microsoft Semantic Kernel, and most MCP server implementations) can parse an OpenAPI document at runtime and auto-generate callable tool definitions from it. No manual wrapping required. One agent's API surface, described in OpenAPI, becomes another agent's toolset automatically.
Here is a minimal example. Suppose you are building a specialist research agent that accepts a query and returns a structured summary:
openapi: "3.1.0"
info:
title: Research Agent API
version: "1.0.0"
paths:
/research:
post:
operationId: runResearch
summary: Execute a research query and return a structured summary
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [query]
properties:
query:
type: string
description: The research question to answer
depth:
type: string
enum: [quick, thorough]
default: thorough
responses:
"200":
description: Research summary
content:
application/json:
schema:
type: object
properties:
summary:
type: string
sources:
type: array
items:
type: string
An orchestrator agent that discovers this spec can immediately understand how to invoke the research agent, what parameters it accepts, and what it will return. No bespoke adapter code, no shared internal library, no coordination overhead. This is what "semantic interoperability" looks like in practice for the tool layer.
Making Agents Discoverable: Registries and Metadata
A protocol tells agents how to talk. A registry tells agents who to talk to.
Agent registries are catalogs where agents publish their capabilities, endpoints, versioning information, and authentication requirements. An orchestrator agent queries the registry by capability rather than by name, receives a list of candidates, pulls the relevant OpenAPI spec, and dispatches the task. No hard-coded routing, no centralized configuration file that someone has to keep updated by hand.
Here is a simplified look at the pattern:
# Orchestrator discovers a capable agent dynamically
def find_and_invoke(registry, capability: str, payload: dict):
# Step 1: query the registry for agents that offer this capability
candidates = registry.find_by_capability(capability)
if not candidates:
raise RuntimeError(f"No agent found for capability: {capability}")
# Step 2: pick the highest-ranked candidate and fetch its spec
agent = candidates[0]
spec = fetch_openapi_spec(agent.spec_url)
# Step 3: auto-generate a client from the spec and invoke
client = OpenAPIClient(spec)
return client.call(agent.endpoint, payload)
This is the pattern that makes agent fleets genuinely composable. A new specialist agent can be registered and immediately become available to every orchestrator in the system, without touching any existing code. Registries can also enforce versioning contracts, surface deprecation warnings, and record usage for observability.
The OpenAI Connector Registry and emerging Agent Specialization Marketplaces are early examples of this infrastructure. Expect the registry pattern to become a first-class architectural primitive over the next 12 to 18 months.
Composability in Practice: Handoffs and Context Transfer
Discovery and invocation are only part of the story. In a real multi-agent pipeline, agents hand tasks off to one another mid-workflow. The hard part is not calling a peer agent; it is passing the right context so that the receiving agent can continue where the previous one left off without losing state.
A2A defines a structured message format for exactly this. A capability query message lets an agent announce what it can do; a handoff message packages the task goal, the accumulated context, and any constraints the receiving agent needs to respect.
{
"a2a_version": "1.0",
"message_type": "task_handoff",
"sender": {
"agent_id": "researcher-agent-42",
"capability": "web_research"
},
"receiver": {
"capability": "long_form_writing"
},
"task": {
"goal": "Write a 1500-word technical blog post on agent interoperability",
"context": {
"research_summary": "...",
"key_sources": ["...", "..."],
"audience": "senior software engineers"
},
"constraints": {
"max_tokens": 2000,
"tone": "authoritative but accessible"
}
}
}
Notice that the receiver is specified by capability, not by agent ID. The orchestrator resolves that to a concrete agent at dispatch time, which means the pipeline stays flexible. You can swap in a better writing agent without rewriting the handoff logic.
This is the building block for event-driven multi-agent orchestration: a model of agent coordination where each agent consumes structured inputs, produces structured outputs, and publishes them to a shared bus or registry that the next agent in the chain can pick up.
NIST and Open Governance: The Institutional Layer
Standards need more than technical consensus; they need governance. Two developments in early 2026 signal that agent interoperability is graduating from vendor initiative to industry infrastructure.
In February 2026, NIST's Center for AI Standards and Innovation launched the AI Agent Standards Initiative, the first federal framework specifically addressing agent interoperability, security, and identity. NIST is not mandating protocols by fiat. Instead, its model is three-pronged: convene industry working groups, support community-driven open-source protocol maintenance, and fund fundamental research on agent authentication and identity infrastructure. The target output is an AI Agent Interoperability Profile, expected in Q4 2026, that codifies baseline protocols (MCP and A2A among them) and security best practices.
The timing matters for enterprise buyers. Federal RFPs are already beginning to reference MCP compliance as a procurement requirement, a mechanism for preventing vendor lock-in at the infrastructure layer. If you are building agents that will touch government or regulated-industry contracts, MCP compliance is quickly moving from optional to expected.
On the governance side, the donation of MCP to the Agentic AI Foundation (Linux Foundation) mirrors the model that made critical internet infrastructure (including the Linux kernel itself) trustworthy enough for enterprise adoption. Open governance means no single vendor can take MCP proprietary, and the spec evolves through community consensus rather than one company's roadmap.
What Builders Should Do Now
The standards are converging but the ecosystem is still early. Five priorities stand out.
Expose OpenAPI specs for every agent endpoint. If a peer agent or orchestrator cannot read your agent's capabilities from a machine-readable spec, you have not built an interoperable agent; you have built a black box. Publish and version that spec as a first-class artifact.
Implement MCP for tool access. If your agent needs to call external tools, databases, or APIs, wrapping those connections in MCP-compliant servers gives you immediate portability across any MCP-compatible runtime. It also makes your tools available to every other agent in your organization without writing new adapters.
Design for handoff from day one. A2A handoff messages force you to think explicitly about what context your agent produces and what context it consumes. Agents built around structured inputs and outputs are far easier to compose into larger pipelines than agents built around conversational prompts and implicit shared state.
Register your agents. Even a lightweight internal registry (a YAML file with agent IDs, capability tags, spec URLs, and endpoint addresses) pays immediate dividends. It makes your fleet inspectable and lets orchestrators discover new agents dynamically rather than requiring a code change every time a new specialist comes online.
Track the NIST Interoperability Profile. The Q4 2026 release will be the clearest signal yet of which protocols and security patterns are becoming industry baseline requirements. Design decisions you make now, particularly around agent identity and authentication, will be much easier to retrofit into compliance if you have followed the emerging consensus from the start.
Conclusion
The agent interoperability problem is not primarily a research problem or an AI capability problem; it is an infrastructure and standards problem, and the industry is solving it right now. MCP, A2A, and OpenAPI form a coherent, complementary stack: MCP connects models to tools, A2A coordinates agents with each other, and OpenAPI provides the machine-readable contract that makes both layers understandable to any participant. NIST's involvement and the open governance of the Agentic AI Foundation are signs that this stack is being built to last.
The builders who instrument their agents for discoverability and composability today will be operating on commodity infrastructure by 2027. The ones who defer the question will find themselves managing a bespoke integration web that looks a lot like the N×M problem they started with.