Agent Training's Real Bottleneck Is Environments, and Terminal-Universe Says They Are Hiding in Your Traces
Two arXiv papers posted fifteen minutes apart on September 3 make the same argument from opposite directions, and one of them shows how to rebuild an executable workspace out of tool-call history you are probably already keeping
Terminal-Bench 2.1, the benchmark both of those papers measure against, shipped as a revision that fixed 28 of its 89 tasks. Not 28 wrong answers. Twenty-eight broken environments. The maintainers grouped the failures three ways: external dependencies that changed after the benchmark was built, resource budgets too tight for a valid solution to finish, and tasks where the written instruction did not match what the tests checked.
Sit with that ratio for a second. Nearly a third of a well-funded, widely cited agent benchmark rotted, and it rotted not in the questions but in the containers the questions run inside. That is the whole story of agent training right now compressed into one changelog. Building a task is easy. Building a machine where the task is actually doable, verifiable, and still doable next month is the hard part, and almost nobody has enough of them.
On September 3, two research groups published within fifteen minutes of each other saying exactly that.
The claim: a trajectory is a single frozen demonstration
Here is the sentence from Terminal-Universe that reframed the problem for me. The Qwen team writes that environments "are what agent post-training actually requires: each can be re-queried into many verifiable tasks and provides execution feedback, whereas a trajectory is a single frozen demonstration."
That distinction is worth more than it sounds. The industry has spent two years treating agent trajectories as the training asset. Collect the traces, filter for successful runs, fine-tune on the good ones. It works, sort of, in the way imitation learning always works: the model learns to produce text that looks like a competent agent's text.
But a trajectory cannot tell you whether a different action would have worked. It has no execution feedback because there is nothing left to execute. You cannot re-query it, cannot branch it, cannot use it for reinforcement learning in any meaningful sense because there is no environment left to reward against. One trace, one lesson, permanently.
An environment is the opposite. Give a model a working container with a real codebase and a real test suite, and you can generate a hundred tasks from it, run a thousand rollouts, and score every one of them against ground truth that actually executes. That is why RL on agents has been bottlenecked: not on compute, not on algorithms, on the supply of containers.
And containers are expensive. You have to pin dependencies, choose resource budgets, write tests that match the instruction, and then maintain all of it as the outside world moves. Ask the Terminal-Bench maintainers.
The mechanism: run the file operations backward
Terminal-Universe's move is the kind of idea that sounds obvious once you have heard it and did not occur to anyone for two years.
When a terminal agent works, it leaves a tool-execution history. Every cat, every sed, every pytest, every file it wrote. That history is not just a record of what the agent did. It is a partial description of the machine it was standing on. If you know the agent ran cat src/parser.py and got back 200 lines, you now have src/parser.py as it existed before the agent touched anything.
So Terminal-Universe replays the recorded file operations in reverse. Every file the agent modified gets restored to its pre-modification state, which yields a partial workspace: the files the agent happened to touch, and nothing else. A completion agent then fills in what is missing, the dependencies and the untouched files that the workspace needs to actually run.
Now you have an executable environment. From there the framework does two things. It reconstructs the original task the agent was trying to solve, and it synthesizes entirely new ones. Then it scales along two axes. Breadth means mining directional dependency relations between related environments and synthesizing queries that span several codebases at once, which is what real development looks like. Depth means extending a single-turn query into a multi-round session where a user agent supplies iterative feedback and shifting requirements.
Run that over public terminal-agent trajectories and you get 37.3k task-sufficient environments. Supervised fine-tuning of Qwen3.5-27B on that corpus moved Terminal-Bench 2.1 single-round performance by 11.9 points and EvoCode-Bench v2 MT@4 multi-round performance by 13.8 points.
The other half: environments have to keep getting harder
Fifteen minutes before Terminal-Universe went up, twelve authors posted Environment Evolution for Terminal Agents. No author overlap with the Qwen paper. Hugging Face's Daily Papers lists it under Tencent Hunyuan, though the arXiv page itself carries no affiliation line, so treat the attribution as the listing's rather than the paper's.
Their problem starts where Terminal-Universe's ends. Suppose you can manufacture environments now. Those environments were synthesized against some assumption about model capability, and the model you are training is getting better every step. Environments built from scratch stop providing learning signal the moment the model outgrows them.
The obvious fix is co-evolution: watch where the model fails during rollouts, synthesize harder environments targeting those failures. The paper's objection is that on-policy dependency generalizes poorly and dries up as the model strengthens. Their alternative raises environment difficulty off-policy, deriving three evolution directions from the multi-turn learning objective and scheduling evolved generations through training so signal keeps arriving.
They validated that the evolved environments were genuinely harder by running rollouts with Hy4 preview, Claude Opus 5, and GPT-5.6 Sol. Then long-horizon RL on Qwen3.6-27B and Qwen3.6-35B-A3B moved Terminal-Bench 2.1 by 14.4 and 18.0 percentage points.
Two groups. One benchmark. One week. No shared authors. Same conclusion: the environment is the constraint.
Put this into practice
You are probably not training a 27B model this quarter. The useful part of this research is not the training recipe, it is the reframing, and the reframing has a cheap first step.
Go look at what your traces contain. If you run agents in production, you almost certainly log tool calls. Open one trace and read it as a description of a machine rather than a description of a task. Which files did the agent read? What did the reads return? What did the test runner say? That is a filesystem snapshot with holes in it.
Reconstruct one environment by hand. Pick a single trace where an agent did something you care about. Make an empty directory. For every file the agent read, write the content it saw. For every command it ran, note the output. Then try to make the test it ran actually pass. You will hit the gap immediately: the files nobody touched. That gap is exactly what Terminal-Universe's completion agent fills, and doing it manually once tells you how big your gap is, which tells you whether the automated version is worth building on your data.
Turn the environment into three tasks. Once the container runs, the original task is one of many. Change the requirement. Break something else and ask for a fix. Ask for the same outcome with a constraint the original run did not have. This is the re-querying property, and it is the entire reason environments beat trajectories. If you can only get one task out of your reconstructed workspace, the reconstruction was too shallow.
Then use it as an eval, not a training set. This is the highest-value move for most teams and the one people skip. You do not need to fine-tune anything to benefit. An eval harness built from your own production traces tests your agent on your actual work, with your actual dependencies, against ground truth you already know. That is a better signal than any public benchmark and nobody else can build it.
Start retaining tool-call history if you are not. Most teams keep the final response and drop the intermediate calls to save storage. Under this framing that is throwing away the asset and keeping the receipt.
Honest limitations
I want to be specific about where this is soft, because the direction is more solid than the numbers.
Both papers are v1 preprints with no venue. Neither has been peer reviewed. Terminal-Universe carries the standard arXiv license; Environment Evolution is CC BY 4.0.
Both train and evaluate inside the same lineage. This is the one that should slow you down. Both papers generate environments with their own pipeline and then measure improvement on Terminal-Bench 2.1. When your training environments and your evaluation environments share a synthesis heritage, "harder environments raise the score" has to be defended against the plainer explanation, which is that the model learned the shape of the generator. Neither paper closes that door to my satisfaction.
The gains are self-reported on the authors' own model families. Terminal-Universe fine-tuned Qwen3.5-27B; the Qwen team wrote the paper. Environment Evolution trained Qwen3.6-27B and Qwen3.6-35B-A3B. No independent reproduction exists on either as of this writing.
Reconstruction is lossy, and the paper says so implicitly. Terminal-Universe recovers a partial workspace and hands the rest to a completion agent. Whatever that agent invents is not the original environment. For a task where the bug lived in a file the agent never read, the reconstruction will not contain the bug.
Trace data carries whatever your agents touched. If your agents read customer records, config with secrets, or internal source you cannot redistribute, then environments reconstructed from those traces inherit all of it. Reversing file operations to rebuild a workspace is, mechanically, a very effective way to reconstitute data you thought you had left behind in a log.
One methodological caution on numbers. Terminal-Universe reports SFT results only. Environment Evolution reports RL results. They are not comparable to each other, and stacking "+11.9 and +14.4" into a combined story about progress would be wrong.
What I would actually do with this
The claim I am confident in is narrow and I think it holds: the marginal value of one more trajectory is small, and the marginal value of one more environment is large, and most teams are collecting the former while starving for the latter.
You do not have to believe the benchmark numbers to act on that. Go open a trace. Read it as a machine instead of a story. If you can rebuild even a rough version of the workspace that agent was standing in, you have something more useful than the trace ever was, and you built it out of data you were already paying to store.
The papers will get reproduced or they will not. The reframing does not depend on it.
Sources: Terminal-Universe, arXiv 2609.04148 · Environment Evolution for Terminal Agents, arXiv 2609.04128 · Terminal-Bench 2.1 · Hugging Face Daily Papers
Medium metadata
Title: Agent Training's Real Bottleneck Is Environments, and Terminal-Universe Says They Are Hiding in Your Traces
Subtitle: Two arXiv papers posted fifteen minutes apart on September 3 make the same argument from opposite directions, and one of them shows how to rebuild an executable workspace out of tool-call history you are probably already keeping
Tags: AI Agents, Machine Learning, Reinforcement Learning, LLM, Software Engineering
Suggested kicker: Reconstruct one environment from one trace this week. That is the whole assignment.