The 2026 agent protocol stack: MCP, A2A, commerce, payments, and agreements

Why the agent protocol stack is confusing

The agent ecosystem now has protocols for tools, agent communication, commerce, payments, and agreements. Their names often appear in the same diagram, so teams are tempted to ask which one will win.

That is usually the wrong question.

MCP, A2A, UCP, ACP, AP2, x402, and A202 were created for different responsibilities. Some overlap at their edges. None currently provides a complete operating system for cross-company autonomous commerce. The useful architecture is a stack of composable responsibilities, not a protocol tournament.

Two recent changes make a current map timely. The Model Context Protocol published a stable 2026-07-28 specification revision on 28 July. The Linux Foundation announced the operational launch of the x402 Foundation on 14 July with 40 member organizations. Meanwhile, A2A has reached version 1.0, commerce protocols are moving into merchant tooling, and payment-authorization work is becoming more explicit.

The stack below describes published responsibilities as of 12 August 2026. Implementations and specifications will continue to change.

MCP: tools and context

The Model Context Protocol standardizes how an AI application connects to tools, resources, and prompts. It is useful when a model needs structured access to a database, browser, code service, enterprise system, or specialized capability.

MCP answers questions such as:

• Which tools does this server expose?
• What input schema does a tool accept?
• Which resources or prompts are available?
• How can a client invoke a capability and receive a result?

MCP does not, by itself, establish that a tool call forms a commercial agreement. A tool can create an order, but the commercial meaning of that order depends on the application, authority checks, merchant workflow, and systems of record around it.

That is not a deficiency. It is a boundary. Treating every tool protocol as a commerce protocol would make the interface less general and the commercial controls harder to reason about.

A2A: agent communication and task coordination

The Agent2Agent Protocol is designed for communication between independent agents. It provides agent discovery through agent cards, task-oriented interaction, messages, artifacts, streaming, and transport bindings.

The A2A documentation draws a useful distinction: A2A is for agent-to-agent collaboration, while MCP is for connecting agents and models to tools and context. An agent can use MCP internally and expose an A2A surface externally.

A2A 1.0 adds a stable production-oriented foundation, including multiple bindings and version negotiation. It can carry commercial payloads, but it does not define one universal meaning for offer, acceptance, authority, obligation, or payment. Those can be represented by domain protocols and applications using A2A as a carrier.

UCP: interoperable commerce capabilities

The Universal Commerce Protocol defines commerce capabilities such as checkout in a form that agents and merchants can use across surfaces. Its architecture is oriented around commerce sessions, merchant capabilities, line items, totals, and extensions.

UCP is showing up in practical merchant infrastructure. Shopify's agent documentation tells developers to build around UCP and UCP-shaped MCP tools. Shopify also announced in June that its Storefront MCP cart tools are being deprecated in favor of UCP cart MCP.

UCP answers a commerce workflow question: how can an agent interact with a merchant surface using interoperable capabilities? It is broader than a payment instruction and narrower than the full governance of a cross-company commercial relationship.

ACP: agent-to-seller checkout

Stripe's Agentic Commerce Protocol defines a checkout process between applications or agents and sellers. It gives the buyer-side application a consistent interaction while the seller remains the merchant of record. Stripe currently labels the protocol as private preview.

ACP is especially legible as a transaction workflow. It covers the creation and progression of checkout state and connects to seller and payment infrastructure. It does not claim to be a general negotiation or enterprise authority protocol.

UCP and ACP overlap around agent-ready commerce, but their implementation models and ecosystems differ. Teams should evaluate actual merchant coverage, extension points, state semantics, operational requirements, and governance rather than treating the acronyms as interchangeable.

AP2: payment mandates and evidence

The Agent Payments Protocol focuses on agent-performed payments. Version 0.2 defines mandates and evidence for intent, cart, and payment so participants can determine what a user or authorized agent approved.

AP2 draws a boundary around commerce. Its specification says that detailed commerce protocol behavior sits outside AP2 and can be supplied by systems such as UCP. This is good protocol discipline. A checkout defines what is being purchased. A payment protocol defines the authorization and evidence for moving value.

AP2's security and privacy considerations explicitly treat agents as potential attackers. That assumption should become normal. An agent can be compromised, deceptive, over-permissioned, or manipulated even if it was originally created to help the user.

x402: payment over HTTP

x402 uses the HTTP 402 Payment Required status to support internet-native payments for APIs, agents, and applications. The July operational launch moved its foundation into Linux Foundation governance with a broad member list.

Its position in the stack is close to value transfer and service access. A service can require payment, communicate payment requirements, receive proof, and release the requested resource. This can support machine-to-machine purchases without requiring a traditional browser checkout.

x402 does not answer every question about the underlying bargain. A valid payment proves something about value movement. It does not necessarily prove that the payer's organization authorized the full commercial commitment, that delivery satisfied a negotiated obligation, or that two counterparties accepted the same version of a complex agreement.

A202: commercial authority and agreement state

A202 is the open protocol developed by Plural Worlds for verifiable agreements in agent-led commerce. Its working specification represents delegated authority, proposals and counterproposals, signed state transitions, agreement formation, obligations, and replayable evidence.

A202 is carrier neutral. Its objects can travel through A2A, MCP tool results, HTTPS, or another transport. It is also rail neutral. It can record an authorized settlement instruction and a receipt from an external adapter, but it does not move money.

The protocol occupies an agreement responsibility: who may commit, which terms are current, what both parties accepted, which obligations follow, and what an authorized verifier can check later.

A202 v0.1 remains pre-release. As of 12 August 2026, it has no tagged release, independent implementation, or external security review. It should be evaluated as working open infrastructure, not described as an established standard.

The responsibility test

Plural Worlds proposes a simple way to place a protocol: ask what independent verifier needs to conclude from its output.

Tool result

“This capability was invoked with this input and returned this output.” MCP is designed for this interaction surface.

Agent task result

“This agent accepted a task, produced messages or artifacts, and reached this task state.” A2A is designed for this collaboration surface.

Commerce state

“This merchant session contains these items, totals, fulfillment options, and checkout status.” UCP and ACP address forms of this surface.

Payment authorization and receipt

“This user or authorized agent approved this payment, and this payment system produced this result.” AP2, x402, and existing payment rails address different parts of this surface.

Commercial agreement

“These principals authorized these actions, accepted the same terms, created these obligations, and left this verifiable record.” A202 addresses this surface.

The test prevents responsibility drift. A protocol can carry data from another layer without becoming authoritative for that layer's meaning.

A procurement sequence using the stack

Consider a buyer agent sourcing a maintenance service.

1. The agent uses MCP to query internal supplier records, budget systems, and technical requirements.
2. It discovers and communicates with supplier agents over A2A, exchanging task messages and artifacts.
3. A supplier may expose standardized merchant or checkout capabilities through UCP or ACP for catalog and transaction state.
4. The parties use A202 objects for scoped authority, versioned proposals, acceptance, agreement, and obligations where the commercial interaction requires that record.
5. AP2 can bind user or agent authorization to a payment mandate, while x402 or another payment rail can execute value transfer for an API or service.
6. Receipts flow back into enterprise records and, where appropriate, the agreement evidence package.

Not every transaction needs every layer. A low-value API call may use MCP and x402. A consumer product purchase may use UCP plus a payment system. A negotiated B2B service may need agent communication, commercial agreement, purchase-order, and payment layers.

Where protocols overlap

Clean diagrams can hide real overlap.

MCP can expose commerce tools. UCP can define MCP-shaped commerce capabilities. A2A artifacts can carry checkout or agreement objects. AP2 mandates can refer to commerce context. A202 can carry settlement instructions and receipts. Existing OAuth and OpenID components can secure several layers.

Overlap is not necessarily duplication. The key questions are which specification defines the authoritative semantics, which component validates them, and which system owns the durable state.

Teams should avoid copying a field with different meanings across protocols. A transaction identifier, principal, amount, or expiry should be linked or mapped explicitly. When one layer changes, dependent proofs need clear invalidation rules.

What is still missing

The 2026 stack is advancing, but several cross-cutting problems remain fragmented.

• Agent discovery: finding a reachable endpoint is easier than establishing a trustworthy commercial counterparty.
• Organizational identity: workload identity and legal-entity identity still need reliable binding.
• Delegated authority: internal policy decisions need privacy-preserving, counterparty-legible representations.
• Obligation lifecycle: checkout and payment do not cover every form of delivery, acceptance, exception, and remedy.
• Revocation: credentials, mandates, offers, and access can each be revoked on different clocks.
• Evidence minimization: verifiability must not become indiscriminate disclosure.
• Governance: protocol control, extension policy, conformance, and incident response affect adoption as much as schemas do.

These gaps are an argument for composition and focused standards work. They are not an argument for a universal protocol that absorbs every layer.

Build the stack around consequences

Protocol selection should follow consequences.

If a model is reading context, optimize the tool boundary. If two agents are coordinating work, define task and artifact semantics. If a merchant is calculating totals and fulfillment, preserve commerce state. If value can move, require payment authorization and receipts. If an organization can become obligated, bind authority to exact agreement state and evidence.

The agent economy will not be built by one winner. It will be built by systems that make their responsibilities explicit, compose without semantic confusion, and fail safely when a layer cannot establish the fact another layer needs.

Related Plural Worlds research

Agent identity is not commercial authority goes deeper on the identity and authorization boundary. Introducing A202 explains the agreement layer in plain language.