Here's the core problem: agents are being forced to download a mountain of data to derive answers the data source should have provided directly.

We did an experiment to show how serious this problem is.

The experiment

We used a Mycelium network (an experimental data layer that returns derived stats instead of raw rows) to run these tests.

Imagine an AI agent that needs one career baseball stat. Hank Aaron's career home runs or Nolan Ryan's ERA, WHIP, or strikeouts per nine.

In the traditional raw-data model the agent doesn't get the answer. It gets every season row required to compute the answer itself, dumped as JSON.

In the derivative model the agent asks for the finished number and receives one value.

We ran this on the full historic Lahman baseball database using Hank Aaron and Nolan Ryan. Token counts came from OpenAI's cl100k_base tokenizer on the actual JSON payloads an agent would see. The DIY side only received the minimum columns needed for each calculation. That is the generous case for raw data.

The results were not ambiguous.

The numbers

Same pattern for simple sums, fixed rate formulas, and LLM-derived stats. Ten pre-defined stats cost 6,074 tokens when fetched separately versus 213 tokens when the source returned the finished answers (96% savings). Eight derived stats cost 6,402 versus 182 (97% savings).

The bigger picture

• Separate fetches for all 18 example stats: 12,476 tokens and 439 season rows.
• One derived answer per stat: 395 tokens.
• Savings: 12,081 tokens (97%).

Even a smart client that reuses three shared pulls (Aaron batting + Ryan pitching + Aaron fielding) still burns 3,854 tokens. Mycelium stays at 395. That's still a 90% cut.

And remember, these numbers already give raw data the benefit of the doubt. Full database rows typically cost two to three times more.

Why this matters

Agents can compute batting average or OPS. But they shouldn't have to. When a thousand agents all want the same deterministic result, making every one of them re-download the same rows and redo the same math isn't flexibility. It's pure waste.

Think of it this way: if a robot asks for a screwdriver, handing it a mine, a smelter, and a steel mill is technically complete, but practically insane. Raw records are the ore. Derivative data is the screwdriver.

A serious data source shouldn't stop at exposing raw data. It should also return derivative data that agents request. These derivative results aren't approximations, they are exact, relative to the source records and the derivation logic. A well-designed system can optionally return the provenance so any client can audit the answer.

Traditional data interfaces were built for expensive human analysts. Agents are cheap and they arrive in volume. 97% fewer tokens is not a nice-to-have. It is the difference between a data source that scales and one that quietly bankrupts its clients.

Agents work differently. An agent asks a question, gets an answer, and acts on it. When you hand an agent raw blocks, logs, and traces, you push the pipeline's work into the agent itself. It has to load a large amount of data into context and reason across all of it to reach a single number.

The cost shows up twice

Raw data costs an agent twice. It pays once to read the data into context, and again to reason over that context to produce a result. A question like "how did USDC transfer volume change over the past year" can pull millions of events into the model to return one figure. The answer is slow and expensive, and you cannot reliably reproduce it. Ask the same question twice and you can get two different numbers.

Ask for the answer instead

Testril takes a different approach. You ask a question in plain language over CLI or MCP, and you get the answer back. If we have computed it before, we serve it from cache. If we have not, we compute it on demand. The agent never holds the raw data in context.

This keeps the token cost per answer low, and a single question can span many chains instead of stopping at one. Because every value traces back to the blocks it came from, the agent can also confirm the answer is right before it acts on it.

Raw data is the input to a pipeline. An agent wants the output of one.

That kind of trust does not scale to systems that run on their own. So we made provenance part of every answer instead of a feature you request separately.

What provenance means here

For any value Testril returns, you can ask where it came from. We report the source events, the block range, the transformation we applied, and the latest block the answer reflects. The number and the record of how we produced it stay together.

Why computing on demand helps

Testril computes answers from indexed source data rather than serving tables built in advance. Because we run the computation when you ask, the full path from source block to final value is always available, and we can replay it. Nothing sits between the chain and the result that we cannot account for.

This has a useful side effect. Two agents that ask the same question get the same answer, and both can trace it back to the same blocks.

Verifiable by construction

Self-describing JSON tells an agent the shape of a result. A provenance request tells it where the result came from. Together they let an agent confirm an answer before acting on it. That is the point of giving agents data they can reason about rather than data they have to take on faith.

So Testril quotes the request first.

The quote comes before the work

When you ask Testril for something, it prices the request up front. You see what the data will cost and what it takes to produce before any block is read. Nothing runs until you accept the quote.

For a system that spends its own money, this matters. The agent can weigh the cost against the value of the answer, decide, and only then commit. There are no runaway jobs and no charges for work it did not want.

Paying over the right rail

When the agent accepts, it pays over rails built for software, x402 and MPP, and the data comes back as self-describing JSON. Every step of the exchange is readable by a machine. The agent asks, sees a price, pays, receives the data, and can verify it.

Quoting before computing makes the cost predictable, and it makes per-query data safe to hand to an agent that pays for its own requests.

That only works if the payment rail is built for software.

x402

x402 takes an old idea and makes it usable. The HTTP status "402 Payment Required" becomes a real flow. A request arrives, the server responds with a price, the client pays, and the request completes. There are no accounts to set up and no invoices to reconcile. The payment happens inside the same request and response the client was already making.

For an agent, this fits well. It can learn the price, decide, and pay in one exchange.

MPP

MPP covers the wider path for machine-to-machine payment. It defines how a client settles an agreed amount for a specific piece of work. Combined with an up-front quote, it turns a data request into a clean transaction with an agreed price and a settled payment.

Why per-request pricing fits agents

A subscription cannot say that one specific answer is worth one specific amount. Per-request pricing can. The agent asks, receives a quote, and pays for exactly what it uses. Testril supports x402 and MPP so that exchange works without extra steps, which is why we price every request before it runs.