The news. On July 14, 2026, researchers released E3, a study arguing that LLM coding agents routinely over-scope simple tasks — rereading files and dependencies before they know which ones matter. It proposes minimum-sufficient execution and formalizes the waste as the Agent Cognitive Redundancy Ratio. On MSE-Bench (121 deterministic edits), E3 matches the strongest baseline at 100% success while cutting cost 85%, tokens 91%, and inspected files 92%, and it beats a strong adaptive-retrieval baseline by 16%. Read the paper →

Picture a plumber called to fix one dripping joint. A nervous rookie pulls the house blueprints, walks every run of pipe, and opens a wall or two "to be safe" — an hour later they finally tighten the fitting that was leaking all along. An expert glances at the likeliest joint, tightens it, runs the water, and only reaches for the wall saw if it still drips. A coding agent asked to change one line often behaves like the rookie: it reads the whole codebase before it touches anything. Every file it opens is context, and context is a scarce resource — a budget the agent spends whether or not the file turns out to matter.

The trouble is that each extra file looks locally reasonable to pull in, so the waste hides. E3's central claim is that most of what an agent inspects on a simple task is never actually used — dead context it paid for anyway. The paper makes this concrete with the Agent Cognitive Redundancy Ratio: of everything the agent read, how much was irrelevant to the fix. That reframes a vague instinct ("agents use too much context") into a number you can drive down, and it exposes why "just retrieve more" is a false economy — the cost profile of an agent run is usually dominated by the tokens it reads, and on a simple task most of those do no work.

So how do you make the agent behave like the expert plumber? E3 flips the order into three phases: Estimate the smallest scope that could plausibly work, Execute that minimal path, and Expand scope only when a verification check fails. The name is the mechanism — the three E's. The estimate keeps the first attempt tiny; the execute-then-verify step is a cheap test of "did that fix it?"; and expansion is gated on failure, the same judgment as knowing when to retry versus when to stop. Because all of this lives in the harness — the scaffolding around the model, not the model's weights — E3 needs no retraining, so you hand the agent a discipline rather than a new model.

Here is where it earns its keep. Picture one MSE-Bench edit. A strong adaptive-retrieval agent opens roughly 25 files and spends about 120,000 tokens before it's confident enough to write the patch (illustrative base — the paper reports reductions, not per-task absolutes). E3 estimates the fix lives in 2 files, edits them, runs the check, and it passes — so it never expands. It opened 2 files, not 25 (−92%) and spent about 11,000 tokens, not 120,000 (−91%), and since reading tokens is usually most of an agent's bill, the cost dropped alongside them. Starting from the smallest scope that works, E3 reports cutting cost about 85% and tokens 91% on MSE-Bench while still solving 100% of tasks — matching the strongest baseline for a fraction of the context.

StrategyHow it gathers contextRetraining?Tokens / cost vs eager baselineTask success
Read-everything (eager)Loads all files & dependencies before editingNoHighest (most wasted)Not reported
Adaptive retrievalPulls files on demand while reasoningNoLower, still gathers earlyStrong (E3 beats it by ~16%, per the paper)
E3 (Estimate-Execute-Expand)Starts minimal, expands only when a check failsNo−85% cost, −91% tokens (E3 paper)100% (matches best baseline)

Goes deeper in: AI Agents → Context Engineering → Context as Scarce Resource

Related explainers

Frequently Asked Questions

Check what you knowMap your AI & GPU knowledge across every track — free, role-based