Agents need context about how a company works before they can produce code that is safe to merge.
2
Curated Markdown files and MCP servers often leave important information undiscovered, stale, or unresolved.
3
A context engine should unify company data, resolve conflicts, personalize retrieval, enforce permissions, and control token use.
Summary
Brandon Waselnuk argues that AI-generated code should feel as if it came from a teammate who has worked at the company for years. Human engineers build that context through rejected pull requests, meetings, incidents, and daily work. A new agent session starts without it, so errors become correction loops, wasted search tokens, review work, and production risk as agents operate with less human supervision. Waselnuk describes two approaches that fall short: manually curated project files that decay over time, and MCP tools that agents may ignore or stop using after finding the first plausible answer. Unblocked's proposed context engine combines company data, relationships, permissions, conflict resolution, targeted retrieval, and token-aware output. In one comparison, the same prompt used about 21 million tokens without context and 10.8 million with it, finishing about two hours sooner. He also introduces open source tools for mapping engineering relationships, checking repository rules, and building a relational context engine.
Agents start each session without the company knowledge human teammates build over time
Waselnuk says AI-generated code should feel like it was written by someone who has been on the team for years. Human engineers gain that understanding by asking questions, shipping pull requests that get rejected, attending meetings, and being present during incidents. They know how work gets shipped and why a production failure happened. A new agent terminal session may be intelligent, but it does not know how the company operates. It needs that information before it can reliably solve problems in an existing codebase.
Bad context creates larger costs as agents become more autonomous
With tab completion, a human can reject bad code immediately. As teams move toward agents that work with less supervision, those agents need answers when they hit obstacles. If their initial context is wrong, they enter correction loops where the human repeatedly says the result is wrong. Waselnuk calls the resulting search and rework waste unacceptable as token costs rise. Parallel agents add a review tax, while background agents need enough context to keep operating without constant intervention.
Manually curated context files decay and have no clear owner
The curated context trap starts with Markdown files in a local or virtual file system that describe how a project works. An agent can grep those files and often perform better. The problem shifts to distribution and maintenance. Teams must put the files somewhere everyone can access them, and the repository eventually becomes stale like other internal documentation. Waselnuk asks who has the judgment and authority to maintain one context repository for an entire organization.
MCP gives agents access to sources, but access does not guarantee understanding
Waselnuk says an agent may never call an MCP server because of the way its server or tool description is written. Even when it does call one, the agent can stop after finding the first answer that appears correct. He describes this as satisfaction of search bias. An architecture record might say to do one thing, while a Slack conversation from the previous night says to do another. If the agent stops at the first result, it misses the later instruction. Information access alone does not resolve the context problem.
A context engine must connect identity, relationships, conflicts, permissions, and timing
The engine should understand who a person is, where they work, which commits belong to them, and who reviews those commits. That information becomes a starting point for finding more relevant material. The engine also needs to resolve conflicts between sources, such as an old architecture diagram and a recent Slack discussion. It must enforce permissions so information about a restricted project does not enter an unauthorized answer. Finally, it should return the right amount of context for the workflow, with token-efficient responses for machine-to-machine use.
The proposed engine combines broad company context with targeted retrieval
Waselnuk describes an engine that ingests data from many sources, including real-time information from incident-management tools, and sends context into the workflow that needs it. He names six characteristics: unified system context, targeted retrieval, conflict resolution, personalized relevance, token optimization, and permission enforcement. Broad context can help models find unknown information across a company. Targeted retrieval is still needed when a user provides a link and expects a quick document lookup. Deep research and fast answers require different retrieval behavior.
Context reduced token use and completion time in Unblocked's comparison
Waselnuk says his team ran the same prompt against the same model twice, once with context and once without it. The run without context used about 21 million tokens. The run with context used 10.8 million and finished about two hours sooner. He attributes the difference to removing the repeated search work needed at the start of each session. He also describes the resulting pattern as fewer tokens, faster triage, and better answers because the model understood more about the business.
The open source examples add relationship data, repository rules, and relational queries
The engineering social graph tool uses deterministic programming to inspect GitHub and map who works on what, who commits where, and who reviews the work. The repo rules agent finds rules files across repositories, reports duplicate or problematic rules, and creates an index for retrieval. The workshop teaches people to build a relational context engine from scratch across six pull requests. Waselnuk explains that retrieval-augmented generation alone cannot answer a question such as which authentication-related pull requests a person worked on during the previous week. That requires discovering a schema and writing a query.
