Workflow Replay

A session ends at 11:40 the night before. Tests green, branch pushed, a note in the PR description that reads like every other note. The engineer opening it the next morning has exactly one artifact to work from if the diff alone doesn’t settle the question: a terminal scrollback several thousand lines long, or a chat transcript that reads like a court reporter typed everything verbatim and skipped nothing. Somewhere in it are the file reads, the failed attempts, the search that went nowhere, the moment the agent changed its approach, and the one edit that actually mattered. Finding out what happened means scrolling, and scrolling does not scale past the second session of the morning.

This is a solvable problem, and most teams have not tried to solve it, because the artifact they have — a wall of interleaved text — was never designed to be reviewed. It was designed to be produced. Nobody sat down and asked what a human would need six hours later to understand what happened; the transcript is a byproduct of execution, not a record built for comprehension. The gap between those two things is this chapter’s subject.

What review inherits from the terminal

Code review has always required a reviewer to reconstruct intent from someone else’s work — a problem that predates AI by decades, and one industry analysis of the shift puts it plainly: review has always depended on a reviewer reconstructing intent from another person’s brain, working backward from a diff to the reasoning that produced it, rather than being handed that reasoning directly. What AI-assisted work adds is not a new problem so much as a worse version of the old one, done from a rawer artifact.

A diff at least groups a change by file and hides the false starts — nobody ships the abandoned approach in the pull request. A terminal scrollback groups by nothing. It is one dimension, time, with every read, search, retry, and edit interleaved in whatever order the agent tried them, most of it dead ends that never mattered and dead time that never advanced anything. The reviewer has to do the file-grouping and the false-start-filtering themselves, by eye, while also doing the harder job of reconstructing why any of it happened. This is the same shift Volume I describes at the review layer of the AI Engineering Pyramid, restated at the level of a single session: the artifact that survives is the least legible one.

Guessing versus watching

The observability community building tooling for production LLM agents ran into the identical problem from a different angle, and named it more bluntly. Without structured visibility into what an agent actually did step by step — which tool call ran, which model invocation happened, in what order, how long each took — engineers debugging a slow or wrong agent response are, in the industry’s own framing, simply guessing. The response emerging from that community is standardized tracing: organize an agent’s run as a tree of discrete spans, one per tool call and model invocation, rather than as an undifferentiated stream of text. The insight generalizes past production debugging. A completed session reviewed after the fact has the same structural problem a live agent being debugged has — the record is technically complete and practically unreadable — and the same fix applies: turn the stream into steps.

Borrowed instruments

Two adjacent fields solved a related problem earlier and are worth borrowing from honestly rather than decoratively. The first is deterministic replay debugging. Tools such as rr — originally built at Mozilla to debug Firefox and now used across large C/C++ codebases — record a program’s execution once, including every nondeterministic input, so that the exact same run can be replayed as many times as needed under a debugger, complete with the ability to step backward to the instant a bug was introduced. The value isn’t novelty; it’s that a failure captured once becomes an artifact you can return to, at any speed, from any direction, rather than a one-time event you either caught or didn’t. An AI session shares that property. It happened once, in real time, and unless it is captured as something more than raw text, the second look is strictly worse than the first.

The second is closer to Operon’s own vocabulary, and the comparison holds up under scrutiny rather than just sounding good: flight data recorders and cockpit voice recorders exist because after-the-fact reconstruction from memory is unreliable, and the tape is not. A flight data recorder logs dozens to over a thousand operational parameters — altitude, airspeed, heading, control-surface position — while the cockpit voice recorder captures crew communication and cockpit sounds; together they let investigators build a second-by-second reconstruction of a flight in ways described as "difficult or impossible to obtain by other means." Nobody replays a cockpit recording to catch the pilot in a mistake for its own sake — the purpose is reconstruction precise enough that the investigation does not depend on which detail a surviving witness happens to remember. That is the honest version of the analogy: not surveillance, but a record built specifically so an ordered sequence of decisions survives long enough to be understood by someone who wasn’t there.

What a replay needs that a log doesn’t have

Put those two borrowed instruments together with the observability framing and a concrete list falls out — not a new theory, just what a session recording needs structurally before "replay" means anything more than "scroll slower."

Two uses: review and teaching

Once a session is structured this way, two genuinely different jobs get faster, and it is worth naming both because teams tend to only build for the first. Review is the obvious one: a human checking an AI’s work after the fact, faster than reading a diff cold, because the replay shows not just the final state but the order in which it was reached — where a flight plan’s steps diverged from what was intended, which searches were dead ends, and which single edit the whole session actually hinged on. Reviewing at compressed speed with the ability to slow down at exactly the moment something looks off is a different activity than reading a diff top to bottom hoping to notice the same thing.

Teaching is the less obvious one, and it has a real, decades-old basis in how people learn. Cognitive load research going back to John Sweller’s 1988 work on problem solving found that novices learn a new domain faster from studying a worked example — watching a problem get solved step by step — than from attempting the same problem cold, because unguided problem-solving spends a novice’s limited attention searching for a solution instead of learning the structure of one. A recorded, scrubbable session is a worked example in that exact sense: a new engineer watching how a senior engineer, or a well-run agent session, actually approached a problem — which files it checked first, when it backed out of an approach, what it verified before calling the work done — builds the same kind of pattern recognition that recorded pairing sessions and conference talks already build, except now the "worked example" is something your own team produced last Tuesday, not a generic tutorial.

A log tells you the work happened. A replay is the only artifact that can also teach someone how.

On the difference between recording and reviewing

Inside Operon’s replay player

What to build first

1. Capture at the trace grain, not the byte grain. If a session is stored as raw stdout, replay is scrolling with extra steps — the timeline has to exist as structured data before playback speed means anything.
2. Build compression in from day one, not as a later optimization. A replay nobody can sit through because the dead time is real time will get used exactly once.
3. Make review the first use case and teaching the second — but design the timeline so a new hire can watch it without narration. If it only makes sense to the person who ran the session, it isn’t a teaching artifact yet.
4. Treat a replay link like the code it can expose. Redaction and expiry aren’t optional polish once a replay is something that leaves the team.
5. Watch what actually gets replayed. Until a team measures whether replay is mostly used for review or mostly for onboarding, any claim about "how teams use it" is a guess dressed up as a feature description.