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?
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.
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.
If you're building something similar, persistence alone isn't the finish line. Both of these are real and documented:
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.So: persist the plan, and archive it on completion.
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.
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.
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?