Building Agentic GraphRAG Systems: From knowledge graphs and ontologies to a unified memory as an MCP server for your AI agent.

I gave this talk twice in one month: at O’Reilly’s Context Engineering Event and at Abi Aryan’s Maven course on LLM inference at scale. After being blasted with questions, I realized something: GraphRAG isn’t a retrieval algorithm, it’s a data modeling problem. Powering agents with knowledge graphs (KGs) and ontologies is still an unsolved problem. All the engineers I spoke to want GraphRAG, but don’t know how to implement it. But at its core, we should ask a different question. Why do we even need GraphRAG in the first place? Why complicate our solution over a simple RAG system? There are three core reasons: 1. context rot 2. data fragmentation 3. the agent’s unified memory naturally maps to a knowledge graph (KG) After spending months in the GraphRAG rabbit hole, I reduced it to these 5 components: 1. Data pipelines gather and normalize your information before you do anything graph-shaped. Pull from URIs, notes, emails, and Google Drive to normalize everything into a single document collection. 2. Memory pipelines turn documents into typed triplets instead of free-form blobs. Each document becomes (entity, relationship, entity) triplets written into the unified memory modeled as a knowledge graph. The ontology is what keeps this sane by restricting the LLM to six entity types and eight typed edges like `PERSON`, `TASK`, `RELATED_TO`, or `HAS`. 3. The knowledge graph is the queryable artifact. This is the materialized view the agent talks to, where properties hang off nodes and edges as JSON. You use a hybrid index where text and semantic search merge via Reciprocal Rank Fusion for entry points before running a 2-3 hop traversal across typed edges. 4. An MCP server exposes two tool families instead of 40 endpoints. The `search_memory` tool brings only the slice of the graph the agent needs into context. The `write_memory` tool runs the data and memory pipelines on demand against a conversation or a URI. 5. The agent harness wires the MCP server tools via skills that carry the business logic, such as `assistant-memory` and `assistant-learn`. These skills decide when to read, when to write, and what counts as worth remembering. As I said at the beginning, GraphRAG is a data modeling problem. Thus, never skip the ontology and let the LLM invent labels. For example, when I ran LangChain `MongoDBGraphStore` run. I let the LLM extract entity and relationship types freely with no ontology. Five documents produced 17 node types and 34 relationship types, with `part_of`, `Part Of`, and `part of` all in the same graph. On the infrastructure side, for 2-3 hop traversals, Postgres or MongoDB handles documents, vectors, and graph lookups in a single system. MongoDB uses `$graphLookup` to walk nodes recursively. You only really need Neo4j when deep traversals or specialized graph algorithms are core to your product. Or you could easily keep Neo4j as a second database, an internal tool for visualizing and exploring the graph without the production overhead. Don't design for Google scale when you're processing thousands of documents. What ontology shape did you land on for your agent's memory? Where did you draw the line between a standard database and a dedicated graph DB? **TL;DR:** GraphRAG is a data modeling problem, not a retrieval algorithm. Define an ontology, run a data and memory pipeline into a knowledge graph, expose `search_memory` and `write_memory` over MCP, and let the agent harness wire it in via skills.