The Ledger Remembers So the Agents Don't Have To

Agents can produce indefinitely. That is not the hard part. The hard part is that production without orientation degrades into motion: branches that go nowhere, features that restate old mistakes, refactors that undo last month's refactors. In a fleet of agent-run repositories, the scarce resource is not output. It is memory of intent. The Loa harness is our answer to that scarcity, and its center of gravity is a set of documents that the harness itself reads, writes, and enforces.

The ledger

Every Loa-harnessed repo keeps a ledger: a running, structured record of what was attempted, what was decided, and what state the work is actually in. We treat it as append-only in practice. New entries supersede old ones; old ones stay put.

The point of the ledger is not compliance. The point is that an agent session is amnesiac by construction. Context windows end. Sessions restart. A new session that begins by reading the ledger inherits the situation instead of rediscovering it. Without that, long-running work has a characteristic failure: the third session re-solves the first session's problem, differently, and now there are two half-solutions. The ledger converts a sequence of isolated sessions into one continuous project.

Listen for the second ledger.

This is an old idea wearing new constraints. Lab notebooks, ship's logs, and flight recorders all exist because the entity doing the work is not the entity that will need to understand it later. With agents, that gap is not an edge case. It is every single handoff.

Three documents, three tenses

Around the ledger, the harness encodes three document types that we think of as tenses.

ADRs are the past tense: decisions and their reasons. We follow the shape Michael Nygard described in 2011: context, decision, consequences, one short file per decision, kept in the repo next to the code it governs. The ADR community's catalog of formats shows how little ceremony this needs. What matters for us is that agents are instructed to read the relevant ADRs before proposing structural change, and to write one when they make a decision that a future session could plausibly reverse out of ignorance.

Known-failure records are the past tense with a bruise. When an approach fails in a way that cost real time, the harness expects a short write-up: what was tried, why it seemed reasonable, how it failed. This borrows from blameless postmortem culture, but the audience is different. A human postmortem teaches a team. A known-failure record inoculates a future agent that would otherwise walk into the same wall with complete confidence, because the wall looks fine from the outside.

Vision documents are the future tense: where the project is going and what "done" means for the current arc. They exist so that local decisions can be checked against direction. An agent optimizing a module in isolation will make locally sensible choices that are globally wrong. A vision document is how we make "globally wrong" detectable from inside a single session.

The beginner's version

If you are running one repo with one agent, the whole system compresses to this:

• Keep one file the agent reads at the start of every session and updates at the end. That is your ledger.
• When you make a decision you might forget the reason for, write three sentences about it. That is your ADR.
• When something fails expensively, write down why, in the repo. That is your known-failure record.
• Keep one paragraph, kept current, about what the project is for. That is your vision.

None of this requires tooling. Plain markdown files work. The discipline is the tool; the harness only automates the discipline once you have proven you want it.

The expert's version

The deeper property is that the documents are load-bearing, not decorative. Most documentation decays because nothing consumes it, so nothing notices when it rots. In the Loa harness, the documents are inputs to the machine. Sessions open by reading them. Gates check for their presence. A stale ledger produces visibly wrong behavior in the next session, which is exactly the pressure that keeps it fresh. Documentation that is executed, in the loose sense of "read by the executor," gets maintained the way code gets maintained.

This gives the system a quality we would cautiously call autopoietic: the harness produces and maintains the documents that produce and maintain the harness's behavior. It is also fractal. The same ledger-ADR-failure-vision structure applies at the level of a function rewrite, a repo, and the fleet, because the underlying problem (an amnesiac worker needs orientation) is the same at every scale.

A recurring shape in our pull request discussions illustrates the payoff. A review objection arrives that a past session already litigated. Instead of re-arguing it, the response is a link to the ADR that settled it, plus a judgment call about whether the old context still holds. Sometimes it doesn't, and the ADR gets superseded. Either way the discussion starts from the recorded reasoning rather than from zero. The interesting cases are the supersessions: they are the visible trace of the system changing its mind on purpose, in writing, rather than by accident.

Completion as the moat

We keep returning to a reflection that shaped this design. The cost of starting software has collapsed. The predictable consequence is a tsunami of half-finished products: repos that demo well and then stall, because the invisible second half of the work (decisions held consistent, failures not repeated, direction maintained across months) was never cheap and has not gotten cheaper. Generation got fast. Coherence did not.

That is why we think of completion as the moat. Anyone can now produce the first 80 percent of most things. The harness exists for the remainder, and the documents are how the remainder becomes tractable for agents at all. We wrote about the shipping side of this in the harness that ships; this essay is the memory side of the same argument. Shipping without memory produces artifacts. Memory without shipping produces archives. The harness is the insistence that a fleet of agents can hold both.

What we'd tell you to steal

Steal the tenses. Whatever your tooling, give your project a past (decisions and failures, written where the work happens), a present (a ledger any newcomer, human or agent, reads first), and a future (a vision short enough to actually be read). Then make something consume those documents, so that neglecting them hurts within days rather than months.

The agents in this fleet do not stay oriented because they are clever. They stay oriented because the repo remembers, and the harness makes forgetting expensive. That trade, cleverness for recorded memory, is the most durable engineering decision we have made.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

• 2026-08-05: enrich the-ledger-remembers-so-the-agents-don-t-have-to: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 3794