A live trace model folds agent runs into typed state — Incremental trace folding — What does it mean?
The news. On 1 September 2026, Egor Pakhomov and Erik Nijkamp posted Parsing the Stream: A Live Trace Model for Long-Horizon Agents and Their Observers (arXiv 2609.01466). The paper treats a long agent run as an append-only event ledger folded incrementally into typed run state and compiled into per-consumer views, then evaluates that design against deterministic ground truth for both readers — the human observer and the agent itself. Code, benchmarks, a regenerable synthetic corpus and the workbench traces are released. Read the paper →
Picture ten years of your bank statement. Nobody reads the statement to find out what they can spend today — they read the balance. The statement is still there, line by line and unedited, because it is the evidence; the balance is what you act on, and it stays current by absorbing one transaction at a time rather than by re-reading the decade.
A long-horizon agent's trace has the same shape and the same two readers. The agent has to fold the run back into a bounded context window before its next tick. The human watching wants one question answered — is this thing stuck? — and gets handed the decade of statements instead. Parsing the Stream keeps the statement and adds the balance: an append-only event ledger for evidence, a small typed run state for decisions, and a separate compiled view for each reader.
The three pieces are deliberately boring, and that is the point. The ledger is append-only, so an event once written stays admissible as evidence. The fold is a deterministic function that takes the current state and one new event and returns the next state — the same operation a running balance performs, and the reason the agent never re-parses history it has already summarised. The typed run state is a fixed set of named fields, not free-form prose, so a reader can ask for errors or step_count instead of grepping a transcript. Because the fold is deterministic and the ledger is complete, every field in the state can be replayed from the events that produced it, so the compression stays auditable — which is what a trace replay needs and what a summary written by a model cannot promise.
The view compiler is the last piece: it projects that state down to the fields one consumer actually needs. The acting agent gets what it needs to choose its next tick; a human monitor gets the health fields. Same state, two shapes, and neither reader is handed the raw log.
Where the token bill actually goes. Hold three things fixed: one reader model, one finished run, and 40 monitoring questions asked of it. The baseline is a budget-capped single call — hand the reader the raw trace, truncated to whatever fits, once per question. Say that costs 140,000 input tokens per question (illustrative; the paper reports ratios, not absolute trace sizes), so 40 questions is 5.6M input tokens. The compiled observer view answered the same questions with approximately 14 to 15 times fewer input tokens, putting the same 40 questions near 10,000 each, or about 400K tokens for the run. Notice that the reported saving on money is smaller than the saving on tokens — 5 to 7 times cheaper, not 14 times — and that gap is the honest part: folding the ledger and compiling the views is work you now pay for, so the input-token ratio flatters the bill. Accuracy moved the other way, 0.85 to 0.87 against 0.48 for the truncated read, though the authors note the monitoring questions were co-designed with the view schema and treat only the token and cost reduction, conditional on schema coverage, as the transferable result.
| Approach | What the reader gets | Reported result | Where it stops helping |
|---|---|---|---|
| Budget-capped raw-trace read | One truncated pass over the whole log, per question | 0.48 observer accuracy, the baseline (arXiv 2609.01466) | Cost grows with the run; truncation drops the part you needed |
| Prompt-level scratchpad | A running note the model keeps inside its own prompt | Matched the fold's accuracy at lower cost (arXiv 2609.01466) | No evidence trail — the note cannot be replayed from events |
| Live trace model (ledger + fold + views) | Typed state, compiled down per reader | ~14–15× fewer observer input tokens, 5–7× lower cost (arXiv 2609.01466) | An order-sensitive task family, where a state that discards ordering cannot answer the question |
Where the fold earns its keep
On the agent side the paper reports the sharper number: on 120-link sequential-dependency tasks, keeping the task's running statistic in per-step state succeeded 30 times out of 30 where full-context prompting managed 8 of 30 — a result the authors explicitly label descriptive, because the benchmark and the system were developed together (n=30).
The paper's most useful result, though, is the one that argues against it. A prompt-level scratchpad — just a running note the model keeps in its own prompt — matched the fold's accuracy at lower cost, and splitting the fold into two arms — one testing its deterministic running total, one testing its compactness — attributes the accuracy to the first and the cost saving to the second, rather than to the architecture as a whole. So the fold's remaining value is narrower than the headline: deterministic auditability, and serving the observer from the same state the agent runs on. If nobody has to audit the run and nobody is watching it, the scratchpad is the cheaper answer. The authors also derive eleven candidate requirements for trace folding from observed failures, and delimit them with an order-sensitive task family on which the fold stops helping — a running state that throws ordering away cannot answer a question that depends on it. Deciding what to log is the same decision as deciding what the state schema covers.
Goes deeper in: AI Agents → Agent Loop & State → The State Object
Related explainers
- Bounded-memory contract via typed retrieval — the same instinct applied to memory: type the thing the agent is allowed to carry.
- Causal trace localization — what you do with the ledger once the run has already gone wrong.
- System, trace and node eval granularity — choosing the level a trace is judged at, which is the same choice a view compiler makes.