The Subagent Architecture: How to Stop Your Coding Agent from Burning Its Entire Token Budget on Repo Search

Most engineering teams deploying AI coding agents treat the model as a single actor: it receives a task, explores the codebase, forms a hypothesis, and generates a solution. That architecture is intuitive and easy to stand up, but it carries a structural cost that compounds as codebases grow. The model doing the exploration is also the model doing the reasoning, which means every file read, every grep traversal, and every dead-end search populates the same context window that should be reserved for coherent problem-solving. The result is a context window that fills with navigational noise before the solver has written a single line of code. Addressing this requires a deliberate architectural decision, not a prompt engineering fix.

The Token Budget Problem at Scale

The scale of the inefficiency is larger than most teams estimate. An analysis of GPT-5.4 agent trajectories conducted as part of Microsoft's FastContext research found that reading and searching operations account for 56.2% of all tool-use turns and 46.5% of the main agent's total token consumption. That means nearly half the token budget on a typical task is spent on navigation, not on the work the agent was deployed to do. For teams running agents against large monorepos, this creates a compounding problem: the more complex the codebase, the more exploration is required, and the more the solver's effective context is crowded out by retrieval artefacts. At production scale, this translates directly into higher inference costs, longer latency, and degraded output quality as the model attends to irrelevant context.

Why Monolithic Agents Fail at Repository Scale

The failure mode is architectural rather than model-specific. A single agent tasked with both exploration and generation must maintain two distinct cognitive states simultaneously: an open, hypothesis-generating state during search, and a focused, evidence-grounded state during code synthesis. These states conflict. Exploratory search benefits from breadth, producing many partial reads and speculative file accesses. Code generation benefits from a compact, high-signal context containing only the files and line ranges directly relevant to the task. When both activities share a context window, the exploratory phase contaminates the generative phase. The model attends to stale search results and intermediate observations that should have been discarded, reducing the effective signal-to-noise ratio at the point of generation.

Role Separation as the Structural Fix

The architectural response is to separate retrieval from generation by introducing a dedicated exploration subagent. Microsoft's FastContext model operationalises this pattern directly. FastContext is a lightweight subagent, available in 4B and 30B parameter variants built on Qwen3 backbones, that is invoked on demand by a main coding agent. It issues parallel read-only tool calls across READ, GLOB, and GREP operations, runs an internal observation-refinement loop, and returns a compact block of file paths and line ranges to the main agent rather than the full exploratory trace. The main agent never sees the navigational work; it receives only the grounded citations needed to begin generation. This separation means the solver's context window starts clean, populated with targeted evidence rather than the accumulated residue of repository traversal 

What the Performance Data Shows

The empirical results from integrating FastContext into Mini-SWE-Agent are worth examining in detail because they quantify both the quality and cost dimensions of the architectural change. With GPT-5.4 as the main agent and FC-4B-RL as the subagent, the SWE-bench Multilingual resolution rate improves from 71.7% to 74.7%, while main-agent token consumption falls from 457k to 338k, a reduction of 26%. On the SWE-QA benchmark, token consumption drops from 418k to 210k, a reduction of approximately 50%, with a marginal quality improvement of 0.7 percentage points. The FC-30B-SFT variant achieves the largest quality gain on SWE-bench Multilingual, reaching 75.0% resolution, at a 22.1% token reduction. Across all configurations tested, the pattern is consistent: subagent-assisted architectures reduce main-agent token consumption by 14% to 60% while improving or maintaining resolution rates, with only marginal overhead from the subagent's own operations. For teams paying frontier model API costs at volume, a 26% to 50% reduction in main-agent token use is a material cost line, not a secondary benefit.

The Loop-Based Model Architecture

A parallel development in model architecture addresses a related inefficiency: the cost of scaling inference-time computation. Standard approaches to improving coding agent performance at test time involve generating more tokens, either through chain-of-thought reasoning or repeated sampling. Parallel Loop Transformers (PLT) offer an alternative by applying shared transformer blocks in repeated passes over the latent representation, increasing effective computational depth without proportionally increasing token generation. LoopCoder-v2, a 7B PLT model trained on 18 trillion tokens, demonstrates that a two-loop configuration improves SWE-bench Verified performance from 43.0 to 64.4 points and Multi-SWE from 14.0 to 31.0 points relative to a non-looped baseline (Yang et al., arxiv 2026). The mechanism is that the second loop provides a productive refinement pass over the latent representation, correcting initial encodings without generating additional output tokens. Critically, variants with three or more loops regress in performance, a non-monotonic effect explained by the cross-loop positional mismatch introduced by the CLP mechanism, which becomes the dominant cost once the marginal refinement gain from additional loops diminishes (Yang et al., arxiv 2026). For teams evaluating model selection for coding agents, this finding has a direct implication: more inference-time computation is not always better, and the optimal configuration requires empirical validation rather than assumption.

Engineering Tradeoffs in Subagent Architectures

Adopting a subagent architecture introduces coordination complexity that teams should account for before committing to the pattern. The main agent must manage subagent invocation, including deciding when to delegate exploration rather than reading directly. If that decision logic is poorly calibrated, the overhead of subagent invocation can exceed the savings from cleaner context, particularly on small or well-structured repositories where a single targeted read would suffice. Latency is also a consideration: the subagent's exploration loop introduces additional round-trips before the main agent can begin generation. In synchronous pipelines, this adds wall-clock time even when it reduces token cost. Teams running latency-sensitive workflows, such as interactive coding assistants, will need to evaluate whether the quality and cost gains justify the added latency, or whether the subagent should be invoked only for tasks above a complexity threshold. Agent identity and permissions also become more complex in multi-agent systems; each subagent needs its own entitlement scope, and audit trails must capture the full call graph rather than a single agent's actions.

Planning the Transition

Teams currently running monolithic coding agents do not need to rebuild their systems immediately, but the architectural direction is clear enough to inform near-term infrastructure decisions. The first practical step is instrumentation: measuring what fraction of current agent token consumption is attributable to exploration versus generation. If that figure approaches the 46% benchmark observed in GPT-5.4 trajectories, the case for role separation is strong. The second step is evaluating whether the task distribution warrants a fine-tuned retrieval subagent or whether a smaller general-purpose model with constrained tool access can perform adequately. FastContext's 4B-RL variant achieves competitive performance with the 30B-SFT variant on most benchmarks, suggesting that retrieval-focused fine-tuning at smaller scale is a more efficient investment than scaling the retrieval model's parameter count. Teams should also consider how subagent outputs are validated before being passed to the solver; a retrieval subagent that returns incorrect file citations does not fail loudly, it silently degrades generation quality, which makes output monitoring a necessary complement to the architecture.