Complexity-aware execution turns agent cost into a control loop (2026)

The paper's central product idea is simple: an agent should make a small, testable first move, then earn more context when the evidence demands it. That is a different control problem from buying a larger context window or setting a permanently low reasoning budget.

The PM takeaway

A fresh paper from Junjie Yin and Xinyu Feng proposes E3, short for Estimate, Execute, Expand. Before an agent searches a repository or calls a large tool set, it estimates the task's execution scope. It then takes the minimum viable path and widens the search only when verification fails. The result is an agent that treats context as a budget to allocate, not a reservoir to fill. 1

For a PM, the decision is where to put the control loop. Put it before model selection and before deep reasoning: first decide what the task needs to inspect, then decide how much intelligence to spend inside that scope.

What changed

The paper calls the default it is attacking "maximum-context-first": read the surrounding files, dependencies, and history before attempting even a small edit. Its example is a two-line icon replacement that gets treated like a codebase audit.

E3 changes the sequence:

Estimate: predict the likely files, tools, and steps needed for the task.
Execute: attempt the smallest path that could satisfy the request.
Expand: add context or search breadth only after a test, tool result, or unresolved dependency shows that the initial scope was wrong.

The distinction from ordinary model routing matters. A router chooses a model, a reasoning mode, or a scalar effort level. E3 predicts a structured scope: what the agent needs to understand before it acts. Its safety mechanism is also different. A bad estimate is recoverable because the verifier can trigger progressive expansion.

On MSE-Bench, a deterministic benchmark of 121 code-edit tasks, E3 reached 100% success with a mean cost of 18.6 in the repository's default cost model. Max-Context-First also reached 100% but cost 122.9; Adaptive Retrieval reached 100% at 22.1. The paper reports the E3 advantage over Max-Context-First as 85% lower cost, 91% fewer tokens, and 92% fewer inspected files, with a further 16% cost reduction against the strong adaptive baseline. 2

Those numbers need a hard boundary around them. MSE-Bench is capability-controlled: no language model makes the edit, so the experiment isolates trajectory cost rather than production accuracy. The authors' companion LLM-Case harness uses a live gpt-4o agent, real vendored code, and pytest grading, but it is a small case study. E3 was the leanest and fastest policy at comparable success; one shortfall came from a provider rate limit, not an incorrect patch. The authors explicitly position larger-model and SWE-bench-style validation as future work. 1

Why PMs should care

The cost problem is also a quality problem. Anthropic's engineering guidance treats context as a finite attention budget and recommends the smallest high-signal set of tokens that can produce the desired behavior. Its practical pattern is just-in-time retrieval: keep lightweight references such as file paths or stored queries, then load the relevant data through tools as the agent works. It also warns that runtime exploration can waste context when tools are ambiguous or poorly designed. 3

That gives E3 a useful product interpretation. The unit being optimized is not just token spend. It is the amount of irrelevant state the agent carries into its next decision, plus the latency and tool calls needed to acquire that state. A simple task that succeeds after inspecting one file should not be charged like a repository migration. A complex task should still be allowed to expand; the product requirement is graceful escalation, not minimality at any cost.

Provider APIs are already exposing part of this idea. Anthropic's February Opus 4.6 release added adaptive thinking and effort controls. Its current documentation says adaptive mode lets Claude decide whether and how much to think based on request complexity, and that lower effort levels may skip thinking on simple tasks. It also supports interleaved thinking between tool calls. That is a useful inner control, but it does not decide which files, tools, or dependencies belong in the first place. 4 5

OpenAI's engineering account of its Codex workflow points to the outer control E3 still needs. The team uses a short AGENTS.md as a map into a structured repository knowledge base, then relies on progressive disclosure, linters, structural tests, and feedback loops. The post's practical lesson is to make the environment legible and the constraints mechanically checkable, rather than placing a giant manual in the prompt. 6

The public attention signal is early, not adoption evidence. An accessible explainer, AI deepdive's Test-Time Compute: How AI Models Think Longer, was published June 30, runs 10:11, and had 12 views when checked. It explains adaptive compute, self-consistency, search, and verifiers, which is useful background for a PM evaluating effort controls, but it does not validate E3's results. 7 On X, verified professor Ulf Pillkahn shared a German summary of E3 on July 18; the captured post showed 22 views and no likes or reposts. That is a reaction signal, not evidence of developer adoption. 8

How to implement now

Start with a reversible agent workflow that already has an acceptance test: code edits, document transformations, or internal research tasks with a known answer. Do not begin with an open-ended assistant where failure is hard to grade.

1. Measure scope before optimizing it

Log the task class, files inspected, tool calls, input and output tokens, wall-clock latency, expansion events, verifier outcome, and failure reason. Add a simple redundancy view alongside success rate:

cost per successful task;
tokens and files per successful task;
percentage of tasks that expand beyond the initial scope;
recovery rate after an expansion;
error rate when the agent does not expand.

The denominator must be successful tasks. A cheap failed run is not an efficiency win.

2. Build a conservative first estimator

Use task and environment signals before adding another model call. A single-file rename, a cross-file change with a known symbol, and a repository-level change should start with different scopes. File paths, dependency edges, test locations, and prior failure patterns can supply the first estimate. Keep the estimator cheap enough that its own cost does not erase the savings.

3. Make expansion an explicit contract

The agent should not widen its search because it feels uncertain. Give it observable triggers: a missing symbol, a failed test, a contradictory tool result, an unresolved dependency, or a confidence threshold tied to a real verifier. Then make the next expansion deterministic enough to audit.

A minimal control loop looks like this:

scope = estimate(task, environment)
result = execute_minimum_path(scope)

while verifier(result) says "insufficient":
    scope = expand(scope, verifier.failure)
    result = execute_next_path(scope)

return result

The important design choice is the verifier. For code, it may be pytest plus static checks. For research, it may be source coverage and contradiction checks. For a consequential action, it must include permission and human-approval gates; cost reduction is not a reason to remove them.

4. Route effort inside the scope

Once the agent knows which information it needs, use provider-level adaptive thinking or model routing to choose how deeply to reason. This keeps two decisions separate: scope routing controls what enters the working set; effort routing controls how much computation is spent on that working set. The paper describes these as complementary, not competing, mechanisms. 1

5. Run a two-week pilot with a stop condition

Compare the current maximum-context workflow against E3 on the same task mix. Keep success, rollback, human escalation, tail latency, and cost visible in one dashboard. Ship the change only if the smaller-first policy preserves success and improves cost without increasing unrecovered failures. If the verifier cannot explain why a task needed expansion, fix the environment or evaluation before tuning the estimator.

The practical bet is modest: make the agent's first move smaller, make failure legible, and let evidence buy the next tool call.

Complexity-aware execution turns agent cost into a control loop