Why AI Coding Agents Forget and How to Fix It

If you have used an AI coding agent for more than a day, you have probably had this moment: you told it something important on Monday, and on Tuesday it acted as if it had never heard it. The short answer is that these agents do not have memory the way a colleague does. Each session starts blank, and even inside one session the agent can only hold so much at once.

This guide explains that limit in plain words, shows how it affects a project, and lists what you can do about it. It is based on the documentation for Claude Code, Anthropic's coding agent. You do not need to write code to apply any of it.

Why does my AI coding agent forget what I told it?

Two different things are going on, and they get mixed up.

First: every new session starts fresh. The Claude Code documentation says each session begins with a fresh context window, without the conversation history from previous sessions. The "context window" is the agent's working memory for the current conversation. When you close a session and open a new one, yesterday's chat is not in it.

Second: working memory fills up during a long session. The context window holds your conversation, the files the agent has read, the output of commands it has run, and its standing instructions. As it fills, Claude Code clears older tool output first and then summarises the conversation if needed. The documentation says your requests and key code snippets are preserved, but detailed instructions from early in the conversation may be lost.

Think of a capable contractor with a small desk. They can do excellent work, but only with the papers on the desk. When the desk is full, older papers go into a folder and a short note replaces them. The note is useful, but it is not the whole paper.

What does this look like on a real project?

A few everyday examples:

• The naming rule. You say early on, "Always call customers 'members' on screen, never 'users'." Two hours later, a new screen says "users". The rule was only in the conversation, and the conversation was summarised.
• The repeated question. Every Monday the agent asks which test environment to use, because nobody wrote the answer anywhere it reads at the start.
• The forgotten decision. You agreed last week not to touch the billing screens. A fresh session has no idea.

None of these mean the tool is broken. They mean the information lived only in a chat.

How do you make an AI coding agent remember?

Write things down in a place the agent reads at the start of every session. Claude Code has two such places.

A project instruction file you write

Claude Code loads a file called CLAUDE.md at the start of each session. It holds instructions you want followed every time: how your product talks to customers, what to avoid, how to run the checks. If your project already has an AGENTS.md file, which other coding agents use, Claude Code can read that in place of a CLAUDE.md.

For a non-coder, the practical advice is this:

1. Say it once, in writing, in plain words. "Customers are called members on every screen" is better than "keep the wording consistent".
2. Keep it short and specific. The documentation says the more specific and concise your instructions, the more consistently Claude follows them.
3. Keep it current. An old rule that contradicts a new one confuses the agent just as it would confuse a new hire.
4. Include what you would tell a new team member on day one: what the product is for, what is off limits, how you want updates reported.

Notes the agent writes for itself

Claude Code also has "auto memory": notes Claude writes itself based on your corrections and preferences. It decides what to save by judging whether the information would be useful in a future conversation. The first 200 lines or 25KB of the main notes file are loaded at the start of each session. The notes are plain files you can view and edit, and they are worth a glance now and then, because the agent wrote them, not you.

Put task details in the request

Memory files are for lasting rules. Details that belong to one task go in the request itself: the goal, the limits and what "done" looks like.

Is a written rule a guarantee?

No, and this is the part many managers miss. The documentation says Claude treats these files as context, not enforced configuration. A rule in the instruction file is a strong suggestion that is usually followed, not a lock.

So sort your rules into two piles:

• Preferences. Wording, style, how to report progress. Put these in the instruction file. An occasional slip is annoying, not harmful.
• Hard limits. Never delete customer data, never email real customers, never change payment settings. A sentence is not enough here. The documentation says that to block an action regardless of what Claude decides, you use a hook (it names the PreToolUse hook), which is a small automatic check that runs before an action and can stop it. Ask an engineer to set that up.

How do you stop a long session from losing the plot?

A few habits help, even if you never open a terminal:

• Split big jobs into separate sessions. One session per feature keeps the working memory cleaner. A fresh session with a good written brief is often safer than a long one that has been summarised several times.
• Re-state the key constraint when a task changes direction. One sentence is cheap.
• Ask for a status summary before you stop. "Write down what you did, what is left, and what you decided" gives the next session something to start from.
• Notice the warning signs. If the agent contradicts earlier choices, repeats questions or undoes agreed work, its working memory is probably crowded. Start fresh with a short written summary.

The documentation also describes ways to control what survives. An engineer can run the /context command to see what is using space, and can add a "Compact Instructions" section to CLAUDE.md to say what should be kept when the conversation is summarised. Helper agents called subagents work in their own separate working memory and hand back only a summary, which keeps the main conversation lighter.

What does forgetting cost?

It costs rework, and rework costs time and plan usage. If an agent builds three screens with the wrong wording, someone has to find and fix all three. The cheapest moment to prevent that is the moment you write the rule down.

How Atlas handles this

Atlas is a team of AI engineers built on Claude Code, and it works within the same limit. Each engineer is its own Claude Code session with a written role and its own working folder. Work lives on a board in a database, so a task does not depend on anyone's chat. Engineers checkpoint, so after a restart they resume where they stopped. Lessons from finished work are passed to future engineers; one is held back as a control, and lessons that track worse results or higher cost are retired automatically. Atlas does not currently show you a single page of what the team remembers. You can read more on the Atlas home page.

Conclusion

AI coding agents forget because of how they are built: a blank start each session and a limited working memory within it. You cannot change that, but you can work with it. Write lasting rules down in short, plain words. Keep task details in the request. Split big jobs. For anything that must never happen, ask for a hard block rather than a polite sentence.

The next time your agent repeats a mistake, ask one question first: where is that rule written down?