# Agentic GraphRAG: Simplifying Retrieval Across Structured and Unstructured Data

Zach Blumenfeld, Neo4j | AI Engineer World's Fair 2025 | 15:25

Source: https://www.youtube.com/watch?v=CzM3cW6FdBs
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/agentic-graphrag-simplifying-retrieval-across-structured-and-unstructured-data
Published: 2025-06-27
Tags: embeddings, mcp, rag, structured-outputs

## TL;DR
- A knowledge graph gives agents a shared data model for retrieving and reasoning across documents and structured sources.
- Graph queries can answer aggregations, similarity questions, and relationship questions that plain vector search cannot control precisely.
- Graph data models can absorb new node and relationship types without the join-table refactoring required in a tabular system.

## Summary
Zach Blumenfeld demonstrates an employee knowledge assistant built from résumé documents and internal collaboration data. He first shows the limits of document-only retrieval: a vector search tool returns a fixed number of résumé matches, struggles with skill aggregations, and cannot reliably identify collaboration relationships buried in text. He then extracts people, skills, accomplishments, domains, and work types into a Neo4j knowledge graph. An agent can read the schema, generate Cypher queries through an MCP server, and answer questions such as how many developers know Python or who is most similar to a given employee. Blumenfeld also adds graph traversal tools for comparing people across skills, systems, domains, and accomplishments. Finally, he adds project and collaboration data from an HR system. The graph accepts those new relationships without the join-table refactor that a relational model would require, allowing the agent to answer collaboration questions with more specific evidence.

## Key ideas
### A knowledge graph gives agents one place to combine document extraction and structured data
[00:47](https://www.youtube.com/watch?v=CzM3cW6FdBs&t=47s)
Blumenfeld places the knowledge graph beside the agent and its tools. The graph can receive information extracted from documents and data loaded through standard ETL processes. He argues that the value for agents comes from the way they now decompose questions into several queries instead of relying on one vector search. A simple data model gives the agent something it can use to break down questions, retrieve information accurately, and grow as more data is added. His example uses an employee graph for skills analysis, substitutions within a team, skill gaps, and collaboration.

### Document-only vector search cannot reliably answer counts or relationships
[03:00](https://www.youtube.com/watch?v=CzM3cW6FdBs&t=180s)
The first version stores each résumé as a document node with metadata, text, and an embedding. Blumenfeld gives an agent one document-search tool and asks how many Python developers there are. It returns five because the search was configured with K equal to five, even though that is not the actual count. Similarity searches can find people with related words in their résumés, but the logic is hard to control. The same setup cannot calculate a skills distribution or identify who collaborated with whom, because those facts remain buried in résumé text.

### A small domain model makes the questions explicit
[05:46](https://www.youtube.com/watch?v=CzM3cW6FdBs&t=346s)
Blumenfeld starts the graph model with people, skills, and the things people do. He then makes it more expressive by representing accomplishments such as building, publishing, managing, optimizing, and shipping. These accomplishments connect to domains and work types, which lets the graph relate similar activities. He uses Pydantic classes and enumerations to define the allowed types, then processes the résumés into JSON containing skills and accomplishments. Loading that extracted information creates connections between people, their skills, their work, and higher-level concepts.

### Schema-aware agents can generate precise graph queries
[08:31](https://www.youtube.com/watch?v=CzM3cW6FdBs&t=511s)
The second agent receives information about the graph model and uses an MCP server that can read the schema and generate Cypher statements. When asked how many developers know Python, it can match person nodes to the Python skill and perform an aggregation, returning 28 in the demonstration. For similarity, it can compare overlapping skills and sometimes accomplishments, then explain how it reached its answer. Blumenfeld says the graph also allows an engineer to audit and adjust specific skills, giving more control over the evidence used in an answer.

### Graph traversal lets similarity queries use several kinds of connection
[10:52](https://www.youtube.com/watch?v=CzM3cW6FdBs&t=652s)
Blumenfeld adds a tool for finding people with similar skills. Its graph query can travel from one person to another across zero to three hops. The traversal can include shared skills, systems, domains, and accomplishments. If the model later adds collaboration or project links, the query can include those connections as well. The agent uses the tool to produce specific counts for overlapping skills and domains when comparing Lucas Martinez with another employee. This gives the answer a visible basis instead of relying only on semantic similarity.

### New collaboration data can be added as relationships without a relational refactor
[12:25](https://www.youtube.com/watch?v=CzM3cW6FdBs&t=745s)
The final example combines the résumé graph with data from an internal human resources intelligence system. That source contains projects and the people working on them together. In the original résumé model, an accomplishment had one associated person. Representing the new many-to-many collaboration data in tables would require another join table and a model refactor. In the graph, Blumenfeld adds new relationships and, where needed, new node and relationship types. The agent can then use a collaboration tool to find people who worked on the same projects within selected domains.

## Notable quotes
- "A lot of what we're seeing is a question being broken down and being handed multiple queries, right, to go and pull the data that you need." (01:22)
- "It's not going to be able to answer that, right? Because it needs to be able to do an aggregation to answer a question like that." (04:43)
- "The great thing about graph is that I don't have to do that at all. I can just sort of create new relationships." (13:23)
- "There's more explanability with the way that these questions are being answered." (12:08)

## Tools & references mentioned
- Neo4j
- Google ADK
- MCP
- Cypher
- LangChain
- Pydantic
- Cyberdyne Systems
- Lucas Martinez
- Sarah
- Amanda

## Who should watch
- You are building an agent that needs both exact counts from structured data and semantic retrieval from documents.
- Your current RAG system cannot answer questions about aggregates, shared skills, or relationships between entities.
- You expect the data model to change quickly as new sources, projects, or collaboration links are added.

## Related talks

- [Intro to GraphRAG](https://aietalks.com/talks/intro-to-graphrag) (Zach Blumenfeld, Neo4j, 1:18:35)
- [Practical GraphRAG: Making LLMs Smarter with Knowledge Graphs](https://aietalks.com/talks/practical-graphrag-making-llms-smarter-with-knowledge-graphs) (Michael Hunger, Jesús Barrasa & Stephen Chin, Neo4j, 19:46)
- [GraphRAG](https://aietalks.com/talks/graphrag) (Mitesh, NVIDIA & Ching Kyong Lamb, PO.AI & Daniel Chalev, Zep & Mark Bane & Vasilia Marovitz, Cognify & Alex Gilmore, Neo4j & Ola Mabad, Cisco & Michael Hunger & Steven Shen, Neo4j & Tom Smoker, YAL.ai, 4:08:05)
- [GraphRAG: The Marriage of Knowledge Graphs and RAG](https://aietalks.com/talks/graphrag-the-marriage-of-knowledge-graphs-and-rag) (Emil Eifrem, Neo4j, 19:15)
- [Agentic GraphRAG: AI's Logical Edge](https://aietalks.com/talks/agentic-graphrag-ais-logical-edge) (Stephen Chin, Neo4j, 15:27)