The Workflow Engine executes the step graph produced by the Orchestrator. It resolves dependencies, runs independent steps in parallel, threads data between steps through a shared context, and supports pausing for human review.

​
What a step carries

​
Execution model

1

Scheduling

Steps whose dependencies are all satisfied become ready and are dispatched together.
2

Parallel dispatch

Ready steps run concurrently, up to a sensible bound (a handful at a time).
3

Variable substitution

Before a step runs, $key references in its inputs are replaced with values produced by earlier steps.
4

Execute & record

The tool runs; its result, outputs, and status are recorded.

​
Shared context & variable passing

Steps communicate through a shared key/value context. A step declares what it produces in outputs, and downstream steps consume those values with $key in their inputs:
Common ambient variables like $user_name and $user_email are resolved from the shared context too.

​
Human-in-the-loop

A step marked needs_human pauses before executing, surfacing the workflow for review. Workflows can be interrupted and resumed via these endpoints:

​
Resilience

  • Retries: each step retries on failure up to its configured limit.
  • Timeouts: each step is bounded by a maximum run time.
  • Runtime capability creation: if a step’s tool is still missing at execution time, the engine can create it as a safety net.

​
History

Completed workflows are saved locally and exposed via GET /api/workflows and GET /api/workflows/{id}. Recurring/scheduled workflows are managed automatically (see Automation).