Skip to main content

What is a Workflow?

A workflow is a durable, multi-step run. You declare the steps and how they connect once, in TypeScript; the platform then executes every run of it, records every step and event, survives restarts, waits for people when a step needs a decision, and lets you watch, cancel, retry and replay the run from the CLI or the desktop.

Think of it as:

A checklist the platform runs for you - each item is a piece of code, a turn of an agent, a review by a specialist role, or a question for a person - with a full record of what happened at every step.
A run can be started by a person (CLI, desktop, chat), by a skill or tool your agent runs, by a schedule, by a trigger or webhook, by a template, or by another workflow.

Anatomy of a workflow

Definition

A createWorkflow({...}) chain in your project. Pushed and versioned like a skill; deployed with lua workflows deploy.

Run

One execution of a definition with a given input. Has an id (wfr_...), a status, a budget, an input and an output.

Steps

The units of work inside a run. Each step has its own status, attempts, input, output and error.

Events

The append-only ledger of everything that happened to a run, streamed live over SSE and kept after the run ends.

Step kinds

Steps are arranged with containers: .parallel([...]), .switch([...], otherwise) / .branch([...]), .foreach(step, {...}) and .dowhile(...) / .dountil(...).

Graph form

A workflow’s control flow is a static graph, not a program that runs at push time. Predicates are built from typed helpers (eq, gt, exists, and, …) and data flow from mapping helpers (fromInit, fromStep, template, …). A closure where a predicate or a binding is expected is a build error. This is what lets the platform draw the graph, replay a run locally, and resume a run on a fresh machine.

Two execution tiers

See Job tier.

Example

Workflows next to skills, jobs and templates

A workflow can carry its own schedule, so a scheduled workflow replaces the “job that calls an agent” pattern when you want step-level visibility, retries and approvals.

When to use a workflow

Use a workflow when

  • The work has more than one step and you want each step recorded and retryable
  • A person must approve, edit or answer something part-way through
  • Steps run in parallel, over a list, or in a review loop
  • A step needs hours, a repository checkout, or a coding session
  • An external system reports back later (a PR review, a payment webhook)

Use a skill or job when

  • One tool call answers the user in the same turn (skill)
  • A short piece of code runs on a timer and nobody needs to intervene (job)
  • You do not need per-step history, replay or a human in the loop

Next Steps

Quick Start

Define, push, deploy, start and approve your first workflow

Authoring

The SDK: steps, containers, bindings, approvals and Workflows.start

Job tier

Long steps, git workspaces and coding turns

Runs and events

Run lifecycle, the events ledger, SSE, approvals and the desktop Runs pages

CLI reference

Every lua workflows subcommand