A developer shares a prototype memory architecture for multi-agent systems with separate storage for episodic, semantic, and procedural memories and intent-based retrieval, seeking feedback on scalability and design choices.
Hey everyone, I've been prototyping a memory system for a multi-agent framework (supervisor → sub-agents) and wanted to run my current setup by people who've actually built or run these in production. Trying hard not to over-engineer based purely on theory/taxonomy, so I’ve been running small experiments first. Here’s where I’m currently at: Pipeline & Flow Working/Session State → Raw conversation & tool calls go to a durable append-only event log. Batch Consolidation → Instead of processing every turn through an expensive extraction pipeline, a periodic batch job extracts useful Episodic Memories (storing this in a cheap local DB/SQL store because of high volume). Promotion Policy → Key facts and preferences get promoted into Semantic Memory (testing Mem0 here). Procedural Memory → Kept completely separate as a structured procedure/skill registry (e.g. Markdown files, task definitions) rather than generic vector embeddings. Retrieval Strategy Instead of searching across all memory stores on every single query, I'm testing routing by intent: User Query → Scope/ACL → Intent/Task Router → Targeted Store Retrieval → Context Injection "How do I request leave?" → Intent: Procedure → Pull from Skill Registry. "What did I work on last week?" → Intent: History → Pull from Episodic Store. "What language do I prefer?" → Intent: Preference → Pull from Semantic Fact Store. Observations from small tests so far: Storing raw episodic events straight in Mem0 added noticeable write/search latency and cost. Generic vector retrieval for procedures/workflows was messy and often grabbed 3–4 adjacent procedures. Exact/registry-style matching was much cleaner. Batch consolidation gave way cleaner facts than trying to extract semantic memories turn-by-turn. Where I’d love some brutal feedback/criticism: Routing vs. Parallel Retrieval: Is intent-based routing (scope → intent → target store) actually reliable in practice, or do queries usually end up needing multiple memory types simultaneously (e.g., preference + procedure in one shot)? Separate vs. Unified Storage: Am I prematurely splitting this into separate stores (Event Log / Cheap SQL / Mem0 / Registry), or is this separation pretty standard once volume picks up? At what scale does keeping everything in a single vector store/pgvector actually break down? Procedural Memory as Code/Skills: Treating procedural memory as structured skill files instead of vector embeddings feels right so far, but does this pattern break down when agents need to dynamically adapt workflows? Failure Cases: What obvious blind spots or edge cases am I missing that will force me to rewrite this V2? Appreciate any insights or horror stories from production!
A practitioner compares three memory architectures for long-running agents — full conversation history, vector-store-only retrieval, and a hybrid of structured episodic logs plus vector retrieval — concluding the hybrid approach works best and flagging memory conflicts during mid-task belief updates as a key open problem.
A developer discussion post asking how others handle persistent memory across AI agent sessions, comparing approaches like notes files, vector DBs, mem0, Zep, and Letta, and raising concerns about stale or outdated facts causing agents to act on obsolete decisions.
This article compares three common shapes of agent memory systems—file-based, structured store, and experience-based—and evaluates their effectiveness through a benchmark using a common agent loop and open-weight model.
The post questions whether memory in AI agents is essential or a workaround for poor architecture, and asks practitioners what needs to be persisted in production systems.
The author reflects on challenges in multi-user agentic memory, emphasizing the need for architectural boundaries between private and shared memory sessions, and discusses building an open-source project to address this.