The agent commerce infrastructure race is already producing winners.
Anthropic’s Model Context Protocol currently runs on more than 10,000 public servers, performs 97 million SDK downloads each month, and connects AI applications to external tools and data.
Google’s agent-to-agent protocol launched with 50 partners in April 2025 and expanded to more than 100 supporting companies before moving under Linux Foundation governance.
On January 11, Google announced its Universal Commerce Protocol, bringing in Shopify, Walmart, Target, Mastercard, Stripe, Visa, and American Express as early supporting companies to standardize the way agents interact with live checkout flows.
Coinbase’s x402 protocol handles the payment transport layer and enables automated stablecoin payments over HTTP. The project reports that by late 2025, more than 100 million payments have been processed across APIs, apps, and AI agents.
This is significant standardization for a technology category that barely existed three years ago.
However, these protocols all address the same narrow scope of how agents connect, coordinate, and initiate payments.
None of them answer the difficult commercial question one step down the stack: Who decides when the work is actually done?
Protocols/Standards What to do and why not MCP (Model Context Protocol) Connects AI applications and agents to external tools, APIs, and data sources. It does not verify whether the task results were actually delivered. It handles the tools/data layer, not the trust layer regarding completed work. A2A (Agent to Agent) Enables agents to communicate and coordinate between systems or organizations. We do not hold funds in escrow or judge the quality of deliverables. Agent interoperability is resolved, but it is not. Conditional Payments UCP (Universal Commerce Protocol) Standardizes agent-driven commerce and checkout flows Does not determine whether purchased services or tasks were completed satisfactorily Pushes agents deeper into the actual transaction and provides greater visibility into missing validation layers AP2 (Agent Payments Protocol) Uses a signed payment obligation to prove the amount an agent is authorized to spend Proves permission, not whether the result of the payment materialized This is an authorization criterion, not work validation Enables automated payments over HTTP, including standardx402 stablecoin payments Moves money, but does not decide whether money should be moved only after work is verified Payment transport rail, not an escrow/arbitrage layer Mastercard Verifiable Intent Creates a trust and audit layer to prove a user’s purchase authorization Focuses on authorized purchases and a trail of disputes rather than task completion itself Shows that incumbents are standardizing intent and accountability, but is not yet complete Verification Defines an ERC-8183 job-based escrow flow: Funds locked, work submitted, rater completion or rejection, refundable to client upon expiry Rateer trust, disputes, or “agency” identity cannot be resolved by itself Targeting the missing conditional payment/verification step is the hook of this article ERC-8004 Provides a trust/reputation framework for agents and trading partners Not itself an escrow or payment release mechanism ERC-8183 Oracle / Staking / zkML / TEE style trust system likely to be a construction layer to make style evaluations more reliable Possible ways to validate results or back up evaluator judgments with stronger guarantees Nothing has yet been established as a standard for widespread agent commerce These are possible answers to the article’s central question. In other words, who gets to decide when the job is done?
Escrow as a missing primitive
ERC-8183, the draft Ethereum standard published on February 25th, is the cryptocurrency’s attempt to make its decisions programmable.
Stripping away the jargon, proposals become minimal state machines for task-based commerce. The client locks the budget in escrow, the provider submits the work, and the evaluator marks the job complete or rejects it.
The expiration date will be automatically refunded to the client. The specification calls this sequence Open, Fund, Submit, Terminal. Additionally, it explicitly states that only the evaluator can mark the job as complete once the work is complete.
Its architecture is narrower than its “agency trading” framework suggests.
Critics on the Ethereum Magicians discussion thread noted that there was “nothing particularly ‘proxy’ about the proposal.” One commenter called this a “job registration with funds in escrow.”
The critique is accurate and also the most helpful thing about this story.
What ERC-8183 actually specifies is a programmable escrow primitive that can be applied to any human or machine task-based transaction.
AI frameworks are layered on top of structures that predate agents. A more interesting question is whether that structure is the only piece currently missing from the stack.
Authorization and verification gap
Existing payments companies that are building around agent commerce are solving for authorization, not validation.
Google’s agent payments protocol assembles payments based on cryptographically signed instructions that certify the amount an agent is authorized to spend.
Developed in collaboration with Google and introduced on March 5, Mastercard’s Verifiable Intent creates a layer of trust to prove what users have authorized, as well as an audit trail designed for dispute resolution.
These are the surefire answers to “Is this purchase authorized?” They don’t say anything about whether the results they purchased were realized or not.
That gap is an accumulation of productive contradictions.
A2A enables agents to have conversations across organizational boundaries. MCP ensures you have access to the right tools and data. AP2 and x402 ensure automatic transfer of funds. ERC-8183 proposes to conditionally hold the funds until the valuer certifies that the deliverables have been liquidated.
Whether that evaluator is a client, an oracle network, a staking system, or a zkML certificate is up to the implementer, but the specification explicitly lists ERC-8004’s trust and reputation layers as recommended configuration points for higher-value jobs.
The power center that no one has named
The role of the evaluator is where the proposal becomes politically interesting.
The security section of ERC-8183 warns that malicious evaluators may arbitrarily complete or reject jobs, recommends reputation and staking mechanisms for higher value contracts, and acknowledges that there is no dispute resolution within the core specification.
One builder in the Magicians thread wrote, “The real complexity is in the evaluator.” Another person summed up the broader problem as, “Everyone checks the pay, but no one checks the work.”
These observations point to structural dynamics in open agent markets. In other words, those who control valuations control the market.
The design of the specs makes the tension clear.
For enterprise deployments where the client and evaluator are the same entity, complexity is manageable. In a multiparty agent network where a provider in one organization sends work to a client in another organization, platform-level leverage makes the evaluator the trust bottleneck.
ERC-8183 names a choke point without having a permanent answer to it yet.
Where the stack actually resides
Adoption numbers suggest surrounding layers are moving faster than validation.
According to Gartner, by 2028, 33% of enterprise software applications will include agent AI, and 15% of daily business decisions will be performed autonomously by the same year, up from 0% in 2024.
Deloitte predicts the global agent AI market will be worth $8.5 billion in 2026, rising to $35 billion by 2030, with 75% of companies likely to invest in the space by the end of this year.
In January, IBM and NRF reported that 45% of consumers are already using AI in the purchasing process, including 41% for product research.
This amount of agent activity requires a payment infrastructure.
The bull case for ERC-8183 and its surrounding stack is that open agent marketplaces covering research, code, inference, data, and microservices will generate enough cross-organizational machine-to-machine commerce that on-chain conditional payments will become truly necessary.
The bear case is that existing payment companies and enterprise software absorb validation issues before cryptocurrencies build a durable wedge.
AP2’s encryption mandate, Verifiable Intent’s authentication audit trail, and UCP’s live retailer integration already position card networks and Big Tech to be exactly the demographic that ERC-8183 is targeting from the opposite direction.
Who owns the Judgment Layer?
If Gartner’s 2028 predictions hold true and agent AI handles a significant portion of enterprise sourcing, research outsourcing, and service purchasing, the most profitable positions in that stack will no longer be held by model providers.
It will belong to those who own the conditional payment moment, an infrastructure that holds funds, proves accomplishments, and releases money only if the work passes validation.
ERC-8183 could be that layer. Or it could be a marketplace escrow that wears a better brand.
The Magicians thread is correct in that the underlying structure is completely older than AI. But the same is true for most financial primitives that turn out to be important.
Escrow has been around since before the internet. Conditional payments predate blockchain.
What is currently being stress tested in theory is whether validation problems in agent commerce are best solved by Big Tech authorization standards or by programmable on-chain escrow with a configurable trust layer.
Both approaches are in practice, and neither is settled. The answer likely depends on where agents are doing the work that makes the most economic sense when adoption crosses a threshold that merits an infrastructure fight.
