Your AI coder forgets everything. Give it a memory.

You told it everything on Tuesday. What the app is for, who it's for, why you went with the simpler signup flow after an hour of weighing options. On Wednesday you open a fresh session and it cheerfully suggests rebuilding the signup flow.

Nothing is broken. This is just what these tools are: each session is a conversation, and when the conversation ends, everything in it is gone. The AI that wrote your entire app has no idea, this morning, that your app exists.

Engineers absorb this cost without noticing, because they read the code and catch the AI re-deciding things. If you don't read the code, the amnesia compounds quietly. The AI re-opens settled decisions. It rebuilds things differently from last month. It asks questions you've answered five times, and eventually you answer one differently, and now the app disagrees with itself. It gets a little less consistent every session, and you can't see it happening.

The fix is three text files

Not a tool, not a plugin — three ordinary text files that live inside your project, that the AI reads at the start of every session and keeps updated as it works. The names below are conventions AI coding tools already understand.

PROJECT.md — the map. What the app does, its main parts in plain words, which outside services it uses (payments, email, hosting, database), and what's built versus half-built versus imagined. This is the difference between starting every session with a stranger and starting it with a colleague.

DECISION_LOG.md — the history. Every decision, with the date and the why, newest first. Its job is to stop re-litigation: "one price tier, not three — decided March 12th, because we have nine customers" costs one line and ends that debate forever. It's for you as much as for the AI. Six months from now you won't remember why you chose that either.

AGENTS.md — the rules. Standing instructions the AI must follow every single session: what to always do, what to never do, how to behave when things go wrong. This file matters enough that the next article in this series is entirely about what belongs in it.

And a fourth file, for the future: the parking lot

The three files above are memory — the past, kept. OPEN_WORK.md is its companion pointing the other way: one file holding everything you've decided to do later.

It earns its place because of what happens mid-session. You're fixing the signup flow, and a good idea surfaces — "we should really add password reset too." Without a parking lot, that idea has two futures, both bad: the AI cheerfully builds it right now, and your one-hour fix becomes a three-hour sprawl; or nobody writes it down and it's gone with the session. "Add it to OPEN_WORK.md" is the third option — the work stays declined and kept. Ours also holds a short list of things we've deliberately decided not to do, with the reason, which stops the AI (and us) from earnestly re-proposing them every month.

Don't trust the built-in memory instead

Most AI coding tools now have a memory feature of their own, stored somewhere on your computer. Here is why we don't use it.

Groundwork — this site — is built with Claude Code, by one founder, across two computers. For a while the tool kept its own memories on each machine. When we finally audited them, most entries had drifted out of date, and one had come to flatly contradict the rules file. The AI had been carrying around beliefs about the project that were wrong, invisibly, on one machine and not the other. We deleted both memory stores and made it a standing rule: memory lives in files inside the project, nowhere else.

The reasons hold for anyone. Files are visible — you can open them and read what your AI currently believes about your app, which you cannot do with a hidden memory store. They're shared — they travel with the project to a new computer, a collaborator, or a different AI tool. And they're correctable — when something in them is wrong, you edit it.

The payoff: many short sessions

You've probably felt a long session go bad. It starts brilliant, and an hour or two in the AI is losing the thread — forgetting the start of the plan, mixing up versions of things you settled, confidently redoing work from earlier. That's not your imagination. An AI holds the whole conversation in a limited working attention span, and as a session grows, older parts get compressed or dropped to make room. The AI genuinely gets worse the longer you go.

People who work with these tools all day handle it the same way: one task, one session — finish, close, start fresh. What makes that affordable is exactly the files above. Without them, every fresh session means re-explaining everything, so you cling to the long degraded one. With them, a new session reads the map, the log, and the rules, and is fully caught up in seconds — at its sharpest, every time. The memory files don't just compensate for the AI's forgetting; they turn it into the cheap part.

Set it up with one prompt

If your app already exists, paste this into a session:

Read through this entire project and create four files at the top level.

1. PROJECT.md — a map of this app in plain language: what it does, its main
   parts, every outside service it depends on, and what is finished versus
   unfinished. Write it for a reader who will never look at the code.

2. DECISION_LOG.md — start it with today's date and any design decisions you
   can infer are already settled (things the code clearly commits to). Newest
   entries go on top. Every entry gets a "why".

3. AGENTS.md — a rules file you will re-read at the start of every session.
   Start it with one rule: "Keep PROJECT.md and DECISION_LOG.md updated as
   part of every change, not as an afterthought — and when work comes up
   that we're not doing now, add it to OPEN_WORK.md instead of starting it."

4. OPEN_WORK.md — the backlog: everything we know we want to do but are not
   doing now, cheapest first. Start it with anything half-finished or
   clearly missing that you noticed while reading the project. When an item
   ships, delete it from the file.

Show me all four before saving them, and flag anything you had to guess.

Read what it produces. This is one of the few moments where you can genuinely check the AI's work without reading code — if PROJECT.md describes an app you don't recognize, you've learned something important early.

Keeping them updated is the AI's job, not yours

Notice what the setup prompt planted in AGENTS.md: keep the files updated as part of every change, not as an afterthought. That placement is the point. If staying current depended on you remembering to ask at the end of each session, the files would be stale within a month — and the entire reason files beat memory is that nobody has to remember anything. Because the duty lives in the rules file the AI re-reads every session, updating the docs is simply part of doing the work, the way a good chef cleans while cooking. This is how we run Groundwork: our AI updates the project docs and the decision log as part of every change, because its rules file says so — not because anyone asks.

One reflex does stay with you, because it can't be delegated: the AI can't reliably tell when your thinking-out-loud hardened into a decision. So when a real choice gets made mid-conversation — a pricing structure, a feature cut, a "no, keep it simple" — say "add that to the decision log" right then, the way you'd say "let's get that in writing." Decisions recorded at the moment they're made are accurate; decisions reconstructed later are fiction.

And if you ever open one of the files and find it lagging behind reality, don't respond by reminding harder — tighten the rule. The rules file you just created holds only one so far; filling it is next.