DEV Community: Nikos Schoinas

Who pays when the AI hires another AI?

Nikos Schoinas — Fri, 12 Jun 2026 18:48:05 +0000

The moment agent-to-agent commerce stopped being theoretical, what Anthropic's Project Deal actually showed, and the three questions about attribution, authorization, and audit that will determine whether the agent economy is legible to anyone after the fact.

Introduction

A research agent has been set up to deliver a morning briefing. Its owner configured it once, on a Thursday in March, and asked it to pull together a summary of relevant news every day at 8am. On a particular morning, the agent encounters a French financial document. It has no translation capability of its own, so it delegates: it calls a translation service, which returns the text, but that service, before responding, calls a grammar-normalization API to tighten the output. Three agents. Two payments. One human, asleep.

At 8am, a summary arrives in the owner's inbox. It is good. The French document is accurately rendered. Somewhere in the background, small amounts of real money have moved. The owner approved agent A. Agent A hired agent B. Agent B called agent C. At what point in that chain did "the owner's money" become "this third-party service's revenue," and who was watching?

The interesting question here is not whether this works. It does. The interesting question is who actually authorized those payments and whether, if something went wrong, anyone could prove it.

This is older than you think

The concept of one party hiring another to act on their behalf has a name in law: agency. The concept of a principal delegating authority to an agent, who can then further delegate to sub-agents, goes back at least to Roman commercial law. English courts were sorting out privity chains in construction contracts by the nineteenth century. The question of what happens when a contractor hires a subcontractor who causes a harm, and who is liable to whom, and what documentation proves it, is genuinely settled doctrine in most common-law jurisdictions.

None of that doctrine breaks down because the "agents" are software. What breaks down is the audit infrastructure it relies on.

Traditional subcontractor law assumes a paper trail: contracts, purchase orders, signed delivery receipts, invoices. Each step in the chain produces a document that a court can later examine to reconstruct what was agreed, what was delivered, and what was paid. When disputes arise, the evidence exists.

Agent chains do not produce documents by default. They produce logs, if anyone thought to configure logging, and API call records, if the underlying services store them, and maybe a database row somewhere. What they do not produce automatically is a durable, tamper-resistant record of the form: at this moment, this principal authorized this sub-agent to spend up to this amount, for this purpose, and here is the cryptographic proof.

The velocity is also different. A construction subcontractor chain might involve six parties over six months. An agent chain can involve six parties over six milliseconds. The audit machinery that legal systems assume, the time to notice, the time to object, the time to stop a transaction that looks wrong, does not fit that tempo.

December 2025: somebody actually ran the experiment

In December 2025, Anthropic ran an experiment that most coverage described as a curiosity. They recruited 69 of their San Francisco employees, gave each of them a $100 budget (paid out afterward in the form of a gift card, adjusted for net gains or losses), and listed their personal belongings on a classified marketplace. Then they handed the whole thing to Claude.

The agents, running in four parallel Slack channels, were given no further instruction after setup. They posted listings. They messaged counterparts. They haggled. They closed deals. No human approved anything mid-run. By the time the experiment concluded, the 69 agents had struck 186 deals across more than 500 listings, for a total transaction value of just over $4,000.

A few details stand out. The first is that the agents did not just comply. They negotiated. They offered discounts, bundled items, and passed on deals that did not meet their owner's unstated preferences. The TechCrunch account describes agents holding firm on prices and walking away from counteroffers. Whatever one thinks of the experiment's scale, the agents behaved like buyers and sellers, not like forms.

The second detail is about model capability and its financial consequences. Agents running Claude Opus 4.5 secured better outcomes than agents running Haiku 4.5; Opus sellers earned $2.68 more per item on average. This is a new kind of economic inequality: not "which human negotiator did you hire" but "which model did your agent run on." The model choice has a direct dollar outcome.

The third detail is the one that matters most here. Forty-six percent of participants said, after the experiment, that they would pay for a service like this. That number is not large. But the people saying it had just watched their agents spend their actual money on their behalf, without their involvement, and came out satisfied. That is a different kind of endorsement than a hypothetical survey.

Project Deal worked because the ownership structure was simple: one employee, one agent, one budget, one marketplace. Every payment traced back to a named human who had pre-funded it. The experiment didn't surface the hard questions because the setup didn't require a delegation chain. When the chain gets longer, three specific problems appear.

The three questions that don't have clean answers yet

Attribution. In a multi-agent workflow, cost allocation is genuinely difficult. When a task runs across fifteen specialized agents, a planner, a researcher, a writer, a fact-checker, a formatter, and the total spend comes in at twice the expected figure, isolating which agent was responsible is not straightforward. Standard tooling doesn't show it. The problem compounds when agents are not all calling a single LLM API but are instead calling paid external services: a data provider here, a translation service there, a grammar check, a domain lookup. Each call costs something. The costs aggregate. The lineage, without deliberate instrumentation, disappears.

Authorization. The delegation problem is harder. If you give agent A a $5 cap and agent A decides the task requires hiring agent B, does agent B inherit that cap, or does it get a fresh budget? Both answers break something. If B inherits the cap, A and B are now competing over the same $5, which may not be enough for either. If B gets a new budget, the human's $5 limit is meaningless: A can hire B, B can hire C, and the total spend across the chain can exceed what the human ever intended to authorize. The only coherent solution is something like a draw receipt: a signed document, issued at each delegation step, that records "I am delegating up to X of my remaining budget to the next agent, for this purpose, expiring at this time." (Full disclosure: this is the problem I work on. Routeweiler implements this pattern with Ed25519-signed budget envelopes for HTTP 402 payments specifically.) Each step in the chain produces an artefact that proves the principal chain and the remaining authorization.

Audit. The Berkeley Technology Law Journal noted in June 2026 that multi-agent liability frameworks are already lagging multi-agent deployments. The specific problem: without a record of what instructions and data passed between agents at each handoff, a plaintiff faces a near-impossible task establishing which agent in the chain caused a harm. The evidence problem is worse when agents are deployed across multiple vendors and jurisdictions, which is already common. A chat log is not a receipt. An API call record is not a contract. What an audit layer requires is a tamper-resistant chain of artefacts that proves, at each step, who authorized this, on whose behalf, up to what amount, and when did the authorization expire. That chain does not exist by default.

What the infrastructure builders are converging on

The payment infrastructure being built for agent commerce is arriving from different directions, but landing on the same primitive.

Coinbase's x402 protocol requires a signed authorization header on every payment request. Stripe's Shared Payment Token, launched in March 2026, issues a scoped credential tied to a specific merchant, amount, and expiry window. Mastercard's Agent Pay framework uses tokenized credentials that an agent can present without the underlying card number leaving the issuing account. Fetch.ai's network of approximately 3 million registered agents uses FET tokens as the unit of exchange, with per-agent identity built into the protocol layer.

The pattern is consistent. None of these frameworks say "give the agent a credit card." All of them say "give the agent a token that is scoped, expiring, and revocable." The credential travels with the payment. The credential is the authorization record.

This matters because a scoped token can carry provenance. It can encode: this token was issued by principal P, delegated to agent A, further delegated to agent B, for use with merchant M, for amounts up to X, expiring at timestamp T. When the token is settled, the full delegation chain is embedded in the transaction record. The audit trail is not a separate database to maintain; it is baked into the payment credential.

Whether this primitive extends cleanly to multi-hop delegation, where the token itself needs to be sub-divided and re-scoped at each step, is still being worked out. But the direction is clear. The credential is doing the work that a signed contract does in a paper-based subcontractor chain.

The part nobody has solved

The audit layer is advancing. The legal layer is not.

As of May 2026, US consumers have no statutory dispute rights when AI agents transact on their behalf. The Electronic Fund Transfer Act and the Fair Credit Billing Act were written for human-initiated transactions. They do not map onto a world where a chain of autonomous agents exchanges real money without any point of human review. If an agent overspends, or is defrauded, or delegates to a sub-agent that misbehaves, there is no chargeback button.

Liability for multi-agent harms is in a similar position. Courts have not established doctrine for a scenario where agent A hired agent B which called agent C, and agent C caused a loss. The closest analogy is vicarious liability in employment law, which generally holds employers responsible for employees acting within the scope of their role. But that doctrine assumes identifiable principals, written contracts, and some level of human supervision in the chain. It does not cleanly extend to fully autonomous delegation across vendors.

Cryptographic receipts solve a narrow problem: they let you prove what happened. They do not assign responsibility for what happened. An audit trail showing "agent A authorized agent B to spend $3.50 between 09:14:02 and 09:14:07 UTC" is genuinely useful to a court. But the court still needs a doctrine to decide what that chain means for liability. We are building the evidence layer ahead of the legal framework that will interpret it.

Where this ends up

Project Deal settled one question. Agents can transact with other agents, on behalf of humans who trust them with real money, and do it well enough that nearly half of those humans would pay for the service.

The question it opened is the one that will define the next five years. Not "can agents pay each other" but "can we reconstruct, after the fact, what they agreed to and on whose authority they agreed to it?" The agent economy runs on delegation. Delegation runs on authorization records. Authorization records require infrastructure that most current deployments do not have.

When it does exist, a lawyer examining an agent-to-agent dispute will pull a chain of signed receipts the way a construction attorney today pulls a chain of signed contracts. The signed receipt will be the unit of trust. We are in the period where people are building the equivalent of a deed registry, before anyone has fully decided what the deeds should say.

That is the actual frontier. Not the agents. The paperwork the agents leave behind.

The authorization and budget-envelope problem mentioned in the Authorization section above is what Routeweiler addresses for Python agents making HTTP 402 payments, if you want to see a working implementation of scoped draw receipts across four payment rails.

Why HTTP 402 slept for 29 years, and what finally woke it up

Nikos Schoinas — Sun, 07 Jun 2026 11:06:07 +0000

Imagine the following scenario: An AI agent calls a paid API. The server replies 402 Payment Required. The agent parses the challenge buried in the X-Payment-Requirements and does a sequence of actions to pay. The server replies 200 OK. The whole sequence takes 1.3 seconds.

That might sound unremarkable. It isn't.

For 29 years, HTTP had a status code designed for exactly this: "pay me, and I'll serve you." RFC 2068, published in January 1997, reserved 402 for "a future payment system." The future never arrived. That status code sat unused for so long that most browsers today don't even know what to display when they see it. They fall through to a generic 4xx error page, because nothing has ever needed it to work.

Until last year, when separate companies/projects decided, within eighteen months of each other, that it was time.

The story of why this happened now, and not in 1999 or 2012 or 2019, is actually interesting, and it has almost nothing to do with blockchain or AI being "hot." The reason is more specific, and more surprising.

The 29-year nap, told accurately

The why behind the dormancy is more interesting than the number.

The obstacle was never technical. It was human.

The first serious attempt to make tiny online payments a real thing was DigiCash, David Chaum's electronic cash company. Chaum understood the problem (digital money, independent of banks, spendable online) better than almost anyone in the 1990s. DigiCash required users to install software, load a wallet, and consciously authorize each purchase. For all its cleverness, it asked people to think before every click. It filed for bankruptcy in 1998.

Then came Flattr (2010), which asked you to fund a monthly tip budget and distribute it across sites you visited. Elegant in theory; tiny in adoption.

Bitcoin looked like it might thread the needle. The amounts were small enough to feel costless, wallets were improving, and the UX was close enough to "just send it." Then Bitcoin became a speculative asset and the micropayment use case got trampled by the investment potential.

The pattern across three decades: every attempt hit the same wall. Call it the consent friction problem. The question every micropayment system has to answer is: will a person consciously approve a sub-dollar payment, before receiving the thing they're paying for, fast enough that the experience feels acceptable?

The answer, every single time, was no. Not consistently, not at scale.

Humans have a revealed preference: they would rather give their credit card number once, subscribe to something monthly, and receive unlimited access (even if that means overpaying) than stop and approve tiny transactions on demand. The paywalled web, Spotify, Netflix: all of them are elaborate workarounds for the fact that per-request payment has never worked for human users.

So HTTP 402 sat. Not because nobody tried. Because the entity that needed to do the paying was always a human, and humans have friction.

What actually changed

Two things shifted between 2024 and 2026. Neither made enough noise.

The first was unit economics. Before Layer-2 chains, making a payment on Ethereum cost roughly $0.30 in gas fees. That made per-request pricing economically ridiculous for anything under a few dollars. On Base today, the same payment costs less than half a cent. Stablecoins solved the asset volatility problem, while Layer-2s solved the fee bottleneck. The combination meant, for the first time, that charging $0.005 per API call was not a rounding error on both sides.

The second change is the one that matters more, and it is the one that reframes everything: the client changed.

AI agents, software that calls external APIs autonomously, without a human in the approval loop for each request, started running at real scale in 2024 and 2025. And agents have a property humans never had: they can authorise payments pre-emptively, within a policy, without pausing.

You give an agent a budget of $5. You tell it to call whatever endpoints it needs to complete the task. The agent handles the payment on each 402 response automatically, within the cap you set.

This dissolves the 29-year problem entirely. Every failed micropayment system assumed a human in the loop. Every human-in-the-loop system hit consent friction. The question was never "can we build a payment protocol". We had those. The question was "can we get a human to approve a tiny payment fast enough that they don't resend it?" And the answer was always no.

The agent removes the human from the loop. The problem that stopped 402 from working was not a protocol problem. It was an interface problem. The agent turns out to be the interface 402 was written for. The client that doesn't flinch at a $0.01 authorization.

A few protocols, all in production

In the space of about six months — October 2025 to March 2026 — many protocols shipped that all do roughly the same thing. They are not compatible with each other. They are also not interchangeable: each makes different tradeoffs that make it the right call for a different context. Here are four examples:

x402

Coinbase launched x402 in October 2025, with V2 following in December. The wire format is JSON: the server returns a 402 with a header that carries the required amount in USDC, the payee's address, the chain, and a nonce. The client constructs an EIP-3009 transferWithAuthorization signature, a meta-transaction that pre authorises a specific transfer without broadcasting anything to the chain, and includes it in the retry header. Coinbase's facilitator verifies the signature and settles the transfer on Base before handing the response back to the origin server.

The numbers that came out in early 2026 were large. As of April, approximately 69,000 active agents have processed over 165 million transactions totalling $50 million in volume, with nearly half a million payments in a single peak week. The x402 Foundation now includes Visa, Google, AWS, Anthropic, Circle, Cloudflare, and Vercel. Cloudflare has support built into their infrastructure products. This is not a whitepaper.

The practical running system depends on Coinbase' facilitator. That is an operational convenience, and it is also a centralisation point, something the Coindesk reporting from March 2026 called out directly. Demand for decentralised alternatives exists.

L402

This is the one that the agent payments community almost never talks about, which is strange because it predates x402 by five years.

Lightning Labs introduced the protocol in 2020, initially as LSAT (Lightning Service Authentication Token), renamed L402 in 2024. The mechanism: the server returns a 402 with a WWW-Authenticate: L402 header carrying two things: a macaroon (a structured, delegatable credential that can encode caveats about scope, time, and spending limits) and a BOLT-11 Lightning invoice. The client pays the invoice over the Lightning Network, receives a 128-bit payment preimage as proof, and re-sends the request with Authorization: L402 <macaroon>:<preimage_hex>.

The preimage is the interesting part. It is cryptographic proof that the Lightning payment settled. The payment is unforgeable, tied to that specific invoice, verifiable locally without any chain lookup. For applications where auditability matters, this is cleaner than reading transaction data off a blockchain.

The granularity is also striking: 1 satoshi is roughly $0.0007 at current prices. You can price an API call at a fraction of a cent and have the maths work cleanly.

The honest limitation is operational. Running a Lightning node is real work. Channel liquidity, peer selection, uptime — not insurmountable, but not nothing either. Most AI startups will not spin up an LND instance for this. L402 is technically elegant and, for now, aimed at an audience that has already decided Lightning is worth the operational cost.

Stripe MPP-SPT

Stripe's Shared Payment Token, launched in March 2026, deserves a small caveat up front: it is not quite an HTTP 402 protocol in the same way as x402 and L402.

An SPT is a payment credential issued by a user (or by an agent on the user's behalf) that is scoped to a specific merchant, capped at a specific amount, and set to expire within minutes. When the agent presents the token at checkout, the merchant redeems it via a standard Stripe PaymentIntent. The underlying payment method — credit card, bank account, BNPL — never leaves the user's wallet. The card number is never shared with the merchant. Stripe
mediates the transfer.

The 402 pattern fits on top: the server can return a 402 with SPT requirements; the client mints a token with the appropriate scope and retries. But the architecture underneath is card networks and Stripe infrastructure, not a blockchain signature or a Lightning preimage.

This is exactly what makes it interesting for a different audience. A finance team that wants AI agents to spend company money on approved suppliers, with hard spending caps, merchant restrictions, and short expiry windows, does not want stablecoins. They want a credential tied to a payment method they already control, which they can revoke from a dashboard if something
goes wrong.

MPP-Tempo

The newest of the four, also shipping in March 2026, is MPP-Tempo: a stablecoin payment rail on a chain built specifically for machine-to-machine transactions.

Where x402 repurposed EIP-3009 from general-purpose Ethereum, and L402 repurposed BOLT-11 from Lightning, Tempo built its transaction format (EIP-2718 type 0x76) from scratch with per-request economics in mind. The MPP shared helper layer, a common header format that both Tempo and SPT use, sits on top and makes the 402 challenge/retry flow consistent regardless of
which backing rail is active.

The interface is the standard; the rail is the implementation

Read the protocol wars coverage (AP2 vs. ACP vs. x402 vs. MPP, the fragmented standards landscape, the thirty-plus competing proposals) and you might conclude that choosing any of these today is a bet you will probably lose.

That's partially right. What I think is more useful is to notice what all four of them share.

Every 402 system uses the same HTTP idiom: the server issues a challenge, the client returns proof. The challenge format differs, e.g. JSON headers, macaroon-plus-invoice pairs, SPT requirements, Tempo transaction descriptors. The proof format differs, e.g. EIP-3009 signatures, Lightning preimages, Stripe tokens, Tempo transactions. But the HTTP structure is identical: 402 Payment Required on the first request, a credential in the Authorization header on the retry, 200 OK on success.

This is not a coincidence. It is the WWW-Authenticate / Authorization challenge-response pattern. It's the same one that has handled API authentication since the late 1990s. The machine-to-machine payment problem, once you strip
away its cryptocurrency context, turns out to be a variant of an authentication problem where the credential is proof of payment rather than proof of identity. The primitives that handle auth for every API you have ever built also handle payment, if the client knows how to generate the right header.

This reframes the question of which rail to use. The interface, i.e. HTTP 402, a structured challenge, a retry with a proof credential, is already converging. The rails are competing implementations of the same interface. An implementations can be swapped out. A client that speaks the 402 challenge pattern can learn a new rail without breaking. (Full disclosure: this is the exact bet I made when I built Routeweiler, a Python library that handles the four rails behind a single HTTP surface. I mention it because it highlights the concept clearly, i.e. we can successfully separate how a payment looks from how it actually processes. No intention to prompt anyone reading this to install it.)

I am not confident which rail will dominate five years from now. Possibly all four survive in different verticals: x402 for crypto-native data APIs, L402 for Lightning-native services, SPT for mainstream retail and enterprise procurement, Tempo for high-throughput machine applications with purpose-built economics. Possibly one absorbs the others, or a fifth protocol nobody has written yet wins the whole thing.

What I feel more confident about is that HTTP 402 itself is now load-bearing for the first time. In 2030, developers will look at agent logs, see 402 → 200, and think nothing of it, the same way nobody today thinks about the TCP handshake that preceded every web page they have ever loaded.

The status code that spent 29 years as a placeholder for a future nobody finally has its moment. The missing piece was never the protocol. It was a client that doesn't flinch at a $0.005 charge before it checks out.

*One footnote: implementing adapters for all four of these got repetitive quickly. Routeweiler is an open-source Python client that handles them behind a single
await client.get(url). Worth a look if you want to skip writing the EIP-3009 signing yourself.