Short-, Long- and External Memory Strategies
Distinguish the three memory layers every agent uses — short-term working context, long-term learned facts, and external retrieval — and pick the right layer for each piece of state so the agent doesn't blow the context window or leak stale data.
Short-, Long- and External Memory Strategies
An agent without a memory strategy is just a chatbot with amnesia. The exam expects you to name three layers — short-term, long-term, and external — and explain which kind of state belongs in each.
The three layers
| Layer | Lifetime | Authority | Examples | | --- | --- | --- | --- | | Short-term | This turn / this session | Volatile, model-visible | Current message, scratchpad, intermediate tool outputs | | Long-term | Across sessions | Agent-owned, low-churn | User preferences, repo conventions, "lessons learned" | | External | Live, on demand | Authoritative system of record | Source code, tickets, DB rows, MCP resources |
The cardinal rule: never store authoritative mutable data in long-term memory. If a file, ticket or row can change without the agent noticing, it must live in external memory and be fetched fresh.
Layered together
A well-built agent uses all three on the same turn:
- External memory retrieves the current file contents from the repo.
- Long-term memory recalls "this user prefers explicit return types in TypeScript".
- Short-term memory holds the plan and the running diff for the active edit.
The agent's working set is the curated slice of those three layers that actually reaches the model. Keep the working set small — context budget is finite, and irrelevant memory crowds out the bits that matter.
Sort the items into layers
Sort by memory layer
Drag each item into the memory layer where it should actually live.
Where this shows up on the exam
Expect a scenario question that hands you a piece of state and asks where it belongs. The trap answer is almost always long-term memory for something that changes (a ticket status, a file's contents). When in doubt, ask: if this value changed in the source system, would my agent notice? If the answer is no, you've picked the wrong layer.
Key terms
- Short-term memory
- The active context window: the current message, scratchpad, tool outputs, and intermediate plans the model sees this turn. Volatile by design.
- Long-term memory
- Facts the agent has learned and chosen to persist across sessions — user preferences, repository conventions, prior decisions — typically stored in a dedicated memory store.
- External memory
- Authoritative data the agent fetches on demand via retrieval, MCP resources, or tool calls — source code, docs, tickets, databases — never trusted as in-model recall.
- Working set
- The subset of memory promoted into the current context for the active task. Keep it small enough to reason over, large enough to be correct.
Common pitfalls
- Treating the model's in-weights recall as memory: the model can confidently hallucinate facts it never stored. Anything load-bearing must live in long-term or external memory.
- Dumping the entire long-term memory into every turn: the context window fills with stale preferences and the agent loses focus on the current task.
- Storing authoritative data (current ticket status, file contents) in long-term memory: it goes stale within minutes. Authoritative data belongs in external memory and is fetched fresh.