In the world of AI agents, you have agents that, when you start off and you start coding, they are basically at ground zero. They have no context about your code, your organization, nothing. Okay. So typically what happens is the first thing they do is they start to rip around your codebase based on the task that you give them to try to gain some understanding, sort of background understanding, before they start to do their task. So context engineering is kind of the art of supplying all the context that you need and, most importantly, none of the context that you don't need in a highly optimized way, so that when the agent starts to run, it executes the task in a streamlined way that's in line with your organization's best practices and expectations and so on.

Not long ago, as in like four years ago or less, you were the context engine. When your agent needed something, you would prompt it, you'd grab the issue ticket, you'd hand it all of the information that it needed to start its task. Over time, you would accumulate this kind of context through experience, right? You'd start a job, maybe start code splunking a little bit... eventually you'd experience real things like incidents and outages... Those are the battle scars, right? And that is what constitutes organizational context. It's the learnings along the way, the "why did we do things the way we did it."

We're becoming the bottleneck as humans. I'm not sure if people have tried managing parallel agents and working on several tasks at once, but everyone's starting to feel this cognitive disconnect because you're context switching all the time and it's just really, really painful. It is very difficult to move from that mode where you're the human managing context into the background agents mode unless you have some kind of context engine that knows how your code operates, how your organization works and understands the motivations for historical changes.

Myth one, naive RAG over my docs is a context engine. If you implement say vector search, you're going to run into a few issues. One is this satisfaction of search problem where the agent will search like crazy, consume your tokens and then in the worst case you'll reach compaction. You need to have personalization... if you just RAG all your data, it's just going to create a huge mess.

And finally, a bigger context window will solve this. Gemini first model to try this and it was really good at finding needle in the haystack. But it wasn't good at all at reasoning across different data sources, understanding the real meaning behind a problem and then recommending the appropriate solutions. Most organizations have more than a million tokens worth of context. Trying to fit all that into the context window isn't going to work anyways.

Satisfaction of search is a term that actually comes out of the medical field in radiology. Techs might find something on the x-ray that explains those symptoms and then they stop. This is what happens with agents... they'll stumble across what looks like the thing they're looking for and they'll stop. But the real golden nuggets of information might be in a different place... like in a past Slack conversation or in an incident report.

Here's the classic iceberg meme. Code that compiles - that's like the baseline. But everything that is actually important happens underneath here: understanding the user's original intent, what was rejected in the past by the team and tried before but failed. You need history as well leading up to decisions.

Unified system contexts... it's more than just recognizing when one piece of data is related to another. You have to go a little deeper... distill historical pull request comments on PRs and try to distill those down to their core essence... store them as "memories" so that when someone is working on a similar piece of code you can load those memories and then the agent can see that.

It's really important that you flow the access controls up. Our context engine integrates with Slack or Microsoft Teams. When you have private channels that are highly sensitive... it will only use that information if the person that's asking the question has access to it. And then those answers are not public.

Without the context engine, it took two and a half hours to finish this task with 21 million tokens. But with the context engine it took only 25 minutes and 10 million tokens. It's a pretty dramatic difference.

Hard lessons: One, initially we optimized for access not understanding. Second one, we hid conflicts instead of surfacing them. A context engine... can't always tell what the truth elements are and when it can't, you should surface that and learn from it. And finally, do not cache the answer... everything changes constantly. If you continuously bring previous answers into context, you're obviously going to pollute the context.

Social graph is not just about conveying information about who the experts are. It's used within the context engine as a pivot point into more important context. Another part of a context engine is "bottling the expert" - distilling what that individual has worked on in the past, where they sit in the hierarchy, the decisions they've made based on Slack conversations... Getting that expert's learnings into context is a really powerful mechanism. It helps drive the rest of the retrieval in an agentic loop and it helps the agent directionally where to go next.

Agent context collection is probably close to that number. It's like 90%. The actual code writing part is really, really fast. The thing that really impacts performance is output tokens.

AI generated code should just feel like it was written by someone that's been in your team for like 20 years. If it doesn't yet, that's fine. It will.