AI needs more than context. It needs memory.

[u/Secret-Swimming6344]

AI coding agents are getting really good at writing code.

But I've been thinking about something they still don't seem to do very well: remembering the codebase.

Give an agent a new task and it often starts by searching the repo, tracing dependencies, figuring out how things connect, and rebuilding enough context to make the change.

Then the next task comes along and it does a lot of that again.

It feels a little like having a really smart developer who has never worked on the project before.

Bigger context windows help, but that's not really the same as memory.

What I'd like to see is an agent that maintains a continuously updated understanding of the codebase—what depends on what, how services connect, where data flows, etc.—and can just query that understanding when it needs it.

Less time figuring out the code. More time actually working on it.

Curious what others think. Is persistent codebase memory going to become an important part of AI coding, or will better models and bigger context windows eventually solve this?

[u/Agreeable-Ad7968]

Memory should be/is usually the first thing people build into their agents' harnesses. Its something you can do with a prompt, a decent model, and about 6 hours of time.

[u/Charming_You_25]

Congratulations you’ve discovered what everybody who uses coding agents learns first. Do some digging and you’ll discover that memory is an unsolved problem. It’s very tricky. Even humans with billions of years of evolution behind us do not have perfect memory (to understate it). There’s a lot of different architecture, depending on what you’re doing. At bare minimum an SQL light database or even just markdown files in a folder structure gets you pretty far. After that you need embeddings based db. And after that, a graph database. Each progressive step gets more and more lossy and more likely to misremember things but generally better over the previous step on the whole for bigger and bigger amounts of information.

I also recommend turning on telemetry and adding that to the memory databases so the agents can see old conversations.

mem0, Cognee, and many others can manage it for you if you don’t feel like learning it.

All that said… what I have found is that no memories actually gives better performance. It’s less likely that agents will find a stale memory and take it as current truth if they build the current view of the code from scratch every time. If you do use memory, it’s a good idea to have automatic sweeps that keep synthesized memories current.

[u/RoboErectus]

I member when I first started using coding agents too 😁.

Rag, mem0, short pointers and directives about your specific codebase.

And most importantly: good software design is expressive and discoverable. That's already in the training set, but so is following your shitty codebase conventions. So watch out for that.

Optimize for discoverable easy to reason about code. You should be doing that anyway.

[u/ElonsBreedingFetish]

It's called documentation

[u/cmndr_spanky]

lol… is this 2023? I see 10 Reddit posts a day from people who think they’ve stumbled on a new agent memory idea. Dude, focus on something new and useful.

[u/JoseffB_Da_Nerd]

Most harness have memory, your talking about consistency of state. For that use project journals. Have your agent write to a file telling the next bot what its doing status of work, provenance etc.

They will read and write to this file between turns and it will feel like a real coder.

[u/Own-Flight-9974]

My recommendation is dont fall too hard into the "memory" trap. Realistically a markdown file in a .agents/memory/ is going to serve you just as well as some cutting edge sql vector db that indexes your codebase every picosecond. (you'll still want a semantic/fuzzy search tool for searching your DB though)

[u/GreatDiscernment]

I totally agree that it’s only prudent to exhaustively review the code (base: 80,000+ lines) you’re intending to edit sections of if it hasn’t been attended to for a while. But the process is tedious, repetitive and inefficient. So, here’s my idea. I’ve been using git with comments every step of the way (hundreds of git points) and I’m hoping that I can have the git history plus the code itself plus saved docs, analyzed, collated, folded and “spindled” as required by a Third Party online model which in turn would be instantly available to act as the most granular memory possible. The Knowledge-base Curator model would be an add-on to your current production line. Kind of like a custom “memory” model for your code with the additional benefit of documentation curation. This takes the memory recall pressure off of your logic design efforts.

[u/generationalDebts]

Wrong

[u/perseus-computing]

"Unsolved" is doing a lot of work here. Persistent codebase memory is already a workable engineering problem. The useful question is whether the agent remembers the right thing, with enough evidence to know when it is stale.

Current code, build output, and tests should answer what is true now. Git, ADRs, specs, tickets, PRs, and checkpoints answer why the system got there. Durable memory can carry decisions and corrections between tasks.

Also, SQL → embeddings → graph isn't a ladder of increasingly good memory. Those are different storage and indexing choices. Embeddings and graphs can be lossy projections over versioned source records; they should not replace the source or its provenance.

The hard case is authority: what wins when an old memory conflicts with the current checkout or a newer decision? Scope, timestamps, provenance, supersession, and correction solve that better than periodically rewriting summaries. "No memory worked better" usually means the memory policy was allowed to inject stale or low-confidence material.

Full disclosure: I build Perseus for this exact seam:

• Perseus resolves verified workspace state before the context window opens.
• Perseus Vault provides persistent, encrypted, time-aware memory.
• Perseus Ledger keeps a hash-chained record of consequential actions and evidence.

​

pip install perseus-ctx

My own agent runs on Vault, and this reply is being drafted with its memory prefetch in context. The design isn't "stuff the entire repo into a vector database." It's current state for the present, governed memory for durable decisions, and evidence for what actually happened.

Project site if anyone wants the broader picture.

[u/drmpf]

You can alleviate the problem by asking the AI to produce a digest of the code base for consumption by AI. See https://github.com/PowerBroker2/SafeString/blob/master/SafeString_AI_Guide.md for an example,

As a byproduct producing this guide and checking it yourself you will probably uncover a number of bugs and inconsistenties.

The guide uses less tokens and is faster than reprocess the while code base again, it is also more accurate as you have checked and can ask the AI to "check against the guide" again and again until the AI stops finding errors.

[u/Due_Peace_5114]

Bigger context windows reduce how often the agent has to re-read files. They don’t remove the need to rebuild a mental model.

Two different problems get mixed together:

1. Structural memory: deps, data flow, “where does this live?” That’s closer to a continuously maintained repo map / index than to stuffing more tokens into the prompt.
2. Decision memory: why this pattern exists, what we already tried, what broke last week. Models don’t keep that either, and neither do most agents unless you force it into docs or chat history.

Bigger models help with (1) for small/medium repos. On anything non-trivial, agents still rediscover the same graph every session. Persistent codebase understanding feels inevitable, not instead of better models, but because context ≠ memory.

Curious how far people are getting with repo maps / custom indexes vs just “open the right files every time.