Why Your Agent’s Brain Needs a Playbook: Practical Wins from Using Ontologies

A user sends a prompt to an AI application. Before asking the LLM to respond, the application retrieves relevant information from a controlled, curated knowledge base. The immediate engineering question is what that retrieval can return: only semantically similar text, or also the connections that make the text useful? Jesús Barrasa, Neo4j’s AI Field CTO, introduces ontologies through this problem of building and retrieving from a knowledge graph.

In Barrasa’s simplified GraphRAG architecture, a knowledge graph on a graph database takes the place of the vector database. The surrounding flow remains familiar: retrieve information, put it into the model’s context window, and generate a grounded response. This is one architecture, rather than a requirement to eliminate vector storage; graph retrieval can incorporate vector indexes and external vector stores.

The graph expands the available retrieval strategies:

• Vector search finds text with similar meaning.
• Graph contextualization follows connections around those matches.
• Generated structured queries retrieve information through the graph’s explicit model.

Barrasa describes improvements in completeness, relevance, precision and faithfulness, but supplies no benchmark measurements. The mechanism to examine is the richer retrieval process itself.

Neo4j’s property graph has two main primitives: nodes and directed relationships. Nodes represent entities—people, objects, locations, events or documents—and key-value properties characterize them with names, descriptions, dates of birth and other values. Together, these entities and their connections form the domain graph.

When the source is unstructured text, a second layer records the documents from which the domain graph was extracted. This lexical graph might represent a document as a sequential list of chunks. A contract may need a richer tree containing sections, subsections, definitions and clauses. Entity extraction then connects a chunk to the entities it mentions, preserving where a fact or reference appeared so retrieval can use that connection later.

A chunk node can retain both its raw text and an embedding. Vectors are properties alongside strings and numbers, and they can be indexed. That puts semantic search and connected document structure in the same platform: the vector locates a useful chunk, while the graph retains its document context and entity links.

Before any of this retrieval is possible, the graph has to be built. With structured data, the pipeline starts from database tables or files and a description of the target graph. Records are mapped to node types; other records or fields define relationships. Neo4j’s visual interface lets a developer define that model and connect it to source data, with an underlying API supporting programmatic construction. The target schema is an input, not something the mapping can avoid.

The unstructured pipeline in Neo4j’s GraphRAG package follows a different sequence. Barrasa describes the LangChain and LlamaIndex integrations as broadly similar:

1. Process and split the document.
2. Embed its chunks.
3. Extract entities using an injected schema.
4. Write the resulting information to the graph.

The extraction schema tells the system what matters in this domain. Medical documents might call for patients and symptoms; financial documents might call for account holders, accounts and money transfers.

Both paths need a model, but their interfaces may express it differently.

Maintaining those descriptions independently introduces divergence. The desired shared artifact is a domain model that does not belong exclusively to one ingestion tool or prompting interface.

An ontology supplies that shared, formal, implementation-agnostic description of a domain. Standards, including W3C standards, provide ways to define it independently of a particular graph-loading interface. Serialization is a separate choice: Barrasa shows XML, jokes about using it in 2025, and points out that JSON-based and other representations are also available.

His example comes from the public Financial Industry Business Ontology (FIBO). The fragment contains classes for a privately held company and a stock corporation, connected through a subclass relationship. It also describes a different kind of connection: a stock corporation is governed by a board agreement. These are the kinds of entity categories and relationships needed to guide graph construction. The example is historical; today’s Corporations ontology source deprecates some of those identifiers in favor of equivalents in CorporateBodies.

The same domain model can guide both structured mapping and unstructured extraction. Barrasa advocates model-driven construction not just as data-engineering practice, but because a well-described graph remains useful during retrieval. A text-to-structured-query system has a clearer model from which to generate queries, and vector search has an explicit structure to use for contextualization. He points to an ontology-guided ingestion example without walking through it, then turns to the retrieval mechanism.

Embedding the graph’s text-bearing nodes creates another search space. A query is embedded into a point in that space, and nearby vectors identify semantic matches. But the matched vectors are still properties of graph nodes. The retriever can therefore dereference each match back to its node and continue through the graph.

That return to the graph is where contextualization happens. The retriever can navigate relationships, enrich a match with connected information, filter results or aggregate them before passing context to the LLM. Vector proximity selects a starting point; graph traversal determines what accompanies it. The completed visual shows both stages: the search region in vector space and exploration among the connected nodes above it.

The Python demonstration makes the two stages concrete. Movie plots have been embedded and placed in a vector index. The search describes a hacker who discovers that the world he knows is a simulated reality controlled by machines—the recognizable premise of The Matrix. Barrasa requests the top three results; three is his chosen retrieval count, not an accuracy result or an optimum established by evaluation.

The retriever wraps the vector index and accepts a retrieval query. That query supplies the exploration logic to run for each vector match. The following Python expresses the pattern using the documented VectorCypherRetriever interface, whose retrieval query receives node and score; it is an implementation illustration, not a reconstruction of the historical slide’s exact package version. Here, moviePlots names the plot index, and ACTED_IN connects a person to a movie.

from neo4j_graphrag.retrievers import VectorCypherRetriever


def search_movies(driver, embedder):
    retriever = VectorCypherRetriever(
        driver=driver,
        index_name="moviePlots",
        embedder=embedder,
        retrieval_query="""
        OPTIONAL MATCH (actor:Person)-[:ACTED_IN]->(node)
        RETURN node.title AS title,
               node.plot AS plot,
               collect(DISTINCT actor.name) AS actors,
               score
        """,
    )
    return retriever.search(
        query_text=(
            "A hacker discovers that the world he knows is a "
            "simulated reality controlled by machines."
        ),
        top_k=3,
    )

The vector search chooses movies by plot similarity. The Cypher query adds actors to each selected movie’s context.

This is powerful, but the author of the retriever must already know the graph model: actors act in movies, and movies have plot properties. In the code, that knowledge appears directly in ACTED_IN, Person, title and plot. Part of the contextualization policy is now hard-coded into the retriever. Changing which relationships should contribute context requires addressing that embedded traversal logic.

The next step is to persist the ontology in the graph alongside the movie data. The database then contains both the domain records and a description of their schema. A dynamic query can consult that description before choosing which relationships to traverse.

Barrasa’s query looks for relationship definitions annotated as contextualizing relationships. The classification uses a subproperty relationship: a particular domain relationship belongs under the broader contextualizing property. In RDF Schema, subPropertyOf describes a property hierarchy; the application’s query explicitly consumes that classification to implement retrieval policy. The standard does not perform the traversal for it.

The retrieval operation now has two connected parts:

1. Query the ontology for relationship types marked as contextualizing.
2. Use those types to navigate the data graph from each retrieved node.

For the Matrix example, the selected relationship is acting in a movie. The retriever follows those connections while excluding producing and directing connections. Those other relationships may exist in the graph; they simply are not selected as context by this policy.

The important change is where the decision lives.

The ontology creates a level of indirection: the retriever’s general logic stays in place while the stored model determines which connections it follows. Changing the ontology can therefore change retrieval behavior on the fly.

This gives the ontology two distinct jobs across the application’s lifecycle. During construction, it is the implementation-agnostic model used to shape the knowledge graph. During retrieval, that same kind of stored description becomes data the retriever consults to choose its behavior. Barrasa closes on those two roles and invites further questions at the booth.