Coding assistants with project memory

Most coding assistants are brilliant for the length of one session and amnesiac after it. You explain that the team uses tabs not spaces, that the auth module is being deprecated, that you already tried the obvious fix for this bug last week. Close the session, open a new one, and you're explaining all of it again.

The model writes good code. What it can't do on its own is hold onto what it learned about your project, so every session it rediscovers conventions you've already settled and re-suggests approaches the team rejected months ago. This page is about giving the assistant a memory of the project that persists across sessions, branches, and weeks.

The problem

A codebase carries an enormous amount of context that lives nowhere a model can see it. Why the payments service was split out. Which patterns the team has banned and why. The fact that a particular test is flaky for known reasons and isn't worth chasing. Some of this is in the code, some in scattered docs, most of it only in the heads of the people who've worked on it longest.

A stateless assistant has access to none of that history. You can paste relevant files into the context window, but a real project is far too big to fit, and choosing what to paste is itself a job. Worse, decisions change. The library you standardised on last quarter gets swapped out this quarter. An assistant that remembered the old choice and never updated would keep steering you wrong, the kind of memory drift that makes a tool feel actively unhelpful.

Then there's finding things. "Where do we handle retries on failed webhooks?" is a question whose answer is a function buried somewhere across thousands of files, and the relevant code rarely contains the words you'd search for. Plain keyword search over a large repo turns up either nothing or everything.

This is also where teams tend to outgrow the memory their framework ships with. A built-in buffer that holds the last few messages is fine for a demo and useless for a project that spans months.

What Exabase unlocks

With persistent project memory underneath, the assistant stops behaving like a clever stranger and starts behaving like someone who's been on the team a while.

You ask it to add a new endpoint. It follows the conventions the team actually uses, because it remembers them: the error-handling pattern, the way routes are structured, the naming the team settled on. You don't restate the house style every time, because it already knows the house style.

You hit a bug you're fairly sure you've seen before. The assistant remembers the last time this came up, what the cause turned out to be, and what fixed it. Instead of walking the whole diagnostic path again, it starts from where you left off.

You propose an approach the team tried and abandoned. Rather than cheerfully helping you reimplement a dead end, the assistant flags that this was attempted, points to why it was dropped, and suggests the direction the team went instead. The institutional memory that usually requires a senior engineer to be in the room is available in the tool.

How it works

Three primitives carry a coding assistant. You don't need the rest of the platform for this.

Memory

Exabase Memory holds what the assistant has learned about the project: conventions, architecture decisions, past debugging sessions, things the team has tried and rejected, individual developers' preferences. You feed it the relevant exchanges and Exabase extracts what's worth keeping, so you're not hand-authoring a style guide for the machine.

The decisive part for code is that decisions get superseded cleanly. When the team migrates off a library or changes a pattern, the new fact replaces the old one rather than sitting next to it, so the assistant stops recommending the thing you just moved away from. That contradiction handling is the line between a genuine memory layer and a log of everything anyone ever said.

Bases

A Base is an isolated environment with its own memory, storage, and search. You create one per project (or per repository), so the conventions and history of one codebase never bleed into another. An assistant working in your payments repo doesn't pull in memories from your marketing site. The isolation comes from a single API call rather than from partitioning logic you build and maintain.

Bases also support filesystem snapshots, which means you can checkpoint the assistant's working state and roll back, useful if you're letting an agent make changes and want a way to undo a bad run. The version control for agent context use case covers that pattern in depth.

Resources

Resources are where the project's material lives so the assistant can search it: design docs, ADRs, runbooks, past PR discussions, whatever written context the project has accumulated. Stored as Resources, they're indexed for Deep Search, so when the assistant needs to find where retries are handled or why a service was split out, it searches by meaning and gets the relevant passage back rather than a list of files to open.

Example architecture

The shape is simple enough to fit in a paragraph, which is the idea.

One Base per project. Hold the Base ID alongside the repo so every session for that project reads and writes the same memory.

As the team works, send the things worth remembering to Memory: resolved bugs and their causes, decisions made in review, conventions agreed on. Store the written context, design docs, ADRs, runbooks, as Resources. If those docs arrive as PDFs or other formats, run them through Extract first to turn them into clean text.

On each session, the assistant retrieves project memory for conventions and history, and runs a Deep Search across the project's docs for anything specific to the task at hand. Both go into the prompt before it writes a line.

Memory and docs flow into a per-project Base as the team works, and get read back at the start of every session. The project's context builds up instead of resetting.

What compounds over time

The argument for building on infrastructure rather than rolling your own gets stronger the longer the project runs.

Every resolved bug, every settled convention, every rejected approach adds to what the assistant knows, and because the memory self-organises, the picture sharpens rather than clogs as it fills. A project the assistant has worked on for six months is one where it genuinely carries the institutional knowledge, not one where it's drowning in stale notes.

That knowledge also stops being tied to individual people. When an engineer rotates off the project or leaves, the context they'd built up usually goes with them. An assistant on persistent project memory keeps the conventions, the war stories, and the reasoning regardless of who's currently on the team, which is the closest most projects get to onboarding documentation that maintains itself.

Who's building this

Teams building coding copilots, dev-tooling agents, and internal engineering assistants are the natural fit, anywhere an agent works the same codebase repeatedly and looks junior when it forgets the project's history.

For a self-contained pattern to learn from, the GitHub PR knowledge base example builds a searchable memory out of pull request history, which is one of the richest sources of project context a team already has lying around.

Get started

Begin with the getting started guide, then the GitHub PR knowledge base example for a concrete build. Memory scoping shows how per-project isolation works, and there's a free tier to start against.

FAQs

Does the assistant read my actual code, or just what I tell it?

It works with whatever you send it. Most teams feed memory from review discussions, resolved bugs, and decisions, and store design docs and ADRs as searchable Resources. Exabase isn't a code indexer that crawls your repo automatically; you decide what context flows in, which also means you control what it can see.

How does it handle a convention or library that changes?

The new decision supersedes the old one through entity resolution. When you migrate off a library, that fact replaces the previous standard rather than coexisting with it, so the assistant stops recommending the approach you've abandoned.

Can I keep separate projects from contaminating each other?

Yes. Put each project in its own Base and the memory, storage, and search for one are fully isolated from the others. An assistant in one Base never sees another Base's memories.

What about rolling back changes an agent made?

Bases support filesystem snapshots, so you can checkpoint state before a risky operation and revert if it goes wrong. The version control for agent context use case goes through this properly.

Isn't this just RAG over our codebase?

Search over your code and docs is part of it, and Deep Search provides that. The other part is persistent memory of decisions, conventions, and history, which is a different thing from retrieval. RAG would re-derive the project's context from raw chunks every session; memory holds the conclusions. The RAG vs agent memory piece explains the distinction.

Why not just use my framework's built-in memory?

Built-in memory is usually a short conversation buffer, which works until the project outgrows it. The point at which that happens, and what to do about it, is covered in when to outgrow your framework's built-in memory.