Training agents for specific tasks such as coding or web navigation requires environments where they can safely practice, fail, and improve. But building these environments is expensive, and once they are created, they typically remain static even as the agent gets better.
Researchers from Google Cloud AI Research and academic partners have developed an open source (Apache 2.0 licensed) framework that turns these static environments into ones that can adapt to the weaknesses of the agent using them.
The framework, called EnvHarness, puts a programmable layer around an existing environment. It can change where an agent starts, what it sees, which actions it can take and how long a task lasts, while leaving the underlying environment and its verifier intact.
Across five benchmarks covering software engineering, web navigation, office work and embodied tasks, agents learning from EnvHarness environments improved by up to 9 points on held-out tasks. On software engineering benchmarks, they also accomplished tasks in fewer steps than agents learning from the original environments.
For enterprise AI teams, the approach presents an alternative to continuously building new simulators and training tasks from scratch: start with a trusted environment and dynamically reshape it around the agent’s current weaknesses.
Why static training environments become a bottleneck
Agents learn by interacting with environments. For a coding agent, the environment might contain a repository, shell and test suite. A browser agent might work against a website. An enterprise automation agent could operate inside a sandboxed version of an internal application.
The environment presents the task, maintains its state, responds to the agent’s actions and determines whether it succeeded. Building all of that takes engineering work, especially when the environment needs a reliable verifier that can tell whether the agent completed the task correctly.
The problem is that most environments remain fixed after they are built. They do not change based on the agent using them. If an agent repeatedly fails because it does not inspect a test before editing code, the environment does not automatically create situations that force it to practice that skill. And once the agent learns the existing tasks, the simulator becomes far less useful, and less likely to improve the agent further.
This also makes useful edge cases harder to find as the agent improves. “As the agent improves, truly challenging environments can become extremely rare within that fixed space, so teams have to sample exponentially more environments to find meaningful edge cases,” Zifeng Wang, Research Scientist at Google and co-author of the paper, told VentureBeat.
One solution to this problem is to generate more environments using AI.
For example, GenEnv is a framework that uses an LLM as a simulator that generates transitions, observations and success signals while trying to keep tasks near the limit of the agent’s abilities. Another technique is Agent-World, which programmatically synthesizes executable tools, databases and tasks to build new environments.
But generating the environment creates its own problems. These pipelines tend to be tied to specific domains, and generated environments need to be checked for correctness. An LLM acting as a simulator can produce incorrect transitions or drifting feedback signals. Meanwhile, executable environments synthesized from scratch can contain logic errors.
Generating more environments also does not necessarily solve the adaptation problem. Wang argues that if those environments still come from a fixed distribution, teams can end up replacing one static pool with another. As the agent improves, the useful training examples again become harder to find.
How EnvHarness makes an environment programmable
EnvHarness takes a different approach. Instead of generating new environments, it changes how an existing one is presented to the agent.
The researchers draw an analogy with the agent harness, the software layer that surrounds an LLM with tools, memory, context management and execution loops.
In simple terms:
Agent = model + agent harness
EnvHarness applies the same idea to the other end of the interaction:
Customized environment = static environment + EnvHarness
The agent continues to interact through the same interface as before. EnvHarness sits between the agent and environment and reshapes the training experience without modifying the simulator itself.
The framework provides three components.
A Stage changes the environment’s starting state. For instance, one of the tasks in the ALFWorld benchmark requires the agent to put a clean mug on a desk. The mug normally starts in plain sight. A Stage can first place it inside a closed drawer, which forces the agent to search before it can complete the task. A Stage can also do the opposite and complete an early part of the task in advance, letting training focus on a later step.
A Contract changes the interaction itself. It can filter actions, modify responses or control what the agent sees. In the same task, a Contract can change the room description and remove some of the details so the agent has to gather information over several steps, or remove navigation shortcuts so it has to search room by room.
A Chain joins tasks together. For example, after putting the mug on the desk, the agent might be asked to heat a potato and place it on the countertop. Success now requires completing both tasks, creating a longer trajectory in which the agent has to preserve its goals and budget its actions.
The other part of the framework, EnvRigger, automates the process of deciding how EnvHarness should modify the environment based on the agent’s weaknesses.
EnvRigger follows an “Observe → Diagnose → Write → Validate” loop. First, it runs the agent several times and examines its successful and failed trajectories for recurring failure patterns. Based on the findings, it composes EnvHarness components designed to expose or correct the failures, and runs fresh trajectories to check whether its changes create a useful and solvable training example.
Wang gives the example of a coding agent that takes a shortcut and submits a patch without first running the tests. “When the system spots an agent taking a sloppy shortcut, like submitting a code patch without running any tests, it automatically creates a plugin rule to intercept that premature submission and return a warning, forcing the agent to properly run the test suite first,” he said.
The important detail is that the plugin changes the conditions under which the agent operates, not the underlying task or its grader.
In this example, the source repository and human-written unit tests remain untouched. The Contract blocks the premature submission from the outside, but the original tests still determine whether the patch is correct. This preserves the trusted verifier while giving the agent a new behavior to practice.
EnvRigger also validates its changes before keeping them. In the paper’s experiments, the basic cycle starts with five rollouts of the original task and five fresh rollouts of a candidate modification. If the candidate makes the task unsolvable, too easy or otherwise fails to produce a useful signal, EnvRigger can revise it and run more validation rounds, up to five write-and-validate iterations.
EnvHarness in action
The researchers tested EnvHarness on ALFWorld, WebArena, SWE-bench Verified, OfficeQA and SpreadsheetBench.
In the main experiments, they collected trajectories from the environments and extracted reusable skills from them. Skills learned from EnvHarness environments outperformed those learned from the unchanged environments across all five benchmarks.
On SWE-bench Verified, in addition to the increased accuracy, training with EnvHarness resulted in the average trajectory shortening from 55.01 to 49.61 steps.
EnvHarness also compared favorably with systems built specifically to generate training environments. On SWE-bench Verified, it exceeded SWE-smith by 2.46 percentage points while requiring 5.11 fewer steps per episode. On ALFWorld, it outperformed GenEnv by 5.7 points on average.
The more interesting result appears when the researchers repeatedly run the adaptation loop. Each new EnvHarness batch is designed against the agent after it has learned from the previous batches. For example, in the coding environment, early rounds expose basic problems such as running tests and editing files. Later rounds encounter different weaknesses, including broken test runners, resource limits and resolving the correct Python interpreter.
The paper’s scaling experiments show the effect of this adaptation. On SWE-bench Verified, the base agent started at 47.67% and reached 54.79% as the EnvHarness training pool grew to 300 environments. Learning from the same number of original environments reached 52.13%, while SWE-smith-generated environments reached 50.37%. The original and generated environment curves flattened earlier, while EnvHarness continued creating training environments around the agent’s latest capabilities.
The same principle transfers beyond coding. In WebArena, the researchers specified a weakness in which an agent would answer without scrolling and miss information below the fold. EnvHarness created a Contract that prevented retrieval actions until the agent had scrolled, producing trajectories that taught the agent to inspect the full page before answering.
What enterprises need to use EnvHarness
EnvHarness does not train the agent itself. It creates experiences that another learning mechanism has to consume.
In the paper’s main experiments, the researchers use a ReasoningBank-style pipeline to turn trajectories into reusable skills. An enterprise deployment would similarly need to pair EnvHarness with skill or memory extraction, fine-tuning, reinforcement learning, or another mechanism that changes the agent based on its experience.
This also makes EnvHarness complementary to the growing class of frameworks that automatically modify the agent harness, such as Self-Harness, HarnessX, and DarwinX.
Those techniques change the agent side of the interaction by improving its rules, workflows, skills or other scaffolding. EnvHarness changes the conditions the agent learns under. “Agent-side optimization cannot happen in a vacuum—an agent’s internal planning, reflection, and decision-making are shaped by its interactions with the outside world,” Wang said. Dynamic environmental constraints can force an improved harness to confront behaviors it might otherwise avoid or solve through brittle shortcuts.
While the researchers did not test EnvHarness together with the self-evolving agent frameworks, the approaches act on different parts of the stack and could in principle form a feedback loop: EnvHarness exposes a weakness, an agent-side system improves the harness, and EnvHarness then creates new challenges around the updated agent.
There are two main implementation costs. The first is integrating an existing environment with EnvHarness. Teams need to write a Bridge that exposes the environment through the framework’s common ActionableEnv interface. The paper already includes Bridges for several types of runtimes, including Docker-based SWE-bench, OfficeQA and SpreadsheetBench environments.
For containerized software workflows, Wang says the integration can sit outside the environment itself. “Enterprise CI/CD pipelines usually run environments inside isolated Docker or Kubernetes containers, and EnvHarness simply attaches as a lightweight outer plugin on top of that existing test runner,” he said. For environments that already expose the required reset-and-step interaction pattern, this means teams can keep the container image, codebase and internal unit tests intact while EnvHarness intercepts commands at the interface layer.
The second cost is compute. “The trade-off with EnvHarness is more computational than architectural,” Wang said. The operational expense comes from the EnvRigger loop, which needs multiple agent rollouts to diagnose a weakness, generate a modification and check that it remains solvable.
The reset requirement also creates a clear boundary around where EnvHarness makes sense. It fits digital sandboxes where rollouts are cheap and state can be restored quickly, such as coding environments, tool-use simulations and web automation test systems. Avoid running the diagnostic loop directly against systems with irreversible side effects or expensive resets, such as live production databases, real customer accounts or physical robots. In those cases, you need a safe simulator, test tenant or restorable copy of the production environment.
Google Research has released the EnvHarness code, experiment configurations and RL implementation on GitHub under the permissive Apache 2.0 license.
As the models that power EnvRigger improve, the researchers expect the cost of designing and validating environment modifications to fall because stronger designer agents should need fewer iterations. But the goal is not to eliminate human-built environments. Wang frames EnvHarness as a way to get more training value from a smaller set of high-quality environments with trusted ground-truth verifiers.
“EnvHarness does not replace the underlying environments—it acts as an amplifier for them,” Wang said. “While human-designed environments will continue to serve as the baseline ground truth, approaches like EnvHarness may offer a practical path to reducing development overhead and getting more coverage from each environment.”