By the OpenEnv Maintainers: Ben Burtenshaw, Sergio Paniego Blanco, Kashif Rasul, Zach Wentz, Davide Testuggine, Sanyam Bhutani, Kai Wu, Joseph Spisak and Govind Kamtamneni
TLDR: OpenEnv uses a client and environment server. The client starts an episode, submits actions, and receives results. Environment authors define the task behavior and feedback, then package the environment so others can run it.
Scheduling a meeting asks an agent to work out which calendar to use, what it has permission to change, and which actions must happen first. Turing built Calendar Gym to test those decisions under limited visibility into other users' calendars. The team reported roughly 90% success when tasks named explicit calendar identifiers, compared with roughly 40% when the same tasks used natural-language descriptions. A task that looked straightforward became much harder when the agent had to resolve those details for itself.
To train on tasks like this, developers need an environment that defines what the agent can do, what it can observe, and how its actions are judged. They also need a way to connect that environment to a training system. OpenEnv's charter describes why that connection has been difficult to reuse across training systems, evaluation tools, and agent harnesses with different interfaces. OpenEnv provides a common interface so developers can spend more time defining the task.
Define the task before choosing a reward
I start with the task's boundaries. Which actions are valid, what information should the agent receive, and what counts as completion? OpenEnv represents these choices through structured action, observation, and state types. The environment implements the task's behavior, and a server makes it available to clients.
The Wordle tutorial offers a small example of those choices. The agent submits a five-letter guess and receives feedback showing which letters are correct, misplaced, or absent. The target word stays hidden, and the game ends when the agent guesses it or uses its six attempts. A calendar task needs different actions and observations, but its author still has to decide what the agent can see and when the work is complete.
Keep the interaction separate from the task logic
Once those boundaries are clear, the client needs a way to run the task. It starts an episode with reset(), submits an action with step(), and can request state(). Results include the observation, numeric reward, episode completion status, and metadata. OpenEnv supports synchronous and asynchronous clients for this interaction.
That interaction pattern stays the same as the task changes. A Wordle guess and a calendar operation can each be represented by their own action type, while the client continues to manage episodes through the same API. The shared interface makes integration reusable, but each environment still defines its own behavior and scoring.
Reuse the tool interface where MCP is supported
Some environments also expose tools through MCP, allowing those tools to be used by external agents as well as during training. The training system uses reset, step, and state to manage episodes, while MCP describes the tools the agent calls. This separates the work of controlling a training run from the actions available within the task.
The implementation determines which path to use. In OpenEnv v0.9.0, FinQA uses the MCPEnvironment base class, and the Echo example demonstrates tool discovery, calls, and error handling through step(). Wordle still uses a custom action type, as the MCP tutorial explains. Before choosing an integration, I check the environment's supported interface.
Make feedback reflect the intended behavior
Whichever interface the agent uses, the feedback needs to reflect the task we want it to learn. Reward design covers task completion, intermediate progress, and penalties. A score is useful only if improving it means the agent is getting better at the intended behavior, so I need to inspect the outputs as well as the reward curve.
In the Pelican SVG environment, for example, structural checks rewarded bicycle-like geometry even when the model hadn't learned to draw the bird. Adding a visual judge didn't solve the problem in the reported run because its feedback supplied too little useful signal for that model. The experiment shows why choosing a more elaborate scorer isn't enough on its own; the feedback must also help the model learn.
Even a well-chosen reward can be undermined by failures in the system that computes it. OpenEnv maintainer Sergio Paniego found that rendering timeouts and unavailable scorers in his watercolour training project returned zero, treating failed infrastructure like a bad painting. He changed those paths to return None and excluded the affected attempts from the training group, so system failures no longer became misleading feedback about the model's work.
Package the environment for another developer
Once the actions and feedback behave as intended, the next step is making the environment usable by someone else. OpenEnv's builder workflow creates a project structure, supports a local development server, validates the declared environment contract, and packages the work for deployment. The deployment guide covers Docker configuration and publishing to Hugging Face Spaces.
Reproducing that behavior also requires clear setup instructions and pinned dependencies. OpenEnv v0.9.0 includes an Echo MCP demonstration for checking tool discovery, calls, and error handling, while the Wordle tutorial shows a fuller training recipe using TRL. I want readers to know which release an example uses and what to expect when they run it, since documentation on the main branch may differ from a stable release.
Connect the environment to training
With the environment running, the training system can use its feedback to update the model. TRL's OpenEnv guide describes how this works over multiple turns, with the environment supplying tools and rewards while the trainer handles model updates. The Wordle example follows that division of work as the model guesses, receives feedback, and tries again. Developers still need to choose a model, training settings, and an evaluation method to check what it learned.
Why we are joining AAIF
Making that workflow reusable takes coordination among the people building tasks, training frameworks, and agents. A change to an environment interface affects the systems that consume it, so those contributors need a shared place to discuss compatibility and project direction.
OpenEnv already has a multi-company Technical Committee that brings those perspectives together. The public AAIF proposal builds on that collaboration by seeking a vendor-neutral home for the shared environment specification, where it can develop alongside MCP. Joining AAIF gives that existing work a foundation home.
What comes next
The roadmap extends the same work from publishing environments to checking whether they're useful for training. Proposed priorities include connecting agent harnesses to training systems, validating environments, providing training recipes, and supporting task sampling, curriculum, and evaluation during training. Individual RFCs are at different stages of review and implementation, so these priorities describe the direction of the work rather than a single upcoming release.
To try the workflow, start with the getting-started guide and run an environment whose behavior you can inspect. Then review the contribution process before proposing a larger change.
Share
Author
