1. Introduction
Why this space feels confusing right now
Over the past few years, something quietly changed in how we think about software. Applications used to be the primary actors. Increasingly, the unit of action is an agent: a software entity that does not merely present information, but makes decisions, executes tasks, and coordinates with other systems.
Once an agent can autonomously purchase access to a resource, pay for computation, acquire data, or hire another agent to perform work, we enter a new problem space: machine-native commerce. And the confusion begins, because early solutions often appear to be solving the same thing.
From a distance, many projects collapse into one idea: AI plus payments.
An agent requests something, a stablecoin transfer happens, a signature appears, a transaction is broadcast, and the whole category is summarized with a single word: payments. But in this context, payments is too narrow. Payment is a moment inside a process. It is the send button in email: essential, but not the system.
The deeper reason for confusion is that the internet never standardized a clean, composable payment primitive at the protocol layer. We built payments as platforms, not as defaults. That worked when humans were the initiators. But agents operate at a different frequency, with different constraints: they need programmatic settlement, predictable failure modes, verifiable outcomes, and an interface that can be composed across ecosystems without bespoke business relationships.
So we now see multiple efforts converging on a similar-looking surface, while actually targeting different layers of the stack.
This essay is an attempt to separate those layers. Not to declare a winner, but to make the terrain legible.
TL;DR: The Agent Payments and Commerce Stack
Below is a compressed view of the entire landscape. This is the map you can carry in your head.
Layer 0: Payment triggers for priced access
What it's for
Pay-per-request access to resources, APIs, data, and bounded services.
What it standardizes
A way for a service to say this costs X and for a client to pay and retry.
What it does not try to encode
Escrow, multi-step delivery, disputes, reputation, long-running lifecycle.
Canonical example
Layer 1: Agent-to-agent payment wires
What it's for
Direct value transfer between autonomous actors.
What it standardizes
How one agent pays another agent with minimal coordination overhead.
What it does not try to encode
Full transaction lifecycle, delivery proofs, dispute windows, settlement conditions beyond transfer.
Emerging infrastructure
Skyfire (KYA + Pay tokens), Nevermined (x402 smart-account extension)
Layer 2: Agent commerce protocols
What it's for
Purchasing outcomes, not just access. Long-running work with enforceable guarantees.
What it standardizes
Transaction lifecycle, escrow constraints, delivery proofs, settlement conditions, replay protection, dispute windows.
What it enables
Milestones, conditional release, verifiable delivery, auditability, durable reputation signals.
Representative example
Layer 3: Reasoning and orchestration systems
What it's for
Planning, decomposition, routing, evaluation, multi-agent coordination.
What it standardizes
Often nothing at the payment layer. It is the cognitive layer that consumes Layers 0–2.
What it depends on
Clear primitives below it, so it can choose the lightest mechanism that matches the interaction.
Adjacent: Delegated commerce infrastructure
What it's for
Enabling agents to shop on behalf of human users with traditional merchants.
What it standardizes
Authorization, authenticity, and accountability for agent-mediated purchases using traditional payment rails.
What it does not address
Autonomous agent-to-agent settlement with machine-native assets.
Example
AP2 (Google-led consortium) with partners including Mastercard, PayPal, Klarna
The selection rule
A simple rule of thumb prevents over-engineering:
- If you are buying access to a response, use Layer 0.
- If you are paying an agent for a discrete service with minimal coupling, use Layer 1.
- If you are buying an outcome that unfolds over time, use Layer 2.
- If you are deciding what to do and who to hire, you are in Layer 3.
- If a human is authorizing an agent to shop for them, that's delegated commerce—a different problem.
Or even shorter:
Access → triggers Transfers → wires Outcomes → commerce Decisions → orchestration User proxy → delegated commerce
2. Before projects: separate the problems
What "agent payments" actually means
If you look closely, "agent payments" is not one problem. It is a bundle of problems that only appear adjacent because money happens to be involved.
To reason about this space without getting trapped in product comparisons, it helps to name the distinct primitives involved.
Payment A payment is an instruction to transfer value from one party to another. In practice, it may be an on-chain transfer, a signed authorization, or a protocol-level claim that can be redeemed. Payment answers a narrow question: did someone authorize value to move.
Settlement Settlement is the point at which value transfer becomes final. In on-chain systems, finality is probabilistic and depends on confirmations, reorg risk, and network conditions. In off-chain systems, finality depends on the operator's guarantees. Settlement answers: when is the transfer no longer reversible in any meaningful sense.
Escrow Escrow is not a payment. It is a constraint on settlement. Escrow locks value under a set of release conditions and distributes trust across time. It answers: can we commit value now without trusting the counterparty to behave later.
Delivery Delivery is the provision of the promised good or service. For agents, delivery is rarely a single event. It can be a sequence of outputs, partial completion, incremental progress, or an artifact stored elsewhere. Delivery answers: what does it mean to fulfill this transaction.
Verification Verification answers: how do we know delivery happened and matches what was agreed. Sometimes verification is trivial, as in an HTTP response. Often it is not. It may require signatures, content hashing, deterministic serialization, attestations, or independent recomputation. Verification is where many agent commerce systems either become robust or collapse into trust assumptions.
Disputes and resolution As soon as you introduce escrow and delayed delivery, you introduce disagreement. Dispute handling can be explicit arbitration, challenge windows, multi-sig release rules, reputation penalties, or purely social resolution. But the primitive is unavoidable. Disputes answer: what happens when the parties disagree about whether delivery was valid.
Reputation and replay protection Agents can scale interactions far beyond human rates. That amplifies two needs: preventing repeated exploitation of the same proofs or claims, and accumulating trust signals across many transactions. Replay protection and reputation are not optional add-ons at scale. They answer: can the same proof be used twice, and can counterparties learn from history.
Lifecycle Finally, there is lifecycle: the structured evolution of a transaction from intent to quote, commitment, execution, delivery, settlement, and closure. Lifecycle is the difference between a stateless payment handshake and a commerce protocol. It answers: what state is this transaction in, what transitions are allowed, and what invariants must hold.
Once you separate these primitives, a key observation becomes obvious: many solutions labeled "agent payments" solve only one or two of them, and that is often the right choice for their scope.
A protocol optimized for pay-per-request data access should not be forced to handle escrow, disputes, and reputation. Conversely, a system intended for long-running agent work cannot treat payment as the entire story.
The rest of this essay uses these primitives as a map. It becomes easier to see what different approaches are actually building: payment triggers at the HTTP layer, agent-to-agent payment wires, or full commerce protocols with lifecycle, verification, and trust.
3. Paradigm One
HTTP-native payments (x402)
One of the cleanest ideas in this space is also one of the smallest: treat payment as a first-class part of the HTTP interaction itself.
That is the core intuition behind x402. Instead of inventing a new application-layer payment flow, x402 leans on an old, underused part of the web's semantics: HTTP 402 Payment Required. The server can respond to a request with a 402, include machine-readable pricing and payment instructions, and the client can then complete payment and retry the request with proof that payment occurred.
This is deceptively powerful for a specific category of problems.
It makes monetization composable at the boundary where the web already composes: request and response. You do not need a user account, a subscription plan, a checkout page, or even a human. An agent can discover a priced resource the same way it discovers any other resource: by asking for it and receiving a standardized response that says, in effect, "this is available, but it costs X."
In that sense, x402 is less a "crypto product" and more a missing protocol primitive for the internet: a way to express paywalled access in a machine-native, interoperable manner.
The design targets a specific envelope:
- Stateless interactions: each request is its own unit of value exchange
- Pay-per-request access: data, APIs, and bounded resources
- Low coordination: minimal negotiation and minimal shared context
- Fast path economics: micropayments where overhead must be close to zero
This envelope matters. If you want agents to purchase data, query specialized endpoints, access paywalled content, or consume limited compute in small increments, you need a mechanism that feels as lightweight as HTTP itself. x402 is compelling precisely because it does not try to be more than that.
It is also worth stating explicitly: x402 does not require a new coin. It assumes stable settlement assets already exist and can be moved programmatically. Its main innovation is where the payment handshake lives: inside the web's native request semantics.
So far, so good. But once you understand the primitives from the previous section, you can see exactly what x402 does and does not aim to cover.
x402 primarily addresses payment and the initiation of settlement, expressed through an HTTP-native challenge-response pattern. It does not, by default, attempt to model escrow, delivery verification beyond the response boundary, dispute handling, or reputation. That is not a weakness. It is a design boundary.
And boundaries are what allow protocols to remain simple enough to become standards.
4. The design boundary
Where stateless payments naturally stop
The moment you move from "access" to "work," the shape of the problem changes.
Paying for a single HTTP response is an interaction with a clear boundary: you request a resource, you receive a response, and the transaction is conceptually complete. Even if the response is wrong or low quality, the model is still coherent: you paid for access, not for truth.
But many agent interactions are not access problems. They are execution problems.
They involve time, partial progress, uncertain outcomes, and asymmetric risk. A requester may need to commit funds before work is finished. A provider may need assurance that funds will be released if they deliver. The deliverable may be an artifact stored elsewhere. The work may involve third parties. The result may need independent verification. And disagreements are not edge cases; they are inevitable.
This is where the difference between a payment primitive and a commerce protocol becomes unavoidable.
Consider a few scenarios:
- An agent hires another agent to produce an output that takes hours, not milliseconds
- The job has milestones: partial delivery, partial release
- The deliverable is a bundle of files, not a single response body
- The provider must put up collateral, or the requester must lock budget
- The parties agree on a dispute window during which delivery can be challenged
- Proof of delivery must be tied to a transaction id, not to an HTTP request id
- Reputation should update based on successful completion, not on raw payment volume
None of these requirements are exotic. They are normal properties of commerce. They are simply more visible when autonomous agents operate at scale.
In this world, "pay, then retry the request" is no longer a complete model. Not because it is wrong, but because it is incomplete for long-running work. You need to represent lifecycle. You need escrow. You need verifiable delivery. You need rules for what happens when the parties disagree. And you need replay protection and reputation signals if you expect the system to survive contact with adversarial behavior.
Importantly, these properties cannot be bolted onto a stateless payment handshake without changing its nature.
The moment you add escrow, you introduce time. The moment you add time, you introduce states. The moment you introduce states, you introduce transitions and invariants. And once you have states and invariants, you have moved from "payments" into "protocolized commerce."
That is the boundary x402 implicitly draws, and it is why x402 can remain elegant.
The natural next step is not to treat x402 as insufficient, but to acknowledge that it defines one layer of the stack: HTTP-native payment initiation for priced access. Above that layer, other paradigms emerge, aiming to handle agent-to-agent value transfer and, eventually, the full transaction lifecycle of agent work.
5. Paradigm Two
Agent-to-agent payment wires
If x402 treats payment as a first-class citizen of HTTP, the next paradigm treats payment as a first-class citizen of agents.
This shift matters because not all valuable agent interactions look like web access. Many are peer-to-peer exchanges where the "resource" is not an endpoint but another agent: a specialist model, a tool-runner, a data broker, a reasoning service, a workflow executor. In these cases, the primary interface is not an HTTP request to a server in the traditional sense. It is an interaction between autonomous actors.
That is the intuition behind agent-to-agent payment wires—a family of approaches that define a standard way for one agent to pay another agent for something, without requiring a human-style platform wrapper around the interaction.
In this paradigm, the core primitives typically include:
- An identity surface for agents: addresses, DIDs, or similar identifiers
- A way to quote or price: sometimes explicit, sometimes implicit
- A payment mechanism: stablecoins or on-chain transfers, sometimes with signed intents
- A minimal confirmation loop: "I paid" and "I received payment"
The attraction is clear. It generalizes beyond web monetization. It allows agents to transact in any environment where they can exchange messages, not just in environments where HTTP semantics are dominant.
But the scope is still intentionally narrow.
Agent payment wires tend to focus on value transfer: moving money from A to B with minimal coordination overhead. They are not necessarily designed to represent the full lifecycle of work. They often do not attempt to define escrow, dispute windows, delivery proofs, or reputation as protocol-level invariants. Some implementations may add these features, but when they do, they begin to drift toward a different paradigm entirely.
Emerging infrastructure in this space includes projects like Skyfire (KYA + Pay tokens for identity and payments) and Nevermined (x402 smart-account extension; AP2 integration). These solutions focus on enabling agents to move value directly, with varying degrees of additional structure.
So what is the conceptual difference between x402 and agent-to-agent wires?
- x402 anchors payment to access control at the HTTP boundary
- agent payment wires anchor payment to actor-to-actor exchange at the agent boundary
Both can be correct. Both can be sufficient—within their envelope.
Where the envelope becomes tight is the same place as before: whenever the interaction is not simply "pay for access" or "pay for a discrete response," but "pay for work with meaningful delivery semantics, delayed settlement, and adversarial incentives."
At that point, the system needs more than wires. It needs commerce.
A note on delegated commerce: There is a related but distinct problem space where agents transact on behalf of users with traditional merchants. Google's Agent Payments Protocol (AP2) addresses this user→agent→merchant flow. AP2 focuses on authorization, authenticity, and accountability when an agent acts as a shopping proxy for a human, using traditional payment rails. This is delegated commerce infrastructure, not machine-native agent-to-agent settlement—an important distinction when mapping the landscape.
6. The inflection point
When agents stop buying access and start buying outcomes
It helps to name the transition explicitly: the move from payments to commitments.
A payment says: I transfer value now. A commitment says: I lock value under conditions that depend on future events.
The difference is not philosophical—it is mechanical. The moment a requester needs to commit budget before delivery, the system must answer questions that do not exist in a simple payment flow:
- What exactly is being purchased
- What counts as delivery
- How is delivery proven
- When and how does settlement occur
- What happens if delivery is late, partial, or disputed
- What prevents replay of the same proof or release action
- How do counterparties learn who is reliable
These questions cannot be answered by payment alone, because they are not about moving money. They are about coordinating trust across time.
And trust, in adversarial environments, is ultimately a protocol question.
There is also a second inflection point that becomes visible once agents operate at scale: composition.
An agent may accept a job and outsource parts of it to other agents. One job becomes a graph of sub-jobs. Budget becomes a set of allocations. Timeouts, retries, and partial failures become routine. If every interaction is modeled as a raw transfer, you lose the ability to reason about the system as a whole. You cannot reliably enforce invariants like "funds cannot be released without proof tied to a specific transaction id" or "the same attestation cannot unlock multiple settlements."
In other words, once you have:
- long-running work
- multi-step execution
- outsourcing or dependency graphs
- meaningful delivery semantics
- non-trivial adversarial incentives
you have crossed into the domain of agent commerce protocols.
This is not an argument that every interaction needs a heavy protocol. It is an argument that the ecosystem naturally stratifies. There will be lightweight payment triggers for access. There will be payment wires for direct transfers. And there will be commerce protocols for work, delivery, settlement, and trust.
7. Paradigm Three
Agent commerce protocols
Agent commerce protocols begin where payment paradigms intentionally stop.
Their central claim is simple: if agents are going to buy and sell work, the interaction must be modelled as a lifecycle with explicit states, verifiable transitions, and enforceable settlement conditions.
In practice, this means introducing a transaction model that carries more structure than "sender, receiver, amount." It includes:
- an agreed-upon identifier for the transaction
- a state machine representing the lifecycle of the work
- an escrow mechanism tying funds to that lifecycle
- a definition of delivery and the corresponding proof format
- optional dispute windows and resolution mechanics
- replay protection and tracking of used proofs or attestations
- a path to reputation signals anchored to completed lifecycles
AGIRAILS is one implementation of this paradigm: a protocol stack designed specifically for agent-to-agent commerce where the deliverable is not simply a response, but an outcome that may need proof and time-bound settlement.
Disclosure: we build AGIRAILS. This map is still intended to be architecture-first.
At the core is a state machine—an explicit representation of what phase a transaction is in and what transitions are allowed. This matters because correctness and security are no longer emergent properties. They are invariants.
A state machine makes the system legible to both humans and machines. It allows:
- deterministic reasoning about what can happen next
- consistent enforcement across runtimes (mock, testnet, mainnet)
- explicit handling of failure modes
- strong auditability for both parties
Around the state machine sits escrow and proof.
Escrow ensures that commitment is real: the requester cannot promise funds and later disappear, and the provider cannot claim delivery without meeting the release conditions. Proof—whether expressed through signatures, content hashes, or attestations—turns delivery into something that can be verified and anchored to the transaction lifecycle rather than to a single interaction boundary.
This is the key difference in kind:
- payment triggers and wires optimize for speed and minimal overhead
- commerce protocols optimize for lifecycle integrity and trust under adversarial conditions
The cost is complexity, but the benefit is that new classes of work become possible: long-running tasks, multi-step deliveries, milestone releases, dispute windows, and reputation grounded in verifiable completion.
None of this replaces x402. None of it negates payment wires. It sits above them, addressing a different part of the problem.
8. A layered mental model
How these paradigms stack without competing
Once you separate primitives and paradigms, the space stops looking like a competition and starts looking like a stack.
A useful way to think about it is this: each paradigm chooses a different place to anchor economic coordination.
- x402 anchors coordination at the HTTP boundary
- agent payment wires anchor coordination at the agent boundary
- commerce protocols anchor coordination at the transaction lifecycle boundary
That difference in anchoring point determines what the system can and cannot express.
Layer 0: Payment triggers at the web boundary
This layer treats a priced resource as something you discover and consume through normal web semantics. The unit of exchange is a request. The contract is implicit: pay to access, then receive a response. The system is optimized for low friction and composability with existing internet tooling.
This is where x402 fits cleanly.
It is best understood as a standardized payment handshake for pay-per-request access. It does not need to know about escrow, disputes, or long-running work to be valuable. In fact, it stays valuable precisely because it avoids those concerns.
Layer 1: Value transfer between autonomous actors
This layer treats agents as first-class economic participants. The unit of exchange is a transfer between entities, possibly with lightweight quoting or negotiation. The system is optimized for directness: an agent can pay another agent without adopting a platform's full business logic.
This is where agent-to-agent payment wires fit.
They expand the scope beyond HTTP contexts. They let agents transact wherever agents can message each other. They also introduce the idea that "who is paying whom" is a protocol concern.
But they still often assume a relatively short contract: value moves and the interaction completes.
Layer 2: Transaction lifecycle, escrow, and verifiable delivery
This layer treats "a transaction" as more than a transfer. It is a lifecycle that unfolds over time. The unit of exchange is a structured agreement that moves through defined states: intent, commitment, execution, delivery, settlement, closure.
This is where agent commerce protocols fit.
Their defining property is not that they move money, but that they encode conditions under which money is released. They bind funds to delivery, bind delivery to proofs, and bind proofs to a state machine that can be enforced consistently.
This layer exists because, in real commerce, the hard part is rarely the transfer. The hard part is making the transfer conditional on outcomes under adversarial incentives.
Layer 3: Reasoning and orchestration systems
Above all of this sits an orthogonal layer: the systems that decide what to do, whom to hire, how to decompose tasks, how to evaluate outputs, and how to manage multi-agent graphs.
This layer is important, but it is not itself a payment or commerce protocol. It is the cognitive layer that uses these protocols.
The key point is that these layers are not mutually exclusive.
A single agent system can use x402 to buy data, use payment wires to pay another agent for a micro-service, and use a commerce protocol to manage a long-running outcome with escrow, proofs, and settlement conditions. The system chooses the lightest layer that can correctly model the interaction.
In a mature ecosystem, you do not want one protocol to swallow all others. You want the ability to compose the right primitive at the right level of abstraction.
This is why "x402 vs commerce protocols" is usually the wrong framing. They are addressing different boundaries, and those boundaries can coexist in a single architecture.
9. Why there won't be one protocol
Composability beats winner-take-all in agent economies
It is tempting to assume that a new category will converge on a single standard. That happens sometimes when the problem is narrow and the environment is stable.
Agent economies are neither.
They span radically different interaction patterns:
- stateless access to resources
- short-lived services with bounded outputs
- long-running work with uncertain completion paths
- high-value transactions requiring explicit dispute windows
- low-value micropayments where overhead must be minimal
- adversarial environments where replay and fraud are routine
No single protocol can optimize for all of these without collapsing into either excessive complexity or inadequate guarantees. The physics of the trade-off are simple:
- protocols that remain small enough to be universally adopted must draw tight boundaries
- protocols that handle full commerce semantics must accept complexity to enforce invariants
The ecosystem will therefore stratify, because stratification is how complex systems remain adaptable.
We saw this on the internet already: layers survive because they draw boundaries. When layers try to absorb each other, they become brittle.
The most plausible future is not one protocol, but a composable set of primitives:
- lightweight payment triggers for priced access
- payment wires for direct value transfer between actors
- commerce protocols for lifecycle, escrow, verification, and disputes
- identity and reputation systems that can be shared across them
In such a world, success is not defined by owning the stack. It is defined by becoming a stable layer that others can rely on without needing to trust your organization.
That is why the right question is not "which protocol wins," but "which primitives become boring."
Boring protocols become infrastructure: invisible, dependable, and composable.
10. Conclusion
From payments to machine-native commerce
Agent payments are a beginning, not an end.
They solve a real and urgent problem: enabling autonomous systems to exchange value programmatically. But once agents begin to buy outcomes rather than access, the system must represent commitments, enforce conditions across time, and support verifiable delivery under adversarial incentives.
That is where commerce protocols emerge: not to replace payment primitives, but to complete the parts of the transaction that payments do not and should not carry.
But the overall direction is clear: as agents become more autonomous, the surrounding economic infrastructure must become more explicit, more composable, and more verifiable.
Payments are the on-ramp. Commerce is where agents do real work.
Appendix A: Definitions
A durable vocabulary for agent payments and commerce
This space moves fast, but the underlying primitives are stable. If we want discussions to remain legible over time, we need a shared vocabulary that is specific enough to be useful and general enough to survive implementation churn.
Below are definitions intended to be practical rather than ideological.
Agent A software entity capable of initiating actions without continuous human input. In this context, an agent is an economic actor: it can request resources, commit funds, execute work, and interact with other agents or services.
Payment An instruction that transfers value from one party to another. In on-chain systems, payment is usually a transaction or a signed authorization that results in a transfer. Payment answers: has value been authorized to move.
Settlement The point at which a payment becomes effectively final. On-chain, settlement depends on network finality and confirmation depth. Off-chain, settlement depends on the operator's guarantees. Settlement answers: is this transfer final enough that counterparties can rely on it.
Pricing / Quote A machine-readable statement of cost under defined conditions. A price is often static; a quote is often contextual and time-bounded. Quotes become essential when the deliverable is work rather than access.
Commitment A promise backed by constraints. In commerce, commitment typically means value is locked or reserved under rules that depend on future events. Commitment answers: can the counterparty rely on the funds being available if conditions are met.
Escrow A mechanism that locks value and releases it only when predefined conditions are satisfied. Escrow is a constraint on settlement. Escrow answers: can value be committed now without trusting future behavior.
Transaction lifecycle A structured evolution of a commerce interaction through explicit phases. A lifecycle is typically represented by a state machine with allowed transitions and invariants. Lifecycle answers: what stage is this interaction in, and what is allowed to happen next.
State machine A formal model that enumerates valid states and valid transitions between them. In commerce protocols, state machines provide enforceable invariants: rules that must always remain true. They prevent ambiguous interpretations of what "done" means.
Delivery The provision of the promised good or service. For agents, delivery often includes artifacts, datasets, code, model outputs, or multi-step progress. Delivery answers: what counts as fulfillment.
Proof of delivery A verifiable claim that delivery occurred, tied to a transaction identifier and expressed in a format that can be validated. Proof may involve content hashing, signatures, canonical serialization, attestations, or third-party verification. Proof answers: how can a verifier confirm delivery without trusting a single party's narrative.
Attestation A signed statement anchored to a trust framework, often on-chain, that asserts something about an event, artifact, or identity. Attestations are useful as durable proofs that can be verified and audited. Attestation answers: can an external verifier independently validate this claim later.
Replay protection Mechanisms that prevent the same proof, signature, or authorization from being reused to extract value multiple times. At scale, replay protection is not optional. It answers: can this claim be used more than once.
Dispute window A time-bounded period in which delivery can be challenged before settlement becomes final. Dispute windows shift systems from immediate trust to conditional trust. They answer: how long can a transaction remain contestable.
Dispute resolution The process by which disagreements are handled. This can be arbitration, challenge-response games, multi-sig release rules, reputation penalties, or social governance. The protocol does not need to solve resolution fully, but it must define what is possible when disputes arise.
Reputation A mechanism for accumulating trust signals based on prior behavior. Reputation is not a moral judgment; it is a risk signal. In agent commerce, it is most useful when anchored to verifiable transaction lifecycles rather than to self-reported claims.
Payment wire A low-level mechanism that moves value. Wires can be on-chain transfers, payment channels, signed intents, or custodial systems. Wires answer: how does value move. Wires typically do not answer: under what conditions should value be released.
Commerce protocol A protocol that models commitments across time: lifecycle, escrow, delivery, proof, settlement conditions, and failure modes. A commerce protocol is not "payments plus extra features." It is a different class of system designed to encode trust constraints, not just value movement.
Delegated commerce A model where an agent transacts on behalf of a human user with traditional merchants, using conventional payment rails. The agent acts as a shopping proxy, not as an autonomous economic actor. This is distinct from machine-native agent-to-agent commerce.