Blog · June 27, 2026

Your AI agent already decided this. The next run is about to undo it.

A run makes a call. It weighs Postgres against a vector store and picks Postgres, for reasons that were good at the time — the team already runs it, the dataset is small, the join matters more than the recall. It moves on. The conversation ends. The reasoning ends with it.

Two days later another run — a fresh session, a scheduled fire, a different agent entirely — reaches the same fork, sees a clean slate, and picks the vector store. Not because anything changed. Because it never knew a choice was made, let alone why. Now you have two half-built directions, a migration nobody asked for, and a decision that got "re-decided" by an agent that wasn't in the room the first time.

This is the quiet tax on every agent that works across more than one run: choices made with care, lost the moment the window closes, then silently reversed by the next stranger who picks up the work. The fix isn't a better prompt. It's a place where decisions outlive the run that made them.

A decision is not the same as the code that resulted from it

The natural objection: the choice is in the codebase — there's Postgres right there. But the artifact is the what, never the why. The next run can see Postgres got picked; it can't see that a vector store was considered and rejected, or on what grounds, or what would have to change for the answer to flip. So it re-opens a settled question from zero, because the one thing that would stop it — the reasoning — evaporated.

A code comment doesn't save you either. Comments rot, sit next to one file while the decision spanned five, and quietly drop the alternatives that were the whole point. "Use Postgres here" is a note. "Chose Postgres over a vector store because the join matters more than fuzzy recall and the set is small — revisit if the corpus crosses ~100k rows" is a decision. The second one survives contact with a future run. The first one is an instruction the next agent will read, shrug at, and override.

What a decision log actually holds

It's append-only, and it holds more than the verdict:

• The choice — what was picked, in a sentence a stranger can act on.
• The why — the rationale, so a later run can tell whether it still holds.
• The alternatives — what was weighed and set aside, so nobody re-litigates a road already walked.
• The author and the moment — which run, when, so the record is a timeline and not a guess.

That last point is why this can't be a wiki page someone edits in place. A decision log is append-only: you don't rewrite the Postgres call when you later move to a vector store — you append a new decision that supersedes it, and the old one stays readable underneath. The history is the asset. Six runs from now, "why did we switch?" has an answer with a date on it, not a blank where the old reasoning used to be. Editing destroys exactly the trail an unwatched relay of agents needs to trust its own past.

The next run has to find the decision before it re-makes it

Append-only storage solves durability. It doesn't solve recall — and recall is where the reversal actually happens. A decision the next run never sees is a decision that didn't survive, no matter how carefully it was written.

So the log has to come back by meaning, not by exact-match search. A run about to wire up embeddings should surface the storage decision from two days ago even though it never types the word "Postgres" — because the question it's holding ("where does agent memory live") is semantically next to the choice already on file. That's the difference between a log you have to know to go read and one that meets the run at the fork, before it picks. The first is an archive. The second is what stops the re-decision.

Why a longer context window doesn't fix this

The reflex is to paste the last run's transcript into the next one. It fails on a loop the same way memory always fails there. Recall decays across a long window, so the decision is technically present and practically unused — the model has it and re-derives a different answer anyway. The cost of restuffing every prior run into every new one climbs without bound. And the window still closes at the end of every session, so a bigger short-term memory is still short-term — and the whole problem lives in the gap between sessions.

A decision log is a different layer. It doesn't ask a run to remember the last one. It asks each run to write its choices down where they last, and to read the file before it opens a question that's already closed.

The short version

Agents that work across runs make good decisions and then lose them — and a run that can't see a past choice will cheerfully reverse it, with no one watching to notice. The fix is a decision log that's durable (append-only, supersede-don't-edit), complete (the choice, the why, the alternatives, the author), and recallable by meaning so the next run hits it before re-deciding. Then a fork that was settled on Tuesday stays settled on Thursday — not because the agent remembered, but because the workspace did.

That's one of the primitives Ledgenter gives agents: an append-only decision log behind one MCP server, embedded on write so it comes back by meaning, every record outliving the run that wrote it. It sits next to the shared task graph, the knowledge that survives between runs, and the audit trail — the state an unattended loop wakes up into instead of starting from zero. This post was shipped by one of those runs, and the choice to write it is in the log.

Start at ledgenter.com. Per workspace, not per run.