Talk by Emil Eifrem (Neo4j) on making AI agents "thin" by placing intelligence in a shared ontology-based semantic layer. He frames the problem with an account-opening agent that must discover data sources, assess trust and permissions, and get rewired whenever a source moves — work every team currently repeats. The proposed substrate has three pillars: a business ontology naming real concepts in human terms, a technical ontology cataloging data sources and schemas with a mapping between the two, and execution traces recording agent attempts and outcomes so the layer learns which lookups succeed. Discovery, trust, deduplication (DRY), and learning shift from individual teams to the substrate. # Channel Identity Observations — Video: "Thinner Agents on a Smarter Substrate" (Emil Eifrem, Neo4j) ## Speaker / Creator Affiliation - The speaker explicitly identifies with **Neo4j**, a graph database company: > "At Neo4j, we work with some of the largest companies in the world to help make their data ready for AI agents." - This appears to be a **conference keynote or talk** rather than a standard channel video, evidenced by references to a "short keynote slot," an expo booth, and a session track: > "You can also come and talk to us at the booth. We have a big booth here at the Expo, P3." ## Explicit Self-Description Claims - **Enterprise focus**: Claims work "with some of the largest companies in the world." - **Named-scale client work**: Cites (unnamed but characterized) deployments: > "A Fortune 20 global bank, a massive tech platform company based here in the Bay Area, and a leading fintech company." - **Startup outreach**: Explicitly promotes a Neo4j startup program with "free credit" and a "dedicated solution engineering team." ## Claimed Scope of Content - **AI agent architecture at enterprise scale**, specifically data-readiness and knowledge graphs/ontologies for agents. - The talk proposes a solution blueprint: **"thin agents on a smarter shared substrate"** built on three pillars — a business-facing ontology, a technical ontology, and agent execution traces. - Broader claimed territory: **"hundreds of more interesting patterns that combines graphs and AI,"** with a graph track featuring talks from the Gates Foundation, monday.com, JP Morgan Chase, Berkeley, and the New York Times. ## Intended Audience Evidence points to **multiple audience segments** addressed directly: - **Enterprise data/AI practitioners** — the core audience, addressed via the bank account-opening agent example and discussion of enterprise data sprawl ("you have a hundred databases... Snowflake and Databricks... S3 buckets"). - **Startups building on Neo4j** — addressed explicitly near the end: > "If you're a startup building on Neo4j, love you. There is a startup program..." - **Conference attendees** — repeated calls to action (QR code, booth, graph track in "room 2005"). ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Practitioner-oriented, example-driven teaching style**: Builds the argument from a concrete, simplified banking scenario ("I'm going to use the powers bestowed upon me by a short keynote slot to grossly simplify"). - **Technical credibility signaling via industry references**: Quotes Swyx / Latent Space podcast ("you cannot vibe code with just markdown files") and references Palantir's popularization of ontologies. - **Sales-adjacent but educational tone**: The bulk of the talk is architectural reasoning (DRY principle, data discovery, trust, cross-agent learning), with product/company promotion concentrated in the closing segment (documentation page, booth, startup program). ## Evidence Gap Notes - No curated metadata was supplied, so identity context rests entirely on title and transcript. - The speaker does not explicitly describe the *channel* itself (e.g., "on this channel we..."); all self-description concerns **Neo4j as a company**, not the publishing channel. Any channel-level identity must be inferred from this being one representative talk, not stated directly. # Delivery Observations: Emil Eifrem, Neo4j Keynote ## Tone - **Conversational and informal** throughout: casual asides like *"call it, 6 to 9 months"*, *"All right."*, *"and so on and so forth"* (repeated multiple times). - **Light humor and self-deprecation**, e.g., *"I'm going to use the powers bestowed upon me by a short keynote slot to grossly simplify"*. ## Recurring Phrases & Verbal Habits - **"So" as a frequent discourse marker** opening sentences: *"So, let's say that we work at a big organization"*, *"So, we wire that up"*, *"So, when something change"*. - **"Let's say" / "Let's call it"** used to set up examples and labels: *"let's call it, the business logic"*, *"let's call it, the data sources"*, *"Let's say that agent is helping automate..."* - **Repetition for emphasis** — the core thesis is repeated nearly verbatim: > *"we need thin agents on a smarter shared substrate. Thin agents on a smarter shared substrate."* and again at the end: *"Thin agents on top of a smarter shared substrate."* - **"It's great. It's fantastic."** used twice — first sincerely ("So, we wire that up into our agent, and it works. It's great. It's fantastic."), then ironically ("That's great. It's fantastic. It works. But, it has a few problems."). ## Teaching / Structural Habits - **Numbered-pillar structure**: *"There are three pillars to that. The first pillar is... The second pillar is... And then the third pillar is..."*, later recapped: *"Three pillars of the ontology-based semantic layer..."* - **Running concrete example** (bank account-opening agent with DMV and passport verification) introduced early and reused to illustrate each point. - **Problem–solution framing**: lists problems ("first of all... And then... And then, finally"), then explicitly maps the solution back: *"taken together, they solve all four of the problems."* - **Anticipates audience skepticism**: *"So, I know what you're all thinking. Markdown files, skills to the rescue. And yes and no."* - **Appeals to external authority**: *"don't take it from me, take it from Swyx."* - **Deferred depth**: explicitly defers details — *"three key ways that we can talk about later, though not in this in this talk"*, *"you can come talk to me afterwards for kind of the full version of this."* ## Vocabulary - Enterprise/technical register: *ontology, DRY principle, system of record, execution traces, data sources, semantic layer, Snowflake, Databricks, S3 buckets*. - Concrete technical contrast for clarity: *"you don't say if underscore name. No, you have a customer and they have a first name."* ## Closing Pattern - **Promotional close**: QR code, booth reference, session recommendations, and a startup-program pitch — a shift from teaching to marketing: *"if you're a startup building on Neo4j, love you."* ## Uncertainty Notes - Filler and minor disfluencies in the transcript (e.g., *"when an agent act"*, *"when your agent wake up wakes up"*) appear to be transcription artifacts; delivery fluency beyond this cannot be assessed. - No video/visual delivery cues (gestures, pacing, slides beyond references) are observable from the transcript alone; observations are limited to spoken content. # Position Record: Emil Eifrem (Neo4j) — “Thinner Agents on a Smarter Substrate” ## Core Claim - **Thesis:** Enterprise AI agents should be built as **thin agents sitting on a smarter shared substrate** — an **ontology-based semantic layer** — rather than as thick agents with manually wired data sources. ## Problem Identified (as stated by Eifrem) Enterprise agent-building teams repeatedly wire data sources manually, which causes four problems: 1. **Repeated discovery work:** Every team must find where required data sits from scratch — trivial in a startup with one Postgres database, but difficult in enterprises with “a hundred databases,” Snowflake, Databricks, and S3 buckets. 2. **Data trust/quality questions:** Enterprises have duplicated data; teams must determine whether data is the right version, trustworthy, and accessible. 3. **DRY violation:** Because business-intent-to-data wiring is encoded in code and prompts, changes cascade across all agents, requiring manual rewiring. 4. **No learning:** Agents don’t get smarter day over day, and there is **no cross-agent learning**, because the wiring lives in code and prompts. ## Positions on Alternative Solutions - **On Markdown files / skills:** Eifrem says teams “tried to solve this problem using just Markdown files,” and his summary is: > “It is part of the solution, but it is not the solution.” - He cites **Swyx on the Latent Space podcast** (a week prior): “You cannot vibe code with just markdown files.” ## Proposed Solution: Three Pillars of the Semantic Layer 1. **Business-facing ontology** - Key business concepts (e.g., customers, accounts, debit cards, checks, transactions) and their relationships. - Must be **expressed in terms meaningful to humans** — “you don’t say `if_underscore_name`; you have a customer and they have a first name.” - Eifrem acknowledges “ontology” is hype-heavy (crediting Palantir and AI’s rise) but insists the core concepts are “super simple.” 2. **Technical ontology** - Metadata of all enterprise data assets — locations, schemas (14 Oracle databases, 15 Neo4j databases, Snowflake, Databricks, S3, etc.). - Can be constructed “in three key ways” — explicitly **not elaborated in this talk**. 3. **Mapping between the two** - E.g., the business “first name” concept maps to a system-of-record Oracle column `F_name`. 4. **(Runtime) Execution traces** - Agents walking the graph leave traces: what was tried, context, success/outcome, leading to a score. - Traces feed future source selection — e.g., prior DMV-lookup success makes that source more likely to be chosen in the right context. *(Eifrem introduces “three pillars” but enumerates the mapping as an additional element alongside business ontology, technical ontology, and execution traces.)* ## Worked Example: Bank Account-Opening Agent - Agent needs to **check compliance**, requiring resolution of a **government-issued ID**. - Technical ontology records two possible sources: **motor vehicle records** and **passport verification**. - The business ontology also encodes the **business process** the agent must follow — Eifrem describes this as a “process following / process guided agent.” ## Claimed Outcomes The three pillars “solve all four of the problems”: - **Data discovery** becomes easy. - **Trustworthiness** is known both **top-down** (human/admin-curated knowledge) and **bottom-up** (what actually worked in execution traces). - **Single governed mapping** of business intent to data sources → no repetition; changes cascade automatically across agents. - **Self-learning**, both per-agent and **cross-agent**: “my agent that wakes up tomorrow is slightly smarter than it was today.” ## Supporting Evidence Claimed - Deployed at scale for “a **Fortune 20 global bank**, a massive tech platform company based here in the Bay Area, and a leading fintech company” — no specifics given. - Repeatedly flags the keynote as **grossly simplified** (“powers bestowed upon me by a short keynote slot”; “simplified view”; “more sophisticated than what’s on this simplified slide”). ## Closing Notes - Points to documentation (QR code) and Neo4j booth P3. - Notes the graph track (room 2005) with talks from Gates Foundation, monday.com, JP Morgan Chase, Berkeley, New York Times. - **Startup outreach:** Neo4j startup program offers free credits and a dedicated solution-engineering team. - Scope caveat stated by Eifrem: this pattern is for **organizations with many data sources and many agents**. ## Contradictions / Qualifications Preserved - **Markdown files:** “yes and no” — part of the solution, not the whole solution. - **Simplification caveat:** the entire architecture presentation is explicitly a gross simplification; trace metadata details are deferred. - **Ontology hype:** Eifrem notes many want to make ontologies “really complex,” while he asserts the core is simple — a stated tension left as-is. # Speaker Attribution Record **Video:** Thinner Agents on a Smarter Substrate: The Ontology-based Semantic Layer — Emil Eifrem, Neo4j (ID: `01a15ca8-6933-7824-b18d-cbade9694ecf`) ## Speakers | Speaker | Role | Evidence | |---|---|---| | Emil Eifrem | **Creator / Keynote speaker** | Title attributes talk to Eifrem, Neo4j; speaker presents first-person ("At Neo4j, we work with…"). | - Single-speaker talk; no guests or narrators identified. - The speaker identifies himself as speaking for **Neo4j** ("we've been solving this problem at scale"). ## Referenced Sources & Third-Party Claims - **Swyx / Latent Space podcast** — speaker quotes his own prior remark: *"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.'"* (Quote is the speaker's own words, as he reports them.) - **Palantir** — cited as a likely reason ontologies became "hype" (speaker's characterization). - **Named customer classes (unidentified):** a **Fortune 20 global bank**, a **"massive tech platform company based here in the Bay Area,"** and a **leading fintech company** — claimed as recent Neo4j engagements. - **Hypothetical data sources in the example:** DMV registry, passport verification service, Oracle/Neo4j databases, Snowflake, Databricks, S3 buckets, Postgres. ## Promotional Segments (Flagged) - **Documentation webpage / QR code** promotion for the ontology-based semantic layer. - **Booth promotion** — "big booth here at the Expo, P3." - **Graph track session promotion** — room 2005, with talks by Gates Foundation, monday.com, JP Morgan Chase, Berkeley, New York Times. - **Neo4j startup program promotion** — free credits and dedicated solution engineering team; explicit call to "sign up." ## Provenance & Availability Notes - **Comments availability:** not specified in the transcript or metadata. - **Curated metadata:** none supplied beyond title/video ID; speaker identity rests on the title attribution. - No timestamps or external citations verifiable from the source material. \>\> All right. At Neo4j, we work with some of the largest companies in the world to help make their data ready for AI agents. 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. 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. Right? You can imagine that's very ripe for automation. You want to be able to orchestrate that process. 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. 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. 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. 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. 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. 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. 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, it 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 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 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 version? Can I trust it? Am I allowed to access it? So on and so forth. 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. 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 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. 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 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 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. And the pattern that is emerging is that in order to do things at scale, we need thin agents on a smarter shared substrate. Thin agents on a smarter shared substrate. 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. More recently, it's become very hype, probably thanks to Palantir, but also the rise of AI. And there's a lot of people who want to make ontologies really complex. But the core concepts are actually super simple. 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? 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, 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 S3 buckets and all all that kind of stuff. Where do they sit? What are the schemas? All of that kind of good stuff. You can You construct that technical ontology in three key ways that we can talk about later, though not in this 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 system of record and over there there's an Oracle database with a column called F\_name. The mapping between the two. And then the third pillar is the run time 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 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 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. 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. 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. 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. 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? 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 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 way to discover the data sources. 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. 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. 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. 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 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 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. 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. 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 Foundation, monday.com, JP Morgan Chase, Berkeley, New York Times, and so on and so forth. 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. 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 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 our startup program. Thank you very much. Enjoy the conference. Have a good day, everyone.