Compression was the easy part.
We gave six agent problems four different ways of handing work from one agent to the next. Cutting the tokens worked: 72.1% fewer than an uncompressed control, and the best code in the set. Delivering what each agent asked for did not — on research fan-out, the case we sell this for, between 0.49 and 0.66 of the declared material arrived and the answers came last of the four. The workload we save most on is the workload we answer worst on, and the cause is measurable rather than mysterious.
Four ways to give an agent what the last agent produced.
Every multi-agent system has to answer one question over and over: when this agent finishes, what does the next one get to see? There are only a few honest answers, and we wanted them measured against each other rather than argued about.
| Regime | What each agent receives | What it is charged for |
|---|---|---|
| broadcast control | The whole shared corpus, every agent, every round. | Everything it reads. |
| curated | Only the artifacts a person tagged for that step, configured per problem by hand. | What it reads. No overhead. |
| json-extract | A structured summary of the previous step, produced by an extra model call. | What it reads, plus the extraction calls. |
| recall-tuned Tileward | What it asks the live Tileward Context store for. | What it reads, plus every token of ingest. |
Six problems — three coding pipelines, three research fan-outs — each ran through all four regimes inside a single invocation, so the comparison lives within one run rather than across sessions. Answers came from gpt-oss-120b, a model we serve exactly as its publisher shipped it and did not compress, through the same public API path a customer uses. Token counts come from a tokenizer rather than an estimator: the counter is the model that answered, chat template applied. Coding pipelines run seven steps; research fan-outs run eight agents, five of them gathering in parallel, over a shared corpus of roughly 49,000 tokens.
Everything below is one run of six agent problems. It is not the same measurement as the conversation figures published on Tileward Context — those are live single-threaded conversations across Claude Desktop and Claude Code, a different workload on a different population. Neither set of numbers predicts the other, and they should not be quoted together.
Cost, quality and latency did not move together.
This is the whole result on one screen. The rest of the post is an argument about which column you should care about.
| Regime | Billable tokens | vs control | Coding score | Research, blind panel | Hand-off latency |
|---|---|---|---|---|---|
| curated | 350,898 | −75.2% | 0.833 | 6.82 | 0 s |
| recall-tuned Tileward | 394,854 | −72.1% | 0.968 | 5.33 | 69 s |
| json-extract | 523,122 | −63.1% | 0.865 | 5.69 | 2,080 s |
| broadcast control | 1,416,144 | — | 0.897 | 5.97 | 0 s |
Coding scores are graded against reference answers, 0 to 1. The research column is a blind panel scored 1 to 10. Higher is better in both. Tileward (recall-tuned) is the only regime that opens the Tileward Context store.
Billable tokens and hand-off latency are deterministic: we re-ran problems four hours apart and context assembly reproduced to the digit. The fidelity measurements behind the next two sections are decidable by inspection rather than judged, and they reproduce in a second, independently written harness. The two quality columns are the weak ones — at n=1, run-to-run variance is larger than the gaps between the arms. Read cost and hand-off as results. Read the quality scores as a direction with a wide bar on it.
A million fewer tokens, with ingest charged at full price.
The number we care about is net. Putting material into the store costs tokens, and it would be easy to publish a saving that quietly leaves them out. Every one of them is inside the figure below: 1,021,290 fewer billable tokens, after charging 182,900 tokens of ingest at full price.
Two instruments, pointing the same way. That figure is our tokenizer's count. The store keeps its own ledger, and over the same run it separately reports 1,282,907 tokens saved. We do not use that number in the headline, because the two are not measuring the same quantity — the ledger does not net out ingest. They agree in magnitude and they do not agree to the digit, and this page is not going to pretend otherwise.
Nearly all of the saving lives on the research problems. There the control costs about 390,000 tokens per problem, because an eight-agent fan-out re-bills that 49,000-token corpus to every agent on every round. Coding pipelines are shorter and the gap is correspondingly smaller. Hold onto that sentence — it is the same fact that produces the bad news two sections down.
Then the quality result came back in two halves.
We expected the answer to be a single number. It was not. On one workload we beat the control outright; on the other we came last of four.
Coding: best in the set
Graded against reference answers across three coding pipelines, Tileward (recall-tuned) scored 0.968 against the control's 0.897 — above the control, and above both other compressed regimes, which posted 0.833 for hand-curated routing and 0.865 for structured extraction. On a benchmark designed to find out what compression costs, this is the arm where it cost nothing and returned something.
One detail cuts against the obvious reading of that win, and it is worth more than the win. On coding, Tileward delivered a mean of 0.81 of the material each step had declared it needed, against the control's 1.00 — and still scored highest. Delivering less of the declared material did not hurt these answers at all. That is a warning about fidelity as a proxy for quality, in both directions, and you should carry it into the next paragraph rather than reading that paragraph as settled.
Research fan-out: worst in the set
On three research fan-outs, judged by a blind panel from 1 to 10, Tileward (recall-tuned) scored 5.33 against the control's 5.97. Hand-curated routing scored 6.82 and structured extraction 5.69. Tileward is last of the four.
The panel is blind in three ways, each closing a specific failure of model-graded evaluation. Citation markers are stripped from every answer before judging, so a regime that hands the next agent bracketed identifiers cannot score on the formatting. Answers are shuffled under neutral labels with no regime names, so the judge cannot prefer a condition it can identify. The shuffle is re-seeded per step, so no regime sits in the same slot twice.
It is not independent of the generator. The judge is the same served model that produced the answers. A model scoring its own outputs can share their blind spots, and this panel does not rule that out — it removes the format advantage and the position bias, not the family resemblance. We quote it because it fails differently from the fidelity measure below, and two weak instruments pointing the same way are worth more than either alone.
The material is not arriving, and we can prove it without a judge.
This is the part that turns a bad score into a finding. Every step in the benchmark names the artifacts it must receive before the run starts, and those artifacts carry markers in their bodies. So "did this agent get what it asked for" is decidable by inspection rather than judged by a model.
On the research fan-outs, Tileward delivered between 0.49 and 0.66 of the declared material, against 1.00 for the control and for hand-curated routing. Required material is not arriving on an eight-agent fan-out — and a panel with no sight of any of that marks the answers down too. Two instruments, one conclusion, and only one of them involves a model's opinion.
An independently written earlier version of the benchmark reproduces it. Run on the two problems the two harnesses share, it put research fidelity at 0.646 against 0.857 on coding. The weakness is not an artifact of one harness.
Research fan-out is the multi-agent case this product targets. The largest token saving on this page and the worst answer quality on this page are the same workload.
Two ways to compress a hand-off, three orders of difference in what it costs.
Tileward (recall-tuned) and json-extract are trying to do the same job — shrink what one agent passes to the next. Only one of them does it without spending wall clock.
| Measure | Tileward recall-tuned | json-extract |
|---|---|---|
| Overhead tokens | 182,900 | 458,909 |
| Hand-off latency | 69 s | 2,080 s |
| Calls | 202 | 45 |
| Total billable | 394,854 | 523,122 |
| Coding score | 0.968 | 0.865 |
30x less hand-off latency on this benchmark, at 24.5% lower total token cost and a higher coding score. Structured extraction spends about thirty-five minutes of wall clock on extraction calls across the matrix; the store spends sixty-nine seconds across four and a half times as many calls.
One functional failure, and a guard that could never have fired.
The 202 store calls in this matrix completed without a gateway error. Across both harnesses there was one functional failure: a single structured-extraction call was cut off by its completion budget mid-payload.
Answers hit their completion cap in every regime, including the control. On the generation calls, 35 of the control's 45 were capped against 26 for Tileward. The panel therefore judged some truncated answers in every arm. Truncation was more common in the control, so it does not explain the research result — but it is a limitation of the instrument all the same, and we would rather say so than let the number stand unqualified.
Capacity needed a separate experiment. Everything above ran at concurrency 1, because the harness is a sequential loop, so its request rate is just one over latency and says nothing about how much load the gateway takes.
And in that separate load driver we found a threshold that was inert. It had two abort conditions. One of them read an error rate that a remote caller is never sent, so its value was empty on every check and that abort could never have fired. The exposure hardening was working exactly as designed; the check was reading a field it was never going to receive. The second, step-level guard was live, so the run was not unprotected — but a threshold that cannot fire is not a threshold, and it looked like one for the length of a run.
We are not quoting a capacity number from that experiment, and the reason is in its own result: throughput varied roughly twofold at fixed concurrency, which makes any peak one sample of a noisy quantity rather than a ceiling. What it does establish is a floor and the location of a knee — queuing begins somewhere between 24 and 32 concurrent clients, where median latency jumps sharply while throughput falls. It ran from a single client host, over the public internet, against a small store, and none of those bounds can be told apart from the gateway's own limit without repeating it from several hosts.
What this run does not establish.
A single run is a weak instrument. Here is where it is weakest, so you can discount the parts that deserve discounting.
Generation variance is larger than the quality gaps. The same problem and regime, run four hours apart, scored 1.000 then 0.809 for hand-curated routing, and 0.881 then 0.952 for structured extraction. Token counts reproduced to the digit across those runs — 83,212 and 38,198 both times — so context assembly is deterministic and the instrument is sound. Per-problem quality scores at n=1 are not.
Six problems, not fifteen. The design called for five coding and ten research problems; three of each exist. The remaining nine would have to be authored, and their reference answers are the scoring target, so writing them while knowing which regime is under test would make the author part of the instrument.
The panel's arms are not scored on identical step counts. It aggregates 13 steps, of which the control has an answer for 12. Over the 12 steps every arm shares, Tileward scores 5.61 against the control's 5.97 — the ordering is unchanged and Tileward is still last, but the gap is narrower than the headline pair.
Hand-curated routing is not a product. It wins on cost and on the panel, and it is per-problem tag routing configured by a person who has already read the problem. What it establishes is that routing beats broadcasting — a property of the workload, not of any implementation.
Prompt caching is not modelled. A provider that discounts a repeated prefix narrows this gap, because the control sends every agent the same block. Any system that returns a different slice per query mutates that prefix and forfeits the discount. The comparison here is against uncached serving, and a cached baseline is the harder one.
One run — and the discount belongs on the quality columns. Cost and hand-off reproduced across re-runs to the digit; the panel scores did not. This is not a seed sweep, not a confidence interval, and not a claim about any workload other than these six.
What we are running next.
Each of these follows from something above, and none of them is a reason to discount the cost result. We are establishing where the research fidelity gap comes from on the fan-out shape specifically, rather than reasoning about it from the aggregate. We are repeating seeds before we quote any quality number again, because the variance is larger than the gaps. We are adding a prompt-caching arm: a provider that discounts a repeated prefix narrows the cost gap, and we would rather publish that number than leave a reader to assume it. We are authoring the remaining nine problems, by someone who does not know which regime is under test. And we are re-running the load ramp from several client hosts against a store of realistic size.
Why publish a run that goes against us. Because the parts that go against us are not the parts you would act on, and the parts you would act on are the solid ones. A 72.1% net saving and a hand-off costing 69 seconds instead of 2,080 do not depend on the quality scores being right — they came from the instrument that reproduces to the digit. And the research fan-out gap is the most useful thing we have measured about our own product: it is decidable rather than judged, it reproduces across two independently written harnesses, and it points at a specific mechanism — declared material not arriving — that we can go and fix. The alternative is that you find it yourself, later, in a pipeline you have already built on us.
The result above is six problems of ours. Point the harness at a multi-agent flow you actually run and we will publish what it does — including if it looks like the research column. Talk to an engineer, or read what else we measured, and its limits.