Skip to main content
A Runbook is a reusable, versioned sequence of steps. A Run is one execution of a published Runbook revision. There is no separate Workflow or Blueprint resource.

​
Step types

Primitive steps store durable intent such as URLs, semantic targets, keys, and values. Never persist snapshot IDs, temporary element references, PIDs, window IDs, coordinates discovered during a session, or provider session identifiers.

​
Safety metadata

Every step declares:
  • surface: browser, native, or either
  • effect: read, local-write, external-write, or destructive
  • risk: low, medium, or high
  • applicationScope: the applications or sites the step may affect
  • completionCondition: the independently verifiable result
An external-write step must be at least medium risk. A destructive step must be high risk. The API rejects a Runbook that understates consequential effects.

​
Browser primitives

browser.createTab, browser.navigate, browser.search, browser.click, browser.type, browser.press, browser.select, browser.hover, browser.scroll, browser.read, and browser.wait.

​
Native computer primitives

computer.launch, computer.activateWindow, computer.press, computer.setValue, computer.type, computer.keyPress, computer.hotkey, computer.scroll, computer.drag, computer.menu, and computer.setWindowFrame. Native primitives require a compatible local executor. The API validates the selected execution target before dispatch.

​
Inputs and outputs

Use input("name") inside primitive input JSON to reference validated Runbook inputs. Use output("step-id", "field") to reference a prior step’s named output. Values must be JSON and primitive input objects are limited to 16 KB.

​
Revisions

Updates use optimistic concurrency through expectedVersion. Runs bind an immutable published revision so editing a Runbook cannot change work already queued or running.
Last modified on August 28, 2026