Speaker A
[music] All right. At Neo4j, we work with some of the largest companies in the world to help make their data ready for AI agents.
Emil Eifrem discusses ontology-based semantic layers to enable thin AI agents accessing trusted data across complex enterprise ecosystems.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Ontology-based semantic layers simplify data discovery and trustworthiness assessment for AI agents in enterprises.
- Thin agents on a shared ontology substrate reduce duplication and manual wiring efforts.
- Combining business and technical ontologies with execution traces enables smarter, adaptive AI agents.
- This approach supports scalability and cross-agent learning in complex, multi-database environments.
- Markdown files are helpful but not sufficient for enterprise-scale AI data orchestration.
What the video covers
- Neo4j helps large enterprises prepare data for AI agents by addressing challenges in data access and orchestration.
- AI agents require both business logic and access to diverse, trustworthy data sources to function effectively.
- Enterprises face complexity with numerous databases and data duplication, making manual data source discovery inefficient.
- Repeated manual wiring of data sources violates the DRY principle and complicates maintenance across multiple agents.
- Markdown files alone are insufficient for managing data source knowledge and agent learning.
- The proposed solution involves thin agents operating on a smarter shared substrate built on three pillars: a business-facing ontology, a technical ontology, and runtime execution traces.
- Business-facing ontology defines key organizational concepts in human-readable terms, facilitating shared understanding.
- Technical ontology catalogs metadata about data sources, schemas, and locations across the enterprise.
- Mapping between business and technical ontologies links business concepts to their system of record representations.
- Execution traces capture agent runtime behavior, enabling learning and optimization of data source usage over time.
Chapters
- 00:00Introduction to AI agents and data challenges
- 00:42Example: Automating bank account opening
- 01:07Agent business logic and data source needs
- 01:44Challenges in enterprise data environments
- 02:29Problems with manual data wiring and DRY principle
- 03:19Limitations of markdown files for data management
- 04:27Thin agents on a smarter shared substrate
- 04:55Business-facing ontology explained
- 05:44Technical ontology and metadata management
- 06:10Execution traces and runtime learning
Full Transcript — Download SRT & Markdown
Speaker A
And today I want to talk to you about a problem that we saw emerging over the last, call it, 6 to 9 months and propose a solution blueprint for that.
Speaker A
So, let's say that we work at a big organization, a big bank, and we want to write an agent. Let's say that agent is helping automate the opening of a bank account.
Speaker A
Right? You can imagine that's very ripe for automation. You want to be able to orchestrate that process.
Speaker A
And I'm going to use the powers bestowed upon me by a short keynote slot to grossly simplify what that agent looks like. I'm going to say there's two pieces.
Speaker A
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.
Speaker A
And we know that when an agent acts, 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
Speaker A
the right time. 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
Speaker A
the agent. 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
Speaker A
passport verification service. 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.
Speaker A
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
Speaker A
operate, where it sits, which if you work at a startup and you have one application, it sits on top of one Postgres database, that's not hard. The data is in that Postgres database.
Speaker A
But, in an enterprise ecosystem, you don't have one database, you have a hundred databases, and you have Snowflake and Databricks, probably, and you have S3 buckets, and so on and so forth. You have to do that work manually
Speaker A
from scratch every single time. And then, when you found the data sources, you know, in an enterprise, there's lots of duplication of data. So, then you need to figure out like, is this the right data? Is it the right
Speaker A
version? Can I trust it? Am I allowed to access it? So on and so forth.
Speaker A
It also violates one of the core principles of software engineering, the DRY principle, don't repeat yourself.
Speaker A
So, when something changes, 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 lot of work.
Speaker A
And then, finally, there's no learning around the data sources and how your agents operate on them. So, when your agent wakes up tomorrow, it's not smarter than it was today, and there certainly isn't any cross-agent learning
Speaker A
because all of that wiring between business intent and the data sources is encoded in a combination of code and prompts.
Speaker A
So, I know what you're all thinking. Markdown files, skills to the rescue. And yes and no. You can come talk to me afterwards for kind of the full version of this, but we've seen a ton of teams that tried to solve this problem
Speaker A
using just Markdown files. And the summary is it is part of the solution, but it is not the solution.
Speaker A
But, don't take it from me, take it from Swyx. A week ago on the Latent Space Spot podcast, I said, "Hey guys, you got to learn your databases. You cannot vibe code with just markdown files." So, we've been solving this problem at
Speaker A
scale for some really massive organizations recently, including a Fortune 20 global bank, a massive tech platform company based here in the Bay Area, and a leading fintech company.
Speaker A
And the pattern that is emerging is that in order to do things at scale, we need thin agents on a smarter shared substrate.
Speaker A
Thin agents on a smarter shared substrate. And what does that look like in practice? There are three pillars to that.
Speaker A
The first pillar is a business-facing ontology. And the word ontology, like I grew up in this world, people talked about ontologies forever. More recently, it's become very hype, probably thanks to Palantir, but also the rise of AI.
Speaker A
And there's a lot of people who want to make ontologies really complex. But the core concepts are actually super simple.
Speaker A
What are the key concepts in your organization? In our banking example, customers, accounts, 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
Speaker A
working in your universe, right? All the people working in your company, it's expressed in that name, in that way. In other words, you don't say if underscore name. No, you have a customer and they have a first name. So, that's the first,
Speaker A
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. I have 14 Oracle databases, I have 15 Neo4j databases, I have Snowflake and Databricks and I have
Speaker A
S3 buckets and all that kind of stuff. Where do they sit? What are the schemas? All of that kind of good stuff.
Speaker A
You can construct that technical ontology in three key ways that we can talk about later, though not in this talk. And then you have a mapping between the two. So that customer that has a first name, that first name has a
Speaker A
system of record and over there there's an Oracle database with a column called F_name. The mapping between the two.
Speaker A
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. Those
Speaker A
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 concepts like checks and accounts and credit history
Speaker A
and stuff like that. 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.
Speaker A
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
Speaker A
that you need to resolve a government-issued ID. 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.
Speaker A
Which is that's really great. So then when our agents come in here and they realize I'm going to check compliance, I need a government-issued ID. Here are the two ways that I can resolve that.
Speaker A
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?
Speaker A
What is my context? And was I successful? 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, then I'm more
Speaker A
likely to choose one if I'm in the right context in my next invocation. 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
Speaker A
way to discover the data sources. We know if they're trustworthy or not. W
Speaker A
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. If something changes, that cascades across all my agents, right?
Speaker A
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.
Speaker A
So, we're moving 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. And this allows us to do a ton more agents
Speaker A
without having to re-engineer them every time. Thin agents on top of a smarter shared substrate.
Speaker A
If you think this is interesting, there's a documentation webpage that outlines more information about this. If you see the QR code here, you can also come and talk to us at the booth. We have a big booth here at the Expo, P3.
Speaker A
We love talking about this this kind of stuff. 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.
Speaker A
But there's hundreds of more interesting patterns that combines graphs and AI. 10 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
Speaker A
Foundation, monday.com, JP Morgan Chase, Berkeley, New York Times, and so on and so forth. So go check out that thing.
Speaker A
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. There is a startup program for Neo4j that is phenomenal.
Speaker A
You get access to free credit, but more importantly, we've built up a dedicated solution engineering team that spent every day working with startups for free, helping them model their data in Neo4j, tune it for performance, and so on and so forth. So please sign up for
Speaker A
our startup program. Thank you very much. Enjoy the conference. Have a good day, everyone.
Topics:Neo4jAI agentsontologysemantic layerenterprise datadata sourcesbusiness ontologytechnical ontologyexecution tracesdata orchestration
