Agent Efficiency · Cost-Aware Execution

The task was simple.
The agent didn't know.

Researchers at the University of Tennessee measured how much compute AI coding agents spend on tasks that were never hard. The answer was 80 to 90 percent. Their fix, a three-step framework called E3, classifies difficulty before starting, caps file reads for simple tasks, and only expands scope when verification fails. On a 121-task benchmark, it matched the best baseline's perfect success rate while cutting cost by 85 percent.

Core concept
Agent Cognitive Redundancy: an agent's tendency to apply maximum-effort reading and reasoning to every task regardless of difficulty, spending 5 to 10 times more compute than simple tasks actually require.

First surfaced in Tandemly Briefing — 2026-07-21.

scroll to explore
01The problem

Agents read everything.
Most of it isn't needed.

When you send an AI agent to rename a variable or fix a typo, most current agents start the same way they would approach a full architecture redesign: open files, read context, reason about dependencies, then do the edit.

Agent cost is dominated by tokens. Every file an agent reads, every reasoning step it takes, every tool call it makes adds to the invoice. For a single bounded task, that cost structure is invisible: one task, one bill. But in production, agents handle hundreds of tasks per day across every difficulty level, and the mix matters enormously.

The prior assumption in most agent design is that generous context is always better. If the agent reads more files, it has more information. If it reasons at full depth, it will catch edge cases. The downside, wasted tokens on simple tasks, looked like a theoretical concern rather than a practical one. It turned out to be neither theoretical nor minor.

Researchers at the University of Tennessee, Knoxville measured this directly. They called the phenomenon Agent Cognitive Redundancy: agents routinely run 5 to 10 times more computation than any objective analysis of the task would justify. For simple, well-bounded edits, the agent sweeps the codebase, traces dependencies, and reasons through alternatives before doing something that takes two lines to express. Across their benchmark, 80 to 90 percent of agent compute was going to work the task did not require.

This matters because agent cost scales with task volume, not just task difficulty. Every simple task mistreated as a complex one burns real money. And most production workloads skew toward simple tasks: renaming, small refactors, documentation updates, straightforward bug fixes. The expensive cases are common, not rare.

The question this paper asks

Do agents have any internal signal for how hard a task is before they start? If not, what would it take to give them one, and how much compute could a correct difficulty estimate save?

02The experiment

Estimate. Execute. Expand.

The researchers built E3 around a deceptively simple idea: before the agent reads anything beyond the task description, it should decide whether the task is simple or complex. Everything else follows from that judgment.

E3 is a three-stage framework that restructures the standard agent loop. The key move is placing a cheap classification call at the very front of the process, before any file reads, before any tool calls, before any reasoning over code. That call gates everything that follows.

E
Stage 1: Estimate
The agent receives the task description and produces a difficulty classification: simple or complex. This is a lightweight call over the task text only. No codebase reads. No tool invocations. The estimate gates how much work the subsequent stages are allowed to do.
E
Stage 2: Execute
For tasks rated simple, the agent caps how much it reads. Instead of sweeping the full project, it focuses on the minimum set of files needed to complete the task and does the work. For tasks rated complex, it proceeds with the standard full-context loop.
E
Stage 3: Expand
The agent runs a verification step on the result. If verification passes, the job is done. If it fails, the agent expands scope: it re-reads with a wider lens and treats the task as more complex than initially estimated. The expand step fires only when evidence of failure demands it, not as a precaution.
The key design choice

Expansion is triggered by evidence, not by caution. The default assumption is that the task is simple. The agent only pays for wider context when the minimum-viable path proves insufficient. This inverts the usual agent assumption, which is that wider context is always safer.

The researchers evaluated E3 on MSE-Bench, a benchmark of 121 deterministic code-editing tasks. These are bounded, well-specified edits with clear correct outputs, which makes them a clean test for whether the minimum-viable execution path can match full-effort baselines. They also corroborated the results on a live gpt-4o harness to confirm the savings appeared in real billed compute, not just estimated token counts.

03Findings

Same results.
A fraction of the cost.

E3 matched the strongest baseline's perfect 100% success rate on MSE-Bench while cutting nearly all the compute. The savings were not marginal.

Cost reduction
85%
vs. full-effort baseline
Token reduction
91%
vs. full-effort baseline
Files read reduction
92%
vs. full-effort baseline
Standard agent loop
Maximum effort, every task. The agent reads broadly, reasons at depth, and traces dependencies regardless of how bounded the task is. A variable rename gets the same treatment as an architecture change. Cost accumulates proportionally to task volume, not task complexity.
E3 approach
Minimum effort, unless evidence says otherwise. A cheap difficulty estimate caps what the agent reads on simple tasks. The expand step fires only when verification fails. Simple tasks become cheap. Complex tasks get full attention. Cost scales with actual complexity.
What the 92% files reduction means

If a full-effort baseline reads 100 files to complete a simple task, E3 reads about 8. The information an agent needs for a simple, bounded code edit is almost always contained in a small local neighborhood of the codebase: the target file and its immediate dependencies. The 92 files scanned beyond that neighborhood add latency, cost, and noise without improving the result.

This is the structural insight behind E3: agent task scope and information need are not correlated by default. They have to be made to correlate, and that requires an explicit estimate of how much information the task actually needs.

Live harness corroboration

The MSE-Bench results were corroborated on a live gpt-4o harness. This matters because token-count savings on a benchmark can diverge from real provider billing once caching, retries, and API-boundary effects are counted. The live harness result suggests the savings are not an artifact of how the benchmark is structured. They appear in metered production compute.

What the paper doesn't report

MSE-Bench's 121 tasks are deterministic code edits that skew toward well-specified, bounded changes. Tasks with genuinely ambiguous scope or open-ended requirements could activate the expand step more frequently, which would reduce the savings. The paper does not report how often the expand stage fires on this benchmark, which would directly quantify how often the initial simple-task classification was wrong. That number would matter for practitioners considering deployment on mixed workloads.

04Practical takeaways

What this changes
for builders.

E3 is not a model trick or a prompt technique. It is an architectural intervention at the top of the agent loop. The implications run through agent design, cost instrumentation, and how teams evaluate agent efficiency.

1
For developers running coding or retrieval agents
The core pattern is a pre-execution difficulty estimate followed by a context cap for simple tasks. The classification call is cheap: it looks at the task description only, before any file reads. Even a rough classifier that correctly identifies "obviously simple" tasks produces real savings across production volume. The key metric to track is cost per solved task, not accuracy alone. Accuracy on simple tasks is near-ceiling for most agents; cost is where differentiation lives.
2
For teams evaluating agent efficiency
Most efficiency benchmarks report accuracy. E3's contribution is a reframe: accuracy on simple tasks is not the binding constraint. Compute spent is. If your agent hits 100% on simple tasks whether it reads 10 files or 100, the 100-file version is not performing better. It is performing identically while burning 10 times the budget. Measuring cost per solved task across a difficulty distribution, not just raw accuracy, surfaces this gap.
3
For people building agent frameworks or scaffolding
E3 is an argument for difficulty-first design at the framework level. A standard scaffolding that defaults to maximum context on every request bakes cognitive redundancy into every workload that runs on it. A framework that supports difficulty classification as a first-class routing signal, and exposes configurable context caps per difficulty tier, would let downstream developers implement E3-style behavior without reinventing it per-agent.
4
A note on expand trigger design
The expand step fires when verification fails after minimum-scope execution. How verification is defined is a design decision the paper leaves to the implementer. A loose trigger, one that fires on any uncertainty, eats the savings. A trigger too tight misses cases where the minimum-scope execution produced a plausible-but-wrong result. For coding tasks, passing unit tests is a reasonable verification signal. For other task types, defining the verification criterion precisely before deploying E3 is the work.
5
For business leaders assessing AI tooling costs
Production agent workloads almost always mix simple and complex tasks. If 80 to 90 percent of the compute is going to simple tasks treated as complex, the total spend is 5 to 10 times higher than it needs to be for that portion. Even a coarse difficulty classifier, one that correctly identifies the obvious cases, recaptures most of that gap. The concrete question for any production agent is: what fraction of tasks could be completed with a 90% smaller context, and what does that reduction look like in monthly billed compute?
05Further exploration

Where to go
from here.

Concrete next steps if you want to take this from theory to your own agent stack.

1
Read the paper
Yin, Feng. "Do AI Agents Know When a Task Is Simple? Toward Complexity-Aware Reasoning and Execution." University of Tennessee, Knoxville. arXiv:2607.13034. July 2026.
2
Audit your agent's file-read behavior
Log which files your coding or retrieval agent reads for a sample of 50 to 100 tasks. Sort tasks by outcome. If you find a cluster of simple, successful tasks reading far more files than the edit touched, you have direct evidence of cognitive redundancy in your workload. That cluster is the savings target.
3
Add a pre-execution difficulty classifier
Implement a lightweight call that classifies each incoming task as simple, medium, or complex before the main agent loop starts. Even a prompt-based classifier over the task description, returning a three-label output, produces usable signal. Cap the number of files the agent can read based on the label. Measure cost per solved task before and after.
4
Instrument cost per solved task as a primary metric
Set up logging that records billed tokens or provider cost alongside task outcome for every agent invocation. Aggregate by task type, difficulty band, and date. This gives you the baseline to measure E3-style improvements against, and it surfaces which task categories are driving cost disproportionately.
5
Read the related work on cost-aware agents
E3 is one piece of a broader set of approaches to agent cost reduction. BAGEN approaches the problem from the budget-prediction angle (will this task succeed?). LaTER reduces token spend during reasoning by exploring in latent space. These approaches are complementary: they address different points in the cost structure and can be combined.