Why Does Your AI Agent Keep Forgetting, And What Is That Costing You?

Last Updated: 30 October 2026

Your agent keeps forgetting because it never remembered. A language model has no memory between calls. What looks like memory is your application replaying earlier messages, or retrieving stored text, and putting it back into the context window. When that window fills, something has to give: either the oldest material is dropped, or the conversation is compressed into a summary, and both lose detail the user assumed was permanent.

The problem is not that agents forget. It is that teams build agents that appear to remember, then discover the appearance breaks at scale. In January 2026, a paper titled "AI Agents Need Memory Control Over More Context" described the failure precisely: as interactions grow, agent behaviour degrades through loss of constraint focus, error accumulation and memory-induced drift. The authors also name the cause, which is the two techniques most teams reach for first. Transcript replay and retrieval-based memory both produce unbounded context growth, and both are vulnerable to noisy recall and memory poisoning.

This post covers why forgetting happens, what the research says about bounded memory, what forgetting costs in hours, what you should store versus throw away, and how to test whether your agent's memory is holding.

Why does an agent forget?

Because the context window is the whole of its working memory. Every turn sends the model a fresh prompt containing the system instructions, the available tools, the recent messages and any retrieved documents. The model reads that prompt, produces a reply and forgets all of it. The next turn rebuilds the prompt from scratch. If your application does not include an earlier fact, the model cannot know it.

That design has a hard ceiling. A large context window holds a lot, but it is finite, and the cost per turn rises with everything you put in it. Long before the ceiling is reached, quality starts to fall: the model pays less attention to material in the middle of a long prompt, and instructions given early compete with details given late.

When the window fills, applications usually do one of two things. They truncate, dropping the oldest messages and losing the facts that were established first. Or they compact, asking a model to summarise the conversation so far. Compaction keeps the thread alive but loses specifics, and a summary of a summary degrades quickly.

Our own gateway is a worked example. One Telegram session reached 254,000 tokens against a 242,000 token budget, which meant every single turn triggered a compaction pass before the model could answer. The fix was to cut how much history was replayed per turn and to raise the timeouts. The agent did not get smarter. It got a smaller, better-managed working set.

What is the difference between context and memory?

Context is what the model sees right now. Memory is what your system chooses to put back into context later. The distinction matters because it tells you where the engineering effort belongs. The model cannot manage memory. Your application has to.

Most agent stacks have three layers, whether they admit it or not. The first is the transcript, the raw record of what was said. The second is long-term storage, usually a database or a vector index, holding facts, documents and prior outcomes. The third is the assembled prompt, which is a selection from the first two plus the current turn.

Forgetting happens at the selection step. The transcript may contain the client's account number, the storage may contain the contract terms, and the prompt may contain neither because the retrieval ranked something else higher. From the user's point of view the agent forgot. From the system's point of view the agent was never told.

That reframing is useful because it turns a vague complaint into a testable question: was the fact available, was it retrieved, and was it ranked into the prompt? Each of those can be instrumented, and each fails in a different way.

What goes wrong when memory grows without bound?

Three things, and the paper names all of them. The first is loss of constraint focus. As the prompt fills with history, the rules that were stated at the start carry less weight, and the agent starts to drift from the brief. The second is error accumulation. A mistake made in turn four becomes part of the record, gets summarised into the state, and is treated as fact in turn forty.

The third is memory-induced drift, which is the compounding version of the first two. The agent's behaviour changes over a long session not because the model changed but because its memory did. The paper describes this as especially visible in real deployments where context evolves, distractions appear and decisions must stay consistent over time.

Then there is the security problem. Retrieval-based memory is vulnerable to noisy recall, where the wrong document is returned with high confidence, and to memory poisoning, where unverified content is written into persistent memory and then treated as established. A single injected instruction that survives into long-term storage can influence every future session. That is not a prompt injection that ends when the window clears. It is a prompt injection with tenure.

What is a bounded memory controller?

The paper's contribution is the Agent Cognitive Compressor, a memory controller that replaces transcript replay with a bounded internal state, updated online at each turn. Two design choices do the work. The first is that the state has a fixed size, so context growth is capped by design rather than by luck. The second is that it separates artifact recall from state commitment.

That separation is the important idea. Artifacts, which are documents, records and retrieved evidence, stay in recall and can be fetched again when needed. State, which is the agent's working understanding of the task, is committed deliberately and updated each turn. Unverified content can be recalled without becoming part of the committed state, which closes the memory poisoning path.

The authors evaluated the controller with an agent-judge framework that measures both task outcomes and memory-driven anomalies across extended interactions. Across scenarios in IT operations, cybersecurity response and healthcare, the bounded controller maintained bounded memory and showed more stable multi-turn behaviour, with significantly lower hallucination and drift than transcript replay and retrieval-based agents.

You do not need to adopt this specific architecture to get the benefit. The principles are portable: cap the state, update it every turn, keep evidence separate from belief, and require verification before anything becomes permanent.

What does forgetting cost a business?

It costs repeat work, and repeat work is measurable. Take a support team handling 400 tickets a day. If 20% of tickets require the customer to re-explain something the agent should have known, and each re-explanation costs 3 minutes of agent and customer time, that is 240 minutes a day, or 40 hours a month.

That is our arithmetic on an illustrative process, not a vendor claim, and the assumptions are deliberately ordinary. A 20% re-explanation rate is not a disaster. It is the sort of number teams accept because it is spread thinly across hundreds of conversations. But 40 hours a month is half a full-time person, and it does not appear anywhere in the reporting because nobody logs "customer explained it again".

The second cost is trust. A customer who has to repeat themselves twice starts to treat the agent as a form, not an assistant, and routes around it. The third is internal: when the agent forgets an agreed outcome, a person has to reconcile the record, which is exactly the work the agent was supposed to remove.

What should you store, and what should you throw away?

Store decisions, commitments and verified facts. Throw away raw chatter, intermediate reasoning and anything you cannot attribute. A useful rule is that memory should hold what a competent colleague would need on their first day back from leave: the client's preferences, the agreed outcome, the constraints, and the open items.

Timestamp everything. A fact without a date becomes a trap, because the agent cannot tell whether it is current. "The client is on the enterprise plan" is useless if it was true eight months ago. "On 12 March 2026 the client confirmed the enterprise plan" is usable, and it can be superseded by a later entry.

Expire what you cannot verify. Access permissions, pricing and contact details all change. A memory system with no expiry policy slowly fills with facts that were true once, and the agent has no way to distinguish them from facts that are true now. Expiry is not just hygiene. It is accuracy.

Keep evidence separate from belief. Retrieved documents should be labelled as retrieved, with a source and a date, and they should not silently become part of the agent's committed understanding. That separation is what the paper calls artifact recall versus state commitment, and it is the difference between an agent that can cite its reasoning and one that cannot.

How do you test an agent's memory?

Replay twenty turns. Give the agent a fact in turn three, a contradiction in turn nine and an irrelevant distraction in turn twelve, then ask about the fact in turn twenty. If the answer is right, the memory is holding. If it is wrong or hedged, you have found the failure before a customer does.

Run the same test after every model change, every prompt change and every memory configuration change. Memory bugs are quiet, and they tend to appear when a model upgrade changes how the agent summarises. A fixed test set turns that from a surprise into a regression check.

Instrument the retrieval step as well. Log which artifacts were retrieved, which were ranked into the prompt and which were dropped. When a user complains that the agent forgot, you can answer the actual question: was the fact available, retrieved and included, or was it never there?

What does this mean for Australian businesses?

Memory is a liability surface, not just a feature. Anything the agent remembers about a person is personal information under the Privacy Act 1988, and APP 11 requires you to protect it and to destroy or de-identify it when it is no longer needed. A memory store that grows forever is a retention problem waiting for a privacy officer to find it.

Two practical consequences. First, decide retention before you switch memory on, and write it down: what is stored, for how long, who can read it and how it is deleted. Second, treat memory poisoning as a security control, not a model quirk. If unverified content can be committed to long-term memory, then any document the agent reads is a potential instruction that outlives the session.

For most Australian mid-market businesses the right starting point is a small, bounded memory with a clear owner and an expiry policy, rather than a vector database of everything the company has ever said. The second is easier to sell and much harder to defend.

How do you start?

Start by listing what your agent currently puts back into context on each turn. Most teams discover it is the full transcript, which is the unbounded design the paper warns about. Then set a budget: a fixed number of tokens for state, a fixed number for retrieved artifacts and a fixed number for the current turn.

Next, separate the two kinds of memory. Facts the agent has verified go into committed state with a timestamp and a source. Documents and records stay in recall, fetched when needed and labelled as retrieved. Nothing becomes permanent without a verification step.

Then run the twenty-turn replay and fix what breaks. If you want a concrete example of an agent working inside a bounded pipeline, our post on designing an agent around a real workflow shows the same discipline at the workflow level. If your agent is forgetting things it should know, talk to us before you add another database.

Frequently asked questions

Why does my AI agent forget things mid-conversation?

Because the model has no memory between calls. Each turn rebuilds a prompt from what your application sends. When the context window fills, applications truncate the oldest messages or compact the conversation into a summary, and both lose detail the user assumed was permanent.

What is the difference between context and memory in an agent?

Context is what the model sees right now. Memory is what your system chooses to put back into context later. The model cannot manage memory, so the selection step in your application decides what the agent appears to remember.

What is memory poisoning?

Memory poisoning is when unverified content is written into an agent's long-term memory and later treated as established fact. Because it survives the session, a single injected instruction can influence every future interaction. Keeping evidence separate from committed state is the control.

How much does agent forgetting cost?

In our illustrative support example, a 20% re-explanation rate at 3 minutes per ticket across 400 tickets a day is 40 hours a month of repeat work. That is half a full-time person, and it rarely appears in reporting because nobody logs the repeat conversation.

How do I test whether my agent's memory works?

Replay twenty turns. State a fact in turn three, introduce a contradiction and a distraction, then ask about the fact in turn twenty. Run the same test after every model or prompt change, and log which artifacts were retrieved and ranked into the prompt.