Blog
/
Research

Compressing production tracesfor agent replays.

JF
Jonas Feld
Research Engineer
September 16, 2026
·
11 min
read
Pixel Bloom cover image for the article Compressing traces for agent replays

Every agent run on Lattis can be replayed step by step in the console. That promise is cheap to make and expensive to keep: a replay needs the exact inputs, outputs and tool results of every step, stored for 30 days.

Why replays are expensive

A long agent run can pass 40 MB of raw trace. Multiply that by 1.2 million runs a month and the storage bill grows faster than the compute bill. Sampling was not an option: the run you need to debug is always the one you did not keep.

Deduplicate across steps

Most of a step repeats the step before it. We split every step into blocks and store each block once, keyed by its hash.

  • System prompts and tool schemas: stored once per run
  • Message history: only the new turn is stored per step
  • Tool results: deduplicated across runs in the same workspace

That change alone removed 81% of the bytes.

step 14
  prompt   sha:9f2c (shared)
  tools    sha:41ab (shared)
  history  sha:77e0 + 1 new turn
  result   read_logs, 2.1 KB

Compress what is left

The remaining text compresses well with a dictionary trained per workspace, because agents in one workspace call the same tools with similar arguments. Together, the two changes bring a replay to about 3% of the raw trace size.

“The cheapest byte is the one you stored last step.”

What it costs to read

Rebuilding a replay takes 40 ms on average, fast enough to open in the console without a loading state. Retention stays at 30 days by default, and teams that need zero retention can still turn traces off per key.

JF
Jonas Feld

Research Engineer at Lattis. Works on trace storage and the replay viewer in the console.