Agentic GraphRAG: Simplifying Retrieval Across Structured & Unstructured Data — Zach Blumenfeld

How should an agent retrieve information when part of the answer lives in documents and part lives in structured records? Zach Blumenfeld’s Neo4j Employee Graph notebook walkthrough starts with an architecture that puts a knowledge graph between those sources and the agent’s retrieval tools. Document extraction brings in unstructured information; standard ETL brings in structured data. Both feed the model the agent queries.

That shared model matters when retrieval becomes a sequence of operations. An agent can decompose a question into several queries rather than make one vector search and answer from its results. A small, explicit data model helps it decide what to retrieve and how the pieces fit together. The model can then grow as additional sources arrive. Here, the starting point is an employee graph.

The employee assistant should support skills analysis, team substitutions, collaboration discovery, and identifying skill gaps. Its first source is a folder of PDF resumes for Cyberdyne Systems—the Terminator reference—with professional experience and descriptions of work. Blumenfeld initially loads each resume into Neo4j as a document node containing text, metadata, and an embedding. The database is a graph database, but this first retrieval path treats it as a document store.

An agent built with Google’s Agent Development Kit receives instructions to retrieve information and one tool: document search. Asked how many Python developers the company has, it reports five because the retrieval setting is K = 5. Blumenfeld explicitly identifies that answer as wrong: the agent has turned the size of its retrieved result set into a claim about the whole workforce. A retrieval limit is not an aggregation.

Entity extraction and additional metadata could help with the counting problem. The next question exposes a different limitation: who is most similar to a particular employee in skills or experience? Lucas is a full-stack AI engineer with Python, JavaScript, and machine-learning experience. The agent uses those descriptions as search terms to retrieve similar resumes. That can find plausible candidates, but the explanation reveals semantic search rather than an explicit, controllable comparison of skill sets.

As the questions broaden, the missing operations become clearer:

A useful workforce summary needs counts and distributions, not just relevant examples. Likewise, searching for the word “collaborators” does not establish who worked with whom. Resumes may contain that evidence, but the relationships remain buried in text.

The next step is to express the questions’ requirements at the data layer. Start with three concepts: people, skills they know, and things they do. Entity extraction turns the resumes into that graph. The accomplishment model then becomes more specific: someone published, built, won, led, managed, optimized, or shipped something. Those things connect to domains and work types, allowing related activities to meet at shared concepts rather than relying on similar wording.

Blumenfeld uses Pydantic models and enumerations to define accomplishment types, domains, and work types. A compact Python version of that extraction contract can look like this; the domain and work-type vocabularies here are illustrative:

from enum import Enum
from pydantic import BaseModel, Field


class Action(str, Enum):
    PUBLISHED = "published"
    BUILT = "built"
    WON = "won"
    LED = "led"
    MANAGED = "managed"
    OPTIMIZED = "optimized"
    SHIPPED = "shipped"


class Domain(str, Enum):
    AI = "AI"
    ANALYTICS = "analytics"
    DATA_ENGINEERING = "data engineering"


class WorkType(str, Enum):
    SYSTEM = "system"
    CODE = "code"


class Thing(BaseModel):
    name: str
    domain: Domain
    work_type: WorkType


class Accomplishment(BaseModel):
    action: Action
    thing: Thing


class EmployeeExtraction(BaseModel):
    name: str
    skills: list[str] = Field(default_factory=list)
    accomplishments: list[Accomplishment] = Field(default_factory=list)

The schema constrains the structure and allowed values of extraction output. It does not establish whether an extracted skill or accomplishment is factually correct.

The extraction workflow—Blumenfeld recalls using LangChain here—decomposes the documents and produces JSON containing each person’s skills and accomplishments. Loading that JSON into Neo4j creates a more expressive model: people connect through shared skills, the things they worked on, and higher-level concepts describing that work. Those connections become queryable evidence for the assistant’s answers.

The next agent receives similar instructions plus a description of the graph’s data model. An MCP server gives it access to the schema and supports the Cypher query workflow. The useful division of labor is schema inspection, language-model query generation, and database execution; MCP is the interface connecting those capabilities, not the reasoning mechanism itself.

Now the Python-developer question can match people connected to the Python skill and aggregate the matches. Blumenfeld reports twenty developers from the graph query, describing the result as much closer to correct. That is a result from the demonstration’s extracted graph, not an independently established workforce total. With illustrative labels and relationship names, the operation is:

MATCH (person:Person)-[:KNOWS]->(:Skill {name: 'Python'})
RETURN count(DISTINCT person) AS python_developers;

The Cypher aggregation counts distinct matched people rather than retrieved documents. DISTINCT prevents repeated matches for the same person from inflating this count; completeness still depends on the people and skill relationships present in the graph.

The same similarity question—who is most similar to Lucas Martinez, and why?—now returns Sarah. The explanation uses shared skills and the sizes of the compared skill sets; Blumenfeld says some runs also consider similar accomplishments. The useful change is that the comparison refers to inspectable relationships and an overlap calculation, rather than only search-term selection.

That also gives corrections a concrete target. If a person has an incorrect skill relationship, it can be audited and changed in the graph. The assistant can then aggregate those same relationships to summarize how many people know each skill, or break down accomplishments. The data model makes both the answer and the underlying evidence easier to inspect.

Generated Cypher is not the only retrieval option. Blumenfeld adds specialized tools alongside it, including a query that traverses between person IDs. He describes a zero-to-three-hop traversal that can follow connections through skills, common systems, domains, and accomplishments. This broadens the evidence for similarity beyond a direct skill match.

Because the query explores relationships, Blumenfeld says an added collaboration or project link could also be picked up by that traversal. The scope is still determined by the query’s allowed paths and hop bounds. He also claims flexibility and higher performance for complex graph traversals, but presents no performance benchmark.

With these tools available, the Lucas Martinez comparison returns more detailed evidence: numbers associated with shared skills and domains such as AI, analytics, and data engineering. The agent can use the retrieved connections to explain how the employees’ work overlaps, instead of giving only a broad statement that their resumes are similar.

The final source is structured internal data from a human resource information system, or HRIS. It describes projects and collaboration among the same people already represented by the resumes. This introduces information the initial extraction model did not capture: multiple employees working on the same thing.

Resume ingestion began with an ownership assumption: a person could have many accomplishments, but each accomplishment belonged to one person because it came from that person’s resume. Shared project records change that relationship to many-to-many.

For the relational design Blumenfeld describes, representing shared ownership would require a join table and a model refactor. In the graph, additional relationships can connect multiple people to shared work. New node and relationship types can also be introduced as sources and agent requirements expand. The existing people and their resume-derived skills remain useful; the new collaboration data adds another way to connect them and another class of questions to ask.

A collaboration tool now matches people working on the same thing within selected domains. Asked which individuals collaborated to “deliver the most AI things,” the agent can invoke that operation against shared project relationships. It no longer needs to approximate collaboration by searching resume text for the term.

The resulting answer identifies Sarah Chen and Dr. Amanda Foster and lists their shared AI projects; it also includes other collaboration evidence involving supply-chain work. The final demonstration brings the two sources together: resumes establish skills and individual experience, while structured project records establish shared work. The assistant can answer who collaborated by returning the projects that connect them.