Agent Autonomy Makes Organizational Context an Engineering Requirement

Brandon Waselnuk argues that the relevant gap in AI-assisted engineering is no longer raw model intelligence but organizational context. Unblocked tested that claim by running the same prompt against the same model twice: once without its context engine and once with relevant context supplied.

The context-enabled run finished about two hours sooner. Waselnuk attributes the difference largely to avoided rediscovery: without context, an agent must search and grep its way back into an organization’s conventions and history at the start of a session. With context already available, it can spend less of its prompt budget reconstructing what the team knows.

That problem grows with autonomy. In tab completion, a developer catches a wrong suggestion, hits escape, and moves on. In an agent IDE, Waselnuk says, missing context produces “doom loops”: the agent declares the task done, the developer corrects it, and the cycle repeats over three to five prompts. The cost is both token spend and rework.

Parallel agents shift the cost into review. If several pull requests arrive at once, senior engineers must determine whether each one respects business logic, conventions, and operational constraints that may not be explicit in the code. At the far end of the autonomy curve, background agents can create silent failures: incorrect code ships, or an incorrectly enriched ticket moves through a workflow without anyone seeing the decision as it happens.

For long-lived, revenue-bearing brownfield systems, Waselnuk’s standard is therefore not merely code that compiles. Generated code should feel as if it came from someone who has been on the team for years—someone who learned through rejected pull requests, meetings, questions, reviews, and incidents, including the production failures that taught the team why a process exists.

Waselnuk describes two common approaches as local maxima: they can improve an agent’s initial performance without solving the underlying context problem.

The first is the curated-context trap. A team writes Markdown files describing how a project works, places them in a local or virtual filesystem, and lets the agent grep through them. The initial result can be useful. But those files must be distributed, maintained, and updated as the organization changes. The central question becomes who has the judgment and authority to curate a shared explanation of the project for everyone else. In practice, Waselnuk says, the repository of context rots like other documentation.

The second is the MCP plateau. MCP servers can expose information from another system to an agent, but access does not ensure use. Whether the agent calls a server may depend on its server and tool descriptions. Even if the agent searches, he says, it can exhibit “satisfaction of search” bias: after finding the first plausible answer, it stops.

An architecture record might support option A, while a Slack thread from the previous night directs the team to do B. If the agent finds the architecture record first, it may never encounter the more current instruction. More servers therefore need not change output quality if the system cannot determine when to search, what evidence to weigh, and whether an apparent answer conflicts with other relevant material.

That is why code that compiles is only the visible portion of the problem. An agent may miss original intent, team conventions, rejected approaches, migration plans, testing standards, architecture tradeoffs, incident learnings, or a rollout procedure requiring a feature flag to be disabled. The result can be syntactically valid code that still causes a production incident.

“Access to information is not understanding,” Waselnuk says. The useful layer is one that assembles, scopes, resolves, and compresses information before delivery.

Waselnuk describes a context engine as a system that ingests signals from code and pull requests, documentation, planning tools, conversations, and incident-management systems, then delivers selected context into coding agents, code review, messaging applications, MCP, command-line tools, or APIs.

The defining requirement is not broad access to information. It is the ability to determine what matters for a particular task, person, and moment. If an engineer asks to get authentication “stood up,” he says, the system should be able to use that engineer’s repositories, commit history, reviewers, and place in the organization as a starting point for finding relevant material.

Waselnuk identifies six capabilities a real context engine needs:

• Unified system context: Merge signals across sources before sending material to an agent, rather than treating each source as an isolated search surface.
• Conflict resolution: Adjudicate contradictions using signals such as recency and authority. An old architecture diagram may say one thing while a current Slack discussion with the CTO says another.
• Targeted retrieval: Retrieve only the material needed for the task, including quickly unfurling a linked document when speed matters.
• Personalized relevance: Scope context to the user’s repositories, teammates, work history, and current work.
• Token optimization: Rank and compress relevant material rather than dumping it into the model’s context window.
• Permission enforcement: Preserve policies and permissions across systems.

Permission enforcement follows directly from cross-system synthesis. A system that can draw from code, Slack, documents, and tickets must not expose details of a restricted project to someone without access. OAuth, scopes, and single sign-on can establish access, Waselnuk says, but the response itself must not leak protected information.

The retrieval problem also has a relational dimension. Waselnuk contrasts retrieval-augmented generation with a question such as: “What are the open PRs that I worked on in the last week with authentication?” RAG is valuable, he says, but cannot answer that question alone. The system also needs deterministic queries over relational data, including a way for an agent to discover a schema and query it.

A Cloudbeds customer quote shown by Unblocked describes the desired result as “~50% fewer tokens, faster triage, and the answer was actually better because it wasn’t buried in noise.” Waselnuk’s claim is that efficiency and answer quality can improve together when a system selects relevant evidence rather than simply increasing the amount of accessible material.

The first of Unblocked’s open-source examples, the Social Comment Network, is for mapping expertise and working relationships. It uses deterministic analysis of GitHub activity and pull-request comments to show who commits where, who reviews whose work, and how connected team members are through historical review activity. Teams can use the resulting expert graph to identify where knowledge appears to sit and to help focus a context engine on the people and repositories most relevant to a task.

The Repo Rules Agent addresses a different failure mode: rules dispersed throughout a repository. It discovers the places where a team has written rule files, reports the severities and other characteristics attached to those rules, identifies duplicate issues or related problems, and produces an index that can be searched. Its purpose is to make distributed repository conventions easier to retrieve and deduplicate rather than leaving them scattered across files.

The third resource is a workshop on building a relational context engine from scratch. Structured as six stacked pull requests, it demonstrates schema discovery and deterministic querying. The practical distinction is important: document retrieval can help answer what a design document or Slack thread says, while relational queries can answer questions about connections among people, pull requests, repositories, topics, and time periods.

Waselnuk extends the same model beyond code generation. He points to ticket enrichment, triage, incident response, code review, customer support, and sales queries as workflows that can benefit when organizational knowledge is available at the point of work.