@pauliusztin_ argues AI agent memory design emphasizes retrieval over storage. His GraphRAG approach uses a unified MongoDB for full-text, semantic, and graph search.
Key facts
- Unified MongoDB handles full-text, semantic, and graph search.
- Graph search traverses 2-3 hops, picks top 10 candidates.
- Deep search builds a lightweight LLM wiki on demand.
- Agentic search lets LLM write database queries with validation.
- MCP server via FastMCP decouples agent from database.
Building memory for AI agents is less about storage and more about retrieval, according to @pauliusztin_, who is constructing a personal assistant from scratch for his next book with Manning. According to his X post, he stores the entire knowledge graph in a single database (e.g., MongoDB), handling full-text search, semantic search, and graph traversal in one system. The trade-off: losing a graph-native query language in exchange for simplicity.
Key Takeaways
- Agent memory design prioritizes retrieval over storage, using unified MongoDB and MCP server.
- GraphRAG enables multi-hop traversal via three strategies.
Three Retrieval Strategies
Graph search: Runs text search and vector search in parallel, fuses rankings using Reciprocal Rank Fusion (RRF), traverses 2-3 hops through the graph to retrieve connected knowledge, reranks candidates, and picks the top 10 to keep context tight.
Deep search: When keeping the top 10 isn't enough, everything retrieved is saved to disk to build a lightweight LLM wiki on demand. This temporary wiki serves as the agent's localized memory, allowing exploration of large data amounts through progressive disclosure without overwhelming the context window.
Agentic search: For questions that don't fit predefined retrieval algorithms, the LLM writes the database query itself. The ontology tells it which entities and relationships exist, with a validation loop ensuring syntactic correctness and a permission layer for safe boundaries.
The insight: GraphRAG isn't just vector search plus a graph; it's multi-hop traversal during retrieval. Similarity finds the entry point and the graph finds everything connected to it.
MCP Integration and Orchestration
Unified memory is served as an MCP server via @fastmcp (by @PrefectIO). The agent never talks directly to the database. Instead, a harness such as Claude Code calls search-and-write tools, while the MCP layer decides how memory should be queried. Every fact the agent retrieves must first be processed.
@PrefectIO handles every ingestion pipeline asynchronously as durable workflows across parallel workers with retries, caching, checkpointing, and centralized rate limiting. Even if one extraction step fails, indexing can continue, so the graph remains searchable. The read path never waits for orchestration.
The design principle: orchestrate the writes, never the reads.
What to watch
Watch for @pauliusztin_'s upcoming Manning book detailing the personal assistant architecture, and whether FastMCP adoption grows among agent builders seeking unified memory retrieval patterns.
