Agents lose organizational knowledge between tasks and must rediscover how a codebase is built, tested, and deployed.
2
Searching a wiki gives agents access to information, but it does not make them understand intent, conventions, past decisions, or architecture rationale.
3
A context engine can give agents relevant sources before they plan, reducing wasted discovery and preventing later steps from running on bad assumptions.
Summary
Peter Werry argues that agents need more than access to a codebase or a large context window. Before agents, engineers carried organizational context by reading code, searching discussions, and remembering decisions from incidents and past work. Agents reset this knowledge for every task, so they often find one plausible answer and stop searching. Werry calls this failure "satisfaction of search," borrowing a term from radiology. Unblocked's context engine gathers relevant code, pull requests, Slack discussions, and architecture documents, then gives the agent sources it can follow and show to a human. In a demo, the same optimization plan took about a minute and cost less than a dollar with Unblocked, compared with about two minutes and higher cost without it. Werry says the larger benefit comes later, because wrong assumptions compound across execution loops. He also shows review and debugging agents that use seniority, expertise, and historical discussions as context, plus open source tools for querying GitHub history and mapping review relationships.
Engineers used to carry the context that agents now lack
Before agents, engineers searched across data sources, discussions, and the codebase to build tribal knowledge. They also accumulated knowledge from incidents, architecture work, and outages. Werry describes this as the organization's "battle scars." That context helped engineers understand how the code was built and why it had its current shape. Agents introduce a different problem because they do not retain that understanding between tasks. The context layer has to be made available again when work starts.
Werry compares an agent to an expert software engineer who is onboarding for the first time. Every time a new task begins, the agent has to rediscover the codebase, the organization's build and test process, and how software gets deployed. He places this problem on an AI maturity curve that moves from autocomplete and tools such as Copilot toward organizational wikis, MCP and skills, and eventually software factories. His point is that increasingly automated agents cannot operate well without organizational context.
Access to information does not give an agent understanding
A wiki, a claude.md file, or a large context window does not tell an agent which information matters for a task. Werry uses "satisfaction of search," a radiology term, to describe how an agent finds one plausible answer and stops, even when other evidence could change the result. Giving the agent the whole codebase and architecture documentation also fails because too much context does not fit, even in a million-token window, and distracts the agent from task-specific work.
The missing context includes intent and past decisions
Werry describes the code an agent can see as the top of an iceberg. Below it are the intent behind the code, team conventions, past decisions, Slack discussions, and the rationale for the architecture. These details affect how an engineer should scope and implement a change. In his view, an agent needs help finding the unknown unknowns, or the pieces that matter but are not obvious from the code alone.
A context engine can explain a component and show its sources
In the demo, Werry asks about Unblocked's internal source mark engine. The system explains the component's architecture and generates a diagram based on how the code works today, along with possible future architecture. The diagram did not exist beforehand. The answer also includes its sources. Werry says showing the work helps a human check an answer and correct the underlying knowledge when something is wrong. He also demonstrates asking questions in Slack, where Unblocked responds when it has a useful answer.
Relevant history improves an agent's implementation plan
Werry asks Claude Code to create an optimization plan for the source mark calculator, first without Unblocked and then with it. Without the context engine, Claude searches the code and reaches a plausible conclusion. With it, Claude finds pull requests about future improvements, Slack conversations, Notion content, and architecture documents. The sources are passed back to Claude, so it knows where to look when it needs more detail. The plan with Unblocked costs less than a dollar and takes about a minute. The comparison without it takes about two minutes and costs more.
Wrong discoveries compound as an agent executes a task
Werry says the value of a context engine is larger than the initial time or token savings. Without context, an agent has to search for information and may discover the wrong information. Later steps then use the wrong plan or assumptions, which forces the agent to loop back and repeat work. The cost compounds across the whole task. Context has to remain accurate throughout execution, rather than being added only at the beginning.
Review and debugging agents can use organizational history
Unblocked's review agent uses pull request data and other sources to generate practices that fit a codebase. It can surface an earlier comment from a senior engineer when that comment is relevant, using seniority or expertise as a signal for boosting comments. Werry also shows a debugging example where a drop in flagged review issues is traced to a Slack conversation about a change in Claude's behavior. The agent can generate a pull request and connect the fix to the discussions that explain why it was needed.
"What you don't see are things like the actual intent, the team conventions, past decisions, things that you've discussed in Slack, for example, architecture rationale, and so on."06:50
Who should watch
You are evaluating coding agents and keep seeing them rediscover the same repository conventions on every task.
Your team has useful decisions in Slack, pull requests, and architecture documents, but agents usually find only the first plausible answer.
You want to compare agent work with and without retrieved organizational context, including the effect of wrong assumptions on later execution.
