Design Layered Memory Architectures
Designs layered agent memory - working, short-term, long-term, entity, and temporal knowledge graphs - with benchmark comparisons.
Why it matters
Build sophisticated AI agents that persist across sessions and reason over accumulated knowledge by designing layered memory architectures.
Outcomes
What it gets done
Design short-term, long-term, and graph-based memory architectures.
Implement temporal knowledge graphs for time-aware queries.
Optimize memory layers from working memory to permanent storage.
Understand limitations of vector stores and benefits of graph-based memory.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-memory-systems | bash Overview
Memory System Design
Guides layered agent memory design across five tiers - working, short-term, long-term, entity, and temporal knowledge graph memory - with a benchmark comparison (Zep, MemGPT, GraphRAG, Vector RAG), four implementation patterns, retrieval patterns, and a memory consolidation process. Use when designing agent memory that must persist across sessions, track entity consistency, or reason over how facts changed over time.
What it does
Guides the design of layered memory architectures that let agents persist across sessions and reason over accumulated knowledge, rather than losing all state when a session ends. It frames memory as a spectrum from immediate context (zero latency, volatile) to permanent storage (persists indefinitely, requires retrieval), and traces the evolution from vector stores to knowledge graphs to temporal knowledge graphs as increasing investment in structured retrieval and reasoning.
When to use - and when NOT to
Use this skill when building agents that must persist across sessions, maintaining entity consistency across conversations, implementing reasoning over accumulated knowledge, designing systems that learn from past interactions, creating knowledge bases that grow over time, or building temporal-aware systems that track state changes.
Inputs and outputs
Why simple vector stores fall short: vector RAG retrieves semantically similar documents but loses relationship structure - it can retrieve "Customer X purchased Product Y" if asked directly but cannot answer "what else did Product Y buyers purchase," and it has no built-in way to distinguish current facts from outdated ones except metadata filtering. Knowledge graphs preserve entity relationships for traversal-based queries; temporal knowledge graphs add "valid from"/"valid until" timestamps to facts, enabling time-travel queries.
A benchmark comparison (Deep Memory Retrieval) contrasts memory systems: Zep (temporal KG) at 94.8% accuracy and 2.58s retrieval (a 90% latency reduction vs. a 28.9s full-context baseline), MemGPT at 93.4%, GraphRAG at roughly 75-85% (20-35% gains over baseline RAG, up to 30% less hallucination via community summarization), plain Vector RAG at 60-70%, and recursive summarization at just 35.3% with severe information loss.
A five-layer memory architecture: Working memory (the context window itself - scratchpad calculations, conversation history, active task state); Short-term memory (session-persistent, not cross-session - session-scoped databases, file-system session directories, in-memory caches keyed by session ID); Long-term memory (cross-session persistent, from simple key-value stores to graph databases, used for learned preferences and growing knowledge bases); Entity memory (tracks identity, properties, and relationships of specific entities across interactions to maintain consistency); and Temporal knowledge graphs (extend entity memory with explicit validity periods, enabling "what was true on date X" queries and preventing contradiction between outdated and current facts).
Four implementation patterns are compared: file-system-as-memory (simple, transparent, portable, but no semantic search or relationship tracking); vector RAG with metadata (embeddings plus entity tags/temporal validity/source/confidence for filtered semantic search); knowledge graphs (explicit entity/relationship types in a graph database); and temporal knowledge graphs (validity-period-aware knowledge graphs). Retrieval patterns covered: semantic (embedding similarity), entity-based (graph traversal), and temporal (validity-period filtering) - illustrated with worked Python/Cypher examples for entity tracking and a point-in-time address query.
Memory consolidation is triggered by accumulation thresholds, too many outdated results, a schedule, or explicit request, and proceeds by identifying outdated facts, merging related ones, updating validity periods, archiving/deleting obsolete facts, and rebuilding indexes.
Eight guidelines: match architecture to query requirements, use progressive disclosure for memory access, use temporal validity to prevent outdated-information conflicts, consolidate periodically, design for retrieval failures gracefully, consider privacy implications, implement backup/recovery, and monitor memory growth and performance over time.
Integrations
Connects to companion skills context-fundamentals (this skill builds on it), multi-agent-patterns (shared memory across agents), and context-optimization (memory-based context loading), and references graph databases (Neo4j) and vector stores (Pinecone, Weaviate) as implementation substrates.
Who it's for
Agent builders designing persistence layers for agents that need to remember across sessions, maintain consistent entity knowledge, or reason over how facts changed over time - choosing the right memory architecture tier (file, vector, graph, or temporal graph) for the actual query requirements rather than defaulting to whichever is simplest to build.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.