I checked what 6 AI coding tools write to disk to stop the agent forgetting its plan. Half write nothing.

Every AI coding tool has the same top complaint: "it forgot what we were doing."

I spent weeks assuming that was a context-window problem. It mostly isn't. It's a filesystem problem — and you can predict which tools suffer from it by asking one question: where does the plan get written down?

The bug that made me go looking

Our own builder had it badly. You'd say "build me a CRM," the agent would plan it, start building, hit its step limit, stop. You'd type "continue" — and it would either start over from a different angle or silently drop half the plan.

The cause was mundane and a little humbling. The plan was never saved anywhere. It was a local variable inside one function, parsed out of the model's own output text, used for step tracking during that single turn, then discarded:

// inside one turn, then gone
const activePlan = parsePlanFromModelOutput(text);

A savePlan() function existed. Nothing in the codebase ever read a plan back. The UI reset the plan to null on every new message. So "continue" was always a cold start — the agent had no record that a plan had ever existed.

Then it got worse. We had a completePlan() that fired whenever the agent hit its max iteration limit — i.e. in the exact moment before a user types "continue" — and it marked every pending step skipped. We were actively erasing the roadmap at the worst possible moment.

And one more: the plan object was only ever built on one model provider's code path. Route the session through a different provider and there was no plan at all. The bug was load-bearing on which model you happened to be using.

What everyone else does

So I went and read the docs, changelogs and forum threads for the tools people actually use. (This is from public documentation and user reports — I can't read their source.)

Tool	Durable plan?	Always-injected memory
Claude Code	Yes — plan files under ~/.claude/plans/, survive compaction	CLAUDE.md, re-read from disk after every compaction
Lovable	Yes — .lovable/plan.md + an archive dir, inspectable and diffable	AGENTS.md + knowledge layers injected every message
Replit Agent	Yes — .local/session_plan.md + a native task board	replit.md, persists across sessions
Devin	Yes — structured JSON plan, editable, survives crashes	scoped memory layers + playbooks
Cursor	No first-class plan; the community maintains a TODO.md by hand	.cursor/rules/*.mdc
bolt.new	No — Plan Mode keeps the plan in the chat	agents.md + Project Knowledge

The two that write nothing to disk are the two with the loudest "it forgets" threads. Cursor's forum has the "completely forgets it's trying to solve a problem" thread; bolt's own documentation concedes that after many prompts the AI loses track of earlier decisions and contradicts its own code.

That correlation isn't proof of causation. But it's a strong hint that this is an engineering decision, not a model-intelligence ceiling.

Two failure modes to design around

If you're building something similar, persistence alone isn't the finish line. Both of these are real and documented:

• Replit's stale-plan bug — session_plan.md isn't cleared between sessions, so the agent abandons what you just asked for to go finish an old plan. A plan that survives forever is its own bug.
• Claude Code issue #34782 — the plan gets re-injected after it's complete. Same root cause, opposite symptom.

So: persist the plan, and archive it on completion.

What we changed

The plan now lives as plan.json plus a human-readable PLAN.md on the workspace's persistent volume. It's written through on every step transition, re-read at the start of every turn, and archived when complete. If the agent stops early, pending steps persist untouched instead of being wiped. We added a provider-parity test so the plan can't silently exist on only one code path again.

The lesson that generalises

This is the part I'd actually tell other people building agents:

You cannot ask a model to maintain a file by putting it in the prompt.

We told our agent to keep a NOTES.md of its decisions. It never created it. Not once. I only found out by inspecting the container.

It also kept referring to a "bug log" it claimed to have been writing. There was no such file anywhere in the codebase — I grepped. It had hallucinated its own persistence layer, and it described it confidently.

The moment we made it a tool the agent has to call, it worked — because a tool call shows up in the trajectory and is verifiable. A prompt instruction is a suggestion; a tool call is evidence.

Enforce it in code. Don't ask the model nicely.

If you're hitting this

Stop tuning your prompt and go ask where the plan is written to disk. If the answer is "nowhere," you've found your bug. It's a persistence problem wearing a memory problem's clothes.

---

I build NoCoder, an AI app builder where you review every change as a diff before it applies. It's a beta. If you want to try to break it, I'd genuinely value that more than a compliment.

Curious what the folks here have hit — has anyone found a tool that handles long-running plan state well?