Docker and what the agent can see
When to use docker, the Dockerfile, and what the agent can see.
local vs docker
The environment is on profiles.yaml, not provider.kind on the task:
# profiles.yaml
format: ageval.profiles/1
environment: docker # or local / e2b / ssh / daytona| Environment | Fit |
|---|---|
local | Dev and most examples |
docker | Container boundary |
e2b / ssh / daytona | Cloud environments; missing keys fail --probe |
docker (and e2b / daytona) need environment/Dockerfile (or an image option) or lock fails. Same recipe for all three.
Official image Python
environment: docker
environment_options:
python_version: "3.13" # omit = 3.12python_version selects the official image CPython minor. A task FROM ageval-attempt:base is rewritten onto the versioned tag (e.g. ageval-attempt:py3.13), so 3.12 and 3.13 images can both stay on the machine. The shape must be ^\d+\.\d+$; empty / latest / 3 are rejected once. An image that cannot be pulled fails with no fallback to 3.12. ACP engine versions are unaffected. When the scoring host omits its own evaluate_host.environment_options.python_version, it inherits this job value.
Plugin bake layers read host AGEVAL_PIP_INDEX as PIP_INDEX_URL; unset keeps pip's default index.
CPU, memory, and GPU
Put these on the task parameters, not on environment_options. Docker applies them when the container starts. Other environment kinds leave them unread.
parameters:
cpus: 2
memory_mb: 4096
gpus: 1
gpu_types: [H100]
verifier_gpus: 1A positive cpus or memory_mb adds --cpus and --memory. gpus: 0 and an empty gpu_types add nothing, so a task that omits limits keeps today's docker run shape. A positive gpus, or a non-empty gpu_types, requires a matching GPU on the machine (nvidia-smi). If the host cannot provide it, the attempt fails with environment_gpu_unavailable and does not start the container. verifier_gpus is the scoring container's GPU count and uses the same gpu_types list. storage_mb is not applied.
A compose sidecar that already declares cpus or mem_limit also receives that limit as deploy.resources.limits. A sidecar that declares no limit stays as authored.
What the agent can see
| Path | Who |
|---|---|
prompts/, data/, … | Business / maybe agent-visible |
evaluation/ | Evaluator only (uploaded at evaluate). Not scoring Dockerfiles |
environment/ | Agent Dockerfile, setup.sh |
environment/evaluate.Dockerfile | Single scoring recipe (evaluate_host.isolated, and no evaluation.environments) |
environment/evaluate/<name>/ | Named scoring recipes; evaluation.environments on the member yaml |
Real isolation is unmounted + upload at evaluate, not deleted yaml fields. That is not path_views. A scoring host's work root is not the Agent bind-mount: the harvested tree snapshot (with exclude) is copied onto that host on first exec / session(environment=).
Multi-actor isolation (shared-container / container-per-group) is declared on profiles.yaml too; ageval owns container ids and UIDs. Agent engines and ACP entries are written into the image at build time — nothing is installed at invoke time.