Why coding agents forget what your team already knows

Ask an agent to find out why a build breaks on one service and not the other. It reads the workflow file, follows the cache key, notices the lockfile is regenerated in one repository and committed in the other, and tells you. Good answer. It took eleven tool calls to get there.

Tomorrow, a different engineer asks a different agent almost the same question. Eleven tool calls again. The two agents never met.

This is not a defect in any one tool. It is the shape of how coding agents work today, and it is worth being precise about the cause, because the wrong diagnosis leads to the wrong fix.

A context window is not a memory

The context window is the set of tokens the model can see while it answers. It is closer to a desk than to a filing cabinet. Everything on the desk is immediately available. Nothing on the desk is kept.

Within a session that is fine. The agent reads a file, holds it, reasons over it, and answers. The moment the session closes, the desk is cleared. The next session starts with an empty desk and the same repository, and has to derive everything again from the same sources.

So an agent is not forgetful in the way a person is forgetful. A person who investigated that build failure would remember the shape of it a week later, badly and incompletely, but they would remember. An agent has no mechanism to remember at all. It has retrieval, and retrieval only reaches what someone wrote down.

What is actually lost

Not the code. The code is still there, and the agent can read it again. What is lost is everything that was true about the code but not visible in it:

• The conclusion. The lockfile is regenerated in CI for service-a and committed for service-b, and that asymmetry is the cause.
• The path not taken. It is not the cache key, and it is not the Node version, both of which were checked first and look plausible.
• The reason it is that way. Someone made that choice deliberately in a pull request eight months ago, and the reason is in the review thread, not in the diff.
• The blast radius. Two other services copy the same workflow.

The code answers what. The investigation answers why, and why does not persist anywhere the next agent will look.

Why a bigger window does not solve it

The instinct is to give the model more room. Longer windows are genuinely useful, and they keep getting longer. They do not turn working memory into storage, for three reasons.

Someone still has to choose what goes in. A window of any size is filled by a retrieval step, and that step can only retrieve what exists. If the finding was never written down, a window ten times larger retrieves ten times more of the same raw material and reaches the same conclusion at greater cost.

Attention is not uniform. Relevant material buried in a large amount of marginally relevant material competes with it. Filling a window because it is available tends to make the answer worse, not better.

And the cost is real. Every token is paid for on every task. A system that pushes the whole repository into context on every question is paying continuously to re-derive things it already knew.

The useful question is not how much can the agent see. It is what deserves to be there.

The three places teams put knowledge now

Instruction files. CLAUDE.md, AGENTS.md, a rules file. These work well for stable conventions: use pnpm, the test command is this, never edit generated files. They work badly for findings, because they are read whole on every task, they carry no evidence, and nothing in them ever expires. We wrote about that boundary separately in what instruction files can and cannot hold.

Documentation. A wiki page, an architecture decision record, a runbook. Better at holding reasoning, worse at being found, and disconnected from the code by construction. A document does not know that the function it describes was deleted.

The person. In practice this is where most of it lives. Someone on the team knows. That knowledge is real, it is high quality, and it is available only when that person is available, which is why onboarding is slow and why a departure costs more than a headcount.

None of these is a memory in the sense the problem requires. A memory would have to be written without ceremony, retrieved by relevance rather than by path, and checked against the code before it is trusted.

What a memory would have to do

Four properties, and the fourth is the hard one.

It has to be written down at the moment of the finding, not at the end of the quarter, because knowledge that requires a separate act of documentation mostly does not get documented.

It has to be retrievable by an agent, which means addressable by what it is about rather than by where someone filed it.

It has to be shared across the team and across the repositories the team owns, because the same finding is usually needed by the next person, not by the same person.

And it has to be checked. Written knowledge decays as the code moves, and a stale finding stated confidently is worse than no finding at all. A memory that cannot tell you whether a claim still holds is a liability with a good user interface. That is the part we think is unsolved, and the part REM is being built to address: claims linked to evidence, reconciled against git, tests and history, so a claim can be shown to be still true rather than merely still written.

Until something does that, every agent session starts from zero, and every team pays for the same investigation more than once.