'Your agents lack context: Here''s how to fix "You''re absolutely right!" - Brandon Waselnuk, Unblocked'

As AI models become more intelligent, the primary bottleneck to effective AI-generated code and agentic workflows is not model capability but context - organiz...

By Sean Weldon

Your Agents Lack Context: Here's How to Fix "You're Absolutely Right!"

Abstract

As frontier language models converge on comparable reasoning performance, the limiting factor in AI-assisted software engineering is shifting from model capability to context - the tacit institutional knowledge human engineers accumulate through years of pull requests, incident response, and organizational conversation. This synthesis, drawing on production deployment data from Unblocked, argues that closing this gap requires a context engine: infrastructure that delivers understanding rather than raw information to autonomous agents. The analysis characterizes an agentic adoption curve along which context requirements intensify, identifies recurring failure modes including the curated context trap and MCP plateau, and specifies six architectural requirements for a functioning context engine. Empirical comparison of identical prompts run with and without such a system shows approximately two hours of wall-clock savings and a token reduction from roughly 21 million to 10.8 million tokens - a 50% decrease. Implications extend beyond code generation to customer success and sales workflows.

1. Introduction

The prevailing narrative in applied artificial intelligence attributes deficiencies in AI-generated code to insufficient model intelligence. Production evidence from agentic coding deployments suggests a different diagnosis: "The gap is not intelligence any longer. It's context." A model may reason correctly given the information in front of it while still producing an output that is organizationally wrong - violating an unwritten convention, contradicting a recent architectural decision, or missing a dependency that was discussed in a Slack thread rather than documented.

A useful benchmark for evaluating AI-generated code is qualitative: it should feel as though it was written by someone who has been on the team for years. Such an engineer knows which service owns which failure mode, which document has been quietly superseded, and which reviewer must sign off on changes to a sensitive code path. This knowledge accrues incrementally through meetings, pull requests, and on-call incidents. Every new agent terminal session, by contrast, begins at zero. As one formulation states, "You have been the context engine" - human engineers have historically served, often invisibly, as the retrieval and synthesis layer that agents now lack.

This paper defines a context engine as a queryable system that ingests heterogeneous organizational data, resolves conflicts among sources, enforces permissions, and returns token-optimized, personalized context to both human and machine consumers. Section 2 situates the problem within an agentic adoption curve. Section 3 analyzes failure modes and the six architectural requirements a context engine must satisfy. Section 4 presents technical implementation details and open-source tooling. Sections 5 and 6 discuss broader implications and conclusions.

2. Background and Related Work

Organizational adoption of coding agents follows a discernible progression, referred to here as the agentic adoption curve: from tab-completion models with token-level human oversight, through chat-based and inline agents requiring explicit prompting, to fully autonomous background agents operating without a human in the loop. Critically, context requirements do not scale linearly with autonomy - they scale with the cost of error. At each stage, agents require better mechanisms to ask questions and resolve context gaps, since fewer human checkpoints exist to catch a bad assumption. This produces two identifiable pathologies: doom loops, in which agents lacking context burn search tokens on unproductive exploration and rework, and a review tax, in which AI code reviewers lacking business-logic context generate low-value or incorrect feedback that human reviewers must then filter.

The default mechanism for supplying external knowledge to models has been Retrieval-Augmented Generation (RAG), which performs semantic similarity search over an embedded corpus. RAG is well suited to prose-answerable questions but performs poorly on relational queries - for instance, identifying which engineer has the most review authority over a specific subsystem based on commit and review history. This limitation motivates the distinction between "access to information" and "understanding," a distinction central to the analysis that follows.

3. Core Analysis

3.1 Failure Modes of Common Context Approaches

Three recurring failure modes emerge from production observation. The first, the curated context trap, arises when organizations rely on manually maintained markdown files or documentation to supply agent context. Such artifacts decay as systems evolve and require what amounts to an "omnipotent curator" - a single source continuously updating documentation faster than the organization changes, which is rarely sustainable at scale. The second, the MCP plateau, occurs when agents are given access to Model Context Protocol tools but fail to invoke them because tool and server descriptions are poorly specified; the agent has access to a capability it never exercises. The third is satisfaction of search bias, wherein an agent halts retrieval upon finding a plausible-seeming answer rather than continuing to search for more authoritative or recent information - for example, relying on an outdated architecture document when a Slack message has since overridden it. Together these failure modes illustrate the paper's central distinction: "Access to information is not understanding." A system can technically expose all relevant data while still failing to deliver it correctly, at the right time, to the right consumer.

3.2 Architectural Requirements of a Context Engine

The analysis specifies six characteristics a context engine must satisfy to move beyond these failure modes. First, unified system context: the system must understand who the user is and where they sit within the organization. Second, targeted retrieval: the ability to fetch precisely the relevant slice of information rather than an oversized or underspecified corpus. Third, conflict resolution: the capacity to adjudicate between contradictory sources, such as reconciling a stale architecture document against a recent Slack message that supersedes it. Fourth, personalized relevance: tailoring returned context to the specific user or agent's role and task. Fifth, token optimization: delivering context economically, since verbose or redundant context consumes budget and degrades downstream reasoning. Sixth, permission enforcement: respecting OAuth, SSO, and scope-based governance to prevent information leakage across organizational boundaries. A colleague's analogy, referenced in the source material, frames this as providing a "map" so that a model can discover the "territory" - the context engine does not replace exploration but makes exploration efficient and bounded.

4. Technical Insights

Implementation of a context engine requires ingestion pipelines spanning multiple heterogeneous sources, including real-time data from incident management tools, version control systems, and chat platforms. Two open-source components illustrate concrete techniques. A social comment network tool deterministically maps GitHub teams, commits, and reviewers into an "experts graph," enabling queries such as identifying true subject-matter authority independent of formal org charts. A repo rules agent discovers and audits rules files scattered across a repository, flags duplicates and severity conflicts, and builds an index that improves downstream retrieval accuracy.

A key technical insight addresses the RAG limitation described in Section 2: a schema-less lookup technique allows an agent to discover a data schema at runtime and construct deterministic queries against relational data - answering questions RAG's semantic search cannot resolve, such as precise counts, joins, or ownership chains. This is taught in an accompanying workshop material, "Beyond RAG," which walks through building a relational context engine from scratch using what is described as a "six PR" implementation stack.

Trade-offs are notable. Targeted retrieval and token optimization are partially in tension with completeness - a system optimized purely for token economy risks reintroducing satisfaction-of-search bias if it terminates retrieval prematurely. Conflict resolution requires maintaining source recency and provenance metadata, adding ingestion complexity. Permission enforcement adds architectural overhead but is non-negotiable for any deployment spanning organizational boundaries, particularly where the context engine serves both human queries (e.g., via Slack) and machine-to-machine agent workflows.

5. Discussion

The measured outcomes reported - approximately two hours of wall-clock time saved and a token reduction from 21 million to 10.8 million (roughly 50%) on an identical prompt - suggest that context delivery, not model substitution, may be the more tractable lever for near-term productivity gains in agentic software engineering. This reframing has implications beyond code generation: the source material notes applications in customer success (real-time ticket resolution) and sales (field-based deal support), suggesting that the context engine concept generalizes to any workflow where an agent must operate with organizationally embedded knowledge.

A remaining gap is measurement standardization: the reported metrics derive from a single paired comparison rather than a systematic benchmark suite, and further work is needed to characterize how token savings and time savings scale across task types, model families, and organizational data maturity. Additionally, the reliance on tools like readiness.unblocked.com to self-assess adoption-curve position indicates the field currently lacks standardized instruments for measuring organizational context readiness, an area ripe for further formalization.

6. Conclusion

This synthesis contributes a structured account of why context, rather than raw model capability, has become the binding constraint on agentic software engineering, and specifies six concrete architectural properties - unified context, targeted retrieval, conflict resolution, personalization, token optimization, and permission enforcement - that a context engine must satisfy to address it. The practical takeaway is that organizations investing primarily in model upgrades while neglecting context infrastructure are likely to see diminishing returns, whereas investment in conflict-resolving, permission-aware retrieval systems shows measurable gains in both cost and latency. Future work should extend benchmarking beyond single-prompt comparisons and explore standardized readiness assessments across organizational contexts.

Sources

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub