Skip to main content
A workflow is a directed acyclic graph of steps connected by edges. Each step has a type (for example ai.parse or transform.script), a typed config, and a typed output. The engine topologically sorts the graph and runs each step through its registered processor, passing outputs forward along the edges. 
Workflow {
  steps        # the nodes, each a typed step
  edges        # data dependencies between steps
  entryStepId  # where execution starts
  outputStepId # whose output becomes the run result
}

​
Steps

Steps come in four categories:
  • AI steps (ai.*), model-backed parsing, extraction, classification, and splitting.
  • Transform steps (transform.*), deterministic data shaping: scripts, templates, merges, regex extraction, and format conversions.
  • Action steps (action.*), external side effects such as HTTP requests and invoking other workflows.
  • Control steps (control.*), flow control: conditions, loops, parallel fan-out, and typed failure.
Every step type is documented under Workflow steps, one page each, with its configuration and output schema rendered straight from the code.

​
Referencing step output

Downstream steps read upstream output with template expressions: 
{{ steps.<step-name>.output.<field> }}
The .output segment is required because each step result is stored as { output, status }. Scalar inputs to the workflow are available as {{ input.<name> }}.

​
Runs

Executing a workflow creates a run. Runs are claimed from a queue by workers, carry a status (created, queued, running, completed, failed, cancelled), and store their inputs and per-step outputs. Inputs are frozen once a run leaves the created state. To change inputs after enqueue, start a new run.

​
Evaluating workflows

Workflows are tested like code: you attach a dataset of examples (inputs plus expected outputs) and run evaluators (exact-diff, LLM-judge, or a custom script) to score each run. The eigenpal workflow CLI commands push datasets and evaluators, run experiments, and compare results.