What a session leaves behind

Somewhere around the third session, every long investigation with a coding agent hits the same wall. The code from yesterday is on disk. The reasoning that produced it is gone. So the new session does what any capable stranger would do: it re-reads the repository, re-derives yesterday's conclusions, and after twenty minutes of tokens arrives roughly where you stopped. Roughly. Now and then it lands somewhere slightly different and starts quietly undoing a decision it made the day before.

The industry's answer is a bigger context window. The windows keep getting bigger, and the wall doesn't move, because a transcript is the wrong thing to carry forward even when it fits. Most of a working session is scaffolding: searches that found nothing, a hypothesis that died in four minutes, three attempts at the same regex. Replaying all of that doesn't tell the next session what was learned. It tells it what happened, which is a much larger and much less useful thing.

Four kinds of record

When we looked at what a resumed session actually needs from its predecessor, the list turned out to be embarrassingly short. What was attempted, and what exactly ran. What changed, or what was learned. What was validated, and whether it passed. And what was still open when the session stopped.

None of that needs a model to reconstruct it. It needs someone to have written it down at the moment it was true.

That is the whole idea behind ldgr, a small command-line tool that keeps an investigation's trail in SQLite: bounded work items, runs, observations, validations, and the decision that closed each run. A session opens by asking what is on the table:

$ ldgr status
state: idle, work available
next: browser-verification
last_completed: seo-fixes
handoff: active_run=false needs_decision=false

A few lines, written by the previous session at the moment of the observation rather than reconstructed from memory afterwards, and the new session is oriented. No forty-minute archaeology pass, no quiet disagreement with yesterday.

Does it hold up on real work?

The largest thing we have pushed through this loop is Session Board, an event operations platform that a coding agent built from a competition brief without active supervision. The planning ledger for that build expands the specification into 98 dependent work items; the brief, the repository, and the work graph are all public on our platform page. Closer to home, the corporate site you are reading came out of the same loop, a bit over thirty closed work items across many sessions.

What it doesn't do is also worth stating. A ledger doesn't remove the need for working context, and it won't rescue a task that genuinely needs a long horizon in a single pass. The claim is narrower: for work that crosses sessions, a durable trail of attempts and outcomes recovers more of the prior session's value than replaying its transcript, at a small fraction of the tokens.

The core of ldgr is open source under Apache-2.0. If you run agent loops that outlive their context windows, ldgr.run has the details — and if you try it, we would genuinely like to hear where it breaks for you.