WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=VGN22pPpb-8 NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/VGN22pPpb-8.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.760 --> 00:00:14.280 All right. s3 00:00:14.280 --> 00:00:21.840 At Neo4j, we work with some of the largest companies in the world to help make their data ready for AI agents. s4 00:00:21.840 --> 00:00:31.400 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. s5 00:00:31.400 --> 00:00:36.400 So, let's say that we work at a big organization, a big bank, and we want to write an agent. s6 00:00:36.400 --> 00:00:42.200 Let's say that agent is helping automate the opening of a bank account. s7 00:00:42.200 --> 00:00:42.760 Right? s8 00:00:42.760 --> 00:00:45.080 You can imagine that's very ripe for automation. s9 00:00:45.080 --> 00:00:47.960 You want to be able to orchestrate that process. s10 00:00:47.960 --> 00:00:55.680 And I'm going to use the powers bestowed upon me by a short keynote slot to grossly simplify what that agent looks like. s11 00:00:55.680 --> 00:00:57.600 I'm going to say there's two pieces. s12 00:00:57.600 --> 00:01:00.560 The first one is, let's call it, the business logic. s13 00:01:00.560 --> 00:01:04.920 Some version of interpreting intent and plan, act, and we loop around that. s14 00:01:04.920 --> 00:01:06.720 It's what your agent does. s15 00:01:06.720 --> 00:01:15.800 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 s16 00:01:15.800 --> 00:01:18.160 to the right data at the right time. s17 00:01:18.160 --> 00:01:22.200 So, the second big bucket is, let's call it, the data sources. s18 00:01:22.200 --> 00:01:31.480 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. s19 00:01:31.480 --> 00:01:37.880 In the example of our account opening agent, maybe we can imagine that we need to be able to validate identity. s20 00:01:37.880 --> 00:01:46.160 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. s21 00:01:46.160 --> 00:01:49.480 So, we wire that up into our agent, and it works. s22 00:01:49.480 --> 00:01:49.960 It's great. s23 00:01:49.960 --> 00:01:50.720 It's fantastic. s24 00:01:50.720 --> 00:01:58.880 And at the same time, you and other teams in your organization are building other agents, and conceptually, they look very similar. s25 00:01:58.880 --> 00:01:59.600 That's great. s26 00:01:59.600 --> 00:02:00.360 It's fantastic. s27 00:02:00.360 --> 00:02:02.000 It works. s28 00:02:02.000 --> 00:02:03.960 But, it has a few problems. s29 00:02:03.960 --> 00:02:13.959 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, s30 00:02:13.959 --> 00:02:20.720 which if you work at a startup and you have one application, it sits on top of one Postgres database, that's not hard. s31 00:02:20.720 --> 00:02:22.800 The data is in that Postgres database. s32 00:02:22.800 --> 00:02:32.520 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. s33 00:02:32.520 --> 00:02:36.120 You have to do that work manually from scratch every single time. s34 00:02:36.120 --> 00:02:41.320 And then, when you found the data sources, you know, in an enterprise, there's lots of duplication of data. s35 00:02:41.320 --> 00:02:43.680 So, then you need to figure out like, is this the right data? s36 00:02:43.680 --> 00:02:44.880 Is it the right version? s37 00:02:44.880 --> 00:02:45.560 Can I trust it? s38 00:02:45.560 --> 00:02:47.160 Am I allowed to access it? s39 00:02:47.160 --> 00:02:49.040 So on and so forth. s40 00:02:49.040 --> 00:02:55.080 It also violates one of the core principles of software engineering, the DRY principle, don't repeat yourself. s41 00:02:55.080 --> 00:02:59.640 So, when something change, that cascades across all of your agents. s42 00:02:59.640 --> 00:03:06.440 You have to kind of manually rewire all of them all the time, which works, but it's just a a lot of work. s43 00:03:06.440 --> 00:03:11.680 And then, finally, there's no learning around the data sources and how your agents operate on them. s44 00:03:11.680 --> 00:03:24.959 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 s45 00:03:24.959 --> 00:03:27.120 and prompts. s46 00:03:27.320 --> 00:03:28.640 So, I know what you're all thinking. s47 00:03:28.640 --> 00:03:31.360 Markdown files, skills to the rescue. s48 00:03:31.360 --> 00:03:40.400 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 s49 00:03:40.400 --> 00:03:41.840 using just Markdown files. s50 00:03:41.840 --> 00:03:47.560 And the summary is it is part of the solution, but it is not the solution. s51 00:03:47.560 --> 00:03:50.600 Uh but, don't take it from me, take it from Swyx. s52 00:03:50.600 --> 00:03:55.600 A week ago on the Latent Space Spot podcast, I said, "Hey guys, you got to learn your databases. s53 00:03:55.600 --> 00:04:00.520 You cannot vibe code with just markdown files." s54 00:04:00.640 --> 00:04:16.480 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. s55 00:04:16.480 --> 00:04:27.240 And the pattern that is emerging is that in order to do things at scale, we need thin agents on a smarter shared substrate. s56 00:04:27.240 --> 00:04:31.440 Thin agents on a smarter shared substrate. s57 00:04:31.440 --> 00:04:32.960 And what does that look like in practice? s58 00:04:32.960 --> 00:04:34.800 There are three pillars to that. s59 00:04:34.800 --> 00:04:37.240 The first pillar is a business-facing ontology. s60 00:04:37.240 --> 00:04:43.160 And the word ontology, like I grew up in this world, people talked about ontologies forever. s61 00:04:43.160 --> 00:04:48.880 More recently, it's become very hype, probably thanks to Palantir, but also the rise of AI. s62 00:04:48.880 --> 00:04:52.560 And there's a lot of people who want to make ontologies really complex. s63 00:04:52.560 --> 00:04:54.800 But the core concepts are actually super simple. s64 00:04:54.800 --> 00:04:57.600 What are the key concepts in your organization? s65 00:04:57.600 --> 00:05:07.080 In our banking example, customers, accounts, um debit cards, checks, transactions, and how do they all relate? s66 00:05:07.080 --> 00:05:14.000 But very importantly, they are expressed in a way that makes sense to all the human beings working in your universe, right? s67 00:05:14.000 --> 00:05:18.440 All the people working in your company, it's expressed in that name, in that way. s68 00:05:18.440 --> 00:05:22.240 In other words, you don't say if underscore name. s69 00:05:22.240 --> 00:05:25.120 No, you have a customer and they have a first name. s70 00:05:25.120 --> 00:05:27.360 So, that's the first, a business-facing ontology. s71 00:05:27.360 --> 00:05:30.160 The second pillar is a technical ontology. s72 00:05:30.160 --> 00:05:36.520 This is all the metadata of all the data sources and data assets in your enterprise ecosystem. s73 00:05:36.520 --> 00:05:46.240 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. s74 00:05:46.240 --> 00:05:47.280 Where do they sit? s75 00:05:47.280 --> 00:05:48.520 What are the schemas? s76 00:05:48.520 --> 00:05:49.560 All of that kind of good stuff. s77 00:05:49.560 --> 00:05:57.160 You can You construct that technical ontology in three key ways that we can talk about later, though not in this in this talk. s78 00:05:57.160 --> 00:05:58.840 And then you have a mapping between the two. s79 00:05:58.840 --> 00:06:08.040 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. s80 00:06:08.040 --> 00:06:10.120 The mapping between the two. s81 00:06:10.120 --> 00:06:14.640 And then the third pillar is the run time signals out of your agents. s82 00:06:14.640 --> 00:06:20.760 When they walk this graph and they execute, they leave the traces around. s83 00:06:20.760 --> 00:06:21.760 What have I tried? s84 00:06:21.760 --> 00:06:22.760 Was I successful? s85 00:06:22.760 --> 00:06:24.280 What was the outcome? s86 00:06:24.280 --> 00:06:25.760 The execution traces. s87 00:06:25.760 --> 00:06:27.520 Those three pillars. s88 00:06:27.520 --> 00:06:32.080 Okay, so let's look at that in the context of our bank account opening agent. s89 00:06:32.080 --> 00:06:34.919 This is a simplified view, but you can see this graph here. s90 00:06:34.919 --> 00:06:40.960 It has a combination of business concepts like checks and accounts and credit history and stuff like that. s91 00:06:40.960 --> 00:06:45.320 This is a process following agent or a process guided agent. s92 00:06:45.320 --> 00:06:48.400 We want this type of agent to actually follow a process. s93 00:06:48.400 --> 00:06:52.720 We've also encoded that in the ontology, a business process. s94 00:06:52.720 --> 00:07:02.080 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. s95 00:07:02.080 --> 00:07:09.840 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. s96 00:07:09.840 --> 00:07:15.160 And then we say that in this particular organization, there are two data sources that can help us with that. s97 00:07:15.160 --> 00:07:18.919 It's the motor vehicle records and the passport verification one. s98 00:07:18.919 --> 00:07:20.120 Which is that's really great. s99 00:07:20.120 --> 00:07:26.760 So then when our agents come in here and they realize I'm going to check compliance, I need a government issued ID. s100 00:07:26.760 --> 00:07:29.200 Here are the two ways that I can resolve that. s101 00:07:29.200 --> 00:07:35.880 When they execute and they try that, they leave the third pillar, the execution traces for that. s102 00:07:35.880 --> 00:07:41.880 And they're more sophisticated than what's on this simplified slide, but involves things like, okay, where was I? s103 00:07:41.880 --> 00:07:42.840 What did I do? s104 00:07:42.840 --> 00:07:44.240 What is my context? s105 00:07:44.240 --> 00:07:45.600 And was I successful? s106 00:07:45.600 --> 00:07:48.960 And ultimately it leads out to some kind of a score. s107 00:07:48.960 --> 00:07:50.400 And you use that as input. s108 00:07:50.400 --> 00:08:01.360 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. s109 00:08:01.400 --> 00:08:11.240 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. s110 00:08:11.240 --> 00:08:14.240 We now have a very easy way to discover the data sources. s111 00:08:14.240 --> 00:08:16.560 We know if they're trustworthy or not. s112 00:08:16.560 --> 00:08:20.600 We know that top-down by some kind of human curated knowledge, right? s113 00:08:20.600 --> 00:08:22.880 An administrator of some sort saying it. s114 00:08:22.880 --> 00:08:25.240 We also know it bottom-up through the execution traces. s115 00:08:25.240 --> 00:08:29.080 This is what actually worked in reality, in practice. s116 00:08:29.080 --> 00:08:34.560 We have a single governed place that maps business intent and the concepts to those data sources. s117 00:08:34.560 --> 00:08:35.840 So, we don't repeat ourselves. s118 00:08:35.840 --> 00:08:40.680 If something changes, that cascades across all my agents, right? s119 00:08:40.680 --> 00:08:42.039 And we have self-learning. s120 00:08:42.039 --> 00:08:46.720 So, my agent that wakes up tomorrow is slightly smarter than it was today. s121 00:08:46.720 --> 00:08:52.360 And not just self-learning on an individual agent, but across agents as well. s122 00:08:52.360 --> 00:09:06.160 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 s123 00:09:06.160 --> 00:09:06.960 layer. s124 00:09:06.960 --> 00:09:15.040 And this allows us to do a ton more agents without having to re-engineer them every time. s125 00:09:15.040 --> 00:09:20.800 Thin agents on top of a smarter shared substrate. s126 00:09:20.800 --> 00:09:26.920 If you think this is interesting, there's a documentation webpage that outlines more information about this. s127 00:09:26.920 --> 00:09:30.600 If you see the QR code here, you can also come and talk to us at the booth. s128 00:09:30.600 --> 00:09:33.400 We have a big booth here at the Expo, P3. s129 00:09:33.400 --> 00:09:35.720 We love talking about this this kind of stuff. s130 00:09:35.720 --> 00:09:44.920 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. s131 00:09:44.920 --> 00:09:49.680 But there's hundreds of more interesting patterns that combines graphs and AI. s132 00:09:49.680 --> 00:09:56.640 10 of them is actually in the graph track that is kicking off right now in room 2005. s133 00:09:56.640 --> 00:10:08.840 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. s134 00:10:08.840 --> 00:10:10.240 So go check out that thing. s135 00:10:10.240 --> 00:10:18.160 And then finally, this was primarily centered around organizations where you deal with many data sources and many agents. s136 00:10:18.160 --> 00:10:22.040 But if you're a startup building on Neo4j, love you. s137 00:10:22.040 --> 00:10:25.600 There is a startup program for Neo4j that is phenomenal. s138 00:10:25.600 --> 00:10:37.880 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, s139 00:10:37.880 --> 00:10:40.360 tune it for performance, and so on and so forth. s140 00:10:40.360 --> 00:10:43.600 So please sign up for our startup program. s141 00:10:43.600 --> 00:10:44.520 Thank you very much. s142 00:10:44.520 --> 00:10:46.120 Enjoy the conference. s143 00:10:46.120 --> 00:10:48.520 Have a good day, everyone.