Eleven of my sixteen paying customers were running the example.

The hypothesis

Tereno was built to test one sentence: autonomous agents will repeatedly buy specialized micro-capabilities when those calls reduce total decision cost, execution friction or the chance of a bad action.

Everything else was in service of that. Eight capabilities on Base, priced from a tenth of a cent to three cents, paid over x402. A shared cache so the second buyer of a deterministic answer pays less than the first. A private path for anything tied to one agent's intent, never cached and never resold. ERC-8004 identities, receipts on every call, evidence artifacts with declared validity windows. It works. That was never the question.

The question was whether anyone needed it. The metric was deliberately harsh: a second full-price paid invocation by the same wallet, at least twenty-four hours after its previous one. Not volume. Not unique wallets. Not attention. Someone coming back.

What the dashboard said

Over ninety days: thirty-two settled invocations, sixteen unique paying wallets, twenty-nine cents of gross revenue, and a second-day repeat rate of 12.5 percent. Availability at 100 percent, median response under half a second. Thin, but the shape looked like a market that had not found its buyer yet.

I spent months reading that number as a distribution problem. Sixteen wallets found it and paid. The work was to find more of them.

The field that ended it

Every invocation in the ledger carries an input hash. It is not a hash of the request body. It covers the normalized input plus the capability version plus the network, because it is the cache key: two calls sharing one are entitled to share an answer.

I had never grouped the ledger by it. When I did, thirty-two settled calls resolved to ten distinct inputs. Two of those ten accounted for nineteen calls across thirteen different wallets.

Wallets do not collide on a byte-identical input by coincidence. They collide when they run the same example. Seven independent buyers checking contracts they cared about would have produced roughly seven distinct inputs. They produced one.

Eleven of sixteen wallets never sent an input that some other wallet had not already sent.

Five wallets arrived with a question of their own. One of those five came back after the twenty-four hour gate carrying its own question. That is the entire measured demand, and I had been reporting it as sixteen.

Trying to break it

A negative result is easier to reach than it should be, so before recording one I wrote the counter-arguments as tests and ran them against the same ledger. They ship as a page in the operator console and recompute on every load, which means they can turn on me later.

• 01Were those wallets real buyers who happened to care about the same popular contract? Asking whether they later branched would be circular, since they are defined by not having. The non-circular question is concentration: eleven wallets produced two distinct inputs between them. Independent subject choice predicts on the order of eleven. Survives.
• 02Was the price the constraint? The capability that reached the most wallets was also among the cheapest, and it carried the lowest share of wallets asking their own question. If price gated demand, that relationship would run the other way. Survives, inside a range that never exceeds three cents.
• 03Did the cheap chain-data capabilities drown out real demand for the decision capabilities? Splitting the two families leaves four wallets with their own question on the decision side and two on the data side. Neither is a market. Survives.
• 04Is ninety days simply too short? Nothing internal settles this. Undecidable, and it is the reason the verdict says not demonstrated rather than refuted.
• 05Does measuring only wallets that already held funded USDC hide a larger population blocked upstream? It does, and that population cannot be sized from here. But everyone measured cleared wallet, funding, network and discovery, so they are the most motivated cohort the funnel can produce. Their return rate is a ceiling, not an average. Removing an upstream barrier brings in a less motivated cohort, which predicts a lower rate rather than a higher one. Survives for retention only.

The part that was structural

One test refused to resolve, and it is the one that taught me the most. Months ago I wrote in the signal log that the right buyer was probably a trading agent on Base, and that it had not arrived. I treated that as a timing problem.

It was not. The economics of this design make a cached answer cheaper precisely because other agents also hold it. To a buyer whose margin comes from holding information others lack, an answer that is widely held is worth nothing. The mechanism I spent the most care on is structurally incompatible with the buyer I kept waiting for. That buyer was never going to arrive at this counter.

The argument only reaches that far, and saying so is the point. It explains why an alpha-seeking buyer would not pay for a shared answer. It says nothing about a wallet interface, a custody desk or a compliance function, for whom a widely held answer is worth exactly as much as a private one. None of those were ever approached. That is reasoning, not evidence, and it sits in the console labelled as such.

What was actually demonstrated

Machine-to-machine settlement works end to end. Thirty-two paid invocations were discovered, quoted, paid, served and receipted with no human in the loop, at full availability. Verifiable work can be priced, cached and reused across wallets without exposing a private decision. Those are real findings and they are not what I set out to prove.

What was not demonstrated is that agents arrive with a question of their own and come back. Across every settled call on record, one wallet did.

What was never tested is whether a human-operated buyer with an existing budget line would pay for exactly these answers. Nothing here was ever offered to one. That is a gap in the experiment, not a finding of it.

Why write this down

An experiment that produces a result and never records it keeps consuming decisions forever. I know, because this one did that to me for weeks while I looked for the next feature to build.

So the verdict lives in the console rather than in a document, computed from the ledger on every load, next to a reopen trigger stated in advance: a wallet that is not ours recording three or more full-price settlements on inputs nobody else sent, with at least twenty-four hours between each. That is one query against the same table. If it ever returns rows, the page changes its own mind without my help.

This is not a claim that agent-to-agent commerce will not happen. It is one operator, one narrow product, one live ledger, reporting that it did not happen here yet, with the numbers attached and the counter-arguments run in public. There is a lot of writing about this market and very little of it carries a denominator.

Every figure above recomputes from capability_invocations at read time. The falsification tests, the wallet table and the reopen trigger are a page in the operator console, not a snapshot pasted into a post.