Long-term memory for AI agents.

Interactive assistants forget between chats; agents forget between runs — and agents run constantly. A nightly report generator, a PR-review bot, a research agent on a weekly schedule: each invocation is a fresh process with a fresh context window. Without an external memory, every run repeats the discoveries, mistakes, and clarifying questions of the last one. With one, runs compound.

Why agents need memory more than chatbots do

• No human in the loop to compensate. In chat, you paste the missing context. An unattended agent has nobody to do that.
• Repetition amplifies waste. A forgotten preference costs one user one correction; an agent repeats the error on every scheduled run.
• State is the product. Many agent tasks — track this, monitor that, continue yesterday's work — are literally definitions of memory.
• Multi-agent coordination. When several agents (or an agent plus its human) collaborate, a shared store is the only sane communication channel across time.

The three-layer architecture

Layer 1: Working memory (the context window)

Everything the model sees during a single run: the task prompt, tool results, intermediate reasoning. It's fast, rich — and gone at process exit. Design principle: treat it as a cache, never as the system of record (why the window can't be the store).

Layer 2: Episodic memory (facts across runs)

Durable, atomic facts written during runs and recalled in later ones: decisions made, obstacles found, preferences learned, state reached. This is the layer people mean by "long-term memory." It needs four operations: write (remember), semantic read (recall), revise, and delete.

Layer 3: Reference knowledge (documents)

The corpus the agent grounds its work in: specs, changelogs, policies, prior reports. Retrieved by similarity, cited by source — classic RAG, distinct from episodic facts (memory vs RAG).

The practical question is where layers 2 and 3 live. Building them per-agent means a vector store, embeddings, and CRUD plumbing per project. The emerging alternative: a hosted context layer speaking MCP, so any agent runtime that supports the protocol — Claude Code, API-built agents, custom loops — gets all three operations without infrastructure. VeelIQ Context is exactly this: remember, recall, and search_knowledge behind one endpoint URL.

Write policy: what should an agent remember?

The classic failure is writing too much. An agent that remembers everything drowns its own retrieval in noise. A workable policy:

• Decisions with rationale — "Chose polling over webhooks; the vendor API drops events."
• Durable environment facts — "Staging deploys require the VPN; prod deploys don't."
• Human corrections — the highest-value writes an agent can make. Every correction remembered is a correction never repeated.
• Progress markers — "Migrated tables A–F; G blocked on legacy auth."
• Not: raw tool output, transcripts, or anything reconstructible from the corpus. Store the conclusion, link the source.

Read policy: recall at the right moments

1. Run start — recall against the task description: "What do I already know about tonight's release-notes job?"
2. Before decisions — recall against the decision topic, so past rationale (and past failures) inform the choice.
3. On surprise — when a tool call fails or output looks unexpected, recall the anomaly; the workaround is often already stored.

Semantic recall is what makes this cheap: the agent doesn't enumerate its memory, it asks for what's relevant and gets the top matches injected as a few hundred tokens.

Memory hygiene for unattended systems

Because agents write autonomously, hygiene is a safety property, not just a quality one:

• Auditability — a human must be able to list, edit, and delete everything the agent stored. A dashboard beats a database dump.
• Contradiction handling — new facts should supersede old ones explicitly ("deadline moved to Aug 14, was Jul 30"), not coexist with them.
• Scoping — separate stores per project or client (workspaces) prevent cross-contamination between unrelated agents.
• Retention — progress markers can expire; decisions and corrections should persist. Time-to-live per category works well.

The fuller checklist lives in best practices for AI memory systems.

A worked example

A weekly competitive-research agent, over four runs:

1. Run 1 — cold start. Asks its owner two clarifying questions; remembers both answers and the report format that was approved.
2. Run 2 — recalls format and preferences; produces the report unaided. Owner corrects one competitor's name; the correction is remembered.
3. Run 3 — recalls the correction; searches the knowledge corpus (last quarter's strategy PDF) to frame findings against company goals; remembers a new competitor it discovered.
4. Run 4 — the new competitor is now tracked automatically. Zero questions, zero corrections, grounded citations.

Nothing about the model changed. The agent got better because its memory did — the pattern detailed in the long-term memory use case.

Key takeaways

• Agents need memory more than chatbots: no human compensates, and repetition amplifies every gap.
• Three layers: context window (cache), episodic facts (remember/recall), reference knowledge (RAG). Only the first is free; the other two need a store.
• Write conclusions and corrections, not transcripts; recall at run start, before decisions, and on surprise.
• Auditability and scoping are non-negotiable when software writes to its own memory.

Related reading