Agentic Systems: The Ledger Is the Product

This is Part 2 of Agentic Systems: Bounds and Evidence, the second series in a pillar on building agentic systems.

• Part 1: Bounded Tools, Not Free-Form Access: constraining what an agent can express, not just checking what it produced.
• Part 2: The Ledger Is the Product: what gets recorded at decision time, and why reconstruction after the fact does not work.
• Part 3: One Interface, Many Models: the model layer underneath, and what swapping it does and does not give you.

Part 1 constrained what an agent is able to do. This post is about what the system knows afterwards about what it did - which sounds like an operational concern and is actually the foundation the entire first series rests on.

Table of Contents

• The Reconstruction That Is Not Evidence
• What a Ledger Has to Capture
• Append-Only, and Corrections as Events
• Everything Else Reads From This
• Input Snapshots and the Reproducibility Problem
• Retention Is a Design Decision, Not an Ops Default
• The Honest Bill
• When a Log Is Enough
• Conclusion

The Reconstruction That Is Not Evidence

Six weeks after the fact, someone asks why the triage system paged the payments team for an incident that turned out to belong to checkout.

The tempting move is to ask the system. Modern agents are extremely good at this: hand one the alert and the decision and it will produce a coherent, specific, plausible account of the reasoning. The account will cite the error signature, note the deploy timing, explain the ownership inference. It will read like exactly what you asked for.

It is not evidence, and the reason is worth being precise about, because the output is persuasive enough that the distinction gets waved away.

The explanation is generated by a system in its current state, about a decision made by a system in a past state. Between the two: possibly a different model version, certainly a different context window, a service map that has since been corrected, prompts that have been revised twice, and calibration weights that have moved. Asking now produces the reasoning the system would use today, not the reasoning it did use then. When those coincide, the explanation is accidentally right. When they diverge - which is precisely when the question is being asked, because something went wrong and something has since changed - the explanation is a confident, well-sourced fiction.

A generated explanation is a plausible reconstruction. It is not a record, and the difference is not a technicality; it is the difference between knowing and guessing eloquently.

What a Ledger Has to Capture

The alternative is to write it down at the moment it happens. Concretely, for each decision:

The shape is unremarkable. What matters is that all of it is captured at decision time, synchronously with the decision, rather than assembled later from logs that were written for other purposes. A field that can only be reconstructed is a field you do not have.

Two entries deserve emphasis because they are the ones most often omitted. Model and prompt version per call is what makes it possible to say "this specialist's accuracy dropped the week we changed its prompt" rather than noticing a drift with no attributable cause - and Part 3 is entirely about why that matters once models become swappable. Orchestrator weights applied is what separates "the panel disagreed and the aggregate came out here" from an unexplainable aggregate; without it, a decision can be traced to its inputs but not to its arithmetic.

In the tender-response case this is worth treating as a design principle rather than a feature: every decision recorded as it is made, the record functioning as the spine of the product rather than a log bolted on afterwards. The question it has to answer - why did we answer that way?, for a specific requirement in a specific tender, months later - should be answerable from the record alone, with evidence rather than recollection. For a system whose output becomes a legal representation to a public body, that is not an operational nicety. It is the product's actual value proposition.

Append-Only, and Corrections as Events

When a human reviewer overrides a proposal, there are two ways to store the result, and only one of them preserves the thing the ledger exists for.

The first is to update the record with the corrected value. The second is to append a correction event referencing the original. These produce the same current state and completely different histories. The first answers "what is the value?" The second answers "what was proposed, what did a person change it to, and why?" - and the second question is the one that carries information, because it is the only one that captures the disagreement.

Disagreement between what an agent proposed and what a human decided is the highest-value signal in an agentic system. It is direct evidence about where the system's judgement diverges from the judgement it is meant to approximate. It feeds calibration. It identifies which decision types are nowhere near earning autonomy. It is the training signal for whatever comes next. An update-in-place destroys all of it and leaves behind a record that looks clean precisely because the interesting part has been overwritten.

The same point runs in the other direction: corrections should be captured as corrections, not silently overwritten. The word silently is doing the work. An overwrite is not merely lossy, it is undetectably lossy - nothing in the resulting record indicates that anything was ever different.

Everything Else Reads From This

The reason to treat the ledger as foundational rather than operational is that three separate mechanisms from earlier in this pillar are all reading from it, and none of them can be built first.

The calibration loop computes per-specialist, per-bucket accuracy - which requires every prediction joined to its eventual outcome, including the predictions that turned out fine and the ones nobody ever looked at. Selective recording biases the figure in the least detectable direction, because the cases that get recorded are the ones somebody found interesting.

Earned autonomy promotes and demotes decision types on their track record. Both directions read the ledger. A demotion rule that fires on recent failures is querying exactly this table, and "revocable autonomy" is an empty promise without it.

The trading-system panel from the first series makes the dependency concrete: every signal, decision, trade, and outcome is persisted, and the calibration job that weights each researcher is a query over that history. The persistence layer is not downstream of the interesting part of the system. It is what makes the interesting part possible, and a system built without it has to be rebuilt to get calibration at all.

Input Snapshots and the Reproducibility Problem

One field above is harder than the rest: the input snapshot.

Recording that the decision consulted "the service ownership map" is nearly useless, because the map is mutable and will have changed by the time anyone asks. Recording the map's contents at decision time is correct and can be expensive, especially when the input is a large document or a full context window.

The usual compromise is a content hash plus a reference, with the underlying content retained separately and immutably. That gives verifiable reproducibility - you can prove what was read - without duplicating large payloads into every decision record. It only works if the referenced store is genuinely immutable; a hash pointing at something overwritable proves nothing.

Worth being honest about the limit: even a perfect input snapshot does not give deterministic replay. Feeding identical inputs to a language model does not reliably reproduce identical output, and the model version may no longer be available to call. The ledger makes decisions explicable - here is what it saw, what each specialist concluded, how it was weighed, what happened next. It does not make them replayable. Treating an agentic ledger as a deterministic event-sourcing log that can be replayed to rebuild state is a category error worth avoiding early, because the architecture it implies will not hold.

Retention Is a Design Decision, Not an Ops Default

Ledger volume is the product of decision rate and record size, and both are larger in agentic systems than in the systems most retention policies were written for. A panel of nine specialists produces nine scored outputs per decision, each with reasoning, plus weights, plus disposition, plus an eventual outcome.

The retention question is genuinely a trade-off rather than a default. Long retention supports wide calibration windows, regulatory answers, and archaeology on old decisions. It also accumulates cost and, where the inputs contain personal data, it accumulates liability - data-protection obligations do not pause because the record is useful for calibration.

A tiered approach usually resolves it: keep full records hot for the longest calibration window in use, keep decision metadata and outcomes - the small, high-value fields - far longer, and age out the bulky payloads first. The fields that actually feed calibration are tiny. The fields that answer "what exactly did it read" are the expensive ones, and they are also the ones most likely to carry personal data.

The Honest Bill

The schema-evolution line is the one that bites late. A ledger is queried across time, so every schema change creates a discontinuity that calibration queries have to handle - and a calibration window spanning a schema change will silently mix two shapes of record unless someone thought about it. Additive changes and explicit record versions are much cheaper than the migration you will otherwise write in a hurry.

When a Log Is Enough

Not every system needs this, and building a full ledger where a log would do is real cost for no return.

• Nothing reads the record programmatically. If there is no calibration, no autonomy promotion, and no audit requirement, structured logs plus retention are adequate. Build the consumer first; a ledger with no reader is storage with ceremony.
• Decisions are low-stakes and self-evident. When errors are immediately visible and cheap to fix, the value of six-week-old reconstruction is close to zero.
• Outcomes are never observable. Half a ledger - predictions with no outcomes - supports auditing but cannot support calibration, so size the investment to what is actually answerable.
• The record would be more sensitive than the decision is valuable. Where inputs are highly regulated personal data, minimal retention may be the correct engineering answer, with calibration built on derived features rather than raw inputs.

Conclusion

An explanation generated after the fact describes the system as it is now, not as it was when it decided, which makes it a reconstruction rather than a record. The alternative is to capture inputs, per-specialist outputs, weights, model and prompt versions, disposition, approver, and outcome at decision time, append-only, with corrections stored as events so that human disagreement survives as signal. Everything else in this pillar - calibration, promotion, demotion, audit - is a query over that record, which is why it cannot be added afterwards.

One field in that record is the seam to the next post. Recording the model and prompt version per call only matters if those can change. Part 3 is about the layer that makes them changeable, and about the difference between a swap being easy and a swap being safe.