"How much memory does an agent actually need?"

"Can it remember things?" is usually the second question I get asked about any agent, right after "what can it do?". The honest answer is that most agents should remember far less than their owners want them to, and the ones that remember too much develop problems that are much harder to debug than forgetfulness. Before adding memory to anything, it is worth being precise about what the word actually means, because three different things hide behind it.

The first is working state: what the agent knows within a single run. Which files it has read, what the last tool call returned, what remains on its list. This is not memory in any interesting sense, it is the context window doing its job, and for a task that takes one sitting, it is all you need. An agent that processes an invoice, drafts a reply, or investigates one alert can start empty, work, finish, and forget. Statelessness is not a limitation here; it is a gift. Every run starts from a known position, every bug is reproducible from the inputs, and nothing that went wrong yesterday can contaminate today.

The second is persistent task state: work that spans sittings. A multi-day migration, a long-running research job, a queue being worked through. This still is not memory in the anthropomorphic sense, it is a checkpoint, and the right tool is boring: a database row, a JSON file, a status field. Write down what is done and what is next, in a structured form your code can validate, and let each session rehydrate from it. The mistake I see is teams reaching for a vector store and "conversation memory" when what they need is a table with a status column.

The third is genuine long-term memory: knowledge that should shape future behaviour. The customer prefers short replies. This supplier's invoices always misstate the VAT line. We decided in March not to use that API. This is the only category that deserves the word, and it is the only one that is architecturally hard, because the difficult part is not storage, it is retrieval and lifecycle. What is worth keeping? When is it stale? What happens when a remembered "fact" was wrong to begin with and now quietly biases every future run?

That last failure mode is real and underrated. Memory is a write channel into all future behaviour, which means a bad entry is a persistent bug. One hallucinated conclusion, one instruction that arrived embedded in an untrusted document, one observation that was true in January and false by June, stored, retrieved, and injected into contexts for months. I treat writes to long-term memory with the same suspicion as any other side effect: validated, attributable, inspectable, and deletable. If you cannot list what your agent believes and remove an entry, you do not have memory, you have sediment.

Summarisation deserves its own warning, because it is the default answer to "the context is getting long" and it is lossier than it looks. A summary is a model's opinion about what mattered. Compress a long working session and the details that get dropped are, reliably, the awkward ones, the caveat, the failed attempt, the exact error message you need three steps later. Worse, summaries of summaries compound the drift, and the agent ends up confidently acting on a paraphrase of a paraphrase. Where I can, I prefer retrieval over compression: keep the raw record somewhere cheap, keep a short structured index, and pull back the original text when it is needed, rather than trusting a précis written before anyone knew what would matter.

There is also a cost argument that gets missed. Everything you "remember" into the context is tokens on every call, and agents make many calls per run. Teams stuff history in because it feels safer, then wonder why the bill tripled and the model started ignoring instructions, long contexts do not just cost more, they dilute attention. Chroma's context-rot study put numbers on this: across eighteen frontier models, performance degraded as input length grew, on tasks far simpler than agent work, and no model held flat across its advertised window. The leanest context that lets the model do the step in front of it is almost always the best-performing one.

So my default is deliberately unexciting: no memory until a specific, observed failure demands it. Start stateless. Add a checkpoint when a task genuinely spans sessions. Add long-term memory only for named categories of fact, preferences, decisions, corrections, each with an owner, a format, and a way to expire. In the systems I run for my own business operations, the agents that work best remember almost nothing between runs; the durable knowledge lives in files and databases that anyone on the team can read, question and correct, not in an opaque store the model feeds itself.

If you are designing an agent and wrestling with what it should remember, or debugging one that remembers the wrong things, this is exactly the work I do. Get in touch via the contact form and we can work out the smallest memory design that actually holds up.