Talk by Peter Werry, founding engineer at Unblocked, recorded at the AI Engineer World's Fair 2026 in San Francisco. Explains what a context engine is and why coding agents need context beyond code search, such as PRs, Slack threads, and incident history. Covers demonstrations of Claude agent sessions with and without that context, including a reported cost reduction of about 50% and tracing a regression to a model switch. Walks through building an open-source document query engine covering automatic schema discovery, identity resolution across systems, query validation that blocks dangerous operators, retries that feed errors back to the model, and full-text search. Closes with an open-source context engine simulator for testing whether pre-gathered context helps agents. The cost figures and demo outcomes are the speaker's claims as described in the description, not independently verified. # Video Identity Observations — "Beyond RAG: A Relational Context Engine That Cuts Token Burn — Unblocked" ## Explicit Self-Description - The speaker self-identifies: **"I'm Peter from Unblocked. And at Unblocked, we build a context engine."** - Unblocked is presented as a **developer-tools company** whose product "takes all of that institutional knowledge" (code, docs, PRs, Slack, incident history) and delivers "grounded context" that is "interrelated… intent specific… personalized and… permissions aware." - The company also offers a **code review product**: "we also have a code review product and Richie works on that." ## Intended Audience - **Software engineers and engineering organizations evaluating AI agents/LLM tooling**, evidenced by: - Framing around team pain points: "you're a new employee… you usually end up having to… look at a whole bunch of code, rip around documentation systems." - Cost/benefit framing for decision-makers: "50% reduction in cost" ($1.29 vs "up to $2.60" and 1:30 vs ~3 minutes). - Practical, implementable takeaways: "a couple of open source projects that you can go and play with after this." - **Developers building RAG/agent systems**: the technical core addresses limits of vector search — RAG "handles content questions… but it doesn't handle… structural questions like PRs that I merged last week." ## Claimed Scope - **Dual-purpose talk**: (1) explain "what a context engine is and how it can add value to your organization," and (2) live-build "a component of a context engine." - **Technical scope**: structured retrieval as "the other half of RAG" — schema discovery, identity resolution, query synthesis, validation/safety (blocking dangerous operators, tenant isolation), self-correction loops, and full-text search. - **Open-source positioning**: the "document query engine" repo and a **"context engine simulator"** for teams who "don't want to wire up Unblocked right away" — an explicitly low-commitment on-ramp. ## Demonstrated Presentation Patterns (observable, not claimed) - **Conference speedrun format**: "we've only got 20 minutes"; live coding demos with visible friction ("I lost my keynote presentation… It's the wrong keynote"), suggesting a real conference talk rather than a polished studio video. - **Product-demo-driven persuasion**: side-by-side Claude sessions with and without the context engine; a real internal incident (Richie's code-review regression traced to an Opus model switch) as a case study. - **Community/marketing engagement**: "if you want some coconuts, come by the booth" — indicates a vendor booth presence at a developer event. ## Caveats for Synthesis - This is a single vendor conference talk; the cost-savings figures and demo results are **creator claims demonstrated only in their own demos**, not independently verified. - No evidence in this video alone supports channel-wide conclusions about content cadence or broader channel identity beyond a developer-tooling / applied-AI focus. # Delivery Observation — Peter, Unblocked: "Beyond RAG: A Relational Context Engine That Cuts Token Burn" ## Overall Format & Framing - **Time-boxed speedrun framing.** The talk is explicitly framed as compressed from the start: *"we're going to be doing a bit of a speedun here because we've only got 20 minutes."* This constraint reappears later: *"we're just going to get right into the building part because we're quite short on time today"* and *"I'm just going to summarize this."* - **Two-part structure announced up front:** *"The talk's going to be split into two parts... what a context engine is and how it can add value... And then we're going to actually go and build a component."* - **Audio check opening.** Opens with *"Can you hear me?"* and asks the audience to confirm — a live-demo speaker's habit before depending on screen sharing. ## Recurring Teaching Habits - **"Let me show you" show-and-tell loop.** The dominant teaching pattern is: state a concept, then immediately demo it. Examples: *"I'm going to show you exactly what I mean by that," "I want to just show you again," "I'm going to show you what that looks like in our demo," "just quickly show the payoff."* Nearly every abstract claim is followed by a live screen artifact. - **Anthropomorphized AI as recurring analogy.** New employees are the recurring frame for both humans and LLMs: *"you were the context layer"* for pre-AI onboarding, and *"I'm sure you're all familiar with what Claude does when it starts a new task. It's like a new employee."* - **Downplaying difficulty after revealing hard parts.** *"But generating the queries is actually the easy part. The hard part is the scaffolding."* Later: identity resolution *"can be solved just using simple procedural tricks,"* and synthesis is *"actually the easiest part."* - **Anti-hype corrective asides.** Twice steers the audience away from defaulting to LLMs: *"you can use an LLM as a Thor hammer... but actually you get really really far just using traditional procedural methods"* and *"don't always fall back to an LLM."* - **Concrete metrics for persuasion.** Cost/time deltas are quoted precisely: *"a dollar 29 on this and it took about a minute and 30 seconds... without I'm spending up to you know 260 and 3 minutes... a 50% reduction in cost which is pretty incredible."* - **Preview-the-goal pattern.** Before building, he shows the target output: *"this is what we're aiming for here. We want to be able to say something like open PRs by machine and then we want to get this kind of query."* ## Vocabulary & Verbal Tics - **"Really really"** as intensifier appears repeatedly: *"really really far," "really really tight," "really really far just using traditional procedural methods."* - **Casual enthusiasm markers:** *"which is just nuts," "which is pretty incredible," "Very cool," "Awesome," "it's just remarkable."* - **"Um" and "uh"** occur densely throughout — high filler rate typical of live, unscripted delivery. - **Domain coinage used consistently:** "context bundle," "grounded context," "jump off points," "scaffolding." ## Handling of Live-Demo Friction - **Visible but quickly-recovered mishaps:** opens the wrong deck — *"Oh, sorry... It's the wrong keynote. There we go."* Later: *"Oh, actually we're actually not running it. So, I'll go back. Let's run it first."* Also *"Whoops, first we have to level up to the next [step] and then run"* and *"Oops, that's the wrong one."* - **Self-narrated failure states:** *"our validation engine said sorry regular expressions aren't allowed you're getting bounced."* He treats errors as teaching material rather than skipping past them. ## Communication Pattern Summary - **Structure:** agenda → problem framing → product demo → theory → live build → payoff → resource handoff (open-source repos, booth, *"if you want some coconuts, come by the booth"*). - **Audience-directed inclusive framing:** *"Imagine that you're a new employee," "you've got context scattered all over the place," "we want to go to this"* — consistently uses "you/we" over "I." ## Stable vs. Uncertain Observations - **Well-supported (repeated ≥3 times):** the show-then-demo loop, the "easy part/hard part" reframing, "really really" intensification, live-demo recovery narration. - **Single-instance, lower confidence:** the closing coconut/booth hook and the "new employee" analogy (appears twice, so moderately supported but not pervasive); the exact cost figures come from one claim and cannot be verified against the screen from the transcript alone. # Observation Record: "Beyond RAG: A Relational Context Engine That Cuts Token Burn" (Unblocked) **Speaker:** Peter, presenting for Unblocked (self-identified in transcript) **Other referenced individuals:** Richie, a colleague who ran the code review regression investigation (referenced, not speaking) **Source basis:** Transcript only. No curated speaker metadata was supplied. All attributions below are to Peter unless noted. --- ## 1. Core Thesis Peter argues that AI agents need a **context layer** that converts scattered organizational knowledge into **grounded context**. - **Grounded context** is described as: - **Interrelated** across sources - **Intent-specific** - **Personalized** - **Permissions-aware** - He frames the pre-agent state as a human new employee who must manually search code, documentation, and incident history. > "What a context engine does is it takes all of that institutional knowledge and it pulls it in and what you get... grounded context." --- ## 2. Claims Made from Demonstrations ### 2.1 Cost and Efficiency (Plan Optimization Session) | Condition | Reported cost | Reported duration | |---|---|---| | With context engine | $1.29 | ~1 min 30 sec | | Without context engine | "up to you know 260" (transcribed; likely $2.60) | "3 minutes" | - **Claim:** "a 50% reduction in cost." - **Basis:** A single session comparison, shown live. - **Caveat:** The transcript's dollar figure for the baseline is ambiguous. The sample is one task, and the speaker does not describe repetition or variance. ### 2.2 Regression Investigation (Code Review Product) - Richie noticed the code review product was surfacing fewer issues. - Peter reports that the context engine narrowed the cause to **"a likely cause"**: a model switch (transcribed as "Opus 48 or Opus 46 to Opus 48"). - **Hedged language:** "likely cause." The speaker does not claim the cause was confirmed. - The tool then generated a PR, which Peter describes as having a description that "understood the PR that caused the regression" and referenced a Slack thread. - **Characterization:** Peter calls this "just nuts" and "remarkable." These are subjective assessments, not measured outcomes. ### 2.3 Baseline Behavior of Unaided Agents - Peter says an agent without context "reps around your codebase" and that it "figures it out eventually or at least... confidently projects that it's figured it out." - **Note:** This is an observational claim from one demonstration, not a measured failure rate. --- ## 3. Analytical Positions ### 3.1 Semantic vs. Structural Retrieval - **Position:** Standard RAG "nails the content part" but does not handle structural questions. - **Examples of structural queries given:** - "PRs that I merged last week" - "who reviewed payments the most" - "open PRs" - "show me a chart of ratio weekly since January 1st" - **Reasoning:** Structural answers are not encoded in a vector store, so they require a query engine. - **Framing:** Retrieval has "two halves": semantic and structured. ### 3.2 Where the Difficulty Lies - **Position:** "Generating the queries is actually the easy part. The hard part is the scaffolding that sits around it." - **Scaffolding components named:** 1. Schema discovery, so the LLM can generate tightly bound queries 2. Identity mapping across systems 3. Validation of untrusted generated queries 4. Error handling and self-correction - **Tension within the talk:** Peter says query generation is "the easy part," but later calls the synthesis step "roughly speaking, this is actually the easiest part." Both claims are stated; the talk does not reconcile them. The distinction may be that synthesis is a prompt-assembly step and query generation includes more constraint-handling, but Peter does not say this. ### 3.3 Deterministic Methods Over LLM Calls - **Position:** Procedural methods can do much of the work; LLMs should not be the default. - **Quote:** > "you get uh really really far just using traditional procedural methods. So you can... don't always fall back to an LLM to do this kind of what looks like non-deterministic work." - **Applied to:** - Schema inference via sampling and enum detection - Identity resolution via fuzzy matching - **Hybrid position:** An LLM can serve as a **tiebreaker** for identity resolution when procedural methods are insufficient. Peter says an LLM "can do a pretty good job" with schema discovery but does not claim it is required. ### 3.4 Validation as the Most Important Component - **Position:** Validation is "actually the most important thing." - **Risks named:** - Dangerous operators (example: a function operator that executes raw JavaScript on the DB server) - Access to hidden fields - Cross-tenant data access - **Mitigation proposed:** Keep tenant and hidden fields away from the LLM and **inject constraints underneath** the generated query. - **Note:** Peter does not describe how injection is verified or what happens if the LLM's query structure bypasses injected constraints. ### 3.5 Self-Correction Loop - **Position:** Validation or execution errors can be fed back to the LLM for correction. - **Implementation as described:** "a loop with some sort of maximum retry." - **Evidence from demo:** The LLM needed "a couple attempts," and the first successful query used exact title match (`match`), which returned no results. - **Limitation acknowledged by speaker:** Exact match was insufficient. Full-text search was added as a remedy. --- ## 4. Demonstrated Limitations (Stated or Shown) - **Exact match limits:** Title matching returned zero results for a plausible query, requiring full-text search. - **Identity gaps:** A user's name may not map to their GitHub identity without resolution logic. - **Time constraints:** Peter notes the talk was condensed ("speedrun") to 20 minutes, so some steps were narrated rather than fully shown. - **Unverified generalization:** Claims about cost savings and regression diagnosis rest on single demonstrations. --- ## 5. Stated Open-Source Artifacts and Offerings - **Document query engine:** Peter says it is open source and shows implementation of schema discovery, identity resolution, synthesis, validation, and retry logic. - **Context engine simulator:** Described as an open-source project that runs locally, generates context bundles per task, and runs **A/B tests** comparing with and without context. - **Caveat:** Peter says it "will allow you to do this entirely locally," which he presents as an alternative to Unblocked for constrained environments. - **Commercial product:** Unblocked is presented as the commercial context engine. Peter does not state pricing. --- ## 6. Summary of Positions by Confidence | Claim | Strength of expression | Evidence cited | |---|---|---| | Context engines reduce cost and time for agent tasks | Stated as fact ("50% reduction") | One live comparison | | Context engine identified likely regression cause | Hedged ("likely cause") | One anecdote (Richie's session) | | Structural queries require a query engine beyond RAG | Stated as a conceptual argument | Examples, no benchmark | | Validation is the most important component | Emphatic ("most important") | Design reasoning, no failure data | | Procedural methods outperform LLMs for schema and identity tasks | Stated with qualifier ("really really far") | Design reasoning | | Generating queries is the easy part | Stated, later partly contradicted | Assertion | --- ## 7. Unresolved Items - The baseline cost figure is transcribed ambiguously ("260"). - The model version names are transcribed ambiguously ("Opus 48," "Opus 46"). - The relationship between "query generation is easy" and "synthesis is easiest" is not reconciled. - No measurements of accuracy, false positives in validation, or query correctness rates are given. - The security model for tenant isolation is described at a high level without verification details. # Video Attribution & Provenance Record ## Video **Title:** Beyond RAG: A Relational Context Engine That Cuts Token Burn — Unblocked **Video ID:** 01a15ca6-aef0-7b30-8aed-d45bcd3a8613 ## Speakers & Roles | Speaker | Role | Basis | |---|---|---| | **Peter** | Presenter, employee of **Unblocked** (company) | Self-identified: *"I'm Peter from Unblocked"* | | **Richie** | Referenced colleague at Unblocked, works on the code review product | Mentioned only; not a speaker | | **Claude** | Anthropic LLM, used in demos | Tool, not a speaker | No other speakers, guests, or narrators are identified in the transcript. No curated metadata was supplied beyond the transcript. ## Talk Structure (as described by speaker) - 20-minute "speedrun" talk, split into two parts: 1. What a context engine is and how it delivers value 2. Live build of a context engine component using open source projects ## Referenced Sources & Tools - **Unblocked context engine** — the company's product; demoed attached to Claude - **Claude** (Anthropic) — used in demo sessions; cost/time comparisons cited by presenter - **Open source repo: "document query engine"** — built during the talk; presenter states *"This is all open source"* - **Context engine simulator** — second open source project, *"a PR code for that"* mentioned; presenter says it was promised in the talk description - Referenced data sources integrated by the context engine: source code, **Notion** docs, **pull requests**, **Slack** conversations ## Third-Party / Presenter Claims (unverified in source) - Claimed **~50% cost reduction** with context engine: *"a dollar 29... versus up to $2.60"*, and ~1m30s vs ~3 minutes runtime - Claim about Richie's session: issue-surface drop traced to a model switch ("Opus 48 or Opus 46 to Opus 48") — presenter's account of a colleague's experience - Claim that Unblocked's engine produced a fix PR autonomously with context drawn from a prior PR and a Slack thread ## Promotional Segments — FLAGGED - The entire talk functions as a **product demonstration for Unblocked** and its context engine - **Booth promotion:** *"if you want some coconuts, come by the booth"* - **Open source projects promoted** (document query engine, context engine simulator) — associated with Unblocked; presented as freely usable ## Availability & Access Notes - Open source code availability is claimed by the speaker; **no URLs, PR links, or repo paths are transcribed** (references like "this is the repo here" point to on-screen content not present in the transcript) - Demos reference on-screen sessions, charts, and PRs that cannot be verified from the transcript alone ## Uncertainty Flags - Speaker's last name, exact role title, and event name/date are **not stated** in the transcript - Transcription artifacts present (e.g., "Rashene," "Opus 48/46" — likely mis-transcriptions of names/model versions; exact spellings uncertain) - A keynote mix-up occurs on stage ("This is the wrong keynote") — minor, noted for context only Are we up? Okay. Can you hear me? Just like this just fine, everyone. Good. Okay. Um, so we're we're going to be doing a bit of a speedun here because uh uh we've only got 20 minutes, but um I'm I'm Peter from Unblocked. And at Unblocked, we build a context engine. So I'm going to show you a couple of things. The talk's going to be split into two parts. Um I'm going to show you what a context engine is and how it can add value to your organization. And then we're going to actually go and build a component of a context engine. And I'm going to show you a couple of open source projects that you can uh go and play with after this. So there's the agenda. What's a context engine? How does it deliver value? And then we'll build. Um so let let's just hop back in time maybe a few years to the times before AI agents. And in those days um you were the context layer. Imagine that you're a new employee to an organization and you're just trying to get to grips with what's what's happening. What you usually end up having to do is look at the look at a whole bunch of code, rip around documentation systems just trying to find the information that you need to get your work done. Um, and not to mention like all of the the sort of shared history that's built up over time through an organization dealing with incidents and the battle scars that come with it. Um, so what a context engine does is it takes all of that institutional knowledge and it pulls it in and what you get the scattered context that goes into the context engine and out the other end you get grounded context which means that the context is all interrelated to each other. It's intent specific. It's personalized and it's permissions aware. And so I'm going to show you exactly what I mean by that. Now let's imagine that I'm going to go into here into Claude and I'm going to show you a couple of interesting sessions that I had. So um I asked Claude here, this is without a context engine attached to create a plan to optimize a component in our layer called the source mark engine. And uh I'm sure you're all familiar with what Claude does when it starts a new task. It's like a new employee. It doesn't understand anything about your your codebase or your organization. So the first thing it does is it reps around your codebase and and tries to figure out what's going on. And so you can kind of see that here. And you know it figures it out eventually or at least you know it confidently projects that it's figured it out. Um, and so it provides kind of like a a recommendation for me there. But now I'm going to show you what it looks like when you attach a context engine to the back end. So now what it does is it calls the unblock context engine and unblock now delivers a very comprehensive but taskspecific context bundle for this task. And what you can see is that it it's referencing not only the source code but also you know notion documents that talk about the architecture um pull requests slack conversations that were had about optimizing this particular component um and the the the net out is that you get this really tight context bundle with all these links. So now uh if if um you know Claude wants to go back and fetch more information, it has all these great jump off points. But the really interesting thing is is this. So here I spent um you know a dollar 29 on this and it took about a minute and 30 seconds. Um that was with the context engine but without I'm spending up to you know 260 and 3 minutes. So what you see essentially is a 50% reduction in cost which is pretty incredible. Um now I want to show you another interesting demo um which is uh an interesting session that my colleague Whoops sorry bring this out here. It's an interesting um session that my colleague had with unblock the other week. So what he we also have a code review product and Richie works on that and he discovered that the number of issues that the code review product was surfacing was was starting to drop. So he just asked unblocked and unblocked was able to pull this information um and and you know narrow it down very quickly to uh a likely cause which was that we switched from Opus 48 or Opus 46 to Opus 48 and the behavior characteristics behind the scenes um you know caused all those issues to drop and uh so what he did is he asked on block to just fix it and now on locked um was able to just create a PR behind the scenes and it has all that context and it knows what to do. But the really cool part is you can see that it created this description and it's it's just remarkable like it it um understood the PR that caused the regression in the first place and then it found a Slack conversation where the conver where where this was being discussed and pulled on some of the data here to help inform um the fix which which is just nuts. So, I'm going to go back to wh I think I lost my keynote presentation here. Let's see. There we go. So, you have the same problem with agents, right? Cost. Oh, sorry. This is the wrong \[laughter\] It's the wrong keynote. There we go. So now I think what we're going to do is we're just going to get right into the building part because we're we're quite short on time today. Um and so I'm just going to summarize this. You've got context scattered all over the place. You've got context in PRs, reviews, comments, issues and tickets, docs, conversations. Um and and all of that is uh semantically queryable, but it's also structured and rag nails the content part. Um, it it can be it can handle things like content questions, find the code, the PR that changed it, the Slack thread that's debating it, and if you wrap that stuff in an agent loop, it can go really really far. You give an agent loop tools to do file search after this and it it's very powerful but it doesn't handle some of the other type of uh structural questions like PRs that I merged last week who reviewed payments the most open PRs etc. Um, and these are queries. They're not semantic searches. So, I want to just show you again, um, going back to Richie's example here that he started the the conversation with unblock by asking it a query based question because there's a temporal element. Can you show me a chart of ratio weekly since January 1st? Okay. So, in order to do this, it's not going to be able to just pull this information from a vector store because that's not where that information is encoded. So, it's it's going to have to do that um through some sort of query engine. And so, you know, retrieval has two halves essentially. We've got semantic retrieval and that can handle those types of semantic based questions. But today, we're going to work on this the structured part. We're going to turn structured queries or natural language queries into structured queries. But generating the queries is actually the easy part. The hard part is the scaffolding that sits around it. So you need to do things like understand the schema so you can pass it to the LLM so it generates the a tightly bound query. Uh you need to also be able to map identities. If I ask a question like open PR is by Rashene, um it's not going to know who Rashene is because his identity in GitHub might be completely different. So we have to be able to map that somehow. And then when you get the query out of the LLM, it's untrusted. It could have uh operations that are dangerous. It could cross tenant boundaries. And so you have to have some way of validating that the query is is uh correct and safe. And then finally, uh, even though you do that validation, there could be errors. Um, and when you actually do the query against the database, there could be errors there as well. And so we can actually get the LLM to try to correct itself if it gets into that situation. So this is what we're aiming for here. We want to go to uh to this. We want to be able to say something like open PR is by machine and then we want to get this kind of query on the back of that. So, just take a sec here. U this is the open- source repo that we're going to be building against. And I'm going to jump right into what that looks like actually. So, this is the repo here. It's called the document query engine. And I want to show you what it looks like when we just boot it up the first time. So, I can say, you know, PR is by Peter at ground zero. Oh, actually we're actually not running it. So, I'll go back. Let's run it first. Now I can ask my question. So, when you start it's going to have it's not going to be wired up at all. It's going to produce nothing. So, we're going to just gradually build this thing up here. Okay. First thing we're going to talk about is automatic schema discovery. This is completely dynamic. is schemalist. Not and not all databases are schemalist, but the same kind of principle can apply. You can dynamically discover the schema at runtime. Um and so what what the technique involves is sampling a whole bunch of documents in the document store and then deriving a schema from that. And uh you know I just want to show you like one tricky part of that which is inferring enums. Um now the the the outcome from this is that you can use an LLM as a Thor hammer um and it can do a pretty good job but actually you get uh really really far just using traditional procedural methods. So you can you know don't always fall back to an LLM to do this kind of what looks like non-deterministic work. This is actually quite deterministic this kind of thing. So now that we've discovered schema, I'm just going to show you what that looks like in our demo. Whoops. First we have to level up to the next and then run. So now we've discovered the schema from our um GitHub collection and this is just pull requests. Okay, so it has not only the schema here but also um indexes that will help improve the performance of queries. The next step is identity resolutions that thing I talked about about mapping you know users to uh real identities and um again this is this can be solved just using simple procedural tricks. So um that that's actually more or less how we do it. Uh and underneath the hooded unblocks when we take usernames or identities from different systems and map them across um you can do this kind of fuzzy matching and then in the end if you have to you can pass a list of names to an LLM and have it act as a tiebreaker. And finally, uh, the last step before we can actually show the cool stuff is this. It's the synthesis part. And roughly speaking, this is actually the easiest part. We just take the schema that we dynamically resolve from earlier. We take the current date and time, uh, maybe some information about the user that's asking the question, so it can easily resolve questions like my PRs and not just Peter's PRs. Um and then we pass it to the LLM and ask it to synthesize a query for us. And the outcome uh will look something like this. Let's get to this one. So now I can go back to my engine and try to run that query again. And it's going to pull the documents for me now and generate this query. Now the next step I I was talking about was was validation. This is actually the most important thing. Um your your uh query could contain really dangerous operators like the function operator for example which would execute raw JavaScript um on the DB server which is definitely not ideal. Um, but there could be other things that you want to do with this. Like for example, you might have hidden fields that you don't want uh to be surfaced either to the LM or for the LM to to derive and execute. If you have metadata fields, for example, that contain um tenant IDs and you want to isolate each query to a specific tenant, you're better off making sure that the LM doesn't interact with those fields at all and then just constraining it behind the scenes. you can inject those fields underneath. And that's kind of what that looks like. So again, we're going to just quickly show the payoff for that and what that looks like. Let's go up to our validation step. Oops. Run it again. So if I now ask a question like this PRs with authentication in the title that is probably going to drive some kind of like regular expression thing and there we go. Okay. So uh our validation engine said sorry regular expressions aren't allowed you're getting bounced and now we're not allowed to do that. So validation is cool. Um but what do we do with that? you know, we got an error. Um, but what we can do instead is just take that error and just loop it back in to the LLM and have the LLM kind of self-correct. And that's kind of what it that's all it is. That's all it looks like from a technical standpoint. It's just a loop with some sort of maximum retry. And so if I try this again, bounce up to my retries and run that. Now, if I try that query again. Oops, that's the wrong one. Let's try this one. Now what you can see is that it actually took a couple attempts. Um but it got there in the end. However, um it constrained it down to use match and unfortunately this is an exact title match. We don't have any PRs with that exact title. So we need one more thing which is this full text search. So now if we add full text search to our engine um hopefully the outcome that we get is something that looks a little bit like this. So let's try it one more time. Awesome. So there you go. We got we went from start to finish there. This is all open source. So you can take a look at how it's implemented and play around with it yourself. And this is what we built. Something that can effectively handle all of the uh other half of rag. So, anything that has to do with uh structural based data, you can have filters, aggregations, it's time scoped, and it selfcorrects. But what's really cool is that it also powers a chat agent. And so if I go over here and I say something like um what authentication related things have we've been working on last week. Now you get this whole thing that will show you exactly what it's doing, all the queries that it creates. And now it has the data and it's just kind of reasoning about it behind the scenes. And there we go. Very cool. So there you are. Structured queryable context for agents and humans. Now there's just one last thing. Um on the description you probably saw that we were promising a context engine simulator. If you don't want to wire up unblocked uh right away because you've got some constraints in your in your environment, um we have an open source project that will allow you to do this entirely locally yourself. And so the idea is uh it will create a context bundle for you on a taskbytask basis and then take that context bundle and run an AB test against the same task and show you the benefits of having all of that context at your fingertips for your agents. And that's the uh PR code for that if you want that. All right. And one last thing, if you want some coconuts, come by the booth. Thank you.