Skip to main content
Use the agent runs API to start and track hosted fix and triage sessions. Every create request must identify the requester before dispatch.

Requester identity

POST /agent-runs requires one of:
  • requested_by - user:<id> or service:<name>
  • user_id - legacy user id, normalized as user:<id>
Optional requested_by_email must be a valid email address. If both requested_by and user_id are sent, they must identify the same user. User requesters are capped at 10 active queued or running agent runs and receive 429 when the limit is reached.

List agent runs

Query parameters:
  • error_group_id - optional error group UUID for fix-run history
  • intent - optional fix or triage
  • limit - optional result limit, default 50, max 200
  • thread_id - optional shared conversation thread id
Response:

Create an agent run

JSON body:
Pass thread_id to link the run to an existing project conversation. The same run then remains discoverable from the web, Slack, API, and CLI investigation record without copying model output between surfaces. For intent=fix or intent=triage, include error_group_id. Fix runs also require the project to have a linked GitHub repository:
Automatic runtime, deployment, and CI triage runs also appear in this API. Responses:
  • 201 - agent run created and queued
  • 400 - invalid intent, missing identity, malformed requested_by, malformed requested_by_email, or missing error group context
  • 404 - project or error group not found
  • 429 - the user already has 10 active agent runs
  • 502 - the API created the run but could not start execution

Get an agent run

Returns the agent run object shown in the list response plus lifecycleOutcomes, an oldest-first record of customer-visible outcomes. The timeline can include safe refusal, pull request open/update/merge/close, deployment, and post-deploy recurrence. Completed fix runs may include these validation fields in artifact:
  • testsPassed - true or false when the isolated sandbox independently reran test commands; null when no executable command was available
  • testOutput - bounded regression-test evidence, commands, exit codes, and output
  • ciPassed - whether every registered GitHub check on the latest pull request commit passed
  • ciOutput - bounded check names, conclusions, summaries, and details links
  • ciRepairAttempts - the number of failed-CI repair iterations, up to three
  • verificationPassed - whether the separate root-cause and diff verification accepted the fix
  • verificationRiskLevel and verificationSummary - reviewer-facing verification context
  • verificationProvider and verificationModelId - the independently recorded verifier identity
  • proposalUrl - the resulting pull request URL, present only after validation and verification permit a PR
Missing or failed executable validation blocks the hosted agent from opening a pull request. After a PR opens, failed CI returns to the same sandbox for a bounded repair, independent test, push, and recheck loop. The run fails if CI does not pass. Lifecycle outcome details are deliberately narrow. They include useful review and deployment references such as pull request URL, commit SHA, environment, service, and timestamps. Raw webhook payloads, provider metadata, trace IDs, fingerprints, credentials, prompts, and reasoning are not returned.

Follow run events

Events are ordered by sequence. Persist the returned nextAfter cursor and send it as after on the next request. terminal becomes true when the run is completed, failed, or cancelled. The journal contains lifecycle state, attempt count, linked thread id, and the names of produced artifact fields. It intentionally excludes raw prompts, reasoning, logs, diffs, test output, and artifact values. Fetch those through the authorized run-detail workflow when needed. Stages progress through setup, context, execute, verify, pr, finalize, and done. A run may finish early or skip a stage when no safe fix is available.

Cancel an agent run

Optional JSON body:
The response is the updated agent run.

HTTP usage

CLI usage

List runs for a project, optionally filtering by intent or error group:
Create a hosted fix or triage run with explicit requester identity:
Inspect or cancel a run:
Omit --reason to use the default cancellation reason, user_cancelled.

Agent handoff

Agents should treat run creation and cancellation as write actions:
Use MCP search("agentRuns") and execute for the same operations when an MCP client is connected.