Nobody is multi-protocol yet: what 1,359 agents actually support

Last week we shipped the Protocol Compatibility Score — a 0-to-4 integer we compute for every indexed agent. It counts how many of the four live agent protocol rails the agent verifiably supports: ERC-8004, x402, A2A, and MCP. We mentioned the result briefly in Crawlers vs. wallets. This is the full piece.

As of June 12, 2026 — after correcting a content-validation bug that was counting soft-404 pages as protocol support — the distribution across 1,359 indexed agents is: zero agents support three or more rails. Exactly one supports two. How we detect each rail is in the next section.

The four rails, briefly

Each rail solves a different problem. They don't compete — they compose. But the communities building them barely overlap, which turns out to explain most of the data.

ERC-8004 is on-chain agent identity. An agent registers a token on Base that attests to its name, operator, and capabilities. The registry is public, permanent, and verifiable without trusting any intermediary. We index registrations and apply a confidence gate (≥ 0.75 match quality) to reject name-only collisions. The gate is intentionally strict: a false positive here poisons downstream trust signals.

x402 is machine-payable HTTP. An agent publishes a /.well-known/x402 manifest that declares its prices and accepted payment methods. Another agent can discover this endpoint, read the price, pay in USDC over Base, and receive the service — no human in the loop, no account creation. We detect it with a HEAD request validated against expected JSON shape.

A2A (Agent-to-Agent) is Google's task-delegation protocol. An agent card at /.well-known/agent-card.json describes the agent's capabilities, input/output formats, and how to task it. An orchestrator agent reads the card and decides whether to delegate a subtask. We detect the card and validate it contains a name field.

MCP (Model Context Protocol) is Anthropic's tool-exposure standard. An MCP server publishes structured tool definitions that LLM orchestrators like Claude, Cursor, and others consume directly. We detect MCP via a manifest at /.well-known/mcp.json, via a primary category of mcp_server in our index, or via a verified payment-rails entry.

What the scanner found

Individual rail coverage is non-zero. Agents with x402 endpoints exist — we track over 46,000 Bazaar resources and several hundred have real paid calls in the last 30 days. Agents with MCP manifests exist — we index 15 MCP servers and the number grows weekly. Agents with A2A cards exist — including AgentCrush itself (we built ours as part of B4). A handful of agents have ERC-8004 registrations with confidence above the threshold.

What the data shows is that these populations barely overlap. An agent that has x402 almost certainly doesn't have an A2A card. An agent with an MCP manifest almost certainly doesn't have ERC-8004 registration. When you ask “which agents support at least two of these?” the answer is: one. When you ask “which support three or four?” the answer is: none.

The PCS-2 agent — the lone outlier — supports both MCP and x402: a tool-exposure endpoint and a payment manifest, on the same domain. That combination makes intuitive sense. An MCP server that also accepts direct payment is a natural product. What's missing is the identity layer (ERC-8004) and the delegation protocol (A2A) that would let other agents discover and verify it without a human referral.

Why nobody stacks protocols

The simplest explanation: each protocol comes from a different room, and the rooms have barely met.

MCP was built by the LLM orchestration community — developers building Claude apps, Cursor plugins, agent frameworks. Their mental model is “how do I expose tools to a model?” Payment rails and on-chain identity weren't in scope.

x402 was built by the Coinbase/crypto-adjacent community — developers who think natively about USDC, Base, and micropayments. Their mental model is “how do I monetize a machine-callable endpoint?” Tool exposure to orchestrators wasn't in scope.

A2A was built by Google's multi-agent orchestration team. Their mental model is “how do enterprise orchestrators delegate tasks to specialized agents?” Payments and on-chain identity weren't in scope.

ERC-8004 was built by the onchain-agent community — teams building tokenized agents with verifiable on-chain provenance. Their mental model is “how does an agent prove who it is?” Tool exposure and payment rails weren't in scope.

This isn't a criticism. Narrow scope is how you ship protocols. But it means the agent that would score PCS-4 — discoverable via A2A, payable via x402, verifiable via ERC-8004, and usable via MCP — would have to understand all four communities simultaneously. Nobody has built that agent yet.

What changes this

The economic logic is clear. An agent that can be discovered (A2A or MCP), paid (x402), and verified (ERC-8004) captures more value than one that requires a human intermediary at each step. The multi-protocol agent isn't a theoretical construct — it's the natural end state for any agent serious about direct agent-to-agent commerce.

What it takes is a team that reads across the communities. An MCP server developer who notices that their tool would monetize better with x402 added. An x402 payment endpoint operator who realizes that an A2A card would make them discoverable to orchestrators without manual integration. A chain-native agent team that adds an MCP manifest and suddenly gets discovered by every Claude and Cursor session.

The first team that ships all four will be the most cited example in every interoperability post for the next two years. We're watching for it.

Why we publish zeros

A data product that can't show zero can't be trusted at any other value.

The first version of this metric had 104 agents at PCS ≥ 3. That number was wrong — a content-validation bug was treating soft-404 pages (sites that return a friendly HTML error for any path, including protocol manifests) as positive detections. We caught it by sampling, fixed the scanner, and the real number dropped to one. That correction is as important as the finding itself. If we didn't publish the corrected zero, we'd have spent months tracking the wrong metric.

The interoperability counter reads zero today. It will move — and when it does, you'll know the movement is real, because you watched us publish the floor.

The numbers update daily as we re-scan the index.