agentcompass run. Use run for one request. Use launch to compare models, evaluate several benchmarks, or mix harnesses and environments across multiple requests.
AgentCompass does not infer a matrix. Every request is named and declared explicitly, which keeps its parameters,
results, failures, and reuse source auditable.
Define an Orchestration
The following orchestration defines two evaluation requests. They share one global pool of 16 Benchmark task slots, while common model settings are defined once underdefaults:
${MODEL_API_KEY}. AgentCompass rejects partial string
interpolation so unresolved or accidentally concatenated secrets do not silently enter a request.
What the fields mean
The request
name therefore remains stable even if its benchmark or environment configuration changes. Use
agentcompass list benchmark, agentcompass list harness, and agentcompass list env to inspect valid component IDs.
Mapping rules
The optional
version defaults to the latest supported orchestration format. Request names must be non-empty and
unique.
Validate Before Running
Resolve the complete orchestration before starting an evaluation:--dry-run loads configuration layers, expands environment references, resolves component defaults, validates every
request, and prints a redacted orchestration. It does not load benchmark tasks or create result directories. Review the
selected component IDs, task filters, environments, endpoint hostnames, concurrency, and reuse settings in this output.
Start the same orchestration after validation:
agentcompass launch --help for the complete option list. Common orchestration-level options include:
Understand Scheduling and Failure Isolation
All requests share one task worker pool. Declaration order defines admission priority: tasks from an earlier request are admitted first, and later requests use idle slots after all pending tasks from earlier requests have been admitted. This ordering is deterministic, but it does not force one complete evaluation to finish before the next begins. In thetask_concurrency: 16 example under Define an Orchestration:
- AgentCompass fills available slots with tasks from
tb21first. - As
tb21tasks finish, its remaining unstarted tasks continue to receive priority. - Once all
tb21tasks have been admitted, any free slots immediately begintb2vrftasks, even if the finaltb21tasks are still running. - If
tb21contains fewer than 16 tasks, the unused slots begintb2vrfimmediately.
task_concurrency controls the total number of Benchmark tasks running across the orchestration.
Each request keeps its own run directory, progress files, logs, summary, and terminal outcome. A request-level failure
is recorded as failed and does not prevent later requests from running. The orchestration returns completed when
all requests complete, partial_failure when only some fail, and a terminal timeout or cancellation status when the
shared operation is stopped.
See Logs and Progress for the terminal behavior of all
three progress modes and how they interact with progress files.
Use the capacity guidance in Run Controls before raising global
concurrency.
Reuse Existing Runs
--reuse enables latest-run reuse by default for every request in the orchestration:
runtime.reuse: false. To select an exact source, set
runtime.reuse_run_id in that request or in defaults; output.run_id names the new result and is not a reuse source.
Multiple requests may intentionally share the same benchmark and model. AgentCompass emits a warning because their
result hierarchy overlaps. Implicit latest-run reuse is ambiguous for such requests and is rejected; assign an
explicit runtime.reuse_run_id to each duplicate benchmark/model request. Explicit output-directory collisions are
also rejected before task execution.
See Resume an Interrupted Run for reuse
matching and usage constraints.
