Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sequentum.com/llms.txt

Use this file to discover all available pages before exploring further.

A Run is what happens when you (or a Schedule) trigger an Agent. Each Run is independent — you can start dozens in parallel, subject to your Space’s concurrency limits.

Lifecycle

A Run moves through RunStatus values defined in the API. The status returned over the wire is an integer; this table is the canonical mapping.
IntNamePhaseWhat it means
1RunningactiveThe browser is open and commands are executing.
2ExportingactiveRecords have been extracted; an Export command is delivering them.
3StartingactiveThe Run was accepted; the runtime is booting.
4QueuingactiveAccepted but waiting for a free worker.
5StoppingactiveA stop was requested; the Run is shutting down gracefully.
12WaitingactiveThe Run is paused, waiting on an external condition.
6Failureterminal, resumableExecution finished with an error or failed success criteria. The Run stays in the active Runs table and can be restarted in place.
9CompletedterminalThe Run finished its commands and the Agent has no success criteria configured.
10SuccessterminalThe Run finished its commands and passed the configured success criteria.
8StoppedterminalA caller stopped or killed the Run.
11SkippedterminalThe Run was skipped (e.g., a Schedule fired but the Agent was archived).
7Failedhistory-onlyOnce a Failure Run is archived to run-history, its status is rewritten to Failed. You only see Failed via the run-history endpoints.
The Invalid (0) sentinel is reserved for malformed records and should never appear on a real Run.

Polling for completion

When polling GET /agent/{agentId}/run/{runId}/status, treat these as terminal — i.e., stop polling:
  • Failure (6)
  • Stopped (8)
  • Completed (9)
  • Success (10)
  • Skipped (11)
A Run that ends in Failure is restartable in place via the restart-run endpoint. A Run that ends in Failed only appears in run-history — by the time you see Failed, the Run has already been archived and can no longer be resumed.

Completed vs Success

The two depend on whether the Agent defines success criteria:
  • Agent with no success criteria configured → terminal status is Completed (9).
  • Agent with success criteria configured → terminal status is Success (10) when the criteria pass, Failure (6) when they don’t.
If you’re treating a Run as “the data is good”, check for both Completed and Success — they’re equivalent for downstream consumers.

Outputs

Every Run produces:
  • Records — the structured data the Agent extracted, available via the run-files endpoints.
  • Files — raw HTML, screenshots, downloaded assets, log files.
  • Diagnostics — per-command timing, failure traces, blocked-page detection.
For high-volume use cases, configure an Export so records land directly in Snowflake or S3 instead of being polled out of the API.

Stop vs. kill

stop waits for the current command to finish, persists what’s been extracted so far, and ends the Run cleanly — the Run reaches Stopped (8). kill terminates the browser immediately and may discard in-flight work. The first call to kill initiates a graceful stop (same as stop); a second call within the stopping window forces immediate termination of the server process. The Run still ends in Stopped (8). Prefer stop. Use kill only when a stop isn’t responding.