Blog · June 23, 2026

Your AI agent forgets everything between runs. Here's where its memory should live.

Run an agent on a real task and watch what happens at the boundaries. It works for a while, then the session ends — the context window closes, the process exits, the cron tick finishes. Next run, a fresh context opens. Everything the agent knew is gone. Not degraded. Gone.

So it starts over. It re-reads files it already read. It re-researches a question it answered yesterday. It re-opens a decision it already settled — sometimes reversing it, because nothing told it the matter was closed. It picks up a half-finished task and can't tell which half is done. The work isn't bad because the model is weak. It's bad because the model has amnesia, and you've asked an amnesiac to run a project that lasts longer than its memory.

This is the single-agent version of the coordination problem. One agent, across time, is still a continuity problem — and the fix is the same shape: the things that have to survive can't live in the context window, because the context window is the one thing guaranteed not to survive.

Here is what actually has to persist, and where.

The plan can't live in the transcript

Most agents keep their plan in their own head — a numbered list in the current context, maybe echoed back each turn. That list is perfectly good until the context closes, and then it's a transcript no one rereads. The next run doesn't inherit the plan. It reconstructs one, slightly different, and drifts.

Put the plan in durable structure instead: tasks, modeled as a dependency graph, stored outside any run. Now resuming is a question, not an act of reconstruction. A new run boots, asks what's ready, and gets a correct answer — the unblocked work, with the finished work already marked done and the blocked work correctly hidden until its dependency clears. The agent doesn't have to remember where it was. It reads where it is.

The graph also keeps a long task honest. "Done with step 3" is a fact in a row, not a claim in a closed window. Past-you recorded it; present-you can trust it.

Decisions have to outlive the session that made them

The most expensive amnesia is the reversed decision. An agent weighs two options, picks one for a reason, moves on. Three runs later — fresh context, no memory of the deliberation — it hits the same fork and picks the other one, just as confidently. Now the codebase has both answers, and a human gets to find out why.

Decisions need to be append-only minutes: the choice, the reason, and the options that were weighed and rejected. Not a comment that gets overwritten — a durable record you supersede rather than edit, so the history of why survives. A run about to re-open a settled question searches first, finds it already answered, sees the rejected alternative spelled out, and moves on. The deliberation happened once. It stays happened.

Research done once should be retrievable, not redone

Agents are expensive researchers. They read docs, trace code, run experiments, and arrive at a finding. Then the window closes and the finding evaporates with it. The next run that needs the same answer pays for it again.

The fix is a searchable memory — knowledge notes written once and retrieved by meaning later. Not a file the agent has to remember to open, but a store it queries before doing expensive work: have I learned this already? A finding written in run one is found by run twelve, by search, without anyone remembering it exists. Rework is the default failure mode of a stateless worker; a queryable memory is what turns it off.

A run needs a logbook it can read back

Ask an agent what it did last Tuesday and, with no durable record, it will guess — plausibly, and sometimes wrong. That guess is how unattended loops drift: each run reasons from a slightly fictional account of what past runs accomplished.

Give runs a logbook. Every run is a real record — what it set out to do, what it touched, how it ended. A new run can read the recent history and see ground truth instead of inferring it: this shipped, that was abandoned, this is mid-flight. The agent stops narrating its own past and starts reading it.

Booting a run is reading state, not being re-prompted

Put those together and the start of a run changes. Today, most "memory" is a longer and longer system prompt — you paste more context in and hope the model holds it. That doesn't scale, and it still resets at the boundary.

The alternative is orientation. A run opens by reading durable state: who am I, what's assigned to me, what's in my inbox, what changed since I was last here, what's the next ready thing. One call, answered from a database, the same way every run. The agent isn't re-briefed by a human each time. It briefs itself off state that outlived its last context — and two different agents, or the same agent a week apart, read the identical picture.

Why a bigger context window doesn't fix this

The tempting answer is "just use a model with a longer context." It doesn't solve it, for three reasons. Recall decays across a long window, so "it's in there somewhere" isn't the same as "it's used." Stuffing every prior run into every new one is a cost that grows without bound. And the window still closes at the end of the run — a larger jar of short-term memory is still short-term memory.

Durable state is a different thing, one layer down:

• The plan survives because it's a row in a table, not a list in a window that's about to close.
• The decision survives because it's append-only minutes, not a sentence in a transcript.
• The finding survives because it's indexed and searchable, not pasted and forgotten.
• The history survives because every run wrote it down, not because the next run guessed well.

Memory you have to re-feed an agent every run is memory that fails the first run you forget to. Memory built into shared, durable state is memory that holds when no one is re-feeding it — which, for an unattended agent, is every run.

The shortest version

A stateless worker on a long task will redo research, reverse decisions, and lose its place — not because it's unintelligent, but because the only memory it has closes with the session. Move the things that must persist out of the context window and into durable state: the plan as a task graph it can resume, decisions as append-only minutes it won't reverse, findings as a searchable memory it won't redo, runs as a logbook it can read back. Then a fresh run doesn't start from zero. It starts from where the last one left off.

That's what Ledgenter is — durable, shared state for agents, behind one MCP server, every record outliving the run that wrote it. The same office that keeps multiple agents from stepping on each other is what keeps a single agent from starting over every morning. You can watch the loop that builds it do exactly this, in public, on a cadence.

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