Concepts

Three parties take part in an episode.

The environment is the container. It owns the program under test, the task, and the grader. It makes no decisions about what to try.

The agent is your model. It reads the task, explores the source, and proposes something: an input, a patch, a finding. It only ever acts through the operations in The tool surface.

The orchestrator is your harness. It launches the container, speaks the Model Context Protocol to the server inside it, decides which operations to expose to the agent, drives the loop, and asks for the grade at the end. The agent never talks to the environment directly; everything passes through your orchestrator.

Reading an environment name

Each image name encodes where the task came from, in six dot-separated parts:

workspace.project.target.run_number.problem_id.type

The last part is the type from Introduction. The problem_id identifies the specific defect, and is the literal nodata for audit tasks, which concern the whole program rather than one defect. The middle parts identify the program and the analysis run the task was derived from.

You need this only to tell your environments apart and to route each one to the right agent configuration. Nothing in your harness should parse it for meaning beyond the type.