How to Generate Mergeable Code with a Context Engine —…
Talk by Peter Werry (Unblocked) on improving AI coding agents with a context engine. He argues that access to information is not understanding: agents behave like expert engineers on their first day, re-learning a codebase on every task, and large context windows do not fix this. He demos a context engine on Unblocked's repository, showing a question about an internal component returning a sourced architecture diagram, and compares the same optimization plan run with and without the context engine, with lower cost and time when it is available. He also covers a review agent that boosts reviewer comments by seniority, tracing a drop in flagged issues back to a Slack thread, and two open source tools: a query engine over GitHub history and a social graph of review coverage.
# Video Identity Observations — Unblocked / Peter Werry
## Explicit Self-Description (Creator Claims)
- **Company and product claim**: "What we do at Unblocked is we build a context engine," defined as delivering "organizational context to both your human workers and now increasingly your agents."
- **Claimed outcomes**: A closing customer quote is cited: "50% fewer tokens, faster triage, better answers."
- **Open-source offerings claimed**: Two open-source projects — a **document query engine** (ingests historical GitHub PRs, synthesizes a schema, supports agent chat queries) and an **engineering social graph** (models team structure, review relationships, and expert coverage).
- **Free entry point**: A "context engine simulator" is offered for those who "don't want to sign up for unblocked right away."
## Observable Presentation
### Intended Audience
- **Engineering organizations using or evaluating AI coding agents.** References to "claude.md," Cursor, Copilot, MCP, and Claude Code assume developer/AI-tooling fluency.
- **Live conference audience.** Sound check ("Can you guys... yeah, we're good"), show-of-hands moments, references to "the keynote this morning" and a colleague's upcoming talk, and a closing "don't forget to get a coconut" indicate an in-person developer conference setting.
### Claimed Scope
- Positioning along an "AI maturity curve" from autocomplete to "software factories," asserting most teams are "at the sort of stage four to five level" where "context is the bottleneck."
- Core thesis stated directly: "Access to information doesn't equal understanding."
### Demonstrated Patterns
- **Demo-heavy delivery**: Live demos of codebase Q&A with generated architecture diagrams, Slack integration where Unblocked "chimes in," and a Claude Code comparison (with vs. without Unblocked context) showing cost/time differences.
- **Show-your-work emphasis**: "You show your work. This is a trust building thing more than anything."
- **Internal dogfooding**: Examples use Unblocked's own team ("Richie here said, 'Oh, that's cool. That's something I would say'"), and "we're a fairly small team" is shown in the social graph demo.
- **Sales-adjacent framing**: The talk closes with a customer quote and a QR code, blending technical education with product promotion.
## Notes on Confidence
- The context-engine definition and customer outcome quote are **creator claims**, not independently verified in the material.
- Demonstrated product capabilities (diagram generation, Slack responses, PR generation) are observed via live demo but on the presenter's own environment.
# Delivery Observations — Peter Werry, "How to Generate Mergeable Code with a Context Engine"
## Overall Tone & Register
- **Conversational, casual conference-talk style**: frequent filler words ("um," "uh," "you know," "kind of") appear throughout, e.g. *"Um, and then through the codebase of course to try to build up tribal knowledge."*
- **Light humor and self-deprecation**, especially around the live demo: *"I'm going to now uh attempt a live demo. And hopefully the demo gods are kind."*
- **Direct audience address**: he repeatedly talks *to* the room rather than at it.
## Audience Interaction Habits
- **Sound/visibility checks**: opens with *"I just want to do a quick sound check at the back to make sure everyone can hear me fine."*
- **Show of hands / smiling prompts**:
- *"can I just uh put a put a show of hands for everyone that's seen this slide before by Vim?"*
- *"Just smile if if this is kind of um bringing up memories for you."*
- **References to shared conference context**: *"I'm not sure if if folks were at the keynote this morning, but um it's it's all about like delivery of context."*
## Recurring Phrases & Verbal Tics
- **"Kind of" as a hedge** — very frequent: *"kind of like," "kind of representative," "kind of interesting," "kind of listen."*
- **Restating/echoing questions before answering**: *"So why why is that important?"*; *"So, what we're going to do is we're going to hop into our time machines."*
- **"Okay?" and "So," as transition markers**: *"they reset their knowledge every time you start a new task. Okay?"*; numerous sentence-initial *"So,"*.
## Teaching & Explanatory Techniques
- **Analogy-driven explanation**:
- *"Agents are like new employees."*
- *"you can think of an agent like an expert software engineer um who's a new employee onboarding for the first time."*
- Cross-domain borrowing from medicine: *"it'll suffer from something that uh radiologists uh call satisfaction of search."*
- **Anticipating and voicing audience objections**: *"some people will then ask, well, what if we just take the entire codebase... and just slam it into the context window."*
- **Compare-and-contrast structure** in the demo (with vs. without Unblocked), supported by metrics: *"the total cost was, you know, subd dollar to create the plan... the usage without unblocked... costs more."*
- **Reframing key ideas in new words**: *"I just want to uh harp on that phrase again. And it can be phrased a different way, which is finding the things that really matter."*
- **Visual metaphors**: the iceberg — *"this is what your agent can see at the top of the iceberg."*
## Demo Delivery Habits
- **Live demo with acknowledged risk**: misclicks and stumbles are narrated openly — *"Oops, I think I'm on the wrong tab. We'll get to that one in a sec. So for now, sorry about that."*
- **Grounding demos in named real people/anecdotes**: the "Richie" sequence — *"Richie here said, 'Oh, that's cool. That's something I would say.' And that's because that actually was something he said."*
- **Calls out credibility markers**: *"this diagram doesn't exist. Um it just figures it out."*
## Structural / Signposting Patterns
- **Explicit time and section management**: *"So, I'm going to now uh attempt a live demo"*; *"I've got only a few minutes left. I'm just going to close this out really quickly."*
- **Enumeration of agenda items**: *"a couple of open-source projects... One is the document query engine... And then lastly the engineering social graph."*
- **Closing with proof point and call to action**: customer quote (*"50% fewer tokens, faster triage, better answers"*), a colleague's talk plug, and *"don't forget to get a coconut."*
## Uncertainty Notes
- Filler density and the "kind of" hedge are clearly stable patterns given repetition across the transcript.
- Traits like "self-deprecating" rest on only a few instances (demo gods joke, "sorry about that"), so the strength of that pattern beyond this talk is uncertain.
# Observation Document: How to Generate Mergeable Code with a Context Engine — Peter Werry, Unblocked
## Speaker
- **Peter Werry**, representing **Unblocked** (all substantive content below is his, as expressed in the transcript).
## Core Position
- Unblocked builds a **context engine** that delivers organizational context to both **human workers** and, increasingly, **agents**.
## The Problem as Framed
### Pre-agent era ("the before times")
- Humans were themselves the context layer: searching data sources, discussions, and the codebase to build **tribal knowledge**.
- Organizations accumulate "**battle scars**" over time — incidents, architecture documentation, outages.
### The agent problem
- **Agents are like new employees**: they reset their knowledge with every new task.
- Framed as "an expert software engineer who's a new employee onboarding for the first time" — every task requires rediscovering the codebase, testing conventions, and deployment practices.
### AI maturity curve (slide attributed by Werry to "Vim")
- Progression from autocomplete (GPT-3.5-era, Copilot) → Cursor → organizational wikis → MCP and skills for agents → software factories (stage 8, "where the puck is going").
- Werry's claim: "most people" are at **stage four to five** and understand context is the bottleneck.
- Full automation of agents is impossible without organizational context — "they get lost."
### Why access to information ≠ understanding
- Attaching a wiki doesn't tell the agent *where* the needed information is.
- **Satisfaction of search** (borrowed from radiology): agents find something plausible and stop, potentially missing other important indicators — analogous to a radiologist stopping after finding one indicator on an X-ray.
- Agents **don't distill understanding** — they don't grasp how dependencies interact or how architecture and future planning scope work.
- **Stuffing everything into the context window doesn't work**: too much organizational context even for a million-token window, and it distracts the agent; tasks need "task specific flow," otherwise tokens and time are wasted.
- References "Tariq from Claude Code" keynote on **unknown unknowns** — "finding the things that really matter." The iceberg analogy: agents see code but not intent, team conventions, past decisions, Slack discussions, architecture rationale.
## Demo Claims
### Human layer
- Humans still ask questions about the codebase; **accountability stops with humans** — "when you hit merge on a PR, you need to understand what it's doing."
- Demo of a question about the internal "**source mark engine**": the system articulated the architecture well, including a **generated diagram** (which "doesn't exist" — synthesized from how the code operates today plus future architecture proposals).
- **Showing your work** is a trust-building mechanism; lets users inspect the knowledge base and correct imperfect answers.
### Slack integration
- Unblocked can chime in on Slack conversations when it has a high-confidence answer, or be addressed directly.
### Agent comparison
- Asked Claude Code to plan optimization of the source mark calculator **without** Unblocked: "it does a pretty good job... maybe could do a little bit better."
- **With** Unblocked: it "really kind of nails the nuances" because it picks up PRs discussing future improvements, Slack conversations, Notion, and architecture documents, and shows its work — sources return to Claude so it knows where to jump next.
- **Usage comparison (Werry's numbers)**: with Unblocked — "sub-dollar" cost, ~1 minute (he instructs the audience to ignore wall-clock time since the session was open an hour); without — ~2 minutes, higher cost, because the agent has to do more discovery work.
- Qualification Werry adds: without a context engine, the agent "doesn't discover the right things," so execution may proceed on wrong plans/assumptions, forcing repeated loops.
- **Claimed real value**: not upfront cost on short tasks, but the **compounding effect** — echoing "the other Tariq from Sonar" on loops compounding.
### Code review agent
- Organizational context means "more than just the underlying data" — "real intelligence."
- Unblocked analyzes pull request data and generates **best practices** aligning agents to the codebase.
- Surfaced a prior comment from **Richie**, a senior engineer; Werry's quote: "Oh, that's cool. That's something I would say... that actually was something he said."
- **Seniority/expertise is used as a signal** to boost important comments.
### Agent debugging example
- Richie noticed the number of code review issues dropped precipitously, debugged it with Unblocked to the root cause, then asked Unblocked to fix it.
- Unblocked can run as an agent in the cloud with organizational context at its fingertips — results described as "pretty magical" (Werry's characterization).
- The generated PR related the fix to ongoing conversations; correlated the drop to switching to **Claude 4.8** ("dropped a ton in issues because the behavior is quite a bit different") and linked to the relevant Slack conversation.
## Open-Source Projects Mentioned
- **Document query engine**: runs over a GitHub repository, ingests historical pull requests, synthesizes a schema from sampled documents, supports queries via agent chat. (Referenced a Monday workshop; possibly repeating the talk.)
- **Engineering social graph**: maps team structure and review relationships at Unblocked ("we're a fairly small team"); lines indicate who reviews whose code; can cluster and generate team labels; shows **coverage across the codebase** and "where you might be lacking expert coverage." Used within the context engine itself.
- **Context engine simulator**: builds context per task behind the scenes and runs the task with and without context to show the difference; pitched for those not ready to sign up for Unblocked.
## Closing Claims
- Customer quote displayed: **"50% fewer tokens, faster triage, better answers."** (Attributed by Werry to a customer; presented as his closing evidence of what a context engine can do.)
- Plugged colleague **Brandon's** talk in room 2020, and a closing aside: "don't forget to get a coconut."
## Qualifications and Tensions Preserved
- Werry hedges several demo claims with evaluative language ("pretty good job," "pretty magical," "mind-blowing") rather than measured results — the cost/time comparison is anecdotal from a single live demo.
- The cloud-agent fixing capability is explicitly framed as something Unblocked is "**experimenting with**" internally, not a shipped settled feature.
- Werry himself notes the human layer "hasn't gone away" and accountability remains with humans — a tension with the automation trajectory he describes.
- No independent verification is offered for the customer quote or the maturity-curve placement ("most people are at stage four to five" is Werry's assertion).
# Speaker Attribution & Provenance Record
## Video
- **Title:** How to Generate Mergeable Code with a Context Engine — Peter Werry, Unblocked
- **Video ID:** `01a15ca7-9f5c-7943-ae6b-58f08a550d78`
## Speakers & Roles
| Speaker | Role | Evidence |
|---|---|---|
| **Peter Werry** | **Presenter / Creator-side speaker** — represents **Unblocked** (his employer; "What we do at Unblocked is we build a context engine") | Sole identified speaker throughout the transcript |
| **Claire** | **Audience member / production assist** — helped correct the demo display ("Thank you, Claire") | Brief, non-substantive role |
| **Audience** | **Unidentified interlocutors** — sound check responses, show of hands | No individual attribution |
| **Richie** | **Referenced third party (not speaking)** — "one of the senior engineers" at Unblocked; appears in demo screenshots/PR conversations | Mentioned only, quoted indirectly |
## Referenced Third Parties & Sources
- **Tariq (Claude Code)** — cited for "unknown unknowns" from the morning keynote
- **Tariq (Sonar)** — cited on compounding agent loops from the keynote
- **Vim** — credited for an "AI maturity curve" slide ("seen this slide before by Vim")
- **Tariq keynote** referenced generally ("this morning's keynote")
- **Named products/tools:** Unblocked, Claude Code, claude.md, Cursor, Copilot, Claude 4.8 ("Claude 48"), Slack, Notion, MCP
- **Radiology concept:** "satisfaction of search" cited as a term from radiology
## Promotional Segments ⚠️
- **Entire talk is vendor promotional** — presented by Unblocked about Unblocked's product
- **Live demo** of Unblocked (question answering, Slack integration, agents, code review, cloud agent PR generation)
- **Open-source projects promotion:** document query engine and engineering social graph ("you can just download it and have a go")
- **Context engine simulator** with QR code — explicit acquisition funnel ("don't want to sign up for Unblocked right away")
- **Customer testimonial quote:** > "50% fewer tokens, faster triage, better answers." — **customer unnamed**
- **Cross-promotion:** colleague **Brandon**'s talk in room 2020 in 10 minutes
## Provenance Facts
- Event talk with live audience; presenter references a prior workshop ("Monday") and upcoming session
- Demo metrics (cost, timing) shown on screen; **wall clock time explicitly discounted by presenter** ("Ignore the wall clock time")
- Unnamed internal components cited: "source mark engine," "source mark calculator"
- Closing reference to event giveaway ("don't forget to get a coconut")
## Unavailability / Uncertainty
- **No curated metadata supplied** — speaker identity comes solely from the video title
- **No comment availability information** provided
- Audience and Claire's exact words are not fully transcribed (responses rendered as "Yeah, we're good," etc.)
- Customer, team members (beyond Richie and Brandon), and cited keynote speakers lack full names in the transcript
What we do at Unblocks is we build a context engine. I just want to do a quick sound check at the back to make sure everyone can hear me fine. Can you guys Yeah, we're good. Awesome. So at a
high level, a context engine delivers organizational context to both your human workers and now increasingly your agents. Okay. So why why is that important? Before we go too deep on the mechanics of how a context engine works, I just want to talk briefly about the problem. So, what we're going to do is we're going to hop into our time machines and we're going to travel back to the before times uh before agents and uh discuss a little bit about what we used to do as humans uh before agents came into the picture. And so for years um you were the context layer. You um had to go and do things like this. you had to find things you were looking for, trolled all over different data sources, different discussions taking place. Um, and then through the codebase of course to try to build up tribal knowledge and, uh, throughout time as your code base progressed, um, you'd be, you know, fighting incidents and things like that. And your organization over time builds up battle scars um from all these all these different things building code uh documenting architecture and and dealing with outages and things like that. But now um we have a new problem because
uh as we introduce agents to the picture um they suffer from all of these challenges except for one thing. Agents are like new employees.
they reset their knowledge every time you start a new task. Okay? And so you can think of an agent like an expert software engineer um who's a new employee on boarding for the first time. Every time they have to rediscover your code base, how your organization builds tests um and how they deploy software with each and every task. Uh can I just uh put a put a show of hands for everyone that's seen this slide before by Vim?
So this is kind of like u this is a good way to view where people are on what we call like the AI maturity curve. Um starting at the the far left uh this is
kind of representative of autocomplete back in the GBT35 days. You know remember co-pilot and things like that. Um and then you know kind of move on to using cursor. Um and then from there you're you're think you're talking about how you can start to solve the context problem. So some people are building organizational wikis. Just smile if if this is kind of um bringing up memories for you. Um and then you know all these things are great except that uh how do you give agents access to this and what are the compounding problems that the scaling problems as you move forward well if you give MCP and skills to your agents um to teach them how to navigate and build context and that's kind of where uh people are today most people they're at the sort of stage four to five level okay and uh they understand that context is the bottleneck and they're trying to build solutions to solve it for their engineering teams. So looking ahead uh to all the way to eight with software factories. This is kind of where the puck is going. I'm not sure if if folks were at the keynote this morning, but um it's it's all about like delivery of context and unknown and unknowns. And this becomes increasingly important as people start thinking about full automation of agents. they just can't operate without organizational context. They get lost. So, you know, like that's the real problem. Access to information doesn't equal understanding. Um I I know that folks are probably familiar with claude.md um and and uh and wiki layouts and all
these things. If you attach a wiki, it still doesn't tell the agent where the information is that it needs. It can search for things in the wiki, but then
what happens is it'll suffer from something that uh radiologists uh call satisfaction of search. So, this is a term in radiology where you look at an X-ray and you're trying to find a region um that might be an indicator for cancer. Okay? And you discover like one indicator and if you stop there uh you might miss other important indicators that might you know lead to diagnosis of even more uh issues. So this is what happens with agents. They don't they they find something that they they think is correct and then they stop. Um the the other thing about agents is that they don't distill understanding. They can look around, they can find information, but they they don't understand how all the pieces fit together because without doing that leg work ahead of time. Um, they don't understand how, you know, your dependencies interact with each other and how your architecture and sort of future planning is going to scope the work that it does next. And so some some people will then ask, well, what if we just take the entire codebase and all of our architecture documents and just slam it into the context window. Um, and then yes, maybe like your agents will reason about everything all at once. And in practice, that that of course doesn't work. Um, not just because you've got way more organizational context than can fit into a context window, even one that's a million tokens in size. Um, but it it it causes the agent to get distracted. When you're working on a task, you want task specific flow. Um, and so your agents will get distracted easily if you give them things that cause them to look this way in that way. Um, and it'll just waste tokens and time. So, in this morning's keynote, um, Tariq from Claude Code mentioned unknown unknowns. I just want to uh harp on that phrase again. And it can be phrased a different way, which is finding the things that really matter. And so this is what your agent can see
at the top of the iceberg. They can see the code and they can operate on the code. What they don't see are things like the actual intent, the team
conventions, past decisions, things that you've discussed in Slack, for example, uh architecture rationale, and so on. And that's why your agents need a context engine to get real work done. So, I'm going to now uh attempt a live demo. And hopefully the demo gods are kind. Um, so I want to pop back up conceptually. Oops, I think I'm on the wrong tab. We'll get to that one in a sec. So for now, sorry about that. And here we are.
So I'm going to ask a question as if I'm a, you know, I'm a human and I want to get some information about my codebase. And, you know, the human layer hasn't
gone away. We talk about agents and their need for context, but um humans are still asking questions about the codebase and we need that level of understanding because ultimately the accountability stops with us. When you hit merge on a PR, you need to understand what it's doing um and you need to understand how the architecture works. So this question I asked here um is about an internal component of our system called the source mark engine and you can see that it uh is able to articulate it fairly well. um understands the architecture. This this diagram here is uh is generated. So it this diagram doesn't exist. Um it just figures it out based on the um the way the code operates today and then some proposals for future architecture. And then uh what's really important is that you show your work. This is a trust building thing more than anything, but it allows people to see if um if the answer is maybe not entirely correct, then you can in look into the uh the knowledge base that you have and make corrections. Increasingly agents are doing this for you. So now um what I want to show you is another place where humans spend their time which is in Slack and this is where a lot of the decisions get made of course. So I can do something like this. And uh unblocked will sit and kind of listen for things that are things that can chime in on when it provides a high degree of Oh, sorry. We went to the wrong You guys can't see that. Thank you, Claire. Oh, come on down. Let's see if I can bring it up. There we go. Perfect. So I can ask questions like this in unblocked and if it thinks it can chime in on the answer then it will chime in. Otherwise I can just um address unblocked directly and ask the same question and when it thinks that it has an answer to give then it will give an answer and so we can get um quite a bit of interesting content there from unblocked. Thank you. Unblocked. I'm going to switch up and show you the the really interesting thing which is the agents. Okay. So, um in in that question, the source mark engine, I'm not sure if people picked up, but there was a little thing at the bottom there that said, you know, there's some optimization opportunities.
Um so what I did here is I went into claw code and I asked it um without using unblocked to um uh generate uh a plan to optimize the
source mark calculator and it did that and it happily went and you know searched through the code and and tried to figure out how the algorithm works and so on. Um and it it reached a conclusion that's great you know it does a pretty good job um but you know it maybe could do a little bit better. So, I asked that question again uh using unblock this time and it it really kind of nails the the nuances because it picks up on the the uh PRs that we um where we discussed future possibilities for improvement. um some Slack conversations that we had and uh of course you know notion and architecture documents and it shows its work and this is really important because um all of these things here the sources come back to Claude and then Claude knows exactly where to jump to next if it needs to elaborate on that context. And so I just want to show you what the impact of that is. So if I um Whoops. Thank you. If I pull up usage here, you can see that with unblocked, uh, the total cost was, you know, subd dollar to create the plan. Uh, took about a minute. Ignore the wall clock time because I've had this open for about an hour. But, um, it's about a minute. And then if I look at um the usage without unblocked, you can see that it's about 2 minutes. And and and it costs more to generate all that context. Now, the reason that happens is because it has to do more work. It has to look around. has to discover things. Um, and this compounds, not only does it have to do more work to discover things, it doesn't discover the right things. So, when you get further down in your execution, it may be operating on the wrong plan or the wrong assumptions. And then you have to go back and you have to loop over and over again. So, the real value of a context engine is not like the upfront cost on these short tasks. It's the compounding effect. Um the the other Tariq from Sonar mentioned this in the keynote this morning and it's true like the loops compound and you have to be like um uh efficient the entire way through with your context. I'm just going to jump back to Safari and I'm going to point out um some really interesting things. So we also have a a code review agent. And when we say um you know
organizational context, we're talking about more than just the underlying data. Uh we're talking about real intelligence. So what unblock does is it
looks at um not like it looks at pull request data and there are other data sources for this and it generates a series of best practices that help align agents to your codebase. But we thought that this would be really helpful to surface for the review agent as well. So what you can see here is um it unblock chimed in and then Richie here said, "Oh, that's cool. That's something I would say." And that's because that actually was something he said. So it surfaced the uh the previous comments. Richie's one of the senior engineers and we use the sort of seniority or expertise as a signal um to boost uh comments that are important. Okay. So another uh interesting interaction by Richie, he uh discovered that the number of code review issues that were being surfaced dropped uh precipitously and he was debugging it with unblocked.
Um he got all the way to the bottom and realized what roughly what the problem was and then asked unblocked to fix it. Now this this is something that we have internally um you know that we're
experimenting with. Um, so unblocked uh can run as an agent in the cloud. Um, but what's really cool about this is that it has all your organizational context at its fingertips and the results are are pretty magical. So it can do things like generate this PR um, and then what you'll see here is that not only does it generate the fix, it also is able to relate it to the all the conversations that were happening. So this PR was created because and you read that context thing. It's mind-blowing. After this PR, we switched to uh Claude 48 and it dropped a ton in issues because of the behavior is quite a bit different. So then it said Richie directly correlated the drop. Now what's this thing here? Let's click on it. It is a Slack conversation. So, it found the Slack conversation, correlated all of that, you know, past history back again, and then we ended up with a with a final PR. So, um, I'm going to I've got only a few minutes left. I'm just going to close
this out really quickly. We have a uh a couple of open- source projects that are kind of interesting if people want to play with them. One is the document query engine. That was, uh, something that I talked about on Monday in my
workshop. Um, I may uh talk about it again tomorrow, but I just want to give folks a sense of what this thing does. Um, whoops. If you want to play with it, it's open source, so you can just download it and have it go. It basically runs over your um uh GitHub repository, ingests uh your your historical pull requests, and then uh synthesizes a schema based on the documents that it can sample. Um and then from there you can issue any kind of queries that you like and get all kinds of insights out of it through the agent chat. You can ask all kinds of questions. Um and then lastly the engineering social graph. So this is the thing that I was talking about earlier that helps us pin down expertise and team relationships. Um so what you can see here is this sort of like the rough breakdown of our team structure at Unblocked. As you can see we're a fairly small team. Um and so we've got these um uh these clusters of people and how they relate to each other indicates the kind of um review relationships that they have. So these are you know these lines show like we review each other's code. Um we can then cluster that and generate team labels for that or show the coverage across your codebase. This is really cool. you can see kind of where the holes are, where you might be lacking expert coverage. Um, and that's exactly what we use within the context engine itself. All right, one last thing we have uh for those that want a taste of what a context engine can do but don't want to sign up for unblocked right away. Um you can use uh something that we call the context engine simulator which will basically build up a context behind the scenes on a per task basis and then use that context uh to to drive the task. It'll do it with context and without context so that you can see what the differences might be. This is a QR code for that if you want to just take a quick snap. Awesome. And I'll just land on a quote from one of our customers. 50% fewer tokens, faster triage, better answers. And that's exactly what a context engine can do. One last shout out um before we end. My colleague Brandon is giving a talk in 10 minutes uh at room 2020. um he's going to speak to in a lot more detail about some of the higher level things that context engines can do. I'm going to run over there right after this and I think all of you should follow me. Awesome. Oh, and don't forget to get a coconut. \>\> \[music\]
