← Writing
August 28, 2026 · 5 min read

We asked one question two ways and published the logs

A governed run and an ungoverned run against the same production question. One returned the answer in 14.4 seconds. The other spent more and returned nothing.

On 23 August 2026 we took a production question we actually needed answered and asked it twice in the same afternoon. Once as a single governed call through the RailCall MCP station. Once through an agent with ordinary web browsing tools and no governed path to the data. Both runs were filmed. Both transcripts are published.

14.4 s
Governed lane, end to end: one governed MCP call, the whole signed answer returned, $0.129 for the session
MEASURED · N=1 · 23 AUG 2026
0 rows
Ungoverned lane, after 70 s and 8 browsing turns: $0.170 for the session, nothing returned
MEASURED · N=1 · 23 AUG 2026

The governed session burned 88,358 tokens counting input, cache reads and output. The browsing session burned 221,794 and finished with an empty result set. The governed call left receipt rcpt_7147f18c behind it.

The sample size is one, and the baseline failed

Before anything else: this is one recorded pair. One question, one day, one model configuration, run by the people who built one of the two lanes. It is not a study. Nothing you could generalize from it has been earned.

The second problem is worse than the sample size, and it is the one that would get this post taken apart if we left it out. The two dollar figures are not comparable. The $0.129 bought an answer. The $0.170 bought an attempt that came back empty. That is cost-per-success against cost-per-attempt, which is the weakest shape a benchmark can have. Had we re-run the browsing lane until it landed the rows, its real cost would be some multiple of $0.170, and we cannot tell you the multiple because we did not run it. A comparison whose headline only survives an inattentive reader is not worth publishing, so we are saying it here rather than waiting for someone else to.

What we did not measure: repeated trials of either lane, variance across question shapes, other agent configurations, or whether the browsing lane succeeds on a second attempt. One filmed pair is the whole dataset.

What the run does establish

Something narrower, and still worth the tape: the governed path was not the slow path. That is the assumption governance tooling normally has to argue its way out of. The expectation is that approval gates, policy evaluation and a signed receipt sit on top of every call as a tax you pay in seconds. In this run they did not show up on the clock at all.

The reason is not subtle. The governed lane made one call to a tool that already knew where the data lived, and the whole answer came back signed. The other lane spent its 70 seconds and its eight turns rediscovering that. The dominant cost was search, not governance. Governance was in the path the entire time.

That is a statement about one run, not a law. It does not show that governed calls are free. It shows that in this case the overhead was small enough to vanish underneath everything else the agent was doing. We have not characterized the governed path across many question shapes, and we are not going to imply that we have.

The number that compounds

The race is the part people share. The durable number is the boring one underneath it. Most agent work is re-asking: the same question, minutes later, to see whether anything moved. RailCall read-only tools hand back a state token with the payload. Pass the token on the next identical call, and if nothing has changed you get a not-modified answer instead of the data.

// first ask — the payload, plus a state token
{ "rows": [ ... ], "state": "<opaque token>" }

// same ask again — hand the token back
{ "if_state": "<opaque token>" }
-> { "not_modified": true }
~40 tokens
Repeat of the unchanged question, answered from a state token instead of re-fetching a payload we estimate at ~2,400 tokens
MEASURED DELTA · PAYLOAD ESTIMATED · 23 AUG 2026

Note the basis line on that one. The 40 tokens is measured. The 2,400 is an estimate of the payload we did not fetch, because we did not instrument the counterfactual on the day, and a number without its basis is not something we put on a page.

Even estimated, that ratio outlives the race. A one-off comparison is a headline. A cheap re-ask is a property of the architecture, and it applies to the tenth poll of the day as much as the first. If your agents watch state on a loop, and most useful ones do, that is where the spend actually is.

Why we published the logs

A receipt you cannot check is a claim. We could have written the two numbers into a slide and asked you to take them. That is the structural problem with a vendor-run benchmark: the only people positioned to check it are the people who benefit from it.

So the run went out with its evidence attached.

  • The transcripts of both lanes, including the eight browsing turns that failed.
  • The signed receipt for the governed call, rcpt_7147f18c, in the hash-chained log.
  • Verification that runs offline, without an account and without calling back to us, so checking our work does not require telling us you are checking it.

None of that makes the sample size larger. It makes the sample honest. If the 14.4 seconds is wrong, or the receipt does not verify, or the chain does not hold, the log is where you would catch us. We would rather ship a small result you can falsify than a large one you have to believe.

Every governed action RailCall runs emits an Ed25519-signed receipt into a hash-chained log. You can verify one offline at railcall.ai/verify — no account, no login, and nothing calls back to us.