When an agent workflow runs up an unsustainable token bill, developers usually pull two levers.
The first lever is swapping the model. You take tasks running on a frontier model and try to force them onto an 8B open-weight model, or you spend weeks attempting to train a prompt router to predict which model can handle each step. The second lever is harness engineering. You rewrite system prompts, enforce structured outputs, add step-by-step reflection rules, and hope the agent stops making redundant tool calls.
Both levers hit diminishing returns quickly. Smaller models drop subtle context and fail multi-step tool sequences, while prompt engineering adds token overhead to every turn.
Almost nobody touches the environment.
We treat the workspace where the agent operates as an immutable surface. We point the agent at a chaotic directory of raw files, give it uncurated terminal access, expose raw OpenAPI schemas with hundreds of parameters, and let it inspect database tables by querying raw catalogs. The agent burns through context windows attempting to orient itself before it writes a single line of useful code.
A paper from researchers at UC Berkeley and UT Austin demonstrates why this default is backward. Titled "EnvOpt: Automated Optimization for Agent Environments" (arXiv:2611.07372, by Mingxuan Li, Huanzhi Mao, Qiuyang Mang, Hanchen Li, Joseph E. Gonzalez, and Alex Dimakis), the study shows that optimizing the stationary environment cuts token costs far more effectively than model swaps or prompt tweaks, without degrading task success.
Stationary environments in production
The paper focuses on what the authors call stationary environments.
In production deployments, agents rarely run in sterile single-turn sandboxes. They operate inside persistent environments shared across hundreds or thousands of tasks. A coding agent repeatedly navigates the same monolithic git repository. A support assistant searches the same corporate Slack workspace and ticketing platform. A data pipeline agent queries the same warehouse schemas.
The underlying artifacts in these environments stay relatively static, yet agents interact with them through raw, unoptimized interfaces.
To measure the impact of restructuring these spaces, the researchers built EnvOpt, a framework that uses an automated research agent to re-architect the environment representation for a given set of tasks. The optimizer restructures stored data, builds helper programs, generates local cheatsheets, and refines tool interfaces, testing changes against task performance without requiring human-labeled reference answers.
The resulting numbers on standard benchmarks challenge the standard playbook for reducing agent costs.
On AutomationBench, optimizing the stationary environment reduced the token cost of Claude Haiku 4.5 by 72.7 percent while raising its pass rate by 14.34 percent.
The optimization also transferred across model families. Deploying the same optimized environment to Claude Opus 5 reduced its operational cost by 68.1 percent with a 1.34 percent accuracy improvement.
When combined with harness optimization, the gains compounded. Stacking the optimized environment on top of Meta-Harness lowered Haiku 4.5 costs by a further 83.4 percent and added 11.17 percent accuracy over Meta-Harness alone. On Data-Eng-Bench, which evaluates agents on complex dbt data engineering tasks, the optimized environment reduced token expenses by 53.44 percent with zero loss in pass rate.
Where the token bill actually comes from
The authors tracked token consumption across input categories, output categories, tool calls, and environment feedback to pinpoint where the savings originated.
The results showed that the bulk of wasted spend does not come from model reasoning or final output generation. The largest token sink sits in environment feedback: the massive blocks of raw text, bloated JSON objects, and verbose error traces returned by exploratory tool calls.
When an agent needs to locate a ticket ID, find a function signature, or verify a schema, it issues exploratory queries. If the environment returns raw, unstructured dumps, the agent's context window inflates instantly. In subsequent turns, the model carries that accumulated noise forward, multiplying costs on every step.
The environment optimizations that produced the largest cost reductions shared a common pattern: they eliminated exploratory loops before the agent triggered them.
The most effective patterns were practical and straightforward:
Pre-parsing messy payloads. On workspace automation tasks, helper scripts converted raw spreadsheets and multi-part emails into clean, plain-text summary blocks containing only the sender, subject, message ID, and relevant body chunks. The agent read clean text directly instead of burning tokens on repeated file-parsing tool invocations.
Static API cheatsheets. Instead of requiring the agent to call discovery tools like
api_searchorapi_fetchto understand endpoint parameters, the optimizer generated local text reference sheets for common Jira, Slack, and accounting actions. Having exact command structures available eliminated multi-turn trial calls.Filesystem index maps. In large file trees simulating enterprise workspaces, the optimizer compiled a single flat index file listing file paths, sizes, and file categories. The target agent could run a single grep command against the index instead of recursing through directories with
findorls.Local SQLite metadata caches. On data engineering benchmarks, the optimizer built an SQLite database indexing table definitions, upstream dependencies, and write destinations. Rather than reading dozens of dbt SQL models to trace lineage, the agent ran a single targeted SQL query.
The optimizations that failed
The paper also documents environment optimizations that failed during evaluation, and these failures offer useful warnings for production builders.
The first failure mode was the mega-file trap. In data engineering tasks, the research agent attempted to build a comprehensive reference file listing every possible value for every column across the database. The intention was to give the agent complete context in one place.
Instead, the massive file encouraged the target agent to make additional tool calls. Seeing a huge catalog of potential values caused the model to launch speculative exploration runs, ultimately increasing total token spend.
The second failure mode was imprecise search helpers. The optimizer built a custom search tool to help agents locate workspace documents. While the tool successfully identified relevant files, its ranking was too broad and included several adjacent files. Seeing those extra matches prompted the agent to read each one, driving up token consumption and execution time.
The third failure mode was rigid verification scripts. In repository debugging tasks, the optimizer introduced validation checks that rejected specific code patterns. While this saved time on early training tasks, it caused the agent to reject valid alternative patches on unseen problems, forcing it into costly recovery loops.
Engineering the workspace
The takeaway for software engineers building production agent workflows is clear.
When an agent gets expensive or unreliable, jumping immediately to fine-tuning or prompt rewrites is often the wrong first step. Look at the workspace you hand the agent. If the model has to run four shell commands just to discover which files matter, or parse a 400-line JSON payload to find two IDs, the environment is leaking tokens.
Structuring the environment with plain-text indexes, lightweight local SQLite caches, and clean CLI cheatsheets gives smaller models the footing they need to succeed at a fraction of the operating cost.
Top comments (4)
"Stationary" is doing a lot of work here. A cheatsheet is basically a cache of the repo, and a repo with 30 commits a day isn't stationary. A stale cheatsheet is worse than raw files, because the agent trusts it and stops looking. Did the paper check how fast the savings fade once the repo drifts?
The paper did not evaluate drift across commits. They benchmarked against static evaluation snapshots, so the environment was genuinely frozen during their test runs.
In an active codebase with high commit velocity, a manual summary rots immediately. The practical way to keep the savings without the hallucination risk is generating the orientation sheet via AST parsing during CI, scoped strictly to public module exports and entry points. If a commit changes exports, the artifact rebuilds. If it only touches internals, the interface map stays valid and the agent avoids grepping through forty files.
This matches what I've seen — swapping models barely moved the needle compared to cleaning up what the agent can see. Curating the tool list and giving it a short schema note instead of raw catalog dumps cut orientation tokens a lot. Do you keep those environment packs versioned next to the agent config?
Yes, tracked in git in the same repo as the task definitions. We treat the environment pack like a lockfile. Tool definitions, schema notes, and sandbox flags live under an env/ directory with an explicit hash. When a tool signature updates or a schema note gets edited, the agent config points to the new commit hash only after passing the local eval runner. That keeps runs reproducible when debugging failures weeks later.