Larger context windows do not make agents reliably attentive because models often focus on the beginning and end while dropping the middle.
2
Context optimization methods have different costs: iterative retrieval needs little setup, hierarchical summarization needs ongoing LLM processing, and knowledge graphs require substantial upfront work.
3
An 80/20 agent design gives open-ended discovery to high-reasoning models and sends validation and summarization through more restricted, deterministic steps.
Summary
Nupur Sharma describes how agent systems fail as their context and orchestration become more complicated. Models may accept large inputs while still losing information from the middle, which she calls the U curve. Sharma compares several ways to control context: context engines, hierarchical summaries, knowledge graphs, iterative retrieval, and critic-based self-correction. Each has a different cost in indexing, LLM processing, developer setup, or latency. She also describes the orchestration paradox, where capable models spend tokens deciding which tool or method to use instead of solving the task. Qodo's approach uses an 80/20 split, with flexible models handling discovery and more deterministic models handling validation. Its code review system collects context, sends relevant portions to specialist agents, and uses a judge agent to combine results with PR history and organization-specific guidance. Accepted and rejected suggestions change future weighting.
Large context windows still lose information from the middle
Sharma says current LLMs often attend to the initial and final inputs while effectively removing the material in between. She calls this the U curve: information at the start and end remains influential, while middle context is less likely to affect the result. In Qodo's code review experiments, an agent could receive the whole codebase, Jira information, and other tool outputs, yet still focus on the original goal and the latest input. The problem is therefore not simply whether a model can accept more data. The system must decide which parts deserve attention before sending them to the model.
Context engines rank useful information but become difficult to scale
Sharma compares a context engine to a bouncer that filters a large, messy codebase. It builds search patterns and ranking logic, then selects the material that appears most relevant to a task. Indexing takes moderate effort, but mapping and indexing can slow down when a system covers hundreds of repositories. That can make retrieval unpredictable, especially for teams whose main product is not a context engine. Sharma's point is that a context engine can help, but it is not a free solution to the U curve.
Iterative retrieval trades runtime cost for low developer setup
For teams building agents for their own processes, Sharma says iterative retrieval often works well. It creates an index rather than a full summary, similar to giving an agent a library card for a topic. The agent can then inspect the underlying code when the topic appears relevant. This approach has ongoing cost impacts, but it asks less of developers than building a large context engine or knowledge graph. Sharma presents it as a practical option when a team wants better context without investing heavily in maintaining a more elaborate representation of its codebase.
Different context strategies carry different forms of cost
Hierarchical summarization creates a summary for each file and folder, allowing an agent to inspect summaries before deciding what to read deeply. Its drawback is continuous LLM processing whenever files change. A knowledge graph can capture dependencies across files and repositories, which Sharma says works well for complex logic, but it demands substantial initial developer effort. Self-correction adds a critic node that checks whether an output matches the original goal and asks the agent to retry when it does not. That requires extra latency, while reducing the amount of context design developers must provide up front.
Highly capable models can waste tokens planning how to solve a task
Sharma calls this the orchestration paradox. As models become better at reasoning, they may spend their time considering which tool or method to use, then reconsidering that choice repeatedly. In her example, a model such as the latest Opus can enter research mode and compare one approach with another instead of doing the requested work. The result is token use devoted to finding a method rather than solving the problem. Teams can limit this behavior with counters that stop after several rounds or timeouts that force the system to continue with the latest result.
An 80/20 split separates discovery from validation
Qodo's approach gives high-reasoning models roughly 80 percent of the work for discovery, tool selection, and planning. The remaining 20 percent handles tasks such as validation and summarization, where the desired output can be stated more precisely. Sharma says the latter steps do not need a model to keep researching. A critic node can compare the result with the original goal, while a restricted step can turn research into the format the user needs. This division limits open-ended loops and avoids spending the most expensive reasoning on deterministic decisions.
Specialist agents need a judge to combine their partial results
Using one agent for testing, review, and every other task can overwhelm it, even when the context window is large. Sharma says an agent may do two tasks well and lose the other two somewhere in the middle. A mixture-of-agents design assigns narrow jobs to specialist agents. She illustrates this with separate agents for hotels, locations, and flights, whose results may conflict. A judge agent gathers those outputs and checks whether they make sense together. The judge is responsible for producing a coherent result from work done independently.
Qodo weighs review suggestions against history and developer behavior
In Qodo's code review architecture, a context collector gathers information from pull requests, tools, and the context engine. It sends relevant portions to specialist agents, such as security, code-difference, and Jira agents. A judge agent then reviews their recommendations, checks the pull request context and history, and decides which findings matter. Qodo also indexes whether developers accept or reject suggestions. Accepted suggestions receive more weight in later runs, while rejected suggestions receive less. Compliance guidance and explicit rules can add further weight, so organizational preferences affect the final review.
"This is like a U curve where some of the things from the start, some of the things from the end make sense but whatever you are providing in between that is not taken up."03:06
Who should watch
You are giving an agent a repository or a long collection of documents and its answers seem to ignore material in the middle.
Your workflow lets a powerful model choose tools indefinitely, causing token costs or latency to grow without producing a result.
You are designing multi-agent code review and need a way to divide specialist work, combine conflicting findings, and adapt to reviewer feedback.
