Skip to main content

Anatomy of a Workflow

A workflow consists of:
  • Name: set when you create it; new workflows are private
  • Versions: each version holds a complete definition
  • Definition: inputs, steps and optional named outputs

Definition Fields

Retries and timeouts are set per step, not for the whole workflow.

Steps

Each step defines an operation in the workflow. Steps can be model invocations, HTTP requests, Python functions, parallel branches, conditional logic, or simple pass-through operations.

Base Step Fields

All step types share these fields:

Retry Configuration

Step Types


Model Steps

Invoke an AI model from the each::api catalog.

HTTP Steps

Make HTTP requests to external APIs or services.

Auth Configuration


Python Steps

Execute Python code within the workflow.

Parallel Steps (Branching)

Use type: "parallel" to run multiple branches concurrently. Each branch contains its own sequence of steps that execute independently.

Branch Fields

All branches kick off at the same time and run independently. The parallel step wraps up once every branch finishes.

Choice Steps (Conditional Logic)

Use type: "choice" to route execution based on a condition. The workflow evaluates the condition and picks either the condition_met_branch or the default_branch.
Here subject is an earlier eachlabs-llm-router step that answers PET or PERSON. After the choice, $.portrait.primary is the image from whichever branch ran. The full workflow is example 7 on the overview.

Condition Types

Conditions can be simple (single comparison) or logical (combining multiple conditions).

Simple Condition

Compares a single expression against a value:

Logical Conditions

Combine multiple simple conditions using and, or, or not:

Condition Operators

Comparison Operators

String Operators

To test one of several values, combine equals conditions with or.

Existence Operators

Existence operators (exists, not_exists, is_null, is_not_null) do not require a value field in the condition.

Choice Branch Fields


Pass Steps

A step that does no processing and returns a fixed value.
Later steps read its fields directly, for example $.static_config.style.

Input Schema

List the inputs under properties. Each input takes:
A run fails if a step references an input that was left out and has no default_value. Files are passed as public URLs; upload your own with each::storage.

Execution Flow

Steps run sequentially by default. Each step’s output is available to subsequent steps via parameter references. Parallel and choice steps let you add branching and conditional logic into the mix.

Step Outputs

Each completed step produces a StepOutput:

Choice Step Output

A choice step reports the branch that ran in selected, and its output and primary are that branch’s result:

Fallback Output

When a fallback kicks in, a separate step output appears with a _fallback suffix:
Fallback reasons: primary_failed (the primary model failed and the fallback ran) or not_triggered (the primary model succeeded; the fallback entry has status skipped). Later steps that reference $.step1.primary receive the fallback’s result when it ran.
Last modified on October 7, 2026