WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=BIhiYL4U9_M NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/BIhiYL4U9_M.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.560 --> 00:00:14.760 Hey, so I'm Anders. s3 00:00:14.760 --> 00:00:26.760 I'm a developer advocate for Oracle AI database and I'm talking about how we can approach agent memory as a systems problem, how we can take context and turn it into a real s4 00:00:26.760 --> 00:00:31.200 memory layer that is going to help your agents work better. s5 00:00:31.200 --> 00:00:41.560 Um when we're talking about agent memory, we're talking about composing memory retrieval, memory formation, and the persistent storage that's backing these memories. s6 00:00:41.560 --> 00:00:52.280 Um and we've probably all used different agents at this point, agents like Claude code or Codex, and we've seen them work on a task and reread the same files over and over again. s7 00:00:52.280 --> 00:00:57.400 And this this is because they have no knowledge of what has happened in the past. s8 00:00:57.400 --> 00:01:00.200 Context windows are are not memory. s9 00:01:00.200 --> 00:01:04.600 Um they're the input for the current run and not a persistent experience. s10 00:01:04.600 --> 00:01:20.520 If I have some agent session, let's say he's working on customer support tickets, he reads a bunch of documents, he runs a bunch of queries, he reproduces a failure, finds root cause, and does all this like great valuable work that synthesizes a useful procedure. s11 00:01:20.520 --> 00:01:23.400 What happens at the end of the session? s12 00:01:23.600 --> 00:01:24.600 It's tossed away. s13 00:01:24.600 --> 00:01:27.120 And this is because there's no persistence. s14 00:01:27.120 --> 00:01:34.760 Uh you know, a long long later another another agent comes on and he works on a similar task and he has to repeat all of the same work. s15 00:01:34.760 --> 00:01:45.720 So he's he's searching more documents, he's running more queries, and this is more opportunity for failure, more opportunity for hallucinations, and and ultimately uh less fidelity. s16 00:01:45.720 --> 00:01:54.560 And memory really cannot begin until these useful experiences from our agents are transformed into managed state. s17 00:01:54.560 --> 00:01:57.520 Uh larger context windows are also not the solution. s18 00:01:57.520 --> 00:01:59.160 We end up throwing more and more tokens. s19 00:01:59.160 --> 00:02:01.560 The session grows longer, compaction occurs. s20 00:02:01.560 --> 00:02:09.479 The useful signal that occurs for our agents is lost in a slew of other irrelevant information. s21 00:02:09.520 --> 00:02:13.440 Likewise, scratch pads are workarounds. s22 00:02:13.440 --> 00:02:20.520 So, things like markdown files, we start building large hierarchies of files, uh wikis, prompts. s23 00:02:20.520 --> 00:02:24.520 These do help, but this is not governed recall. s24 00:02:24.520 --> 00:02:30.040 Uh files do not scale in large multi-tenant environments. s25 00:02:30.040 --> 00:02:38.760 Uh tools like grep are extremely useful for finding data, but they also don't scale well, and it is not complex hybrid retrieval. s26 00:02:38.760 --> 00:02:47.760 And I feel like if we continue to the logical conclusion of trying to build a memory layer on top of files, we're going to be building our own database. s27 00:02:47.760 --> 00:03:01.560 And I don't I you could just use a Uh in this presentation, this is unpacking the lessons that we've learned as a database vendor working with customers who are developing agent memory, customers s28 00:03:01.560 --> 00:03:07.360 who are solving real problems with agents and needing recall. s29 00:03:07.640 --> 00:03:17.720 And where we're seeing modern agent memory systems converge is there's there's a pattern that's implementing memory formation, memory recall, evolution, and evaluation. s30 00:03:17.720 --> 00:03:22.760 So, when we form memories, these are these are distilled experiences, structured facts. s31 00:03:22.760 --> 00:03:25.440 This is not a raw transcript dump. s32 00:03:25.440 --> 00:03:29.880 When we're recalling memories, hybrid retrieval is emerging as a dominant method. s33 00:03:29.880 --> 00:03:33.720 This is This is a form of retrieval that fuses different types of search. s34 00:03:33.720 --> 00:03:44.280 So, vector similarity search, lexical search, entity search over relational objects, graph traversals, and different signals over temporal data, recency, and feedback. s35 00:03:44.280 --> 00:03:46.280 We also need consolidation in these systems. s36 00:03:46.280 --> 00:03:47.920 So, duplicates can emerge. s37 00:03:47.920 --> 00:03:49.560 We need to resolve conflicts. s38 00:03:49.560 --> 00:03:51.600 The system needs to evolve over time. s39 00:03:51.600 --> 00:03:55.720 Otherwise, because it becomes stale, irrelevant, and useless. s40 00:03:55.720 --> 00:03:57.800 Memories need element of temporality. s41 00:03:57.800 --> 00:03:59.280 So, when was this created? s42 00:03:59.280 --> 00:04:00.960 When was it accessed? s43 00:04:00.960 --> 00:04:02.000 How long is it valid for? s44 00:04:02.000 --> 00:04:05.040 It may only be valid for a certain time window. s45 00:04:05.040 --> 00:04:09.200 And this all needs to come into regular feedback and evaluation. s46 00:04:09.200 --> 00:04:16.519 If I'm not measuring use, I'm not sending feedback into the memory layer, it's all going to fall over. s47 00:04:16.519 --> 00:04:21.120 Um another important piece is the governance controls. s48 00:04:21.120 --> 00:04:26.240 So, secrets, personal information, that needs to be redacted before it hits the memory layer. s49 00:04:26.240 --> 00:04:30.120 Rights need to be scoped, scoped to the agent, scoped to the workflow, the team, the user. s50 00:04:30.120 --> 00:04:34.080 This is especially important in multi-tenant environments. s51 00:04:34.080 --> 00:04:41.240 We need appropriate admin approvals, review, and ability to suppress stale or poisoned data. s52 00:04:41.320 --> 00:04:45.320 When we walk through the memory loop, we have an agent session. s53 00:04:45.320 --> 00:04:50.919 It does some work, reads documents, run queries, synthesizes useful data. s54 00:04:50.919 --> 00:04:54.560 After that session or during that session, a fact is created. s55 00:04:54.560 --> 00:04:59.520 We record that fact through redacting, enriching, storing it in the persistence layer. s56 00:04:59.520 --> 00:05:06.520 And then when another session comes along with related context, it can retrieve that fact and use it for context card reconstruction. s57 00:05:06.520 --> 00:05:12.919 So, it's using that fact that came from a prior art to make the next task easier. s58 00:05:12.919 --> 00:05:15.720 That's less work for the next agent to do. s59 00:05:15.720 --> 00:05:21.160 And if that agent uses the fact successfully, we can add feedback scores to that memory. s60 00:05:21.160 --> 00:05:23.160 So, we're adapting over time. s61 00:05:23.160 --> 00:05:25.960 We get related data and new temporality. s62 00:05:25.960 --> 00:05:26.840 We access it again. s63 00:05:26.840 --> 00:05:30.160 We We did something with it. s64 00:05:30.760 --> 00:05:34.720 Now, memory, it's invoked as a function by the agent runtime. s65 00:05:34.720 --> 00:05:38.360 So, it needs read, write, and storage layers. s66 00:05:38.360 --> 00:05:44.680 Your agent runtime can invoke the memory layer through things like hooks, MCP, skills, or other methods. s67 00:05:44.680 --> 00:05:55.760 And the memory layer API is exposing these the read write the feedback administrative APIs and then talking to the storage platform or databases. s68 00:05:56.520 --> 00:06:09.160 The choice of database here I I think multi-model databases are especially useful because they allow you to not work work with your rows, columns, vector embeddings, full text search, relational entities, graphs, s69 00:06:09.160 --> 00:06:12.600 episodes and facts all in one place. s70 00:06:12.600 --> 00:06:17.919 So your memory can live in a consolidated place with one database query connection. s71 00:06:17.919 --> 00:06:23.160 I can do all sorts of hybrid search and return that data back. s72 00:06:23.760 --> 00:06:26.680 Uh what does the memory look like? s73 00:06:26.680 --> 00:06:32.560 Uh it's going to be typed and this you may have seen this model at different presentations or some form of it. s74 00:06:32.560 --> 00:06:35.800 Um this loosely comes from human memory can be applied to agents. s75 00:06:35.800 --> 00:06:36.720 So we have episodic memory. s76 00:06:36.720 --> 00:06:40.919 This is specific past events or slices of transcripts that the agents worked on. s77 00:06:40.919 --> 00:06:43.120 We have semantic memory. s78 00:06:43.120 --> 00:06:48.600 Um these are specific facts about our workflows, user preferences, and other entities. s79 00:06:48.600 --> 00:06:49.440 We have procedural memory. s80 00:06:49.440 --> 00:06:53.840 This is like how we did a specific task or routine, maybe a build step. s81 00:06:53.840 --> 00:07:00.120 These are reusable rules the agents are going to want to pull up again and again if they're are repeating similar work. s82 00:07:00.120 --> 00:07:01.280 And we have working state. s83 00:07:01.280 --> 00:07:02.960 Working state is like short-term memory. s84 00:07:02.960 --> 00:07:10.840 It's what are we what are we current currently working on and that that temporal data may only be valid for a certain time window and we may promote it to a different type of memory. s85 00:07:10.840 --> 00:07:17.960 This helps us bucket into different areas and we can use different search techniques on these types of memory. s86 00:07:18.400 --> 00:07:20.880 Uh what does the storage schema look like for memory? s87 00:07:20.880 --> 00:07:24.520 Um so memory are typed objects plus lookup path. s88 00:07:24.520 --> 00:07:28.720 So our our memory object is going to have some ID like a primary key. s89 00:07:28.720 --> 00:07:32.720 It'll have its text content, JSON tags, document data. s90 00:07:32.720 --> 00:07:34.800 It'll have a vector embedding. s91 00:07:34.800 --> 00:07:39.640 Uh we have a vector created over the content with a vector index for similarity search. s92 00:07:39.640 --> 00:07:44.600 Ideally we'll also have a text index to facilitate full text keyword search. s93 00:07:44.600 --> 00:07:46.800 That combines with vector search. s94 00:07:46.800 --> 00:07:48.720 Uh we can have graph links to different edges. s95 00:07:48.720 --> 00:07:51.080 Memories can be related through an entity graph. s96 00:07:51.080 --> 00:07:53.760 So, this memory is connected to this memory, which is connected to that memory. s97 00:07:53.760 --> 00:07:57.400 It's additional context that we can pull back during the search stage. s98 00:07:57.400 --> 00:07:59.480 We can also have temporal facts. s99 00:07:59.480 --> 00:08:01.080 When is this memory valid to? s100 00:08:01.080 --> 00:08:03.280 What was the last time that we used it? s101 00:08:03.280 --> 00:08:05.520 And then also it's super importantly audit events. s102 00:08:05.520 --> 00:08:07.400 Who Who created this memory? s103 00:08:07.400 --> 00:08:10.160 What did they use it for? s104 00:08:10.160 --> 00:08:15.600 Uh the log of of of of how it's been used and associated metadata. s105 00:08:15.800 --> 00:08:20.919 Um this should all be part of your storage schema when we're working with memories. s106 00:08:20.919 --> 00:08:23.960 When we create memories, we want to intentionally form them. s107 00:08:23.960 --> 00:08:25.960 Good memories are very intentional. s108 00:08:25.960 --> 00:08:31.440 So, we need to decide the life cycle, the scope, the different relationships, and associated metadata. s109 00:08:31.440 --> 00:08:36.479 When an agent runtime decides to create a memory, we should first start with redaction. s110 00:08:36.479 --> 00:08:42.240 Uh redaction is very important as the first step because before I do embeddings, before I do enrichment, I want to strip out PII. s111 00:08:42.240 --> 00:08:47.160 I don't want secrets or irrelevant weird information slipping into the memory layer. s112 00:08:47.160 --> 00:08:49.240 That's a recipe for disaster. s113 00:08:49.240 --> 00:08:51.400 So, we do redaction first. s114 00:08:51.400 --> 00:08:52.720 Then we can enrich the memory. s115 00:08:52.720 --> 00:08:55.400 What is the mem- What is the memory related to? s116 00:08:55.400 --> 00:08:56.960 What is the metadata of the memory? s117 00:08:56.960 --> 00:08:58.800 We can apply the scope to it. s118 00:08:58.800 --> 00:09:00.800 Uh what is the agent that worked on this memory? s119 00:09:00.800 --> 00:09:01.760 What's the team? s120 00:09:01.760 --> 00:09:03.240 What's the organization? s121 00:09:03.240 --> 00:09:11.880 This helps bucket into specific areas so I'm not getting memories in other sessions that are associated with other agents or workflows, which adds confusion. s122 00:09:11.880 --> 00:09:14.960 We can do the embedding so we create the vector of the content. s123 00:09:14.960 --> 00:09:16.560 And then we can form what's called the episode. s124 00:09:16.560 --> 00:09:19.440 These are the slices of the transcript that created the memory. s125 00:09:19.440 --> 00:09:23.000 This is good for provenance and additional context. s126 00:09:23.000 --> 00:09:26.839 Um any organization-specific policies here can also be applied. s127 00:09:26.839 --> 00:09:29.440 Uh whatever you need for your specific use case. s128 00:09:29.440 --> 00:09:33.040 And then we can save down to the storage layer. s129 00:09:33.080 --> 00:09:36.440 Um when we create memory, the individual memories can be quite compact. s130 00:09:36.440 --> 00:09:45.160 So, we take the transcript and we distill it down to that content and metadata and embedding and and and related stuff, but we can also we create these episodes. s131 00:09:45.160 --> 00:09:52.720 So, we take the agent transcripts, we filter them, find candidates for these episodes, save the memory record, and link it back. s132 00:09:52.720 --> 00:09:57.640 You can do this with uh relations, just straight-up database relationships. s133 00:09:57.640 --> 00:09:58.600 You can do it with graphs. s134 00:09:58.600 --> 00:10:03.960 I particularly like graphs because they allow a broader search here. s135 00:10:04.280 --> 00:10:08.720 Uh when we're talking about memory recall, that is how do we remember something? s136 00:10:08.720 --> 00:10:13.480 This is a retrieval problem, so a query problem on the storage layer. s137 00:10:13.480 --> 00:10:22.280 Um and with with retrieval or recall, hybrid search is emerging as the dominant method of context reconstruction. s138 00:10:22.280 --> 00:10:26.440 And this this form of retra retrieval can fuse different search methods. s139 00:10:26.440 --> 00:10:38.560 So, I can take vector similarity search, I can take a full-text keyword search, I can take relational entities, I can do graph traversal, I can take other feedback signals like importance s140 00:10:38.560 --> 00:10:45.280 uh uh and usefulness of the memory to yield more comprehensive results than one specific query branch alone. s141 00:10:45.280 --> 00:10:53.120 Like, if I was only doing similarity search, I only get the most similar results according to the embedding model that I'm using. s142 00:10:53.120 --> 00:10:55.200 Um and in general, this has not been enough. s143 00:10:55.200 --> 00:11:01.280 So, we have all these different query branches, um different types of memory, you can decide which ones you want to do. s144 00:11:01.280 --> 00:11:07.560 Things like facts, you might not want similarity, you might just want to do like an exact ID match on a fact. s145 00:11:07.560 --> 00:11:14.440 Um we can take these results, we can fuse them, apply thresholds, do re-ranking, and then we get a context card with scored evidence. s146 00:11:14.440 --> 00:11:21.000 So, we can say this memory it rate it rated very well on vector search and a little bit lower on lexical search. s147 00:11:21.000 --> 00:11:24.720 Um that's the provenance of the memory, where it came from, how we got it. s148 00:11:24.720 --> 00:11:27.280 That's important, too. s149 00:11:27.640 --> 00:11:41.320 Um as we as we walk through hybrid search, uh vector distance useful for for semantically similar things like contains operator, very good for lexical search, uh, graph table, temporal data, all this stuff. s150 00:11:41.320 --> 00:11:44.360 We take these branches, we apply weights to them. s151 00:11:44.360 --> 00:11:46.320 We can await differently as needed. s152 00:11:46.320 --> 00:11:49.800 This is something that can be tuned in your your hybrid search algorithm. s153 00:11:49.800 --> 00:11:58.760 The The results are merged to an overall score from the different query branches, and then we can take the top K of the overall results to say hey, here are the top three s154 00:11:58.760 --> 00:12:01.720 best results from our hybrid search algorithm. s155 00:12:01.720 --> 00:12:12.440 And that's loosely how you can implement hybrid search in a multimodal database, a database that is capable of providing all of these different search methods from one pane of glass here. s156 00:12:12.840 --> 00:12:19.360 Now, memories, it's not just a repository where we push data in and we pull data out. s157 00:12:19.360 --> 00:12:22.600 Memories need to evolve over time to be truly useful. s158 00:12:22.600 --> 00:12:28.320 We also don't want to just shove all our data in every time, otherwise we get tons of memories. s159 00:12:28.320 --> 00:12:33.960 Um, and this is where we can kind of close the memory loop with consolidation and error handling. s160 00:12:33.960 --> 00:12:42.480 Uh, stale memory can occur when, say, my my project uses NPM at one time and then we decide to switch to another build system. s161 00:12:42.480 --> 00:12:45.880 Well, what happens to all the memories that were related to NPM? s162 00:12:45.880 --> 00:12:52.000 If an agent recalls those, it's it's going to be a little tricky and it may try to do the wrong thing. s163 00:12:52.000 --> 00:12:57.640 Uh, so the system it needs to expect stale facts over recall quiet drift. s164 00:12:57.640 --> 00:13:04.040 Bad scope can occur where we're not appropriately appropriately scoping memories in the right context. s165 00:13:04.040 --> 00:13:08.440 This is like if you log into your ChatGPT account and you get someone else's message history. s166 00:13:08.440 --> 00:13:12.080 Um, if you're not applying scope properly, you can have some really bad data leaks. s167 00:13:12.080 --> 00:13:16.080 So, this needs to happen on write and on read. s168 00:13:16.080 --> 00:13:21.280 Uh, poison memory is when a untrusted source plants a durable instruction in your memory layer. s169 00:13:21.280 --> 00:13:35.080 This is kind of the worst-case scenario, like a prompt injection happened, you didn't have the appropriate guardrails, You didn't have the appropriate review, redaction, controls on memory, and and some really nasty stuff got in there, and all your data got exfiltrated. s170 00:13:35.080 --> 00:13:41.840 So, uh be very sure to avoid these kind of things through the proper guard rails and administrative actions. s171 00:13:41.840 --> 00:13:44.920 Uh a memory conflict is when I have two different memories. s172 00:13:44.920 --> 00:13:47.520 One says, "Hey, we do the task this way." s173 00:13:47.520 --> 00:13:50.760 And the other says, "Well, actually, we do it this way." s174 00:13:50.760 --> 00:13:54.760 Because they're both about the same task, they're going to rank very highly on retrieval. s175 00:13:54.760 --> 00:13:57.760 So, you probably get these same conflicts in your context card. s176 00:13:57.760 --> 00:14:04.520 And when the agent consume that, it's like, "Well, you know, you told me the restaurant's to the right, and it's actually to left. s177 00:14:04.520 --> 00:14:06.400 I don't know what to do." s178 00:14:06.400 --> 00:14:11.280 Um so, detection review here is very important for conflict resolution. s179 00:14:11.280 --> 00:14:12.120 Uh scoping as well. s180 00:14:12.120 --> 00:14:15.800 Sometimes there are different ways to do the same task. s181 00:14:15.840 --> 00:14:20.320 Um over recall and irrelevance happen as your memory system grows. s182 00:14:20.320 --> 00:14:32.560 Um if we're just shoving all of our data in there and not really thinking about what we're writing, um we can get into the situation of over recall where we have so many different weak matches, they're crowding out the context card. s183 00:14:32.560 --> 00:14:37.760 This is the same problem with the very large context window where we try and smoosh in as much data as possible. s184 00:14:37.760 --> 00:14:40.040 It's just confusing. s185 00:14:40.040 --> 00:14:47.000 Irrelevance, uh semantically close memories that rank highly on hybrid search, but it's not actually about the task. s186 00:14:47.000 --> 00:14:48.280 It just it rated highly. s187 00:14:48.280 --> 00:14:53.560 So, these are these are problems of of management and your search algorithm tuning. s188 00:14:53.560 --> 00:14:58.240 Data leakage is when we get weird, unexpected data that enters memory system. s189 00:14:58.240 --> 00:15:00.720 This is a less serious version of poisoned memory. s190 00:15:00.720 --> 00:15:07.360 Um proper enrichment and distillation of the memory records on the right path is the way to solve leakage. s191 00:15:07.360 --> 00:15:09.920 Uh over time also, we get silent drift. s192 00:15:09.920 --> 00:15:11.400 This is where the memory system grows. s193 00:15:11.400 --> 00:15:14.839 Maybe it works freaking awesome at like a thousand records. s194 00:15:14.839 --> 00:15:21.640 But then when I have 50,000 or a million or more, it's I'm getting all these weird results, and it's it's really working. s195 00:15:21.640 --> 00:15:30.960 So, it's very, very important to apply the proper countermeasures, the reduction before write, the scope checks review, life cycle, and most importantly feedback. s196 00:15:30.960 --> 00:15:33.600 Feedback is what closes the loop from memory. s197 00:15:33.600 --> 00:15:35.320 Memory quality needs to be measurable. s198 00:15:35.320 --> 00:15:37.120 We need to have correct retrieval. s199 00:15:37.120 --> 00:15:42.880 We need to account for stale or harmful memories, and ultimately the downstream usefulness of the system. s200 00:15:42.880 --> 00:15:46.520 It needs to feedback to these ranking life cycle decisions. s201 00:15:46.520 --> 00:15:51.080 So, if an agent retrieves a candidate memory, it'll use it, it'll reject it. s202 00:15:51.080 --> 00:15:55.000 Maybe if it uses it, everything goes haywire and it crashes. s203 00:15:55.000 --> 00:15:57.760 Like, that feedback needs to come back. s204 00:15:57.760 --> 00:16:00.640 And if if the memory was harmful, the feedback should go down. s205 00:16:00.640 --> 00:16:03.720 If it was useful, maybe we promote it. s206 00:16:03.720 --> 00:16:05.600 So, it's not just a repository. s207 00:16:05.600 --> 00:16:21.400 It needs to store Your memory layer needs to store whether memories were helpful, stale, irrelevant, harmful, etc. Um and we really we want to design for measurable recall with governed memory formation built on a multi-modal s208 00:16:21.400 --> 00:16:22.480 storage platform. s209 00:16:22.480 --> 00:16:26.400 So, without memory, these agents are more likely to restart the same tasks. s210 00:16:26.400 --> 00:16:28.839 They're going to recreate over and over again. s211 00:16:28.839 --> 00:16:30.080 They're going to read the same files. s212 00:16:30.080 --> 00:16:31.160 They're going to run the same queries. s213 00:16:31.160 --> 00:16:38.240 They're going to waste tons of time, tons of tokens, uh be much slower, and much more much more failure prone. s214 00:16:38.240 --> 00:16:40.160 They're going to repeat the same mistakes. s215 00:16:40.160 --> 00:16:43.240 If it doesn't know about prior art, it's going to do the same thing over again. s216 00:16:43.240 --> 00:16:47.000 And if that thing was wrong, it'll be wrong again and again. s217 00:16:47.000 --> 00:16:50.440 And with governed memory, the agents can resume where they left off. s218 00:16:50.440 --> 00:16:56.440 They can reuse what came before them, and ultimately reduce repeated failures. s219 00:16:56.440 --> 00:17:00.960 This is This is the true goal of recording, retrieving, governing, evolving. s220 00:17:00.960 --> 00:17:02.680 Um we want to improve the success rate. s221 00:17:02.680 --> 00:17:03.560 We want to do it faster. s222 00:17:03.560 --> 00:17:04.360 We want to do it cheaper. s223 00:17:04.360 --> 00:17:06.920 We want to do it better. s224 00:17:07.240 --> 00:17:13.680 Um if you are hands-on, um I recommend checking out our Python SDK for agent memory. s225 00:17:13.680 --> 00:17:22.120 This code will take you to a GitHub link with a Python notebook that walks through how to do this using our SDK. s226 00:17:22.120 --> 00:17:25.079 The SDK is built on database primitives. s227 00:17:25.079 --> 00:17:28.600 Um everything that we talk about here lives in the database. s228 00:17:28.600 --> 00:17:32.080 Um you We also have our developer hub. s229 00:17:32.080 --> 00:17:38.080 If you're an AI engineer, you're builder, you're curious like how does a modern multi-model database fit into AI development? s230 00:17:38.080 --> 00:17:48.160 This is the place to go to check out our samples, um see what's possible, and maybe even inspire you to build something cool uh with a very awesome database. s231 00:17:48.160 --> 00:17:50.600 Uh again, I'm Anders um Anders Swanson. s232 00:17:50.600 --> 00:17:54.800 If you want to chat or connect with me, I'll be over at the Oracle booth. s233 00:17:54.800 --> 00:17:56.080 Um and thank you so much. s234 00:17:56.080 --> 00:18:01.720 I hope this was useful to you guys and uh helpful as you're you're building awesome things. s235 00:18:01.720 --> 00:18:04.040 Thank you so much.