AI Engineer World's Fair 2026
Thinner Agents on a Smarter Substrate: The Ontology-based Semantic Layer
Read the talk
Thinner Agents on a Smarter Substrate
A bank-account-opening agent shows how a shared ontology can connect business intent to enterprise data, centralize source mappings, and reuse execution feedback across agents.
From a talk by Emil Eifrem
Before you start: Familiarity with agent tool use and database schemas is helpful; no prior knowledge of ontologies or graph databases is required.
Opening an account means finding the right data
What does an agent need to open a bank account? Beyond deciding what to do next, it needs to know which data can support each decision. Emil Eifrem introduces this problem from Neo4j’s work with large enterprises, where he says it had become increasingly visible over the preceding six to nine months.
The account-opening example starts with a deliberately simplified agent containing two parts:
- Business logic: interpret intent, plan, act, and repeat.
- Data sources: identify the information the task requires, locate it, and make it available to the agent.
Not every action operates on data, but access to the right data at the right time is a large part of making the agent useful.
For identity validation, the agent might consult the Department of Motor Vehicles registry and a passport verification service. Wire those sources into the account-opening workflow and the agent can do its job. Meanwhile, other teams build agents of their own, each with a similar division between business logic and source integration. The first implementation works; the difficulty appears as that pattern spreads.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The costs accumulate across agents
Discovery comes first. In a startup with one application backed by one Postgres database, locating the data is straightforward. Eifrem contrasts that with an illustrative enterprise containing 100 databases, Snowflake, Databricks, and S3 buckets. Every team must work out which parts of that estate its agent needs.
Trust comes next. Finding a dataset does not establish that it is the correct copy, the right version, or a source the agent is allowed to access. Enterprise duplication turns source selection into a question of authority and permissions as well as location.
Maintenance repeats the same work. If each agent encodes its own source mappings, a change to a source forces teams to revisit every affected integration. This violates the DRY principle—Don’t Repeat Yourself—at the boundary between business intent and data access.
Experience stays isolated. When the knowledge connecting intent to sources lives in individual agents’ code and prompts, a successful execution does not by itself improve the next invocation. Nor does it teach another team’s agent which source worked in that context. The missing piece is a shared place to retain and use that experience.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect business meaning to physical sources
The shared layer has three pillars. The first is a business-facing ontology: the concepts people in the organization use and the relationships between them. Although the term has attracted attention through Palantir and AI, the starting point is simple. For a bank, it includes customers, accounts, debit cards, checks, and transactions. Names should make sense across the company: a customer has a first name, regardless of whether a database happens to call its column F_name.
The second pillar is a technical ontology describing data assets, their locations, and their schemas. Eifrem’s illustrative inventory includes 14 Oracle databases, 15 Neo4j databases, Snowflake, Databricks, and S3 buckets. This layer describes where information physically resides. He mentions three ways of constructing it but leaves those methods outside the talk.
The connection between these ontologies makes them useful together. The business concept of a customer’s first name maps to its system of record: an Oracle database column named F_name. An agent can start with the business meaning and follow the mapping to the relevant storage detail.
A small Cypher representation makes that relationship concrete:
cypher
CREATE (customer:BusinessConcept {name: 'Customer'})
CREATE (firstName:BusinessProperty {name: 'first name'})
CREATE (oracle:DataAsset {kind: 'Oracle database'})
CREATE (column:Column {name: 'F_name'})
CREATE (customer)-[:HAS_PROPERTY]->(firstName)
CREATE (oracle)-[:HAS_COLUMN]->(column)
CREATE (firstName)-[:HAS_SYSTEM_OF_RECORD]->(column);
Here, the node labels and relationship names express the example as a graph. The essential feature is the explicit link from business meaning to the authoritative physical field.
The third pillar is runtime execution traces. As agents traverse the graph and act, they record what they attempted, whether it succeeded, and what outcome followed. In this blueprint, those records supply feedback about how the mappings work in practice; retaining and using them is an additional mechanism, not an automatic consequence of defining an ontology.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Follow the compliance check through the graph
Return to account opening. The graph contains business concepts such as checks, accounts, and credit history, but it also encodes the business process itself. This matters because the agent is process-guided: it should follow the required workflow, not merely retrieve related information.
The compliance step connects business intent to technical options:
- Reach Check Compliance, the node highlighted in green in the diagram.
- Follow its requirement to resolve a government-issued ID.
- Discover the two available sources: Motor Vehicle Records and Passport Verification.
The agent now has a graph path explaining why those sources are relevant to its current step. Their relevance no longer has to be reconstructed independently inside each agent.
When the agent tries a source, it leaves a trace containing its position in the graph, the action it took, its context, and whether it succeeded. Eifrem notes that the actual traces are richer than the simplified slide. These records connect an execution outcome to the circumstances in which a source was used.
Those observations can feed a score used in subsequent source selection. If DMV lookups have been successful, a later invocation becomes more likely to select that path when the context is appropriate. The feedback changes a future choice; it does not make the DMV source preferable in every situation. Eifrem describes this mechanism without specifying a scoring formula or reporting a measured learning gain.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Govern the mapping and share the feedback
Together, the business ontology, technical ontology, and execution traces are intended to address the original four problems. Discovery becomes a traversal from a business concept to candidate sources. Trust draws on two kinds of evidence: top-down knowledge curated by an administrator and bottom-up observations of what actually worked during execution.
A single governed mapping also changes the maintenance boundary. Instead of editing source knowledge in every agent, teams update the shared relationship between business intent and data. Agents using that mapping can then pick up the change. Execution feedback can likewise inform both the agent that produced it and other agents using the same layer.
| Concern | Per-agent wiring | Shared semantic layer |
|---|---|---|
| Discovery | Locate sources for each agent | Follow business-to-source mappings |
| Trust | Assess sources separately | Use curated knowledge and traces |
| Maintenance | Rewire affected agents | Update the governed mapping |
| Learning | Experience remains local | Reuse feedback across agents |
This is the shift from thick agents containing manually wired source knowledge to thin agents using an ontology-based semantic layer. The intended scaling benefit is less repeated engineering as the organization adds agents. The shared mappings and feedback still have to be built and maintained; moving them into a common layer makes that work reusable. Eifrem points to further documentation through a QR code on the slide.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Beyond the enterprise account-opening example
For further discussion at the conference, Eifrem directs attendees to Neo4j’s booth P3. He places this architecture among a much broader set of graph-and-AI patterns, describing hundreds of possibilities and pointing to ten represented in the graph track in Room 2005. The named organizations include The Gates Foundation, monday.com, JPMorgan Chase, Berkeley, and The New York Times.
The scope of the architecture remains specific: organizations with many data sources and many agents, where repeated discovery and integration become substantial work. For startups building on Neo4j, Eifrem closes with a separate invitation to the Neo4j startup program. He describes free credits and a dedicated solution engineering team working with startups for free on data modeling and performance tuning—the practical work of making the underlying graph useful.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Program application, eligibility requirements, Aura credits, and graph-engineering guidance for startups.
Further reading
The startup engineering team's launch announcement describes help with graph schemas, retrieval architecture, and production scaling.
Updates since the talk
Eifrem's companion essay expands the talk into an executable enterprise knowledge layer and describes incremental adoption.
Jesús Barrasa explains ontology mappings, source discovery, governance, and shared memory for enterprise agents.
Read the complete timestamped transcript
- 0:00
[on-hold jingle] All right. At Neo4j, we work with some of the largest companies in the world to help make their data ready for AI agents.
- 0:21
And today, I wanna talk to you about a problem that we saw emerging over the last, call it, six to nine months, and propose a solution blueprint for that.
- 0:31
So let's say that we work at a big organization, a big bank, and we wanna write an agent. Let's say that agent is helping automate the opening of a bank account.
- 0:42
Right? You can imagine that's very ripe for automation. You want to be able to orchestrate that process. And I'm gonna use the powers bestowed upon me by a short keynote slot to grossly simplify what that agent looks like.
- 0:55
I'm gonna say there's two pieces. The first one is, let's call it the business logic. Some version of interpreting intent and plan, act, and we loop around that. It's what your agent does.
- 1:06
And we know that when an agent act, it doesn't always operate on data, but we equally know that in order for agents to be successful, a huge part of that is giving it access to the right data at the right time.
- 1:18
So the second big bucket is, let's call it the data sources. Need to identify, figure out, okay, in order to solve my problem, I need access to these few things, and wire them up and make them available to the agent.
- 1:31
In the example of our account opening agent, maybe we can imagine that we need to be able to validate identity, and so we might look at two data sources for that, the Department of Motor Vehicles, the DMV registry, and maybe some kind of passport verification service.
- 1:46
So we wire that up into our agent, and it works. It's great. It's fantastic, and at the same time, you and other teams in your organization are building other agents, and conceptually, they look very similar.
- 1:58
So that's great. It's fantastic. It works. But it has a few problems. So first of all, every single time a team has to build an agent, they have to figure out from scratch where the data that they require for that agent to operate, where it sits, which if you work at a startup, and you have one application
- 2:17
that sits on top of one Postgres database, that's not hard. The data is in that Postgres database. But in an enterprise ecosystem, you don't have one database, you have 100 databases, and you have Snowflake and Databricks probably, and you have S3 buckets, and so on and so forth.
- 2:32
You have to do that work manually from scratch every single time. And then when you've found the data sources, you know, in an enterprise, there's lots of duplication of data.
- 2:41
So then you need to figure out, like, is this the right data? Is it the right version? Can I trust it? Am I allowed to, uh, access it? So on and so forth.
- 2:49
It also violates one of the core principles of software engineering, the DRY principle, Don't Repeat Yourself. So when something change, that cascades across all of your agents. You have to kind of manually rewire all of them all the time, which works, but it's just a, a lot of work.
- 3:06
And then finally, there's no learning around the data sources and how your agents operate on them. So when your agent wake up-- wakes up tomorrow, it's not smarter than it was today, and there certainly isn't any cross-agent learning because all of that wiring between business intent and the data sources is encoded in a combination of code and
- 3:25
prompts. So I know what you're all thinking, "Markdown files, skills to the rescue." And yes and no. Um, you can come talk to me afterwards for kind of the full version of this, but we've seen a ton of team that tried to solve this problem using just Markdown files.
- 3:41
And the summary is, it is part of the solution, but it is not the solution. Uh, but don't take it from me, take it from Swyx. A week ago on the Latent Space spo-- podcast, he said, "Hey, guys, you gotta learn your databases.
- 3:55
You cannot vibe code with just Markdown files."
- 4:00
So we've been solving this problem at scale for some really massive organizations recently, including a Fortune twenty global bank, a massive tech platform company based here in the Bay Area, and a leading fintech company.
- 4:16
And the pattern that is emerging is that in order to do agents at scale, we need thin agents on a smarter shared substrate. Thin agents on a smarter shared substrate.
- 4:31
And what does that look like in practice? There are three pillars to that. The first pillar is a business-facing ontology. And the word ontology, like, I grew up in this world, people talked about ontologies forever.
- 4:43
More recently, it's become very hype, probably thanks to Palantir, but also the rise of AI, and there's a lot of people that wanna make ontologies really complex. But the core concepts are actually super simple.
- 4:54
What are the key concepts in your organization? In our banking example, customers, accounts, um, debit cards, checks, transactions, and how do they all relate? But very importantly, they are expressed in a way that makes sense to all the human beings working in your universe, right?
- 5:14
All the people working in your company, it's expressed in that name, in that way. In other words, you don't say, "F_name." No, you have a customer, and they have a first name.
- 5:25
So that's the first, a business-facing ontology. The second pillar is a technical ontology. This is all the metadata of all the data sources and data assets in your enterprise ecosystem.
- 5:36
I have 14 Oracle databases, I have 15 Neo4j databases, I have Snowflake and Databricks, and I have S3 buckets and all of that kind of stuff. Where do they sit?
- 5:47
What are the schemas? All of that kind of good stuff. You con- you construct that tech- technical ontology in three key ways that we can talk about later, though not in this, in this talk.
- 5:57
And then you have the mapping between the two. So that customer that has a first name, that first name has a system of record, and over there, there's an Oracle database with a column called F_name.
- 6:08
The mapping between the two. And then the third pillar is the runtime signals out of your agents. When they walk this graph and they execute, they leave the traces around what have I tried, was I successful, what was the outcome, the execution traces.
- 6:25
Those three pillars. Okay, so let's look at that in the context of our bank account opening agent. This is a simplified view, but you can see this graph here, it has a combination of business concept like checks and accounts and credit history and stuff like that.
- 6:41
This is a process-following agent or a process-guided agent. We want this type of agent to actually follow a process. We've also encoded that in the ontology, a business process.
- 6:52
And then if you look at the node that is surrounded by green, the check compliance one, we flip to the technical ontology, and we've put in the graph here, we've discovered and encoded that in order to do a compliance check, you might imagine that you need to resolve a government-issued ID.
- 7:09
And then we say that in this particular organization, there are two data sources that can help us with that. It's the motor vehicle records and the passport verification one.
- 7:18
Okay, so that's really great. So then when our agents come in here and they realize, "I'm gonna check compliance, I need a government-issued ID," here are the two ways that I can resolve that.
- 7:29
When they execute and they try that, they leave, the third pillar, the execution traces for that. And they're more sophisticated than what's on this simplified slide, but involves things like, okay, where was I, what did I do, what is my context, and was I successful?
- 7:45
And ultimately, it leads out to some kind of a score, and you use that as input. It's like, okay, I've been very successful using the DMV lookup, for example.
- 7:55
Then I'm more likely to choose one if I'm in the right context in my next invocation.
- 8:01
Three pillars of the ontology-based semantic layer, a business ontology, a technical ontology, the execution traces, taken together, they solve all four of the problems. We now have a very easy way to discover the data sources.
- 8:14
We know if they're trustworthy or not. We know that top-down by some kind of human curated knowledge, right, an administrator of some sort saying it. We also know it bottom-up through the execution traces.
- 8:25
This is what actually worked in reality, in practice. We have a single governed place that maps business intent and the concepts to those data sources, so we don't repeat ourselves.
- 8:35
If something changes, that cascades across all my agents, right? And we have self-learning. So my agent that wakes up tomorrow is slightly smarter than it was today, and not just self-learning on an individual agent, but across agents as well.
- 8:52
So we remove it from this world, a world of thick agents with manually wired data sources, into this world, where we have thin agents on a smarter, shared ontology-based semantic layer.
- 9:07
And this allows us to do a ton more agents without having to re-engineer them every time. Thin agents on top of a smarter, shared substrate. If you think this is interesting, there's a documentation, a webpage that outlines more in- information about this, if you see the QR code here.
- 9:28
You can also come and talk to us at the booth. We have a big booth here at the expo, P3. We love talking about this, this kind of stuff.
- 9:35
But not just that. This is one pattern, a very exciting pattern that we see a lot of traction around right now for using graphs in AI. But there's hundreds of more interesting patterns that combines graphs and AI.
- 9:49
Ten of them is actually in the graph track that is kicking off right now in room 2005. And you have some really amazing talks from organizations like The Gates Foundation, monday.com, JPMorgan Chase, Berkeley, New York Times, and so on and so forth.
- 10:09
So go check out that thing. And then finally, this was primarily centered around organizations where you deal with many data sources and many agents. But if you're a startup building on Neo4j, love you.
- 10:22
There is a startup program for Neo4j that is phenomenal. You get access to free credit, but more importantly, we've built up a dedicated solution engineering team that spend every day working with startups for free, helping them model their data in Neo4j, tune it for performance, and so on and so forth.
- 10:40
So please sign up for our startup program. Thank you very much. Enjoy the conference. Have a good day, everyone. [upbeat music]