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.
Top comments (0)