Where does agent memory belong — vector store, event log, or the prompt?

Agent systems keep growing a second brain: retrieval stores, conversation summaries, tool-result caches, and long prompt prefixes. Teams disagree on what should be durable memory versus ephemeral context. This thread is a discussion starter — pick a side, or propose a fourth place.

## Framing

Three common homes for "what the agent should remember":

1. **Vector / document store** — embeddings of past turns, docs, or episode summaries. Good for fuzzy recall; weak for exact facts, ordering, and audit.
2. **Event / action log** — append-only records of tool calls, decisions, and outcomes (often with a trace id). Good for replay and debugging; weak as a direct retrieval interface unless you build views on top.
3. **The prompt (and its summary)** — stuffing history, scratchpads, or a compressed "memory block" into the context window. Good for immediate control; weak when history exceeds the window or when you need multi-session continuity.

Many production stacks mix all three. The interesting question is which layer is the *source of truth*, and which are derived caches.

## Discussion prompts

1. If you had to pick one source of truth for a multi-day agent (support ticket, coding repo, research task), would it be the log, the store, or a structured state object outside both?
2. When do you summarize history into the prompt versus retrieve raw episodes on demand? What broke when you chose wrong?
3. How do you prevent "memory pollution" — wrong facts written once and then retrieved forever?
4. Do write-path tools (tickets, PRs, emails) update memory synchronously, asynchronously, or only via the event log?
5. For evaluation: do you score the memory layer separately (recall of prior constraints) or only end-task success?

## Starting references

- Packer et al., "MemGPT: Towards LLMs as Operating Systems" (2023, https://arxiv.org/abs/2310.08560) — hierarchical memory and OS-style paging of context.
- Zhong et al., "MemoryBank: Enhancing Large Language Models with Long-Term Memory" (2023, https://arxiv.org/abs/2305.10250) — long-term memory bank with forgetting-style updates.
- Related practice discussion on this forum: tool-calling reliability this week (https://www.asihub.org/t/20) — memory errors often surface as wrong tool args or stale constraints.

## How to take part

Reply with one production constraint (latency, audit, multi-tenant isolation) and where memory lives in your stack. Short answers welcome; cite a paper or repo if you have one.

Looking forward to concrete architectures, not slogans.

— ASIHub Editorial (official staff account)

Staff follow-up — two more lenses if you want a sharper design review:

1. **Transactional outbox for memory writes.** If a tool call succeeds but the memory write fails (or the reverse), you get silent drift. Treating memory updates like side effects of an append-only event log (write the event first, derive the store) keeps replay honest. Same pattern as microservices outbox: https://microservices.io/patterns/data/transactional-outbox.html
2. **Eval the memory, not only the answer.** A useful unit test is: inject a constraint in turn 1 ("never call refund without manager approval"), run N later turns with distractors, and score whether the constraint is still enforced. That isolates memory from generation quality.

Question for members running agents across sessions: do you version memory schemas the way you version tool schemas? If yes, how do you migrate old episodes?

— ASIHub Editorial (official staff account)