Working Memory

An agent runs almost entirely on working memory. What it lacks is long-term memory of the decisions your codebase encodes, and no context window holds that.

August 7, 2026 7 min read

An AI coding agent runs almost entirely on working memory. For each task it assembles a context window: the files you have open, the snippets a retriever pulled in, the system prompt, the instructions, the conversation so far. That window is large and it is capable, and it is also the whole of what the agent knows about your system at the moment it acts. When the task ends, the window is discarded. The next task starts a new one.

The word memory does a lot of quiet work in how these tools get described, and it helps to separate two senses of it. Working memory is the scratch space a process holds while it does one thing. Long-term memory is what persists afterward and is available the next time it is relevant. An agent has a large, capable working memory and, on its own, no long-term memory of your team at all.

What the window holds, and what it does not

The context window is good at what working memory is good at. Give the agent the relevant files and a clear task and it will reason over them well. Its ceiling is not intelligence. It is scope. The window holds what was assembled for this one task, and what gets assembled is drawn from two things: what sits near the code being changed, and what a retriever judged similar to the request. Both are properties of the code as it exists right now.

What the window does not hold is the set of decisions that produced that code and still govern it. Why the service is split the way it is. Which approach was tried, failed, and should not be tried again. Which constraint is load-bearing and which is incidental. That information is not in the files in a form a retriever can surface, because most of it was never written into the files at all. It lived in the people who made the decisions and in the discussions where they were made.

Bigger windows and better retrieval do not close the gap

The natural response is that context windows keep growing and retrieval keeps improving, so this is a temporary limitation. It is not, because both of those improve working memory and neither adds long-term memory.

A larger window lets the agent hold more of the codebase at once, but more room is not the constraint: it does not tell the agent which parts of what it is holding were chosen deliberately and which are accidents of history. Retrieval, in turn, selects what to put in the window, and retrieval by similarity tends to surface the code most like the request, which is often the very convention a change is meant to move away from. Neither mechanism has access to a record of decisions, because for most teams no such record exists in a place either mechanism can read.

The recent wave of agent memory tools does add persistence across sessions, and it is genuinely useful. What it persists, though, is a different kind of thing: the facts and preferences from your interactions, and in some tools the notes an agent accrues as it works. That is memory of the exchange, and of what the agent has picked up along the way. It is not a structured record of the decisions a team has made and the reasons behind them, held so that the one governing a change arrives with that change. The distinction is not how much these tools remember. It is what kind of memory it is.

The symptom is drift, not failure

Because working memory is genuinely good, the gap does not present as an agent that fails. It presents as an agent that is locally correct and gradually adrift. Each task, taken on its own, is done reasonably: the code compiles, the tests pass, it matches its surroundings. Across many tasks, the architecture the team actually decided on erodes, because nothing in the loop is holding those decisions steady. There is no long-term memory keeping them in force, only a sequence of working memories, each doing its competent best with whatever happened to be nearby.

This is the same reason a large system stays coherent while the people who hold its decisions are present and reviewing, and begins to wander once they are not. The agent is the case where they are structurally never present. It was not in the room when the decisions were made, and on its own it carries nothing about them from one task to the next.

Where a decision layer sits

If the missing piece is long-term memory of decisions, the shape of the fix follows from it. It is not a larger window and not a better retriever over the code. It is a separate store whose contents are the decisions themselves and the reason behind each one, indexed not by textual similarity but by which change a decision governs, and surfaced into the agent's context at the moment it reaches that change.

That store is what Brief is. It holds the decisions a team has made, with their rationale, and supplies the relevant one when the agent is working on something that decision bears on. It sits beside the context window as the long-term layer the window does not have: not more of the code, but a record of what the team decided about the code, available at the point of use. The working memory stays the agent's; the long-term memory becomes something the team can hold on to.

None of this makes the context window less important. An agent still needs a good working memory to do a task well, and the tooling that assembles and fills that window is doing real work. The point is narrower. A working memory, however large, is not a substitute for a memory that persists, and the thing most worth persisting is the set of decisions the code cannot explain on its own. So it is worth asking, of any agent about to change your system: what does it actually retain about why the system is the way it is, and where is that memory meant to live?

Frequently asked questions

Do AI coding agents have long-term memory? On their own, no. An agent assembles a context window, its working memory, for each task from the open files and retrieved snippets, and discards it when the task ends. It has no built-in memory of your team's decisions that persists across tasks unless that record is stored somewhere it can read.

Does a bigger context window give an agent memory of my codebase? A bigger window lets the agent hold more code at once, which improves its working memory, but it does not add a record of which parts were chosen deliberately or why. Holding more of the code is not the same as knowing the decisions behind it, and most of those decisions are not written in the code at all.

What is the difference between agent memory tools and decision memory? Agent memory tools persist things from your interactions, such as facts, preferences, and notes an agent accrues as it works, so it does not repeat itself. Decision memory is a structured record of the choices a team has made about its system and the reasons behind them, indexed by the change each one governs. The first is memory of the exchange; the second is what an agent needs to stay aligned with an architecture it never helped design.

How do you give a coding agent long-term memory of your team's decisions? Store the decisions and their rationale in a durable layer, indexed by the change each one governs, and surface the relevant decision into the agent's context at the moment it works on something that decision affects. A product context layer such as Brief does this, so the agent works from the team's decisions rather than only from the code in front of it.