Agentic GraphRAG: How does an AI agent use a knowledge graph?

Neo4j outlined Agentic GraphRAG, an approach in which an AI agent rather than a fixed retrieval path decides how to query and maintain a knowledge graph, using a ReAct (reason, act, observe) loop to adapt retrieval to each question. Neo4j's example walks through a support agent answering "Which other customers were impacted by the same issue?" in three steps — vector search to find the ticket, a query for the error it reports, then a query for every other customer who reported that error — with each step shaped by the previous result and recorded so the answer can be traced. Neo4j frames the practical question for any use case as how much autonomy to hand the agent for retrieving from and writing to the graph.

Agentic GraphRAG: How does an AI agent use a knowledge graph? 9 min read Systems built on basic retrieval-augmented generation RAG https://neo4j.com/blog/genai/what-is-retrieval-augmented-generation-rag/ run into a ceiling: a fixed retrieval path can’t adapt when the question or the underlying data doesn’t match what you planned for. GraphRAG https://neo4j.com/blog/genai/what-is-graphrag/ closes part of that gap by connecting facts in a graph rather than scattering them across isolated chunks, so an answer can follow relationships rather than relying on similarity search alone. But a graph is only as useful as an AI application’s ability to navigate it. Agentic GraphRAG hands an AI agent https://neo4j.com/blog/agentic-ai/what-is-ai-agent/ the steering wheel. The agent decides where to start exploring the graph, which retrieval tool to call, how far to follow relationships, whether it has enough context to answer, and whether to write and maintain the graph as new information arrives. It’s especially useful when retrieval paths vary from question to question, when your domain keeps introducing new information, or when past decisions should inform future ones. The practical question for a given use case is how much autonomy you hand to the agent for retrieving from and writing to the graph. The agent adapts retrieval to each question An agent can reason and query dynamically to retrieve the information it needs from the graph, choosing its retrieval steps at runtime based on the question and the results of each step. A ReAct loop — reason, act, observe — is what makes this dynamic retrieval possible. The agent checks the graph schema, runs a query, inspects the results, and decides whether it has enough information to answer or if it needs to retrieve more information. Suppose a support agent is asked, “What plan is this customer on?” If the customer’s name or ID is known, the agent can query the graph directly and follow a single relationship from the customer to the plan, with no broader search needed. That’s a direct lookup, and the ReAct loop stops there. The agentic loop earns its place with a harder question that can’t be answered in one step, such as “Which other customers were impacted by the same issue?” A ticket may mention an authentication failure, but the customers affected are facts connected elsewhere in the graph. The agent needs to use multi-step reasoning, working through a sequence of retrieval steps, each informed by what the last one returned rather than resolving everything in a single query. First, vector search finds the ticket by matching the user’s description against similar tickets by meaning: CALL db.index.vector.queryNodes 'ticketEmbeddings', 1, $descriptionEmbedding YIELD node AS t, score RETURN t.id AS ticketId Knowing the ticket, the agent can then query for the error it reports: php MATCH t:Ticket {id: $ticketId} - :REPORTS - e:Error RETURN e Knowing the error, a final query reaches every other customer who reported it: MATCH e:Error {id: $errorId} <- :REPORTS - :Ticket <- :FILED - other:Customer RETURN other Three steps, each shaped by what the last one returned — the same reason, act, observe loop described above, repeated until the agent has enough evidence to answer. Because each step is a recorded call, you can also trace and explain exactly how the agent reached its answer. New to GraphRAG? Start with the fundamentals Get a plain-language walkthrough of how GraphRAG grounds LLM answers in a knowledge graph before layering in agent-directed retrieval. The agent builds and maintains the graph Another aspect of agentic GraphRAG is when the agent builds and maintains the graph as it goes. This is especially useful when interactions with the agent introduce new information that the graph doesn’t yet represent. To build or maintain a graph, the agent can start by understanding the schema. The agent can then using the GraphRAG Python package https://neo4j.com/developer/genai-ecosystem/graphrag-python/ , for example extract entities and relationships from natural language, resolve matching entities, and write the resulting graph to the Neo4j graph database. In the support example above, the customers, products, tickets, and errors already exist in the graph. Investigating a new ticket, though, can require reaching a supplier behind one of a product’s components — an entity the graph has never modeled, because no question has needed to reach that far upstream before. Until the supplier is added, queries can’t connect it to the customers, tickets, or errors it affects. As new information arrives, the agent can: - Identify candidate entities and relationships in documents or records - Compare them with the existing schema and decide where they fit - Resolve repeated references to entities already stored - Detect conflicting facts or low-confidence additions that need review - Write approved nodes, relationships, properties, and provenance back We recommend keeping retrieval and graph updates on separate paths. That way, read tools can query the context the agent is authorized to access, while graph-changing actions can operate under narrow permissions, schema checks, confidence thresholds, or human approval. A question can therefore trigger several reads without giving every retrieval step permission to change the graph. A context graph lets the agent reuse past interactions and decisions Everything described so far — the customers, tickets, errors, and product — lives in a knowledge graph https://neo4j.com/blog/knowledge-graph/what-is-knowledge-graph/ that captures domain facts and their relationships. A context graph https://neo4j.com/blog/agentic-ai/what-is-context-graph/ extends that same graph with the agent’s own operational history, so conversations, tool calls, decisions, and outcomes become additional context. | | Knowledge graph | Context graph | |---|---|---| | Stores | Facts about the domain and how they relate | Domain facts plus the agent’s operational history | | Examples | Customers, tickets, errors, releases, products | Everything in a knowledge graph, plus conversations, tool calls, decisions, and outcomes | | Use when | Retrieval needs domain facts and relationships | Retrieval needs not just domain facts and relationships but also past interactions, decisions, or tool use | GraphRAG is the retrieval mechanism running on top of a knowledge graph or context graph. The same vector search, traversal, and agent-directed routing from the sections above work on both. Take a refund request, for example. In a context graph, the agent can connect the current request to the order, refund policy, past cases, and final outcome, while it writes the current request to the graph. When another similar request arrives in the future, the agent remembers the context from past decisions. When is agentic GraphRAG worth building? Fixed retrieval falls short when the system can’t determine the right path ahead of time or new information keeps changing the graph. The added complexity of agentic GraphRAG is easiest to justify — and calibrate — in three situations: 1. Retrieval paths vary from question to question. One query may need a semantic search, another a graph traversal, and a third several rounds of both. Let the agent’s own reasoning handle the ones that don’t fit a fixed path, with a clear enough view of the graph schema to query the right places efficiently. A fixed path still answers faster when it fits, so it’s worth keeping for the questions that don’t need the flexibility. 2. The domain is changing, introducing new concepts or relationships. Adding another customer record does not change the meaning of Customer, but a new product type, regulatory rule, supplier relationship, or integration model introduces structure that the current graph doesn’t represent. Give the agent write access to extend the graph, with the schema checks and permissions described above. 3. Earlier decisions need to inform later ones. If an agent should reuse a past refund exception, investigation, or approval decision, add a context graph to preserve the conversations, decisions, actions, and outcomes associated with that work, and to retrieve them the next time a similar case arises. The right balance isn’t something you decide up front. You try an architecture, evaluate the quality, accuracy, and latency trade-offs, and adjust until you find the sweet spot for your use case. Get started with agentic GraphRAG Agentic GraphRAG connects an organization’s data to the humans and AI systems using it, surfacing how things relate and why, alongside the facts themselves. The Neo4j Graph Intelligence Platform https://neo4j.com/product/ gives you the tools to build, store, and query the knowledge graph and context graph, GraphRAG https://neo4j.com/graphrag/ tools, and the graph construction and memory tooling covered here, already in place — so you’re not building each piece from scratch. Getting started means having a working GraphRAG system to build on: a knowledge graph or a context graph and a retrieval mechanism that already answers your core questions. From there, hand the agent more when it earns its place. Learn how to build agentic GraphRAG See how vector search, graph traversal, and agentic retrieval layer on top of one another in GraphRAG. Agentic GraphRAG: FAQs Agentic GraphRAG uses an AI agent https://neo4j.com/blog/agentic-ai/what-is-ai-agent/ to control how graph-backed retrieval runs. The agent decides which retrieval methods to use, how far to follow relationships, whether it has enough context to answer, and what step to take next. GraphRAG already supports agent-driven retrieval and construction, such as an agent choosing the traversal path at runtime, sequencing vector search and graph queries, or reconciling graph structure as new information arrives. “Agentic GraphRAG” is simply the name that’s caught on for describing GraphRAG when an agent is doing that work, rather than a separate technology with its own capabilities. For a multi-hop question like “Which customers got the same error?”, an agent can sequence vector search, graph traversal, and a second graph query in one pass, choosing each step based on what the previous one returned. The workflow can extract candidate entities and relationships, compare them with the existing schema, resolve repeated references to the same entity, validate uncertain or conflicting facts, and write approved changes back to the graph. A context graph can also connect conversations, tool use, decisions, evidence, and outcomes so later interactions can retrieve that history. The choice depends on the information available and the question being answered. Vector or full-text search can locate a starting point when the exact entity is unknown. Graph traversal can then follow explicit relationships from that entity to gather connected facts. Many questions use both methods in sequence. Ask yourself whether your questions have unpredictable retrieval paths that can’t be predetermined or whether your domain keeps introducing new entity types or relationships. If the answer is no, GraphRAG with fixed retrieval patterns could be enough. Agentic GraphRAG earns its added complexity when either is true, and a context graph adds further value when past decisions also need to inform future ones.