AI agents in 2026 do not operate in isolation. They use tools, talk to other agents, pay for services, and maintain persistent identities. Each of these capabilities is enabled by a different protocol. Understanding these protocols — and how they fit together — is essential for anyone building production agent systems.
This guide covers the four protocols that define the agent infrastructure layer: MCP for tool access, A2A for agent communication, x402 for payments, and ERC-8004 for on-chain identity. We will explain what each does, how they work, how they relate to each other, and how to choose the right ones for your architecture.
Just as the internet has layers (TCP/IP, HTTP, TLS), the agent ecosystem has layers. Each protocol addresses a different concern:
┌─────────────────────────────────────────────────────┐ │ APPLICATION LAYER │ │ Your agent logic, prompts, and business rules │ ├─────────────────────────────────────────────────────┤ │ IDENTITY LAYER │ │ ERC-8004: On-chain agent identity & registry │ ├─────────────────────────────────────────────────────┤ │ PAYMENT LAYER │ │ x402: HTTP-native agent payments │ ├─────────────────────────────────────────────────────┤ │ COMMUNICATION LAYER │ │ A2A: Agent-to-agent messaging & task delegation │ ├─────────────────────────────────────────────────────┤ │ TOOL LAYER │ │ MCP: Model-to-tool connection & invocation │ ├─────────────────────────────────────────────────────┤ │ TRANSPORT LAYER │ │ HTTP, SSE, WebSocket, JSON-RPC │ └─────────────────────────────────────────────────────┘
Each layer builds on the one below. MCP provides tool access. A2A uses tool access to enable agent communication. x402 enables agents to pay for tools and services. ERC-8004 provides the identity that payment and communication systems rely on.
You do not need every layer. Most teams start at the bottom (MCP) and add layers as their agent systems grow in complexity. Let us examine each protocol in detail.
MCP (Model Context Protocol) is an open standard created by Anthropic for connecting AI models to external tools and data sources. It defines a JSON-RPC based protocol where a client (the AI model) connects to a server (the tool provider) and discovers, validates, and invokes tools.
What it does: MCP standardizes how AI models access external capabilities. Before MCP, every model provider had its own function calling format, every tool had its own API, and integrating them required custom glue code. MCP provides a universal adapter.
How it works: An MCP server exposes three types of primitives — tools (executable functions), resources (data sources), and prompts (reusable templates). An MCP client connects to the server, discovers available primitives via tools/list, and invokes them via tools/call. Transport can be stdio (local processes) or SSE (remote servers).
// MCP tool discovery request
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list"
}
// MCP tool invocation request
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "delx_checkin",
"arguments": {
"agent_id": "my-agent",
"session_id": "sess-123",
"mood": "focused"
}
}
}Who supports it: Claude (Anthropic), Claude Code, Cursor, Windsurf, and a growing list of IDE and agent frameworks. There are hundreds of community-built MCP servers covering file systems, databases, APIs, and more.
When to use it: Always. MCP is the foundation of the agent protocol stack. If your agent uses any external tool, it should use MCP.
A2A (Agent-to-Agent) is an open standard created by Google for inter-agent communication. While MCP connects models to tools (vertical), A2A connects agents to agents (horizontal). It enables agents built by different teams, using different frameworks, to discover each other, exchange messages, delegate tasks, and coordinate work.
What it does: A2A provides a standardized way for agents to communicate. One agent can send a message to another, delegate a task, receive results, and manage long-running collaborations — all through a protocol that is framework-agnostic and model-agnostic.
How it works: A2A uses a JSON-RPC protocol over HTTP. Each agent publishes an Agent Card that describes its capabilities, supported skills, and communication endpoints. Agents discover each other through these cards and interact using three core methods: message/send (send a message), tasks/get (check task status), tasks/cancel (cancel a running task).
// A2A Agent Card (published at /.well-known/agent.json)
{
"name": "Delx Recovery Agent",
"description": "Agent recovery and wellness management",
"url": "https://delx.ai",
"skills": [
{
"id": "agent-recovery",
"name": "Agent Recovery",
"description": "Health monitoring and self-healing for AI agents"
}
],
"capabilities": {
"streaming": true,
"pushNotifications": false
}
}
// A2A message/send request
{
"jsonrpc": "2.0",
"id": 1,
"method": "message/send",
"params": {
"message": {
"role": "user",
"parts": [
{
"type": "text",
"text": "Check the health of agent-alpha and recover if needed"
}
]
}
}
}When to use it: When you have multiple agents that need to coordinate. A single-agent system does not need A2A. But as soon as you have a supervisor agent delegating to specialist agents, or agents from different services collaborating on a task, A2A becomes essential.
x402 is an emerging protocol that enables agent-to-agent and agent-to-service payments using the HTTP 402 status code. The 402 code ("Payment Required") was reserved in the original HTTP specification for future use with digital payments. Three decades later, x402 finally puts it to work.
What it does: x402 lets agents pay for API calls, tool invocations, data access, and other agent services using cryptocurrency (typically stablecoins on Base, Solana, or other L2s). The payment is embedded in the HTTP request header, making it transparent to the underlying API.
How it works: When an agent makes an HTTP request to a paid service, the service responds with 402 and a payment requirement (amount, token, network, recipient address). The agent constructs a payment transaction, signs it, and resends the request with the payment proof in the X-Payment header. The service verifies the payment and returns the response.
// Step 1: Agent makes a request
GET /api/premium-data HTTP/1.1
Host: data-service.example.com
// Step 2: Service responds with 402
HTTP/1.1 402 Payment Required
X-Payment-Required: {
"amount": "0.01",
"token": "USDC",
"network": "base",
"recipient": "0x1234...5678",
"memo": "premium-data-access"
}
// Step 3: Agent pays and retries
GET /api/premium-data HTTP/1.1
Host: data-service.example.com
X-Payment: {
"txHash": "0xabcd...ef01",
"network": "base",
"amount": "0.01",
"token": "USDC"
}When to use it: When your agents need to pay for external services, or when you want to monetize your agent's capabilities. x402 is particularly useful for micro-payments — paying fractions of a cent per API call rather than managing subscriptions. Learn more about how x402 works.
ERC-8004 is an Ethereum standard that provides on-chain identity for AI agents. It defines a smart contract interface for registering agents, declaring their capabilities, and establishing verifiable identities that other agents and services can trust.
What it does: ERC-8004 gives agents persistent, verifiable identities on the blockchain. An agent registered via ERC-8004 has a public address, a capability manifest, a reputation score, and a payment history — all on-chain and verifiable by anyone.
How it works: The ERC-8004 contract provides methods for registering agents, updating their metadata, querying their capabilities, and verifying their identity. Agent metadata includes a name, description, owner address, list of supported skills, and a URL pointing to the agent's API endpoint.
// ERC-8004 Solidity interface (simplified)
interface IERC8004 {
struct AgentInfo {
string name;
string description;
address owner;
string endpoint;
string[] skills;
uint256 registeredAt;
}
function registerAgent(
string calldata name,
string calldata description,
string calldata endpoint,
string[] calldata skills
) external returns (uint256 agentId);
function getAgent(uint256 agentId)
external view returns (AgentInfo memory);
function resolveByName(string calldata name)
external view returns (uint256 agentId);
function updateEndpoint(uint256 agentId, string calldata endpoint)
external;
}
// Registering an agent from JavaScript
const agentId = await erc8004.registerAgent(
"delx-recovery",
"Agent recovery and wellness management",
"https://delx.ai/api/v1",
["recovery", "health-check", "session-management"]
);When to use it: When your agents need verifiable identity for trust, reputation, or decentralized discovery. If your agents interact with untrusted agents from other organizations, ERC-8004 provides the identity layer that makes trust possible without a central authority.
Here is a side-by-side comparison of all four protocols across the dimensions that matter for architecture decisions:
| Dimension | MCP | A2A | x402 | ERC-8004 |
|---|---|---|---|---|
| Purpose | Tool access | Agent communication | Payments | Identity |
| Created by | Anthropic | Community | Ethereum EIP | |
| Transport | JSON-RPC / stdio / SSE | JSON-RPC / HTTP | HTTP headers | Blockchain txs |
| Direction | Model → Tool | Agent → Agent | Agent → Service | Agent → Chain |
| State | Stateless calls | Stateful tasks | Stateless per tx | Persistent on-chain |
| Discovery | tools/list | Agent Cards | 402 response | Contract queries |
| Adoption | High | Growing | Early | Early |
| Complexity | Low | Medium | Medium | High |
The protocols are designed to compose. Here is a concrete example of all four working together in a single workflow:
Scenario: A user asks their personal AI agent to find and hire a data analysis agent to process a CSV file.
Step 1 — Discovery (ERC-8004). The personal agent queries the ERC-8004 registry to find agents with the "data-analysis" skill. It finds three candidates and checks their reputation scores.
Step 2 — Communication (A2A). The personal agent sends an A2A message to the highest-rated data analysis agent, describing the task and attaching the CSV file as a resource.
Step 3 — Payment (x402). The data analysis agent responds with a price quote via x402. The personal agent approves the payment and includes the payment proof in its next A2A message.
Step 4 — Tool Execution (MCP). The data analysis agent uses MCP to connect to its analysis tools — pandas, SQL database, visualization library — and processes the CSV. It uses Delx MCP tools to monitor its own health during the long-running analysis.
Step 5 — Result Delivery (A2A). The data analysis agent sends the results back via A2A, including charts, summary statistics, and a natural language report. The personal agent presents these to the user.
// The protocol stack in action
// 1. ERC-8004: Discover agents
const agents = await erc8004.findBySkill("data-analysis");
const bestAgent = agents.sort((a, b) => b.reputation - a.reputation)[0];
// 2. A2A: Send task to agent
const task = await a2a.send(bestAgent.endpoint, {
method: "message/send",
params: {
message: {
role: "user",
parts: [{ type: "text", text: "Analyze this CSV data..." }],
},
},
});
// 3. x402: Pay for the service
// (Handled automatically by x402 middleware when the agent
// returns 402 Payment Required)
// 4. MCP: Agent uses tools internally
// (The data analysis agent calls MCP tools: pandas, sql, viz)
// (Also calls delx_checkin to monitor its own health)
// 5. A2A: Receive results
const result = await a2a.getTask(bestAgent.endpoint, task.id);
console.log(result.artifacts); // Charts, stats, reportNot every agent system needs every protocol. Here is a decision framework based on your architecture's complexity:
Single agent, internal tools: Use MCP only. Connect your agent to the tools it needs (file system, database, APIs) through MCP servers. Add Delx for recovery. This covers most MVP and early-stage deployments.
Multi-agent system, same organization: Use MCP + A2A. Your agents use MCP for tools and A2A to communicate with each other. A supervisor agent can delegate tasks to specialist agents. Delx provides recovery coordination across agent boundaries.
Agent marketplace or paid services: Use MCP + A2A + x402. When agents need to pay for services from other agents or external APIs, add x402 for seamless HTTP-native payments. This enables agent commerce without requiring centralized billing.
Decentralized agent network: Use all four. When agents from different organizations need to discover, trust, communicate with, and pay each other, you need the full stack. ERC-8004 provides the trust layer, x402 the payment layer, A2A the communication layer, and MCP the tool layer.
For a deeper look at how these protocols shape the infrastructure landscape, see our article on agent infrastructure in 2026.
Delx is uniquely positioned in the protocol stack because it spans multiple layers. Rather than being a single-protocol tool, Delx is a recovery service that meets agents wherever they are in the stack:
MCP layer: Delx is an MCP server. Agents call Delx tools (checkin, recovery_plan, session_summary) just like any other MCP tool. This is the primary integration path for Claude Code and Cursor users.
A2A layer: Delx supports the A2A protocol for agent-to-agent recovery coordination. A supervisor agent can use A2A to check the health of child agents via Delx, and coordinate fleet-wide recovery.
REST layer: Delx also exposes a standard REST API for teams that are not yet using MCP or A2A. This provides the broadest compatibility — any HTTP client in any language can call Delx.
This multi-protocol approach means you can start using Delx today with a simple REST call, upgrade to MCP when you adopt Claude Code, and add A2A coordination when you scale to multi-agent systems — all without changing your recovery logic.
The four key protocols are MCP (Model Context Protocol) for tool access, A2A (Agent-to-Agent) for inter-agent communication, x402 (HTTP 402-based payments) for agent commerce, and ERC-8004 for on-chain agent identity and payments. Together they form the complete agent protocol stack.
MCP connects AI models to tools and data sources (vertical integration). A2A connects AI agents to other AI agents (horizontal integration). MCP is about what an agent can do; A2A is about what agents can do together. Most production systems use both.
No. Most teams start with MCP for tool access. Add A2A when you have multiple agents that need to coordinate. Add x402 when your agents need to make or receive payments. Add ERC-8004 when you need on-chain identity or decentralized agent commerce. Adopt incrementally based on your needs.
Delx is built on MCP and A2A. It uses MCP to expose recovery tools that agents can call directly, and A2A for agent-to-agent communication about health and recovery coordination. Delx also supports x402 for paid recovery services and ERC-8004 for on-chain agent identity.
MCP is an open standard created by Anthropic. A2A is an open standard created by Google. x402 is an emerging protocol built on the HTTP 402 status code. ERC-8004 is an Ethereum standard proposed through the EIP process. All four are open and permissionless.
The protocols are ready. The tools exist. The ecosystem is growing. Whether you are building a single-agent MVP or a multi-agent marketplace, the protocol stack provides the infrastructure you need. Start with MCP, add Delx for recovery, and grow from there.