AgentEnv Framework

Frontier models train in environments that have to behave like the real thing, whether the agent drives a browser, an MCP server, a desktop, or a phone. The tasks have to be realistic and backed by rich data, and one framework has to express anything from a single turn to a full world simulation.

Scale built the AgentEnv Framework to make them, after finding that existing frameworks start from the task rather than the environment. Now open source, it gives engineers and domain experts one system, from the environment and its data down to the RL tasks inside it.

Environments snap into one, behind one gateway. Click to add one.

Dynamic, composable environments

Everything starts from the Environment primitive. Each environment is declared as a document and publishes an Environment Card, like the Agent Card an agent publishes in A2A. Any number of environments compose into a larger one that is still an Environment, with one card and one gateway, so the agent connects to it the same way.

1 environment1 gateway1 connection

01 / 04

One environment.An environment serves its tools through an MCP Gateway. The agent connects once and calls them.

claude-codeA2A · role agent
slackmcp_server3 tools
mcp gateway
agent's viewclaude-code→ 1 connection →slack /.well-known/agent-env.json3 tools

Every environment exposes its tools through an MCP Gateway, which adds a virtual clock, triggers, and RBAC, among many other features.

Service and tool names are illustrative.
Clock speed

agent

role: agent

MCP Gateway

clock not armed

no virtual time

--:--:--

press “Set the clock”

calendar

clock/v1

email

clock/v1

get_time returns

…

the email service stamps the message

…

Use any environment with any agent in any sandbox

Environments expose their tools over MCP, through a /step REST endpoint, and as a generated CLI. Agents connect through A2A extensions and address each other over A2A, so one environment and one RL task run unchanged against any agent.

Sandbox providers are pluggable. We evaluated several and standardized on Modal, so the framework ships with a Modal provider; more providers follow in the coming weeks.

pick one from each column · the task does not change

environment

agent

sandbox

The only step that changes:

{
  "type": "deploy_agent",
  "env_ids": ["support-desk"],
  "a2a_agent_id": "claude-code",
  "agent_name": "solver",
  "role": "agent",
  "sandbox_type": "modal"
}
claude-code on support-desk7 turns

prompt · Resolve the open billing tickets.

  1. 109:00:00list_tickets
  2. 209:00:04read_ticket T-1042
  3. 309:00:09send_email
  4. 409:30:05read_inbox
  5. 509:30:12reply_to_customer
  6. 609:31:00issue_refund $98
  7. 709:31:20close_ticket
same task, every agent on support-desk
claude-code7 turns0 denied09:00:00–09:31:20
openai-agents8 turns0 denied09:00:00–09:30:25
openclaw9 turns1 denied09:00:00–10:00:22

The sandbox changes where the run happens, not what the agent does. Trajectories shown here are illustrative, not captured runs.

Express any task with a DAG

Primitive task steps compose into a DAG. The framework ships with 48 built-in step types, from deploying an environment to grading a trajectory, and most RL tasks need no code. When the built-ins fall short, Plugins add new step types.

Expressing tasks as DAGs has been incredibly useful for us as an organization building training data across heterogeneous settings.

One prompt, one rubric. The smallest task the framework runs.

6 steps · 5 waves

Add after Prompt
Promptprompt_agentwave 3 of 5 · after seed, agent

Sends the prompt and waits for the agent to finish. prompt_id is the join key every verifier uses to find this trajectory.

docs for prompt_agent →Rubric judge depends on it.
{
  "id": "prompt",
  "type": "prompt_agent",
  "prompt_id": "p1",
  "agent_name": "solver",
  "prompt": "Resolve the open billing tickets.",
  "timeout_seconds": 900,
  "depends_on": [{"task_step_id": "seed"}, {"task_step_id": "agent"}]
}

Two tasks, end to end

Agents, environments, and universes are separate primitives, built separately and composed in the task. Two examples: one agent building a 3D scene in its own sandbox, and two agents in a ten-service personal environment, one of them playing the user.

4 steps

Build a 3D scene from a brief

One agent, its own sandbox, a brief in, a rendered scene out. No enterprise environment at all: the task is infrastructure plus an agent.

  1. 1briefbrief.pdfstyle_notes.md
  2. 2agent sandboxBlender (headless)Python 3shell
  3. 3modelerrole: agent
  4. 4blockout.blenddetail pass.blendprops.blendmaterials.blendlighting.blendpreview.pngfinal render.png

Illustrative: the brief, files, and the agent’s actions are made up. Step types and fields are real.