Good afternoon. I hope everyone is having a great time. It's warm out there, but we have amazing weather. The UV index was around 10, so hopefully you are all practicing safe sun hygiene. I'm here to talk about context engineering. I was fortunate to follow Jay from LinkedIn, because he talked a lot about the actual system design and the decision-making process. I'm going to lean into the tooling and the open-source code that is coming out at the end of the week. So, if you looked at the preceding presentation, you're going to get a lot of tooling that you can try, and today I'm going to teach you a few techniques.

The goal is to fix the "you're absolutely right" problem. I think they've already updated the prompt to say "you're right" or something else, but I'm sure you've all hit this. I'm Brandon. I work at Unblocked. Yes, I have the coconuts. We're giving those out for the new context—fresh coconuts.

What I really want to talk about is those models, especially the frontier models, looking like they're going to solve all our problems today. That's what they tell us. You can make an app in five seconds. That's true for a landing page and an MVP. But what I want to think about is: with these tools, the code that the AI produces looks like it was written by someone who has been on your team for years.

To set the stage properly, you have to remember that you were the context engine for many years. How did you do that? You built the context by walking through the workspace, asking questions, reviewing PRs, rejecting PRs, attending meetings—all these tiny things that formed your mental model. You know how things work here, you know what happens when a release goes out, you were on call that night when the outage happened, and you know why it happened.

The problem is that these agents have the exact same challenge. You start a fresh session with a terminal agent: it's very smart, but it has zero context about how your company works. It has to figure it out from scratch. The issue is that when you scale these agents, the cost compounds if you do something wrong right at the beginning.

Using context properly is essential. When we look at the evolution over the last few years, code autocomplete was great because all that happened was a ghost text popup: "Hey, do you want this completed by hitting Tab?" Your brain, the internal context engine, quickly evaluated: "No, that's bad," or "Oh, that's good," and pressed Tab.

As we move toward agent execution, we enter scenarios where agents work without human intervention, or at least you want them to. To achieve that without failure, they need a way to ask questions, solve tasks, or resolve problems, and eventually generate code that can be merged into the main codebase—especially for legacy codebases that have been around for years and generate real revenue, not just greenfield projects.

The cost of incorrect context at the beginning is severe. If you think about "shifting left," you want to catch bugs as early as possible. That applies directly to context. Because in a multi-turn conversation, you get caught in failure loops: you ask the agent to do something, it says "Hey, I did it," you reply "No, that's wrong," and then it gives rule after rule after rule. That's a waste of search tokens and a waste of iteration time. It doesn't scale with tokenomics.

When you run parallel agents, you start paying a heavy tax for verification. That's why we try to use AI code reviewers; but again, context is required for those reviewers to understand business processes, business logic, and operational realities. Ultimately, if you want to take humans out of the final loop where agents make mistakes, you need an enterprise context engine so agents can formulate precise queries and get the answers required to deliver successful outcomes.

There are some common approaches that only work partially. They represent local maximums. Two of the most frequent patterns we see among hundreds of enterprise and mid-market customers are:

First, Curated Context. You create a virtual filesystem or local directory, fill it with markdown files, and say: "Here is all the project context, here is how everything works." Then you allow the agent to search through it. It gets lots of useful information and starts working better. But the problem is that this repository goes stale, just like any other documentation. Who is the omniscient curator in the company responsible for maintaining that file or repository for everyone? You quickly run into maintenance bottlenecks.

Next comes the Model Context Protocol (MCP). We have MCPs, and they are great. You can provide them to an agent so it can pull information from other systems. The problem, however, is that based on the server response or tool descriptions, the agent might never read what it actually needs to read. Or it suffers from confirmation bias: the agent finds the first piece of information, assumes it is correct, says "Oh, I have everything I need," and moves on.

In most organizations, yesterday's Slack conversation might state that we should do A instead of B. But if the agent can't find that, it relies on the original written architecture. Therefore, it does not have a holistic understanding of the context. The issue isn't just access to information—it's having no real operational understanding.

To supervise models effectively, you need other methods. If your agent cannot see what lies beneath the surface, it might produce code that passes 100% of the build, but that code breaks in production at 1:00 AM, causing a P0 incident because it missed a deployment procedure or a required feature flag.

Your team needs a contextual provider that understands who you are, what role you play in the organization, and what code you touch. It should understand: where do I work, what Git commits did I make, who reviewed them, who are my contacts—and use that as a starting point to discover relevant information. It should resolve conflicts between outdated architecture diagrams and yesterday's Slack message from the tech lead. Which one is correct? You need an approach that understands this nuance.

Of course, this must be paired with respecting permissions and access policies. While MCP allows OAuth and SSO integrations, if someone asks a question about confidential Project A, the system must ensure unauthorized details are not leaked in the response.

Finally, delivering context to the model at the right time without inflating the context window is critical for token optimization.

Here is how the mechanism works in practice: On the left side, you observe all the incoming data sources. We look at engineering teams, the tools they use, and technical writing tasks—support tickets, sales notes, and more. You gather all this data, receiving real-time event updates from tools across the workflow.

These events feed into the engine, which powers six key pillars:

1. Organizational Context: Understanding the entire engineering organization and who works on what.
2. Deep Research & Targeted Fetching: Balancing in-depth technical exploration with low-latency, immediate retrieval to prevent token waste.
3. Conflict Resolution: Resolving discrepancies between conflicting data sources (e.g., stale documentation vs. active engineering discussions).
4. Temporal Relevance: Recognizing current operational state, user identity, and active project focus.
5. Token Optimization: Formatting and pruning context to maximize response quality without overflowing the context window.
6. Access Control & Permissions: Enforcing OAuth and identity boundaries so private project information is never leaked.

For large enterprises like LinkedIn, Workday, or General Motors, having this unified contextual layer is mandatory. They need full visibility across complex engineering activities.

In our experiments comparing models running with and without this contextual engine: Without optimized context, a heavy task consumed roughly 10.8 million tokens due to repetitive exploratory loops and redundant searches. With the contextual provider, token consumption dropped by over 50%, while accuracy and execution speed improved significantly because the model operated with full awareness of the internal business environment.

I want to share three tools and open-source resources:

First, a deterministic GitHub analysis tool that automatically maps team structures, identifies code ownership, and builds an expertise matrix across your repositories. When integrated with OpenAI or Anthropic models, it allows agents to intelligently route questions to the right engineering domain.

Second, an agent rules analyzer. It inspects all prompt and rule files across your repositories, detecting duplicated rules, conflicting constraints, and outdated instructions, while providing a clear health score to keep your agent prompts clean.

Third, our workshop on building relational contextual providers from scratch, moving beyond basic RAG. Traditional RAG fails on queries like "What PRs were opened last week regarding authentication?" because vector similarity cannot effectively process temporal and relational queries. Combining relational data schemas with deterministic extraction enables agents to retrieve accurate structural facts without hallucination.

The impact of this context engine extends beyond code generation. When customer support and sales teams use the context engine, ticket resolution times drop significantly, and sales cycles close up to four times faster because team members can instantly query technical truths directly from the codebase.

The barrier today is no longer raw intelligence—frontier models from Anthropic, OpenAI, and others already possess extraordinary capabilities. The real challenge is context: how to feed them the exact, verified context they need, within appropriate token economics and strict permission boundaries. Thank you for your time.