Why More Context Makes Your Agent Dumber and What to Do About It

When a pipeline crashes, you can inspect the failure and fix it. What do you fix when an agent keeps searching, changes its interpretation, or produces an answer that misses the task? Nupur Sharma approaches that question from DevSecOps and her work on agentic code reviews at Qodo: moving from deterministic pipelines to agents changes both the failure modes and the engineering needed to contain them.

Early static prompts made the input-selection problem obvious. With a 4K context window, developers had to decide what mattered before asking the model to act. A poor selection meant a poor answer. Larger windows made more inputs possible, and tool-equipped agents could search documents, act, then search again. But that introduced a different problem: without a stopping criterion, the agent could keep requesting more information instead of completing the task.

Adding agents expands the available expertise but also the coordination burden. A security agent looks for vulnerabilities, a review agent evaluates code, and a coding agent proposes fixes. Their interpretations can clash. More context, tools, and agents increase capability without automatically producing a coherent result.

A model may accept a large input without using every part equally well. Sharma describes a U-shaped pattern: the initial instructions and final inputs remain prominent, while information in the middle receives less reliable attention. The practical concern is neglected evidence, not literal deletion of tokens from the context window.

An audience member asks how she knows. Sharma points to internal code-review benchmarking: task-specific agents receive context, including experiments with an entire codebase, and the team checks whether that context affects the result. She reports that the initial goal and final input remain salient while intermediate material—such as Jira information and context available through MCPs—can be overlooked. The talk provides no named models, evaluation protocol, or quantitative results for that comparison.

Context selection remains an engineering responsibility even when context capacity stops being the immediate constraint. Instead of giving the model everything and expecting it to discover what matters, build a process that selects useful evidence for the task.

A context engine acts as a gatekeeper. For a large, messy codebase, it builds search and ranking logic so that a task retrieves material judged relevant before the model starts working. Sharma characterizes the initial indexing effort as moderate but reports mapping and indexing slowdowns when dealing with 600–700 repositories. She gives no repository sizes or latency measurements, so this is an operational warning rather than a fixed scaling limit. Maintaining that infrastructure may be disproportionate for a team whose main product is not the context engine itself.

Two alternatives make the codebase navigable through different structures:

• Hierarchical summarization: Create summaries for files and folders, then let an agent use those summaries to decide where to inspect the underlying code. The expense is both initial and ongoing: new or changed files require fresh LLM processing and updated mappings.
• Knowledge graphs: Represent dependency chains, such as one file affecting another that affects a third. A graph database is especially useful for complex logic and dependencies spanning repositories, but requires substantial developer setup and hosting.

The distinction is what the agent needs to navigate: descriptions of content, or explicit relationships between pieces of the system.

For teams building agents for their own processes, Sharma favors iterative retrieval as a lower-setup starting point. Give the agent a topic index—a library card—rather than a full summary of everything. It checks whether a topic is relevant, then retrieves the associated code for deeper inspection. Retrieval still costs money, but developers do not have to construct as much infrastructure upfront.

A critic node addresses a different failure: the agent has produced something, but it has drifted from the original goal. The critic compares the output with that goal and can request another attempt. This requires relatively little initial developer input, but repeated runs add latency.

Context selection does not solve the orchestration paradox: an increasingly capable model can spend its effort deciding how to solve a problem instead of solving it. It selects a tool, questions that choice, researches another method, and repeats. Tokens go into method selection while the task remains unfinished. Sharma uses the then-current Opus, without specifying a version, as an example of this repeated self-challenging behavior.

Her team's response is an 80/20 hybrid approach: allow broad exploration for the research portion, then constrain final validation and summarization. The percentages express a design heuristic, not a measured optimum. The final stage has prescribed behavior: given a particular result, produce the required output rather than reopening the entire search for a method.

The exploratory portion still needs a boundary. Sharma gives two organizational examples:

• Iteration limit: After four or five cycles, proceed with the latest result.
• Time limit: After five minutes, proceed with the latest tool choice or decision, then revisit it if the resulting output is poor.

These limits force a transition from exploration to execution; they do not establish that the latest answer is correct.

The research model decides what to investigate. The finalization stage turns the collected material into the requested result. Sharma argues that this second stage need not use the most capable reasoning model because its instructions are narrower. The workflow can enforce hard gates, but a lighter model's judgment is not thereby guaranteed to be deterministic.

The same division applies between individual actions. Deciding what to investigate next belongs to the exploratory side. Once the results are available, deciding how to assemble the user's requested output belongs to the constrained side. Separating those responsibilities prevents every synthesis step from becoming another open-ended research task.

A large context window also tempts teams to give one agent every responsibility. Testing and reviewing code may use overlapping material, but they remain distinct tasks. Sharma illustrates the risk with an agent assigned four tasks that delivers strong results for two while losing the other two along the way. A mixture of agents instead assigns small issue experts a specific job.

Specialization creates a reconciliation problem. Imagine separate agents finding the best hotel, destination, and flights for a vacation. One returns a hotel in Greece; another returns a flight from Amsterdam to Portugal. Each recommendation may look plausible in isolation, but together they do not describe a usable trip.

A judge agent receives the specialist outputs and checks whether they make sense together. Its job goes beyond collecting answers: it must turn local recommendations into one coherent result. The specialists supply depth; the judge supplies a shared decision about what belongs in the final answer.

Qodo applies this pattern to pull-request reviews. The pipeline separates gathering evidence from producing findings:

1. Collect context. A context collector gathers material from the PR, the context engine, and available tools.
2. Partition the evidence. Rather than immediately generating a review, it distributes selected material to specialist agents.
3. Produce candidate findings. Specialists investigate concerns such as security flaws, code differences, and Jira issues.
4. Judge relevance. The judge examines the returned findings and can revisit the context engine and the PR before deciding which belong in the review.

In Sharma's example, ten candidate findings are inputs to this refinement process, not ten comments that must all reach the developer.

The first implementation question is how those agents communicate. Does the system exchange files, or use proprietary machinery? Sharma identifies LangChain as underlying infrastructure. The handoff she describes is straightforward: collect an agent's results and use them to construct the next agent's prompt. When several outputs need combining, another agent can collect and refine them before the next handoff. The linked documentation describes current subagent patterns; the talk does not identify a particular LangChain API or version.

A small Python prompt builder makes that handoff concrete. It retains the review goal, associates each finding with its specialist, and asks the next agent to evaluate the combined candidates. It constructs a prompt; it does not itself decide which findings are valid.

import json


def build_judge_prompt(goal: str, results: dict[str, list[str]]) -> str:
    candidates = [
        {"specialist": specialist, "finding": finding}
        for specialist, findings in results.items()
        for finding in findings
    ]
    return (
        f"Review goal: {goal}\n\n"
        "Evaluate the candidate findings together. "
        "Keep findings relevant to the goal and identify conflicts.\n\n"
        f"Candidate findings:\n{json.dumps(candidates, indent=2)}"
    )


prompt = build_judge_prompt(
    "Review the pull request for relevant security and code issues.",
    {
        "security": ["A changed file contains a hardcoded API key."],
        "code-review": ["The change follows an existing repository pattern."],
    },
)

The meaningful boundary is the conversion from separate outputs into an explicit next task. Merely concatenating results does not perform the judge's reconciliation.

A second question concerns calibration: how does an agent learn what counts as a good or bad review finding? The same Java framework can serve healthcare, retail, and finance organizations with different priorities. Framework knowledge alone does not tell the agent what matters to a particular team.

Sharma describes indexing PR history and retrieving earlier changes similar to the current submission. That history enters the workflow twice: first when specialists receive their context, and again when the judge evaluates their recommendations. If specialists return fifteen recommendations, the judge can consult previous reviewer and developer comments to decide which are worth presenting.

This calibration applies to every agent, but it does not mean every agent receives the same complete history. The context engine selects the subset relevant to each specialist's task. Shared organizational knowledge and identical agent prompts are different things.

The audience pushes on the cost of that separation. A code-quality agent and a framework-specific reviewer may each operate correctly on their own inputs without seeing the full architectural picture. Checking linting or the presence of tests is relatively local. Architectural decisions require weighing concerns, including security, against one another. Where does that broader judgment happen?

Sharma answers through the structure of human reviews. A senior engineer knows the codebase and its packages. A security expert checks for issues such as hardcoded API keys and SQL injection. An auditor concerned with ISO or SOC 2 compliance may ask whether changes are logged. These reviewers contribute specialized knowledge rather than duplicating one another's entire perspective.

The agent equivalent needs explicit organizational inputs. Sharma describes a web portal where architects and compliance staff supply guidelines that agents can check. The context collector holds the broader collected picture, then routes relevant portions to specialists. This makes the selection step consequential: an agent cannot validate a requirement that never reaches its context.

Supplying those documents is not universally required. Organizations can use the system out of the box, but without guidance they should not expect findings specific to their working practices unless relevant PR history is available. When an audience member questions whether history is the best source, Sharma qualifies it as one source among several. Past reviews can supply evidence about a team; they are not a complete specification of how that team should work.

The remaining question is how to balance new engineering principles against historical behavior. Sharma describes several weighting signals: the importance assigned in the compliance portal, whether an item is an error or a recommendation, and whether developers accept the resulting suggestions. Accepted suggestions gain weight; unaccepted suggestions lose weight. The talk identifies these signals but does not provide a numerical formula or a complete procedure for resolving conflicts between them.

Two sources of behavioral evidence feed that process: acceptance of current recommendations, and whether similar findings in past PRs were actually implemented. But those signals can encode bad habits. Sharma recalls arguing with a developer accustomed to hardcoding API keys: an established practice does not make the practice safe.

The audience makes the objection explicit: historical behavior does not establish correctness. Sharma's final distinction is between explicit rules and feedback-sensitive bug findings. If an organization supplies a rule, violations remain highlighted regardless of whether developers want that feedback. For a bug finding, repeated reviewer disagreement and non-implementation may reduce its weight; her example of ten rejections illustrates that behavior rather than specifying a product threshold.

That boundary determines what adaptation is allowed to change. Developer feedback can influence which bug findings receive attention, while explicit rules remain obligations. A review system needs both forms of knowledge: evidence about what the team tends to accept, and requirements that acceptance history must not erase.