How LLM Agent Scaffolding Fixes Failing Code Review Agents

GitHub gave Copilot code review deeper repository access and a richer set of tools, expecting the upgrade to sharpen its suggestions. The opposite happened. Code review quality regressed enough that the engineering team had to rethink the architecture before shipping further improvements. The lesson, and the reason it matters far beyond one product team, is that production agent quality is decided by scaffolding decisions far more than by the foundation model behind them. LLM agent scaffolding is the discipline of constraining what the model sees, what it can call, and how its outputs get checked. When that discipline is absent, more tools and more context make a capable model measurably worse.

The Counterintuitive Regression in Copilot Code Review

The team published a rare post-mortem about this exact failure mode. After broadening the agent's repository access and expanding its tool surface, the system started surfacing lower-quality suggestions and missing issues it had previously caught. The regression came from giving a competent model too many uncoordinated ways to act, not from a weaker model or a prompting slip.

This is the core finding the broader AI engineering community should internalize. A model that aces benchmarks can still produce worse outputs in production when the surrounding scaffold is under-engineered. The experience, documented in GitHub's engineering post-mortem, frames the problem in terms that translate directly to any agent you are building.

The deeper repository access that triggered the regression also expanded the security surface. Separate research on Copilot's permissions has demonstrated a Copilot security vulnerability where broad access creates exploitable paths. Quality and security are two faces of the same architectural coin: unconstrained access hurts both, and disciplined constraints protect both.

The implication for teams shipping agents is uncomfortable. Upgrading the model, adding more tools, and widening access are all intuitive moves that engineers reach for when quality slips. In an agentic setting, those same moves can be the regression.

Why LLM Agent Scaffolding Matters More Than Model Choice

Code-review agents fail differently from chatbots. The system instructions that define review behavior, what to flag, how to phrase a suggestion, when to stay silent, must hold attention weight throughout a multi-step run. But every tool call and retrieved diff competes for that weight, and as context fills, those instructions lose their grip on the model's decisions. A stronger model with a richer toolset can produce worse reviews than a constrained one. The scaffolding, not the model, controls whether the review instructions survive.

Research on why LLM agents fail identifies the same architectural root causes: wrong tool selected, wrong arguments passed, too many steps chained, or the original objective lost in a growing context. The model often knows what a correct action looks like, but the architecture does not protect it from plausible-but-suboptimal alternatives. The productive question is not which model is smartest but which constraints keep it on track. LLM tool use is an architectural challenge before it is a model capability.

The Mechanics of Tool Proliferation and Action Sprawl

Action sprawl is what happens when an agent has many direct tools and no mechanism to narrow the field before it commits to an action. But the failure runs deeper than a larger menu.

Semantic overlap. When two tools appear to do the same job, the model does not pick the better one. It hesitates, calls both redundantly, or picks arbitrarily based on superficial description matches. In a code-review agent, give it a file-search tool and a grep tool whose descriptions both mention finding code, and it will frequently call both for the same query, burning context on duplicate results before synthesizing anything useful. The model knows what it wants but cannot tell which handle to grab.

Recency bias. Tool definitions are loaded into context in sequence, and models can gravitate toward the most recently described tool when the decision is ambiguous. Add a new tool at the end of the list and watch the agent over-select it for tasks it was never designed for. The ordering of your tool schema may act as a hidden prompt, yet few teams test for positional bias in tool selection.

Description interference. One tool's parameter schema bleeds into another's argument formatting. The model reads a file_path parameter on a search tool and then passes that same formatted argument to a diff tool that expects a different path convention. The schemas are individually correct. This cross-contamination appears to happen at the attention level, where the model carries parameter patterns from one definition into the next call. It is a widely observed behavior in production agents, not a formally characterized mechanism in the literature.

These mechanisms compound. By the time an agent has fifteen or twenty tools with overlapping semantics, it fights interference on every step.

How flat architectures amplify action sprawl

A flat agent architecture exposes every tool to the model at every turn. There is no gating mechanism that says, for this kind of query, only these three tools are relevant. The model carries the full tool inventory in its context window and reasons over all of it on every step.

The failure mode is not dramatic. The agent does not crash or hallucinate openly. It simply makes slightly worse choices more often, and those choices compound across a multi-step workflow. By the time the final output arrives, the quality gap between the flat-architecture agent and a constrained one is large and consistent.

How Context Fragmentation Degrades Agent Quality

Action sprawl is half the problem. Context fragmentation is the other half, and the more insidious because it is invisible.

Picture a code-review agent's token budget before reasoning begins. The system prompt, defining what to flag and how to phrase suggestions, runs roughly eight hundred to twelve hundred tokens. Fifteen to twenty tool definitions, each with a signature, description, and parameter schema, add three to eight thousand more. Retrieved diffs and repository context add ten to thirty thousand depending on PR size. Before the model reasons about a single line, a meaningful slice of a 128k-token window is spent, and it grows with every tool call as outputs flow back in.

Research on context fragmentation suggests that even when a model technically has room, attention quality degrades as context fills with loosely related material. For code review, this means something specific. The system instructions governing review behavior, what constitutes a blocking issue, how to phrase suggestions, get pushed below the model's attention focus as tool outputs and retrieved code accumulate. This differs from chatbot-style fragmentation, where retrieved text is the primary payload the model should attend to. In code review, tool chatter and retrieved code compete with the instructions that define the review itself.

The context budget as a zero-sum resource

Treat the context window as zero-sum. Every token on an irrelevant tool definition is a token the model cannot spend on the code under review. The question is not whether the model can hold everything but whether the most important instructions stay salient after loading. You solve it by deciding, per query, what belongs in the window.

Thinking-mode features add another budget competitor. As thinking mode in agentic workflows shows, reasoning tokens consume budget the agent can no longer spend on retrieved evidence. A code-review agent that burns five thousand tokens on chain-of-thought has that much less diff context to reason over, and suggestions become shallower precisely when the model is reasoning hardest.

Scaffolding Patterns That Restore Agent Quality

The general principle is to constrain the active tool surface per subtask. Instead of one agent holding every tool and deciding what to do at each turn, a coordination layer classifies the request and dispatches it to a focused subtask where only the relevant tools are active. The main context never fills with irrelevant tool definitions because the irrelevant tools are not in scope for that particular call.

Based on the published account, GitHub's resolution appears to center on this kind of rebuild rather than a rollback of repository access. The approach described suggests a disciplined multi-step architecture where the agent a user interacts with is thin, and the heavy lifting happens in bounded subtasks whose context is assembled for that subtask alone and then discarded. The post-mortem does not publish internal architecture diagrams, so the specifics should be read as informed inference from a team that solved the problem publicly, not as a verified blueprint.

The mechanics of why this works are straightforward even if the implementation details are not. A coordination layer reduces the action space the model reasons over at each step to only the tools relevant to the classified subtask. It also protects the context budget, because tool definitions for unrelated subtasks never enter the window. Architectural references for multi-agent system architecture describe this separation as a key scaling approach for complex agentic workloads.

The trade-off GitHub likely weighed is engineering cost against quality recovery. A coordination layer adds a new failure surface, the router itself, and requires an evaluation harness that can measure routing accuracy independently from execution accuracy. That cost is real, but the alternative, a flat architecture where quality drifts silently as tools accumulate, is harder to diagnose and more expensive to fix after users notice.

Comparing flat and routed agent architectures

The architectural shift has three properties worth comparing directly:

Evaluability is what makes the pattern maintainable. When quality slips, you can isolate whether the router misclassified the request or the subtask executed poorly. In a flat architecture, the two failures are tangled together and the regression is much harder to localize.

Implementing Hierarchical Tool Routing

The router is the load-bearing component in this architecture. Its job is to take a raw request, classify its intent, and dispatch it to a subtask that owns a small, relevant toolset.

Two patterns dominate in practice. The first is a classifier router: a small, fast model trained or prompted to map a request to one of a fixed set of subtask types. The second is a learned router, trained with reinforcement learning to optimize routing accuracy over multiple rounds. Multi-round routing research shows that RL-trained routers can outperform static classifiers on tasks where the correct subtask depends on information that only emerges mid-conversation.

The trade-off is engineering cost. A classifier router is cheap to build, easy to debug, and sufficient for most code-review workloads where intent categories are stable. An RL router is more powerful but requires training data, evaluation harnesses, and ongoing maintenance of the routing policy.

LLM tool routing versus direct tool calling

This is the practical fork most teams face. Direct tool calling, where the main model picks among all available tools at every turn, is simpler to build and fine for prototypes. Hierarchical routing, where an intermediate layer narrows the tool space before the main model acts, is what scales.

The rule of thumb from agentic workflow pattern guidance is to start with direct calling when you have fewer than roughly five to eight tools and stable query types, and to move to routing once tool count, query variety, or both start growing. The migration cost is real, but it is far cheaper than diagnosing a slow quality drift after the fact.

A Framework for Diagnosing Your Own Agent Regressions

Most agent regressions look like model problems on the surface. The output got worse, so the model must have gotten worse. That intuition is usually wrong, and acting on it wastes engineering time. Run this five-step diagnostic before you blame the model.

1. Isolate the regression trigger. Pin down exactly what changed. Was a tool added, a context window widened, a system prompt lengthened, a model version swapped? The Copilot regression was triggered by tool expansion. Yours probably has a similar non-model trigger.

2. Measure context occupancy. Instrument your agent to log how full the context window is at each step, and what is filling it. If tool descriptions and retrieved payloads are consuming the majority of the budget by mid-run, you have a fragmentation problem regardless of how good the model is.

3. Test tool selection accuracy in isolation. Take a sample of queries, present the agent with the tool list, and check whether it picks the right tool on the first try. If selection accuracy is below your baseline, action sprawl is the prime suspect.

4. Check for model drift separately. Foundation model providers update models on rolling schedules, and behavior can shift between versions even when the version string stays the same. Guidance on detecting model drift outlines the monitoring patterns that catch silent behavior shifts. Treat drift as a hypothesis to test, not the default explanation.

5. Compare routing versus flat on the same eval set. If you suspect scaffolding is the issue, build a minimal router that narrows the tool set per query and re-run your evaluation suite. If quality recovers, you have confirmed the diagnosis and the fix in one step.

Building the evaluation harness that catches regressions

None of those diagnostics work without a repeatable evaluation set. For code-review agents, that means a curated set of diffs with known issues, run through the agent on every meaningful change. The software-engineering agent evaluation literature has converged on task-based metrics, pass rates on defined issue categories, and human-judged suggestion quality as the signals worth tracking.

The harness is the asset that compounds. Each regression you diagnose sharpens it. Over time, the harness becomes the thing that lets you ship model upgrades and tool additions with confidence, because you have an automated guard that catches regressions before users do.

What This Means for Teams Shipping Agents

The Copilot code review post-mortem is a gift to the AI engineering community because it names a failure mode that most teams discover the hard way. More tools, richer context, and deeper access are not unqualified improvements. In an agentic architecture, they are forces that must be constrained by scaffolding or they will quietly degrade quality until users notice.

The teams that ship reliable agents treat scaffolding as the primary engineering discipline. They budget context, gate tools behind routing, evaluate every change against a regression suite, and treat model intelligence as a fixed input they design around rather than a variable they wait for. That posture is what separates a prototype that demos well from an agent that holds up in production.