Stateful Step-Based Execution
Shared State
Each step reads from and writes to a typed
TState object passed through the workflow.Step Types
AgentStep, FunctionStep, ConditionStep, ParallelStep.
Retry & Error Handling
Configurable retry policy and step result status (done, error, skipped).
Event-Driven
Optional EventBus for workflow lifecycle events.
WorkflowConfig
string
required
Display name for the workflow.
TState
required
Initial state object. Steps read from and merge updates into this state.
StepDef<TState>[]
required
Ordered array of steps. See Workflow Steps.
StorageDriver
Storage integration. Persisting data does not make arbitrary step effects replay-safe; see recovery contracts.
object
{ maxRetries, backoffMs } for failed steps. See Retry & Error Handling.EventBus
Custom bus. Emits
workflow.step with { runId, stepName, status: "start" \| "done" \| "error" }.boolean
default:"true"
Put this workflow in the global registry.
false for tests.WorkflowCheckpointStore<TState>
Save state after every step so you can replay or fork. See Time travel.
workflow.run(opts?)
Returns
WorkflowResult<TState>: { state, stepResults }.
StepResult
Step shapes
State Machine Concept
Workflows behave like state machines:- Initial state —
initialStateis the starting point. - Steps — Each step receives the current state and can return a partial update.
- State merge — Updates are merged into the state before the next step.
- Result —
WorkflowResultcontains final state andstepResults.
Basic Example
WorkflowResult
TState
Final state after all steps (including any updates from steps).
StepResult[]
Per-step results:
stepName, status (done | error | skipped), error?, durationMs.Next Steps
Workflow Steps
AgentStep, FunctionStep, ConditionStep, ParallelStep.
Retry & Error Handling
retryPolicy, StepResult status, WorkflowResult.