Agentic GraphRAG: AI’s Logical Edge

How many girls can fit in a classroom arranged as a grid? In Stephen Chin’s example, OpenAI o3 anchors on an article about the non-attacking-kings problem and assumes the grid is square. That assumption matters: the displayed alternatives include rectangular layouts, so solving only the square case misses part of the problem. Chin introduces the example against a broader concern about agentic systems failing to meet their intended use cases, invoking Gartner’s warning without specifying a forecast.

The completed slide shows four layouts: 6×6 with G=9, 3×12 with G=12, 4×9 with G=10, and 2×18 with G=9. The rectangular alternatives make the unsupported square assumption visible.

Chin reports that o3 spent roughly 40 seconds reasoning on this example. He then asks whether the girls and boys will attend home economics or sports, supplying a misleading gender ratio. The answer calculates that all the girls will attend cooking class. The failure now combines an inference from irrelevant information with a gender stereotype.

A classroom puzzle makes those mistakes easy to spot. In drug discovery or supply-chain planning, an unsupported assumption can instead propagate into a business decision before anyone notices. Chin’s critique is that fluent language and elaborate reasoning can encourage users to ascribe capabilities the system has not demonstrated. He proposes knowledge graphs as a complement: give the system explicit information and relationships to work with, rather than relying on language generation alone.

One response is to add collaborating agents. Each agent observes, thinks, and acts; an orchestration layer connects those agents to generative models and tools. Different agents can perform different parts of a workflow and check or extend each other’s work. But tightly coupling all those pieces creates maintenance problems: changing tools becomes difficult, and security boundaries become harder to manage.

Model Context Protocol (MCP) provides a client/server boundary between agents and the tools or data sources they use. Those sources can include files, database records, and a graph database acting as the system of record. This gives integrations a separable interface; it does not, by itself, establish that the resulting system is secure.

The Neo4j MCP tools illustrated in the talk cover three distinct responsibilities:

Cypher is the graph query language. Chin describes a prompt-driven workflow that turns questions into Cypher queries. The current repository documents schema access and query execution, so the natural-language generation step should be understood as part of the overall agent/tool workflow, not assumed to occur entirely inside the server. Memory and cloud operations remain separate capabilities that an agent architecture can combine as needed.

A graph can describe the agent’s workflow, as in Chin’s LangGraph illustration, while a separate graph stores information the agent remembers. These serve different purposes: one organizes activity; the other makes information available across that activity. Chin names Zep, Cognee, and Mem0 as users of Neo4j for graph memory, while noting that some allow a choice of graph database. That is his description of the ecosystem at the time, rather than a requirement that every deployment use Neo4j.

The video-search and summarization architecture he shows brings these concerns together. It includes short-term memory, lookup information, a GraphRAG pipeline, and a vector pipeline. Graph retrieval and vector retrieval coexist because they offer different ways to assemble context. Chin attributes richer results and typically fewer hallucinations to the GraphRAG path, but presents that as a qualitative benefit rather than a measured benchmark for this system.

The healthcare example makes the retrieval distinction concrete. A direct LLM response is generic. Baseline retrieval-augmented generation supplies more information, but the answer can remain incomplete because vector similarity retrieves nearby text without necessarily finding every relationship relevant to the question. Similarity is not the same as relevance.

For a question about emphysema, the proposed retrieval sequence is:

1. Run vector search. Match the question against embeddings, using either a separate vector database or Neo4j’s vector-search capability.
2. Map the matches into the graph. Associations between embeddings and graph nodes identify the emphysema node.
3. Expand through relationships. Retrieve connected nodes, including related diagnoses and conditions.

The initial semantic match locates the topic. Graph traversal then supplies connected information that a similarity search alone may omit. This is especially useful when the source material mixes structured relationships with unstructured text.

The broader architecture accepts the question, retrieves through vectors or the knowledge graph, and can use graph analytics to organize the results. Community algorithms and groupings provide another way to gather context; Chin points to Microsoft’s GraphRAG research in this connection. The retrieved information is then passed to the LLM as context for generating an answer. The graph contributes evidence and relationships; the model still produces the language of the response.

Text-to-Cypher offers a direct route from a question to graph retrieval, but its usefulness depends on the quality of the generated query. Chin warns that LLM-generated Cypher can fall short of application requirements. His recommended starting point is vector search with graph context: use semantic matches to find an entry point, then retrieve related nodes.

Filtering adds another control over what reaches the model. Pre-filtering narrows the candidate set; post-filtering refines retrieved results. Chin also emphasizes putting the most relevant information high in the supplied context. His claim that models largely ignore the rest of a long window is broader than the evidence he presents, but the practical concern is clear: a larger context window does not guarantee that every included fact will influence the answer. Context selection and ordering remain part of retrieval design.

Chin’s enterprise example is Klarna’s knowledge assistant, bringing together an enterprise wiki, HR systems, and internal documentation. He characterizes the project as replacing all of Klarna’s SaaS systems; the customer account supports substantial consolidation, not that universal scope. Chin reports approximately 250,000 employee questions in the first year, 2,000 daily queries, and 85% employee adoption. These are attributed usage figures, not answer-accuracy measurements; the daily volume describes activity at reporting time rather than a year-long average.

For learning the underlying graph technology, Chin recommends the Neo4j certification program, describing a credential with a LinkedIn badge and a mailed T-shirt. He also points to GraphAcademy courses on chatbots and LLM applications. Additional GraphRAG certifications are a possibility he raises for the future, not an offering he announces as available.

Chin describes NODES as an annual, free conference running for 24 hours across three time zones. It offers another route into graph development through sessions and examples.

The first audience question checks the entire retrieval sequence: submit a question, embed it, perform semantic search, find the corresponding graph node, and retrieve related nodes. Chin confirms that sequence. The advantage is that a convoluted natural-language question does not first have to become a precise Cypher query. Semantic matching provides the entry point.

That entry point depends on associations created beforehand. In the emphysema example, matching embeddings point to the emphysema node because the graph and embeddings have already been connected. The next step is to select relevant surrounding information, not indiscriminately return every neighbor. Chin mentions cosine similarity and community-grouping algorithms as possible selection methods before passing the resulting context onward.

A follow-up asks whether the embedded chunks are the same pieces represented by nodes in a simple architecture, and who creates those associations. Chin describes using LLMs to construct a node structure from unstructured data, then storing text embeddings as properties on the nodes. That explains one ingestion approach without requiring a universal one-to-one mapping between every text chunk and every entity.

For building those associations, he names Neo4j’s Python library and plugins, followed by integrations with LangChain, LlamaIndex, and Haystack. The framework is a choice; the necessary work remains creating graph structure and connecting it to the embedded text that retrieval will search.

The next question distinguishes two responsibilities that are easy to conflate: exposing memory tools and deciding how memory should change. Does the memory MCP server own update and deletion logic, or does another framework orchestrate those operations? Chin says he does not know the implementation answer. He identifies the server as open source and directs the question to Michael Hunger’s team, which built the MCP servers, and a later session with Michael and Jesus. The lifecycle-policy question remains unanswered in this talk; tool availability alone does not establish who decides when a memory should be changed or removed.

The final question asks whether LangChain and LangGraph are complementary. Chin describes LangGraph as the agent tooling built by the LangChain team, rather than offering a detailed comparison. His team has experiments and prototypes using LangGraph for agents, alongside integrations with LangChain and memory vendors. His closing position is to choose the tool that fits the application: Neo4j’s integrations are intended to support that choice, rather than require a single orchestration framework.