Skip to content
Talk to our solutions team

Usage

GET /jobs jobs defined for the product
GET /runs run history
GET /agents connected agents and their state
GET /workflow/queue queued work
GET /workflow/queue/:id one queued item

Runs carry their outcome and their logs, so “why did last night’s job fail” is a query rather than an archaeology exercise across agent hosts.

A job runs when something fires it.

A cron expression. The common case, and the one to reach for when the work is genuinely periodic rather than reactive.

An inbound HTTP call fires the job, with the request body as input. Use this for third-party callbacks — payment confirmations, delivery notifications — where the other side pushes.

A change in a watched table fires the job. This removes the polling loop most teams write by hand: a job that should run “when a row lands” does not need a one-minute cron and a watermark column, with the lag and the missed-row edge cases that come with them.

A new commit on a watched repository fires the job. The basis for content or configuration pipelines that follow a repo.

A message in a connected workspace fires the job — the “run this from chat” pattern, without building a bot.

Every firing produces a run with a status, timing, output and logs. A failed run can be retried by id.

Retry re-dispatches the same job with the same input rather than re-deriving it. That matters when the trigger was a one-off webhook you cannot replay — re-deriving would mean the input is simply gone.

Jobs execute on agents: long-lived worker processes that connect and receive work. The orchestrator distributes runs across whatever is connected, so scaling throughput is running more agents rather than reconfiguring anything.

An agent that disconnects mid-run leaves the run recoverable rather than lost; the queue holds work until an agent can take it.

  • Operations — capacity, failure modes and what to watch