Cross-stage context delivery: contract keys, pull access, per-node budgets

[denkhaus]

The situation

Fabro's context storage is already a durable KV store: Context is serde-serialized into every checkpoint, values over 100KB offload to a content-addressed blob store, and stages write to it via context_updates (routing JSON). The storage model is solid.

The tension is one layer up — delivery. Every stage receives its predecessor state as a pushed preamble, and the fidelity level decides what that push contains:

Fidelity	What the stage sees
compact (default)	goal + stage outcomes + (in theory) remaining context keys
summary:*	summaries with outputs
full	everything, via thread reuse

From running a multi-role workflow (planner → implementer → gate → evidence → reviewer) in production for a day, we hit all three walls below. Each has a workaround today; none of the workarounds is free.

Three observations from real runs

1. The default silently breaks the inter-stage contract.
context_updates is the documented API between stages — planner emits current_seed_id / current_seed_brief, implementer consumes them. In run 01M0NJ3QZ1FK53X9DK3BBAN2ED (default fidelity), the implementer's preamble showed "## Completed stages: planner: succeeded" and nothing else — no Context section, no values. The implementer re-derived the seed from the tracker (17 wasted tool calls, even re-claimed the seed itself: a role violation). The code intends to render those keys (append_filtered_context), so this is a correctness bug first (we're preparing a fix + reproducer) — but it exposed how fragile "the preamble should carry the contract" is as the only channel.

2. Push has hard size ceilings that are tighter than any model window.
PROMPT_INLINE_VALUE_MAX (8KB per value) demotes anything larger to a 300-char preview + a blob/file pointer. Fine for tool-agents; fatal for tool-less prompt nodes — our reviewer (shape=tab) can never read the pointer. Evidence output at 8.3KB made review structurally blind (run 01M0NGQXB67674XQ5YCR1MB4BN, two identical rejections). Modern models have 200k–1M windows; the delivery layer, not capacity, is the bottleneck.

3. There is no pull.
A tool-agent that needs a large or rarely-read value cannot fetch it: no context_read tool exists. The only way to make a value visible is pushing it into every subsequent preamble (paying it per stage) — which is also why our run billed 828k tokens, largely re-reading the same briefs.

What we think the optimum looks like

A hybrid, built on the existing KV backbone:

1. Contract keys are always pushed, at every fidelity. context_updates values are small by definition and are the API between stages. Delivery must be guaranteed, not fidelity-dependent. (Bug fix we're preparing; independent of the rest.)
2. Large values travel as pointers with a budgeted inline preview — already implemented via blobs; the budget should be configurable per node (e.g. inline_max="16k"), so workflow authors can pay tokens for full-fidelity review when the receiver is tool-less.
3. A read-only context_read(key) tool as the pull side, enabled per node alongside fabro_tools. Prompts stay lean; agents fetch specialist values on demand; tool-less prompt nodes keep relying on 1+2, now reliably.
4. thread_id for conversation continuity where continuity (not state handoff) is the actual need.

Questions for the room

• Is there a reason push-only was chosen deliberately (determinism? reviewability of what a stage saw?) that a pull tool would erode?
• Should context_updates keys carry a delivery hint ({key: value, push: true} — always-inline vs pull-able), or is "small = contract = always pushed" the cleaner rule?
• Any appetite for making fidelity per-node less bucket-y in the long run — e.g. budgets per key class instead of global levels?

Happy to contribute: the contract-key fix, a context_read prototype, and our run evidence are all available. The lab workflow that produced this is MIT-able as a stress-test reference for any redesign.