Your vibe coded agent forgets because its memory isn't versioned

I spent an evening last week convinced my build agent had gotten dumber. It kept forgetting things it had decided the day before, drifting back to a naming convention the project had explicitly thrown out, re-asking a question the spec already answered. My first instinct was the wrong one: assume the context window was too small and start writing a longer, heavier system prompt to cram more history in. Then I went looking for where the agent's memory actually lived, and the answer was embarrassing. The file that told it who it is and what this project had already settled was sitting untracked on disk, right next to a spec and a session log that were both under version control. The memory was never in git. The chat window was never the memory.

If your vibe coded agent keeps forgetting what it's doing across sessions, the fix is almost never a longer prompt or a bigger model, it's to put the load-bearing memory into versioned files the next run re-reads, because context rot is a storage problem wearing a context-window costume. The thing that carries a decision from yesterday into today is not the transcript, which evaporates, it's a file the agent opens at the start of every run. Any document that changes what the agent does belongs in the repo, committed alongside the change it describes, next to the spec and the build log. Persistent memory is files, not history.

why does my AI agent keep forgetting what it's doing?

Because the place it's reading from resets and the place it should be reading from was never wired up. A session is a rolling window, and everything in it is gone the moment the window rolls or the session ends. So if the only record of "we decided to route inputs explicitly, not parse them" lives in yesterday's chat, today's run starts from zero and rediscovers the wrong default. That's context rot: not the model degrading, but the memory that was supposed to survive the session never existing as anything durable in the first place. This is one of the quieter failure modes of vibe coding, and a vibe coder feels it as the agent getting less sharp over a project, when what's actually happening is that each run is a fresh amnesiac reading whatever scraps happen to be in the current window. The longer prompt feels like a fix because it stuffs more of yesterday back in by hand, but you're manually re-loading memory every session instead of giving the next run a file to open. The window was never built to remember. Files are.

what actually belongs in version control, and why untracked memory is worse than none

The rule I settled on is simple: if a document changes what the agent does, it gets committed with the change it describes. The identity file, the one that says what this project is and who the agent is inside it, belongs in the repo next to the spec and the session log, not floating untracked in a working directory. Untracked memory is not neutral, it is actively dangerous, because it breaks the one guarantee version control is supposed to give you. When you roll a bad build back, git restores every tracked file to the known-good state and leaves the untracked ones exactly as they are. So the code reverts and the wrong instructions stay, and now the agent is reading stale memory against fresh code, which is a subtler failure than plain amnesia. The moment I moved the identity and decisions file into the tree, a rollback started carrying the memory back with the code, and the two stopped drifting apart. This is the same instinct as putting your AI decisions in files instead of prompts: a decision nobody committed is a decision nobody is accountable for, and a memory nobody tracked is a memory a rollback can't reach.

why the harness churn makes this more urgent, not less

There's a new coding-agent CLI landing most weeks right now, offline binaries, per-agent sandboxes, a different harness every time you look. That churn is the argument for external memory, not against it. If your agent's identity and your project's settled decisions live inside one tool's session state, then every time you swap harnesses, and you will, you re-teach the new one everything from scratch. But if that memory is versioned files in the repo, the file survives the swap and the session doesn't. Whichever agent you point at the project next reads the same spec, the same decisions file, the same log, and picks up where the last one left off. AI orchestration that couples memory to a single harness is orchestration that gets amnesia every time the harness changes. Keep the load-bearing context outside the tool, in files the next agent re-reads, and the harness underneath becomes a swappable detail instead of a thing you rebuild your memory around every week.

questions that keep coming up

Isn't a bigger context window the real fix? It buys you a longer session, not a durable one. A bigger window holds more of today in memory, but it still empties when the session ends, so tomorrow's run starts blank unless something on disk feeds it. The window is working memory. The repo is long-term memory. You need both, and only one of them survives the night.

How is this different from just writing a really detailed prompt? A prompt is something you re-send every run, which means you're the one carrying the memory across sessions by hand. A committed file is something the agent re-reads on its own, versioned, diffable, and restored by a rollback. The prompt fixes one session. The file fixes every session after it, and it tells you what changed and when.

What actually goes in the file? The decisions that would be expensive to rediscover: the constraints the project has ruled in and out, the conventions that are settled, the "we already tried that and here's why it broke" notes. Not the whole transcript, just the load-bearing conclusions, committed next to the spec so the next run reads the contract and the history together.

If you're formalizing how your agents remember across a real multi-session build and want to compare notes on what actually holds at production scale, /work-with-us. Most of the drift I've watched vibe coders fight isn't the model getting worse, it's memory that was never given a durable home, and that one is fixable with a commit.

The reason this holds is not clever. Version control already solved durable, restorable, diffable state for code, and the memory your agent runs on is just more state that deserves the same treatment. Put the file the agent reads to know itself in the repo, commit it with the change it describes, and context rot stops being a mystery about the model and becomes a checklist item you can actually close. The session forgets. The repo doesn't, if you let it hold the memory.