Skip to main content

Status

Where a run has got to: status, the plan it stated, spend so far, and its answer once it has one. Safe to poll often, it is a row read, not a browser. A job you submitted in the same process has the same call as job.status().

Events

Everything a run has done, in order: steps, findings, dead ends, plan changes. Ask for the verbosity you want with level: status, step (the default) or debug. Resume from the after cursor you last saw rather than re-reading from the start. Over HTTP this streams as newline-delimited JSON; the SDKs page through it for you and keep going until the run ends.

Results

The records a run has appended, oldest first. Records land during the run, so this answers before it finishes, and a cancelled run still delivers what it had already produced.

Webhooks

A run can notify a bare webhook URL when it settles, and unlike a monitor, this one retries.
Verify the signature before trusting a payload: the header carries a Unix timestamp and an HMAC, in the same t=...,v1=... shape Stripe’s webhooks use.
An agent run can only notify a bare webhook URL, never Discord or Slack directly, those two are monitor-only targets. In exchange, a run’s webhook does retry: up to 8 attempts, backing off 1 minute, 3 minutes, 9 minutes, 27 minutes, then three more at 1 hour each, about 3 hours 40 minutes in total, before it gives up after the eighth refusal. A monitor’s notification, by contrast, is sent once. Either way, a run’s own events stay readable through agent.events and agent.results regardless of whether the webhook ever lands.