part two · the bookend · same graph, same window
The Agent Walks the Graph — and Lives
Same avatar, same graph, same 32k window — the one that killed it at 35,750 tokens. This time the agent stays put: the data layer does the traversal where traversal is cheap, and what enters the window is a bounded, cited evidence packet. Watch the odometer — the whole point is how long it stays at zero. Missed part one? Watch it drown first →
Proposed packet design · not yet a Bonfire accuracy result
- 1 plan: parse("first abnormal HbA1c") → { Observation · code 4548-4 · reducer: first ≥ 6.5% } deterministic — no LLM call +0
- 2 scan: Observation series, whole date range · 1,204 results runs in the store — 0 tokens enter context +0
- 3 reduce: keep first + last verbatim · resolve Encounter refs · dedupe endpoints preserved by construction +0
- 4 packet: HbA1c 6.8% · 2124-03-11 [Observation/obs-8842] + series summary (n=1,204) + coverage ledger bounded · cited · endpoints verbatim +4,200
- 01
Same question. Same graph. The agent stays put.
This is the same illustrative graph the agent drowned in. This time it doesn’t walk: in this proposed design, the question compiles deterministically, with no model call, into a typed plan: resource type Observation, code HbA1c, reducer first-at-or-above-6.5. The context window hasn’t spent a token.
- 02
The data layer walks the graph instead
In this design, the traversal would happen in the database, where scanning 1,204 results is a query plan, not a context budget. Newest-first pagination stops mattering: the scan would cover the whole in-scope series, including page 12. The odometer still reads zero: none of this enters the model’s window.
- 03
Both endpoints kept, references resolved
The proposed selection keeps the first and last values verbatim, which is designed to make this specific recency trap impossible by construction. It resolves the encounter references the raw walk had to chase one fetch at a time, and dedupes. Still zero tokens spent.
- 04
One bounded, cited packet
What finally enters the window is the compiled evidence packet this design proposes: the answer-bearing observation with its citation, a series summary, the encounter context, and a coverage ledger designed to attest nothing in-scope was dropped. On the same gauge where the raw walk died at 35,750, this is a sliver; the ~4,200-token figure is illustrative, not a measured Bonfire result.
- 05
The agent answers — with receipts
The model reasons over evidence that fits, and every claim in its answer carries a citation back to a record id. The value it names is the exact one the raw walk never fetched: 6.8%, from 2124, twelve pages deep.
- 06
What this is — and isn’t, yet
What’s measured: question-aware selection beat blunt projection in two paired A6a runs (+9.5pp preregistered, then +8.3pp in the repaired replication). What you just watched, the full packet composition with reducers, reference resolution, and the coverage ledger, remains an illustrative design, not a measured Bonfire result. We show the mechanism; we don’t claim its number until the run exists.
What's real here (and what's illustrative)
The measured part is A6a: deterministic question-only selection beat query-blind truncation by +9.5pp (preregistered, McNemar p=1.3×10⁻⁵) while sending 43% less payload — that result licenses exactly one sentence, and this page leans on no more than that. The drown-run marker on the gauge (35,750 tokens) is part one’s illustrative accumulation scenario, built to mirror the measured multi-turn failure mode.
The illustrative part is the rest of the composition you watched: typed reducers, reference resolution, the series summary, and the coverage ledger — that is the evidence-packet architecture as designed, and its token figure (~4,200) echoes the concept demo, not a benchmark run. It is an illustrative design awaiting its own registered test. When that run exists, this page gets its number; until then the coverage ledger is “designed to attest,” never “proves.” The measured result →
Selection is a data-layer job. This is the data layer.
bonfireDB compiles the question into the bounded, cited slice underneath your app — your agent never holds a million-token human in its head.