Why agents need external memory
An LLM has no memory of its own between calls — each request is independent, bounded by the context window. Anything you want it to 'remember' has to be re-supplied from outside.
So 'agent memory' isn't a model feature; it's an architecture you design around the model. The patterns below are the building blocks.
Pattern 1: a curated memory file
For durable facts — architecture, conventions, key decisions, constraints — a maintained file (like CLAUDE.md) that the agent reads each session is the simplest, most reliable memory.
It's high-signal and human-editable. The discipline is keeping it compact and current rather than letting it sprawl.
Pattern 2: retrieval (RAG)
For large or changing knowledge that won't fit in the window, store it externally and retrieve only the relevant pieces per task. This keeps the context focused and the knowledge base unbounded.
Retrieval shines for documentation and codebases; the risk is pulling irrelevant chunks, so quality of retrieval matters as much as storage.
Pattern 3: scratchpad and state
For an ongoing task, let the agent keep a working scratchpad — a running list of what it's done, decided, and still needs to do. This carries state across steps within a job.
Pair it with summarization: when a session gets long, compress the history into a short state summary and re-anchor, so the window stays usable.
Choosing and maintaining
Match the pattern to the data: curated file for stable facts, retrieval for big/changing knowledge, scratchpad+summaries for evolving session state. Most real agents combine all three.
Whatever you use, keep it curated and current. Memory's value is relevance; stale or bloated memory misleads the agent and wastes context.