# Building the Context Engine AI Agents Need: The QCon Boston 2026 Talk URL: https://getunblocked.com/blog/building-the-context-engine-ai-agents-need/ Published: 2026-10-26T18:40:00Z Author: Brandon Waselnuk Categories: Context Engine, Engineering Insights Written version of the QCon Boston 2026 talk published by InfoQ: why agents loop, what a context engine must do, the 6 requirements, and a readiness check. --- AI coding agents fail for lack of context, not lack of intelligence, and the fix is a context engine that gives them what a tenured teammate already knows. That is the argument of my [QCon Boston 2026 talk](https://boston.qcon.ai/presentation/boston2026/building-context-engine-ai-agents-need), given on June 2, which [InfoQ recorded and published](https://www.youtube.com/watch?v=UCgQj1ZlDqk) on June 24. This is the written version, with the video below. A **context engine** is a system that connects code, conversations, tickets and docs, resolves the conflicts between them, and returns only the slice a given person or agent needs and is allowed to see. [External Video](https://www.youtube.com/watch?v=UCgQj1ZlDqk) ## Why do AI agents keep looping on the same task? Because they are outsourcing their thinking to you. Everyone who has used these tools knows the moment. You ask the agent for something, it does it, and you say "that is not right." Then the game starts: feed it another file, rephrase, correct it again. I call these doom loops. A **doom loop** is the cycle of re-prompting an agent that keeps producing the wrong thing because it never had the information to produce the right thing. For years, you have been the context engine. You know where things live, how work gets done, and which parts of the codebase are landmines because of an incident nobody wrote down. When you type `claude` in a terminal, the agent that spawns is very intelligent and knows none of this. Every correction loop is the agent asking you to be its memory. You built that memory in standup, in rejected pull requests, in pairing, and by searching every tool until you had a model of how the company operates. For a strong engineer that took six months to a year. The agent never gets the six months. ## What context actually means for an agent Context is everything the code does not say. The code tells an agent what runs today, and nothing about why that choice was made, who made it, what was tried and reverted, or which Slack thread last week changed the plan. Agents handle code that compiles well and cannot see any of the rest. The rest breaks into four things: the code and its history, the decisions and the reasoning behind them, the conversations where plans were actually made, and who knows what. Imagine a front-end change where two approaches conflict, and one came from the engineer who owns the front end. A human on the team knows which to pick. An agent with only the repository cannot. The trust numbers reflect this gap. Nearly three quarters of developers use coding assistants or agents daily, yet only 16% trust it for most tasks short of important decisions. Another 48% trust it only when they can easily validate the answer ([Stack Overflow Developer Survey 2026](https://survey.stackoverflow.co/2026/ai)). Validation is the correction loop by another name. ## Why rules files, MCP connectors and bigger windows are not enough Each gives a real lift and then stalls. **Rules files.** Past about 20 engineers, teams write a static layer: CLAUDE.md, AGENTS.md, Cursor rules. It helps, then it rots like every other document. Rules multiply per team until the monorepo has duplicates and contradictions that inflate every session. Claude Code's docs say these files are [treated as context, not enforced configuration](https://code.claude.com/docs/en/memory), and Cursor's docs tell you to [keep rules under 500 lines](https://cursor.com/docs/context/rules). In our monorepo I counted 124 rules. And who at a 200-person org has the judgment to decide what belongs in a static layer? **MCP pipes.** The next move is to connect every source over MCP. Agents do not know when to call which pipe, because they do not know your org. The [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) makes tools "model-controlled," so the model picks them from their descriptions. Anthropic's [tool search docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool) put a typical multi-server setup at about 55k tokens of definitions before any work starts, with selection accuracy degrading past 30 to 50 tools. See [A Pile of MCP Connectors Is Not a Context Engine](https://getunblocked.com/blog/mcp-connectors-are-not-a-context-engine/). **A bigger context window.** Opus arrived with a million tokens, and the problem stayed. Anthropic's [context window docs](https://platform.claude.com/docs/en/build-with-claude/context-windows) now say "more context isn't automatically better" and call the degradation context rot. A January 2026 [arXiv paper](https://arxiv.org/abs/2601.11564) fed Llama-3.1-70B and Qwen1.5-14B large volumes of irrelevant context and found model quality falling while system cost rose non-linearly with the KV cache. Dex Horthy's written guidance at HumanLayer is to [keep utilization in the 40 to 60 percent band](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/ace-fca.md). In the talk I used his blunter version: past about 40 percent you are in what he calls the dumb zone, where the agent either greps more or guesses. **Plain RAG over docs.** A retrieval pipeline over your documentation has no idea who you are, where you work, or what the company intends. Providing access to data is not the same as giving an agent understanding. A context engine delivers understanding. ## What are the pieces of a context engine? Six requirements, built on a pipeline that connects every system where engineering happens. That means source control, planning tools such as Linear and Jira, documentation wherever it lives, conversations in Slack or Microsoft Teams, and incident tools such as Sentry and Datadog. Connect through APIs so permissions flow all the way through. Ingestion runs on top. We do RAG as one technique, with embeddings and a first knowledge graph, then use telemetry to build a personalization graph of how the organization operates. The payoff is agentic retrieval. **Agentic retrieval** is a search that starts at the most likely place, follows what it finds, and only then decides. It finds a Notion doc, notices it links to six old PRs and an incident report, opens those, follows them into the code, then judges. A single MCP call gets one view into one tool and stops. The six requirements: 1. **Unified system context.** Search exhaustively across sources, then converge on one answer. 2. **Conflict resolution.** The code runs A, a Slack thread from yesterday says do B. The engine has to decide. 3. **Token-optimized responses.** The same answer is shaped for whoever asked. A human gets readable prose, and an agent gets a dense response of around 3,000 tokens in our system: these files, this service, here is the map. 4. **Targeted retrieval.** Hand it a ticket and it returns context fast, then optionally runs a broader research pass for the unknown unknowns. 5. **Personalized relevance.** Who is asking shapes what matters. 6. **Permissions enforcement.** One of our largest customers has tens of thousands of engineers, confidential projects and M&A activity, so some information can be served to some people and not others. The access model has to inherit OAuth through SAML and SSO. This is very hard to build yourself. ## How does a context engine decide what is true? By scoring every candidate on recency, authority and proximity to the person asking. A decision from yesterday usually outranks a doc from last year. Authority comes from the commit graph, because the person who reviewed and committed the code in that area probably knows. Proximity adjusts the other way: an opinion about a system the speaker has never touched is weighted down. The **social graph** is the map of who reviews whose code, who ships where, and which people cluster around which systems. On our own team, if a front-end conflict comes down to A or B, and B came from the engineer who owns the front end, the engine picks B. Rally's CTO described the same mechanism from the customer side: > A lot of our context and knowledge is in Slack. Unblocked doesn't just backfill all of our past conversations. It continuously updates and keeps that context fresh. It weights recent information higher than old information, and for a product moving as fast as ours, that's so important. What makes Unblocked smart is that context management. It's not just putting everything into Claude and having it respond. > > — Alec Robins, CTO & Co-founder, Rally For the longer treatment, see [Source of Truth for AI Agents: Who Decides What Is True?](https://getunblocked.com/blog/who-decides-what-is-true-for-ai-agents/). ## What it looks like when the agent asks Unblocked instead of a person In the talk I ran our `ask-unblocked` skill inside Claude Code and asked how to optimize one of our services. The agent called Unblocked first to hydrate context, so its next decisions were correct instead of lost, and the answer came back with every citation: the Slack deep dive, the PR history, the key files. Then I asked it to plan a migration from Kotlin to Rust. With organizational context, it told me not to. It found the postmortem we wrote on an earlier Kotlin Native attempt, and in effect said: you have talked about this before and it was not a good idea; if you genuinely want to, here is how. That is what institutional context for coding agents buys you. The second demo planned a first-class Zendesk integration, which touches 80 to 90 files in our codebase. It found every in-flight PR and the Slack threads where we had been planning it. In our testing, an agent without that context silently breaks callers and does not realize it is editing a hot file. Three open-source tools from the talk let you try the techniques without buying anything: - [engineering-social-graph](https://github.com/unblocked/engineering-social-graph) builds the expert, team, peer and heat-map views from a local clone and its GitHub pull-request history; see [OSS Social Graph Builder](https://getunblocked.com/blog/oss-social-graph-builder/). - [repo-rules-agent](https://github.com/unblocked/repo-rules-agent) finds every CLAUDE.md and AGENTS.md in a codebase, reports duplicates and conflicts, and grades each rule's strength (must, should, can); see [OSS Repo Rules Agent](https://getunblocked.com/blog/oss-repo-rules-agent/). - [context-engine-simulator](https://github.com/unblocked/context-engine-simulator) runs an A/B test on your machine, one arm that searches your codebase and connected MCPs and one that works from the task description alone, and reports the time, token and quality difference. ## Where is your team on the maturity curve? Almost every company we work with sits at level three or four. The staircase in the talk is adapted from [Bassim Eledath's 8 Levels of Agentic Engineering](https://www.bassimeledath.com/blog/levels-of-agentic-engineering): tab complete, agent IDE, context engineering, compounding engineering, MCP and skills, harness engineering, background agents, and autonomous agent teams. Level eight is still mostly a dream unless you are on the Claude Code team. We mapped the context each level needs in [The 8 Levels of Agentic Engineering](https://getunblocked.com/blog/8-levels-of-agentic-engineering/) and on the [context maturity page](https://getunblocked.com/context-maturity/). The curve matters because the cost of bad context compounds with distance from your keyboard. With tab complete, you see the wrong suggestion and hit escape. In an agent IDE, the doom loops cost time and tokens. With parallel agents, the bottleneck moves to code review, so a context engine should also serve your AI reviewer; ours can decline a PR on business intent, because it knows where the company is going. With background agents, nobody is there to catch it, and the wrong code ships. Pick the next step. Skipping ahead breaks the foundation unless you buy something built for it. To find your level, chat with the assessment at [readiness.getunblocked.com](https://readiness.getunblocked.com/). It asks six questions or so, maps you onto the staircase, and hands you a report. ## What should you measure? Correction loops, wall-clock time and tokens, on the same prompt with and without context. In the talk I showed one controlled run: the same prompt to the same model on a medium-sized task, once with Unblocked and once without. Our founding engineer Peter reviewed both outputs to confirm they landed where he would have landed them. Without context, he went through five correction loops and the run took about two and a half hours of wall clock. With context, the agent one-shotted the prompt in about 25 minutes, which we did not expect. Token usage dropped by nearly half, almost all of it search tokens the agent no longer spent grepping around the codebase. That run is separate from the test we published later. There we measured the same method on a different task, with a blind LLM judge and an open-source harness, and came out at 42 percent fewer tokens and 27 percent less time ([Same Prompt, Same Model, Different Context](https://getunblocked.com/blog/same-prompt-same-model-different-context/)). Run the harness on your own repository before you believe any vendor's number, including ours. The other measurement is deflection. Unblocked sits in Slack and Teams and answers the questions that sales, solutions engineering and customer success would otherwise ask an engineer. In the talk I put that at 60 to 80 percent of the questions in an ask-engineering channel. The same engine handles ticket enrichment, 2 a.m. incident triage and code review. The gap is not intelligence anymore. It is context. Andrej Karpathy was making a version of this point, under the name context engineering, before I was. The [video page](https://getunblocked.com/videos/building-the-context-engine-ai-agents-need-infoq/) has the talk alongside the other sessions. ## FAQ ### Is a context engine just RAG over my documentation? No. Retrieval is one technique inside it. Plain RAG does not know who is asking, which of two conflicting sources is current, or who the expert is. A context engine adds the social graph, conflict scoring and permission inheritance on top. ### Do I still need CLAUDE.md and AGENTS.md files? Yes, for the small set of stable, team-wide rules. They are no substitute for live organizational knowledge, because they rot and conflict across a monorepo. Run the repo rules agent to see what yours actually say. ### How is a context engine different from connecting a lot of MCP servers? An MCP server is a pipe to one tool, and the agent has to decide when to call it from a description. A context engine is called once, traverses every connected source, resolves the conflicts and returns one answer with citations. It is delivered over MCP too, as the one tool the agent calls first.