Good afternoon.
I hope you're all having a lovely day here at AIE. We've had great weather, though the UV has been nine, so hopefully you put your sunscreen on and are being appropriate adults. I'm here to talk to you about context engineering, and I have the good fortune of following AJ from LinkedIn, because he talked a lot about the system that we actually design and sell to other solutions, and I'm going to give you a bunch of open-source tools. So if you watched that last talk just before me, you're going to get a bunch of tool chains so you can go mess around yourself, and I'll teach you a bunch of techniques today. The goal, of course, is to fix your absolutely right.
I think they've taken that out of the prompts now, so it just says you're right or other things, but I'm sure you've all been there. So I'm Brandon. I work at Unblocked. Yes, I have a coconut. We've been giving these away for fresh context, fresh coconuts. But the thing that I want to talk to you about is with these models, especially with Mytho class models— I think Fable 5 is coming back today, so they say you can watch my grain call recording and try to book this. We'll ignore it. But what I want you to do is think about the fact that with these tools, AI-generated code should feel like it was written by someone who's been on your team for years.
So to get in the right headspace, for years you have to consider that you have been the context engine.
How did you do that? You built context by going to work and asking questions, shipping PRs and getting them rejected, going to meetings, and all this slowly over time built up the engine that is your brain. You understand how it works here. You know how stuff gets shipped. You were on call that night when you took prod down and why that happened. The problem is that these agents have this exact same problem. Every time you create a new terminal session with an agent in it, it's very intelligent, but it doesn't have any context on how your company operates. So it needs to get that somehow. The problem is as you move these agents up in scale,
that cost compounds if you get it incorrect at the beginning. The leverage off context and content. We're just going to fix this because I think people want to take some photos. Perfect. That context issue will compound. So at the far left, we all remember the age-old time of two years ago where we had tab complete models that were pretty cool. What happened is it popped up and said, hey, do you want to tab this? And quickly in your head with your context, you either go, no, that's bad, or you went, oh, sweet. You hit tab. Nice. As we move along the agentic adoption curve, what happens is you are moving into more situations in which you have agents running
without a human in the loop, or at least you wish you didn't have to be in the loop. What they need is some way to be able to ask the questions they need when they hit walls in order to write code or solve or fix the issue and ultimately output code that's mergeable into your code base. So we have a lot of people here who actually work in brownfield code bases that have been around for a long time that run real revenue across them, not just greenfield fund projects. So that cost of bad context compounding at the beginning is cheap. If you think shift left, finding a defect or a bug, you want to find it as early as possible. It's the same with context.
Because as you move across, you get into doom loops. You usually ask your agent to do something. It's like, hey, I did it. And you're like, no, man. And then you correct and correct and correct. That's wasted search tokens. It's also wasted rework time. And that is not acceptable with the tokenomics we have coming. And then as you move into parallel agents, you start hitting a review tax. So these AI code reviewers we're trying to use. But again, key context is important there. So those code reviews are able to understand how the operations of the business are. So it knows the business logic and more.
And then finally, if your hope is to move all the way out of the loop, you're like background agents, get it done, make no mistakes. You really need to make sure that you have a context engine. So those agents can query it and get all the answers they need so they can keep operating in an effective way. There are some common approaches that don't work. They're basically local maxima. Two of the ones we see the most with our hundreds of enterprise clients and mid-market sized businesses is the curated context. If you've ever sat down and taken a virtual file system or a local file system, you put some markdown files in it.
And you're, here's all the context of this project. It's how it works. You then allow your agent to grep over that. And it gets a bunch of good data. And then it will perform better. The issue is first, now you have to distribute that. So maybe you throw it up in the GitHub and your team can grab it. But then the next is that repo is going to rot just like all the other docs you wrote down. And then who at your org is the omnipotent one who has the taste to curate this file? And then you have to do a repo for literally everyone in the org. So you start to hit these issues. The next is the MCP plateau. This one is pretty clear. We have MCPs. They're great.
You can give it to your agent. And now it can basically get information from another source system. The problem is, of course, based on how you write the server description, the tool descriptions, your agent may never call it, even though it should have. Or if it does, there's a known bias called the satisfaction of search bias. What that means is the agent, when it finds the first piece of information that it thinks is correct, it goes, oh, I have what I need, and it proceeds. In most organizations, there's a Slack conversation from last night that says you should be doing A instead of doing B. And the agent will never find it if it found some architecture record first.
So it doesn't actually consider all of the context. The problem here is access to information is not understanding. So to deliver understanding to a model, you have to do other techniques. What I'm basically trying to say is what your agent can't see is everything below the waterline. It can get code that compiles, but that code that compiles is taking down prod and you have a P0 at one in the morning. Because it missed the fact that you have a certain rollout procedure, you're supposed to turn off a feature flag, whatever it might be. So your team needs a context engine because what it should do is understand who you are and where you work in an organization.
So if I say to you, I want to get auth stood up, it knows where I work, it knows where my git commits are, it knows who reviews those commits, and it understands that my context, it can focus me and then use that as a trigger point to find the rest of the information. It resolves conflicts, as mentioned, an old architecture diagram and last night's Slack convo with the CTO. Which one is right? You need to use a bunch of techniques to determine that. It respects permissions and governance, of course. MCP allows us to use OAuth and other scopes and SSO, but if someone asks a question over here who's not supposed to know about secret project A,
you need to make sure that doesn't leak into the response. And then finally, deliver the right context at the right time to the model in a token optimized way. We have multiple surface areas because human engineers still talk to Unblocked all the time to get information they need in Slack or otherwise. But then you want token optimized responses if you're just speaking machine to machine in order to not waste a bunch of bold classes on your token spend. This is how an engine works. I'm going to be brief on this, but basically on the left hand side, you see all the data sources that are coming in.
For us, we focus on engineering teams and that's who uses us, as well as the technically light teams around it, like support, sales, and otherwise. You ingest all that data, you get real-time data from tools like your incident management toolchain. It comes into the engine, where that engine thinks. At the bottom, I'll expand on that slide in a moment. But basically, it uses these six key characteristics. And then on the right, you output the context to the exact workflow in the manner that it is needed. Those six key points, as mentioned, unified system context. You have to go across the whole thing.
At large orgs, companies like LinkedIn scale, Workday, General Motors, whatever, they need this type of data. They need to understand everything that's happening. And Tharik this morning, actually talking about Fable coming out potentially later today, he mentioned that you need to actually provide a map and then let Fable discover the territory. The way to help confine that is making sure that these models have access to all of the context because they will find your unknown unknowns. There are definitely things going on in your company that you're just unaware of, but would be really helpful for the task you're trying to do.
That will move faster, but the targeted retrieval, you should be able to, if you provide a link, quickly unfurl it, get that document back and move along. So two tasks: deep research, go long, that's fine. But you also need speed when speed is required. Conflict resolution, we already talked about that, but one thing says do A, one thing says do B, who is right. Personalized relevance, who am I, where do I work, what am I working on. That token optimization, making sure the response is good and effective and doesn't bloat the window. And then permission enforcement, of course. OAuth, you shouldn't see it, you shouldn't see it.
What we did with some tests is we actually ran the exact same prompt to the same model and one with context and one without. This is the wall clock time savings and then two hours, which is great. And then the tokens savings. So it was a sizable task, it took about 21 million tokens without and then 10.8 million tokens with it. This is the type of experience that you typically see when you're using a context engine, because the majority of those wasted search tokens where it has to grep at the beginning of every session to understand and discover things are no longer there when it's hydrated with context. And then as you move forward, you get these types of outcomes.
50% fewer tokens, faster triage, and the answer quality is actually better because it knew what was going on inside of the business. Now this next part, you'll probably want a photo. If you don't know, you can actually take a picture of a QR code and then later in photos tap on it and then load the link so you don't need to float here because I'm going to give you three QR codes. This first one is for the social comment network. I'll pop that up so you can take a photo. But this is an open source tool that we've got that actually using all deterministic programming goes over your GitHub and understands who works on your team. This is my real team.
We called Rasheen the machine because he ships constantly. But on the right, you can see who he commits, where he commits, who's reviewing his work. And then in those tabs, you can find a distilled experts graph. You get full coverage of what's going on in your business. And if you optionally add one of the API keys for either OpenAI or Anthropic, it'll determine what your teams are by doing some labeling for you. It's a really cool tool to understand where your team works and get that social network in there in order to focus a context engine if you're going to be building these tools yourself. The next is called the repo rules agent.
This is a sample from our real code base. I'm going to pop that up anyway so you don't need to talk to the thing. But in short, what it does is discover all the places your team has written rules files, checks them all, and then tells you what severities you've given, what other things you've given. It tells you, hey, it's good to meet you all. Basically, it will find all the rules that are inside of your repo and then tell you if you have duplicate issues or other problems, and then you can grep over it as an index. So that index can be called and you can dedupe, and it'll help improve your retrieval of context.
And then finally, on Monday, we delivered this workshop, which was going beyond RAG, and taught how to build a relational context engine from scratch. So if you scan that, you'll get the full workbook. It has six PRs stacked that teach you how to walk through doing this. But in short, RAG is an incredible technique, and you want that. But the other half of the problem is what people actually ask is, what are the open PRs that I worked on in the last week with authentication? RAG cannot answer that question alone. You need queries. So this shows you how to do a schema-less lookup that allows the agent to discover a schema and then write queries against it.
And then you can see how to do it deterministically in order to get that type of relational data out. Very useful technique. Use cases of a context engine, of course, go beyond code generation. This is where we live a lot. A lot of our customers spend their time. But it's amazing to see what happens when a bunch of other people around the business start picking up these tools. Customer success people solving tickets right at the time that it comes in from a customer. We've got salespeople closing deals earlier in their quarter because they're able to query the unblocked context engine on the fly while in the field. And so many more.
What you can also do is if you saw that curve chart earlier where I talked about the levels, we've built a fun little tool where basically an LLM will quiz you and ask you about what's going on. And then it will map you to exactly where you are and then tell you some techniques about how to level up through that if you are looking to compound your capabilities and ship with AI tools at scale. It's readiness.getunblocked.com. The gap is not intelligence any longer. It's context. We will continue to get incredible models like Mythos as it's been grown by Anthropic. And I'm sure Sol, once I'm allowed to see it, I will get it. Happy Canada Day, by the way.
But what's happening is it's about the context you surround these models with in order for them to be effective and token efficient inside of your organization. So I have a question slide, but I'm not sure I'm allowed. Nope. So what you'll do is come meet me at booth P16.
You can look for the coconut. It would be great to hang out with all of you and get into details here if you need it. Thank you for your time. Thank you. Thank you. Thank you for your time.
Thank you. Thank you.