The bottleneck in agent post-training is rarely a shortage of demonstrations — teams have logged millions of them. It’s executable environments. A trajectory is one frozen run; an environment can be re-queried into many verifiable tasks with real execution feedback. Terminal-Universe makes a sharp observation: the tool-execution history in a trajectory already exposes the structure of the environment it ran in, so you can reconstruct the workspace by replaying file operations back to their pre-edit state and letting a completion agent fill in the missing files and dependencies.

What lifts this above log-replay is how it scales along breadth and depth. Breadth mines dependency relations across reconstructed workspaces to synthesize cross-codebase queries — the messy multi-repo work real development actually looks like. Depth turns a single-turn task into a multi-round session with a user agent supplying feedback and shifting requirements. That second axis is the one I care about: single-turn benchmarks flatter agents, and the reported multi-round gain — EvoCode-Bench v2 MT@4 up 13.8 points after fine-tuning Qwen3.5-27B on 37.3k reconstructed environments — is the number that maps to how agents actually get used.

The uncomfortable implication is a data flywheel. Every trajectory your agents produce is latent training infrastructure, not just a log to grep when something breaks. That collapses the wall between observability and environment generation: the same execution traces you keep for debugging become the substrate you post-train on. The HF paper page has the code and discussion. If an agent’s own history can rebuild the environments it needs to improve, how long before the logs you’re archiving are the most valuable dataset you own?

tags: [ agentic-ai ] [ llm-ops ] [ research ]