Learn

Market map

The Agent Payments Stack: MCP, x402, AP2 and Accord

Agent payments are not one protocol. They are a stack of tool access, payment authority, payment execution, work verification, settlement evidence and policy.

The mistake is looking for one protocol

Agent payments sound like a single problem until a real workflow touches money. A buyer agent needs to discover a tool, understand price, receive authority to spend, prove or execute payment, get the work, verify whether the work matched the request and record what happened for audit or settlement.

No single layer should own all of that. The healthier architecture is a stack. MCP handles tool connectivity. x402 handles HTTP-native payment mechanics. AP2-style flows help express payment authority and intent. Accord records the work terms, verification result and settlement evidence around the task.

MCP is the tool interface, not the commercial record

The Model Context Protocol gives applications and agents a common way to expose tools, resources and prompts. That is a major step for interoperability because tool calling stops being a private integration for every client and server pair.

But a tool interface does not answer the commercial questions: what exactly was purchased, what output counts as complete, what verifier is acceptable, what happens if the output fails and how should settlement evidence be recorded. Those questions need a work-agreement layer.

x402 is the payment mechanism, not the completion mechanism

x402 makes the HTTP 402 Payment Required status useful for programmatic payments. A client requests a resource, receives payment requirements, sends a payment payload and the server or facilitator verifies and settles the payment before returning the resource.

That is powerful for paid API calls, content access and machine-to-machine payments. It is still not enough for outcome-oriented work. A repository audit, model evaluation, data cleanup or compliance review can be paid for and still be incomplete, low quality or rejected under the buyer's acceptance criteria.

AP2-style authority answers who allowed the payment

Agent-led payments need a way to show that an agent had authority to transact. AP2-style mandates and payment authority records are useful because they move the ecosystem away from vague trust in a chatbot and toward auditable intent.

Authority still does not equal completion. A user can authorize an agent to buy a service, and the service can receive payment, while the actual work still needs a task record, verifier verdict and settlement trail.

Accord is the work layer

Accord exists for the space between payment and finished work. The Agreement Object records the task, price, parties, deadline, verifier and rail assumptions. The Verification Receipt records whether the output was accepted, rejected or partially accepted. The Settlement Receipt records the economic closeout and rail evidence.

That separation makes the agent payments stack inspectable. A payment protocol can do payment well. A tool protocol can do tool access well. Accord can do work verification and receipt semantics without pretending to be a wallet, facilitator, bank or payment network.

A clean reference architecture

A robust agent payment flow should be assembled in this order: discover the tool, construct the agreement, check buyer policy, grant or reference payment authority, verify or execute payment, run the work, verify the output, then write settlement evidence. Each layer should have a clear artifact that later systems can inspect.

The result is not just a successful request. It is an audit trail that says what the agent was allowed to buy, what was promised, what was delivered, who checked it and what settlement evidence exists.

FAQ

Is Accord a replacement for MCP, x402 or AP2?

No. Accord is designed to compose with tool, payment and authority layers. It records paid-work terms, verification and settlement receipts.

What is the shortest way to explain the difference?

MCP connects tools. x402 verifies payment. AP2-style flows express authority. Accord verifies completion.

Which layer should a developer start with?

Start with the work lifecycle: define what the buyer expects, how the result will be verified and which payment or authority layer will be referenced.

Sources and references

Model Context Protocol repository

Official MCP repository containing the specification, protocol schema and documentation.

x402 Foundation repository

Open x402 implementation and specification source for HTTP-native payment flows.

Google Cloud AP2 announcement

Google's announcement of AP2 as an open protocol for secure agent-led payments across platforms.

Next action

Start with the stack map

Use the stack model before choosing a payment, authority or tool layer.

Open