AI agents forget because the model only sees the context you provide for the current run, while useful facts live across prior sessions, documents, tickets, and tool calls. The fix is an external memory layer with a deliberate write path, scoped retrieval, citations, and inspection.
Why do agents forget?
Agents forget for the same reason a stateless API call forgets: prior information is not automatically present unless the application sends it or stores it. When you build your own agent, you own the memory architecture: the application has to decide which facts should be written, recalled, inspected, and deleted.
OpenAI’s conversation state guide makes that application boundary explicit: developers need to manage or reference prior state when they want continuity across responses (OpenAI conversation state guide). Memory is the product layer that decides what state deserves to survive.
What are the most common forgetting failures?
Most forgetting bugs fall into five buckets:
| Failure | Symptom | Root cause |
|---|---|---|
| Session reset | The agent asks for the same setup every time. | No durable store for prior facts. |
| Context compaction | Important details disappear after a long run. | Temporary context was summarized or dropped. |
| Retrieval miss | The source exists but is not recalled. | Search, ranking, or scope failed. |
| Stale recall | The agent uses an old policy or price. | No supersession signal. |
| Hidden conflict | Two memories disagree and the agent chooses one silently. | No inspection or conflict handling. |
These are not all model problems. They are memory product problems.
Why is a bigger context window not enough?
A bigger context window helps when the missing fact is already known and can be sent to the model. It does not decide which facts should be preserved, which source is current, who is allowed to see the fact, or how to delete it later.
Anthropic’s context engineering guidance focuses on selecting the right context for agents (Anthropic context engineering). That is the right frame. Memory is one input to context engineering; it is not a replacement for careful source selection.
The durable fix is a write path. When the agent learns a fact that should matter later, the system stores it with source, scope, type, and lifecycle metadata. When the user asks a related question later, retrieval brings the right memory back with citations.
Why is chat history not the same as memory?
Chat history is a source. It is not necessarily memory.
A full transcript may include jokes, false starts, private notes, temporary plans, and facts that changed. If a product retrieves raw history without a write policy, the agent may recall noise. If a product summarizes history without source links, the user may not be able to inspect the answer.
Useful memory is curated enough to retrieve and inspect:
- A source artifact or transcript segment.
- A summary or extracted fact.
- Scope metadata.
- A current/superseded state.
- A deletion handle.
- A citation back to evidence.
Research and framework docs commonly separate short-term state from long-term memory for this reason (LangChain memory concepts, survey of memory mechanisms).
How does MCP help fix forgetting?
MCP helps because it gives agent clients a standard way to call a memory server. Instead of wiring memory separately for each agent, a team can expose recall, source search, and context tools through one server.
The Model Context Protocol does not solve memory quality by itself. It solves delivery. The memory server still needs source ingestion, retrieval, citations, tenant scope, supersession handling, and deletion behavior.
That delivery layer is still important. If Claude Code, Cursor, and another agent can use the same memory server, the user does not need to rebuild memory for every tool.
How do you fix agent forgetting in practice?
Start with a narrow loop:
- Choose one source the agent needs: docs, tickets, transcripts, or a website.
- Ingest it into a source-aware memory store.
- Store source IDs and citation spans.
- Expose retrieval through MCP or an API.
- Ask the agent a question whose answer is in the source.
- Inspect which source was retrieved.
- Add supersession or deletion metadata before you scale.
The inspection step matters. If the agent answers incorrectly, you need to know whether the memory write failed, retrieval missed, ranking picked the wrong source, or the model ignored evidence.
What should you avoid?
Avoid these shortcuts:
- Dumping a large raw export into every prompt.
- Treating the vector database as the full memory product.
- Calling old source snapshots current.
- Publishing a benchmark claim without a reproducible scorecard.
- Saying the system forgets if derived summaries or embeddings remain retrievable.
- Locking memory to one agent client when the user needs multiple tools.
Those shortcuts create the same failure in different clothes: the agent sounds confident, but nobody can inspect why.
Where does Answer Engine fit?
Answer Engine fixes the practical forgetting path by giving agents a persistent, source-aware memory layer available through MCP. It is built for grounded recall from your own sources, not for vague promises that the model will improve itself.
The launch claim should stay honest: persistent memory, citations, tenant isolation, and an inspection direction. Deeper retrieval evaluation, richer cold-path inspection, and stronger erasure proof should remain labeled as roadmap until shipped and verified.