An evaluation run checks how your workflow performs against a set of test cases. Use it to assess a change before relying on it in production, or to investigate a regression. Creating a run queues the enabled cases from an existing suite; read the run until it reaches completed, failed, or cancelled, then inspect its summary and individual results.
Runs are queued work
POST creates a run in queued state; workers advance it through running to a terminal state. The API does not promise an immediate result or an automatic client retry, so persist the returned run ID and poll deliberately.
Standard and shadow modes
A standard run evaluates suite cases with their stored inputs. A shadow run samples production traces, optionally filters and segments them using only the documented allowlist, and can compare a candidate workflow version; sample size defaults to 12 and is clamped to 1 through 25.
Result and review views coexist
Terminal reads include aggregate pass rate and counts, per-case results, trace IDs, latency and cost, plus review counts and reviewed pass rate. Automated passed and score remain distinct from any final human-reviewed values.
Before you begin
The command-line examples require curl and jq; any exception is identified in its introduction.
An existing eval suite linked to a workflow target, with enabled cases prepared in the operator console.
A machine credential with eval_runs:write to schedule and eval_runs:read to fetch results.
Add eval_suites:read only if the machine client will list or inspect suites; the optional suite-creation example separately requires eval_suites:write.
A reachable workflow target and any managed secret required by its outbound authentication mode.
How it works
Choose a ready suite
List or read eval suites and verify the intended target and enabled cases. Creating a suite through the machine API does not create its cases.
Queue the run
POST its eval_suite_id, adding a workflow version or shadow parameters only when needed. Store the returned id; a monthly eval-run quota can reject creation with 429.
Read through a terminal state
GET the run at a controlled interval. Stop on completed, failed, or cancelled; on completion, inspect every result as well as aggregate fields because a completed run can contain failed or error cases.
Examples
These examples are illustrative. Replace the sample values with your own.
Keep credentials in environment variables or a secret manager, never in client-side code.
Create the suite shell
This establishes suite policy. Add enabled cases in /app/evals/suites/:id before expecting case results.
HTTP 200 returns aggregate fields and a results array. Each result can include status, automated and reviewed scores, latency, cost, trace IDs, and its eval-case summary.
Troubleshooting
The run completes with zero cases
The suite had no enabled cases. Machine suite creation does not accept a cases payload; create and enable cases in the operator eval-suite UI before scheduling.
Creation returns 429
The workspace exhausted eval_runs_per_month. The quota problem includes upgrade context; changing the run payload does not bypass the quota.
A run stays queued or becomes failed
Check /ready for queue health, then inspect run results and related traces. Verify the target is reachable, its secret is valid, and its timeout covers the workflow response.
Endpoint reference
Ready to integrate? Open an endpoint for its required permissions, request fields,
response format, and status codes. The examples above explain the workflow;
these details define each individual request.
POST
/api/v1/eval_runs
API key / access token
Create an eval run from an eval suite
eval_runs:write
Description
Schedules a new evaluation run. Requires an existing eval_suite_id. Create eval suites via POST /api/v1/eval_suites or the operator dashboard. sample_size is clamped to 1..25 (default 12). segment_filters and segment_by are allowlisted to environment, workflow_version_id, service_agent_id, metadata.customer_tier, and metadata.language. Create returns 429 when eval_runs_per_month is exhausted.
Auth
API key / access token
Required Scopes
eval_runs:write
Request Body
Field
Type
Required
Description
trace_id
string
No
AgentOps trace UUID. Must belong to this workspace and engagement when both are supplied.
candidate_workflow_version_id
string
No
Candidate workflow version for shadow runs
engagement_id
string
No
AgentOps engagement UUID. Must belong to this workspace.
eval_run_id
string
No
AgentOps eval UUID for correlation; must belong to this workspace.
eval_suite_id
string
Yes
UUID of the eval suite to run
hiring_id
string
No
Marketplace hiring identifier for cross-system correlation.
provider
string
No
Canonical provider name supplied by the originating runtime.
provider_run_id
string
No
Provider run identifier supplied by the originating runtime for cross-system correlation.
run_kind
string (standard, shadow)
No
Run mode
sample_size
integer
No
Requested shadow sample size. Clamped to 1..25; default 12.
segment_by
array<object>
No
Shadow summary dimensions. Allowlisted to environment, workflow_version_id, service_agent_id, metadata.customer_tier, metadata.language.