AEnvironment, three names for one project and two runtimes in one tree

The features prose promises SWE-Bench and the table omits it

The Key Features section and the built-in environments table do not agree on what ships.

The features line says benchmark environments are supported out of the box and names three: TAU2-Bench, SWE-Bench, and Terminal-Bench. The table lower down lists three different things: TAU2, Mini Terminal, and TerminalBench. SWE-Bench is absent from the table, and Mini Terminal is absent from the features sentence.

TAU2 and Terminal Bench appear in both lists under two spellings each, which suggests the prose is using benchmark names while the table uses environment directory names. That reading would tidy things up if the two sets matched, and they do not. Either a SWE-Bench environment exists and is not in the table, or that sentence is aspirational. The table links to directories under aenv/builtin-envs/, so the directory listing is the more authoritative of the two, and it holds three entries.

There is no version column in the table either, which matters because every environment in the code samples is addressed by name and version.

One project, three names, and two vocabularies

The repository and documentation site are AEnvironment. The distribution on PyPI is aenvironment. The importable Python package is aenv, which is also the directory name at the root of the tree and the prefix on every example import path.

That split is not unusual for a project with a long name, but it is worth writing down before you start, because the install command, the import statement, and the pip name all differ. The sample that wires an agent into reinforcement learning training imports from aenv.examples.tau2_rl.agent, so the runtime path never matches the project name either.

The operational side has its own vocabulary. A news entry describes the AEnv CLI as handling instance and service management, so a deployed thing is an instance and a running application is a service, and both are separate from the environment concept the library is named after.

The documentation site is served from GitHub Pages under the inclusionai organisation rather than a separate domain, so the docs travel with the repository.

Environments are addressed as name@version, and the versions are all 1.0.0

Every environment in the samples is opened with a name and a version in one string.

The mini program sample opens Environment("[email protected]"). The agent-as-environment sample opens Environment("[email protected]"). The part before the at sign is a name you choose, and the part after it is a version, so the addressing scheme is the one a package registry uses.

Two things follow from that. You can hold two versions of the same environment side by side, which is the point of versioning anything in a training setup where a result has to be reproducible. And you can name an environment that does not exist yet, because no sample shows a registry lookup or an error path for a name and version that do not resolve.

The built-in table carries no version column, so the version a built-in environment answers to is stated nowhere in the file. If you intend to pin, that number has to come from somewhere else. The sample names also show how wide the namespace is meant to be: a mini program generator, a second agent, and the benchmark environments all share one addressing scheme.

The whole tool surface is list_tools and call_tool

An environment exposes exactly two methods in the samples, and both are awaited inside an async with block.

list_tools returns what the environment can do. call_tool takes a name and a dictionary of arguments. Because both are reached inside a context manager, the lifetime of the environment is tied to the block rather than to an explicit close call.

The arguments are plain JSON-shaped dictionaries. write_file takes a path and a content string, read_file and execute_python_code are named in a comment rather than shown, and the chat tool takes a message. The reply from chat is read through a content attribute, so return values are objects with fields rather than bare strings.

That is the OpenAI Agents SDK shape rather than an MCP shape, which sits oddly beside the claim of native MCP support. Both can hold at once, since MCP is about how tools are advertised to a host while this interface is about how a Python caller drives the environment directly. The mini program example describes its tool set as file operations, code execution, and validation tools, with a live preview of the generated application layered on top.

A Python package sitting under a Go workspace

The primary language is Python, and the root of the repository is a Go workspace.

At the top level sit aenv/, holding the Python package with its examples and built-in environments, and four directories whose names describe infrastructure rather than a library: api-service/, controller/, deploy/, and envhub/. Alongside them are go.work and go.work.sum, the two files that make a multi-module Go workspace.

So this is two systems in one tree. The Python side is what you import, and it is what most of the documentation is about. The Go side is the service and control layer that the AEnv CLI and the deploy skill drive. An operator installing this is as likely to meet Go as Python, and the language field says Python only because that is where the package lives.

A .gitmodules file sits in the same listing, so at least one component arrives as a submodule rather than vendored source. .pre-commit-config.yaml and a .claude/ directory indicate a project that runs commit hooks and keeps its own agent configuration in the repository, and LEGAL.md sits next to the Apache-2.0 LICENSE and CONTRIBUTING.md, which is a heavier legal footprint than a plain library usually carries.

The training loop comes from AReaL, not from this package

The reinforcement learning path is a shim over an external framework.

# Entrypoint for AReaL training
from aenv.examples.tau2_rl.agent import run_agent_return_reward

# Run a single episode and return reward
reward = await run_agent_return_reward({
    "domain": "telecom",
    "task_id": "task_123"
})

The import name says AReaL and the prose agrees: training runs with the AReaL framework, which the repository describes as deeply integrated with AEnvironment inside Ant Group. The rollout machinery and the distributed execution come from AReaL, and this repository supplies the environment plus a function that returns a reward for one episode.

What the environment side contributes is named in the example: reward functions exposed for training, an episode runner doing turn-by-turn agent execution with automatic tool invocation, and support for large-scale distributed training. A task is identified by a domain and a task id, with telecom used as the domain in the sample. The snippet awaits at what looks like module scope, so the enclosing entrypoint is expected to be async, and that detail is left to the example README.

Version 0.1.7, with seven weeks of commits after it

The release cadence is regular, the version number has not left zero, and main has moved past the newest tag.

The releases are v0.1.5 on 27 February 2026, v0.1.6 on 16 March 2026, and v0.1.7 on 21 May 2026. The last push to main is 10 July 2026, and the repository is not archived.

Two things follow. The project has been in the 0.1 range at least since February without moving its minor number, so nothing here carries a stability guarantee. And roughly seven weeks of work on main sit past v0.1.7, which for training infrastructure means the tag you can install is not quite the code the team is running.

The header describes the platform as production grade while the version reads 0.1.7. Both statements can hold, since the production claim may be about the deployment story rather than the library surface, but the pairing is worth keeping in mind before a training pipeline depends on it. Two milestones are dated in prose rather than in tags: a deploy skill in February 2026, and AEnv CLI instance and service management arriving with v0.1.4 in January 2026.

Editorial conclusion

AEnvironment is worth a look if you are running agentic reinforcement learning and already recognise the AReaL ecosystem, because the environment abstraction is built to sit under it rather than beside it. Check four things first. Whether SWE-Bench actually exists as a built-in environment, since the features sentence says so and the table does not. Whether the version your environment answers to is one you can pin. What the Go control plane requires to deploy, since the Python install alone gives you the library and not the service. And whether you can live with a 0.1 version number on infrastructure you intend to run training through.

Frequently asked questions

Official sources

1. inclusionAI/AEnvironment on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases