Why your coding agent forgets between sessions, and what a plan is for
You spent an hour explaining the product to your agent. It understood, it built the right thing, it even pushed back on one of your ideas for a good reason. The next morning it is a stranger again. It reads the repository, guesses the intent from the code, and ships the literal request. This is not a bug you can file. It is how the tools work, and it points at something the code was never going to hold.
What actually happens at the end of a session
A coding agent's working memory is the conversation. Everything it worked out with you, every reason it gave, every alternative it rejected, lives in that transcript. When the session ends, the transcript is gone or archived, and the next session starts from whatever is on disk plus whatever it is told. On disk is the code, which records what was built, and maybe a conventions file, which records how to work on it. Neither records why.
So the agent does what any capable newcomer does: it infers the why from the what. Sometimes that works. Often it produces a confident, tidy change that undoes a decision you made three weeks ago, because the code did not say the decision existed, and you were not there to say it either.
Memory features patch the symptom
The tools are getting better at this. Agents now keep notes across sessions, summarise old conversations, and load a memory file on start. These help, and you should use them. But look at what they store: fragments. A note that says "user prefers small commits". A summary that says "we discussed the billing page". They are a diary, and a diary is read back in order, not by relevance. Ask the agent why the billing page exists and the diary can tell you that it was discussed, not what it is for or what else depends on it.
The deeper issue is that memory files grow without structure. Every session adds a little. After a month the agent is reading a long, flat list of things that were once true, with no way to tell which still are. The forgetting problem turns into a stale-memory problem, which is worse, because a wrong belief held with confidence does more damage than no belief at all.
What a plan is for
A plan is the thing that was missing: a structured, current statement of why the work exists. Not a document, a tree. Outcomes at the top, each with a measure. User needs under each outcome. Approaches under each need, each a bet with a status, because some bets are still being tested and some have been dropped. Jobs under each approach, each an observable checkpoint assigned to a phase.
Three properties make this the right shape for an agent that starts cold. It is small: a real product fits in a hundred or so nodes, which an agent reads in one call. It is navigable: the agent can start at the job it was handed and walk up to the outcome, or start at an outcome and see everything serving it. And it carries status, so a retired bet reads as retired and does not get rebuilt by accident.
When a plan like this exists, the first thing the agent does in a session is read the branch it is working on. That replaces the hour of re-explaining with a few seconds, and it replaces guessing with reading. The agent still forgets the conversation. It stops forgetting the reasons.
Keeping it true
A plan only helps if it matches reality, and the agent that just did the work is the best-placed thing to update it. That is the part most planning tools miss: the plan lives where the human writes, and the agent cannot reach it. In ProductBrain the plan is a canvas for you and an API for the agent. It searches the plan, reads a node in context, adds a job under the right approach, and marks it done when the change is live. The same data is yours as JSON or an OKF markdown bundle at any time. The free tier includes the API, up to a hundred nodes.
None of this makes the agent remember. It gives it something worth reading when it wakes up.
See a plan an agent built and can read
This one is for Plausible, the privacy-first analytics product. A coding agent reconstructed it from the public repository: the outcomes, the needs, the bets and their status, and the jobs that check each bet. Read it top-down and every job has a reason above it.