Skip to main content
The OpenFang workflow engine enables multi-step agent pipelines where each step routes work to a specific agent, and output from one step flows as input to the next. Compose complex behaviors from simple, single-purpose agents without writing code.

When to Use Workflows

Use workflows when you need to:
Sequential ProcessingChain agents in a pipeline (research → write → review)
Parallel ExecutionFan work out to multiple agents and collect results
Conditional LogicBranch execution based on previous step outputs
Iterative RefinementLoop until a quality gate is met

Quick Start

Create a workflow via the REST API:
Execute the workflow:

Step Configuration

Each step in a workflow has the following structure:

Agent Resolution

Specify exactly one of:
  • agent_name - Reference agent by name (first match)
  • agent_id - Reference agent by UUID
If the agent cannot be resolved at execution time, the workflow fails.

Execution Modes

Sequential (Default)

The step runs after the previous step completes. Previous output becomes {{input}}.
1

Step 1

Receives initial workflow input
2

Step 2

Receives Step 1’s output as {{input}}
3

Step 3

Receives Step 2’s output as {{input}}

Fan-Out (Parallel)

Multiple steps run in parallel. All receive the same {{input}} from the last sequential step.
If any fan-out step fails or times out, the entire workflow fails immediately.
Example: Three agents brainstorm in parallel:

Collect

Gathers all outputs from preceding fan-out steps. This is a data-only step (no agent execution).
Outputs are joined with \n\n---\n\n and set as {{input}} for subsequent steps. Typical pattern:

Conditional

The step only executes if previous output contains the condition substring (case-insensitive).
Example: Fact-check only if the article mentions claims:

Loop

The step repeats up to max_iterations times. Terminates early if output contains the until substring.
Each iteration feeds its output back as {{input}} for the next iteration. Example: Iterative refinement until approval:

Variable Substitution

Prompt templates support two kinds of variables:

{{input}} - Previous Step Output

Always available. Contains output from the immediately preceding step (or workflow’s initial input for the first step).

{{variable_name}} - Named Variables

When a step has "output_var": "my_var", its output is stored and can be referenced in later steps:
Variables persist for the entire workflow run. Later steps can overwrite variables by using the same output_var name.

Error Handling

Fail (Default)

The workflow aborts immediately on error or timeout. The run state is set to Failed.

Skip

The step is silently skipped on error. A warning is logged, but the workflow continues. The {{input}} for the next step remains unchanged.

Retry

The step is retried up to max_retries times after the initial attempt (4 total attempts). Each attempt gets the full timeout budget.
If all attempts fail, the workflow aborts with an error.

Complete Examples

Example 1: Code Review Pipeline

Sequential pipeline where code is analyzed, reviewed for security, and summarized.

Example 2: Multi-Agent Brainstorm

Three agents brainstorm in parallel, then a fourth synthesizes their ideas.

Example 3: Iterative Refinement

Agent refines a draft until it meets quality standards.

Event Triggers

The trigger engine provides event-driven automation. Triggers watch the kernel’s event bus and automatically send messages to agents when matching events arrive.

Creating a Trigger

Trigger Patterns

Prompt Templates

When a trigger fires, {{event}} is replaced with a human-readable event description:
  • "Agent 'coder' (id: <uuid>) was spawned"
  • "Agent <uuid> terminated: shutdown requested"
  • "Quota warning: agent <uuid>, tokens at 85.0%"
  • "Health check failed: agent <uuid>, unresponsive for 30s"

Use Cases

Health Monitoring

Spawn Notifications

Quota Alerts

Memory Changes

API Endpoints

Workflows

Triggers

CLI Commands

Limits and Quotas

Run Eviction: The workflow engine retains a maximum of 200 workflow runs. Oldest completed/failed runs are evicted when this limit is exceeded.
  • Step Timeout: Default 120 seconds per step (configurable)
  • Loop Iteration Cap: Default 5 iterations (configurable)
  • Hourly Token Quota: Enforced per-agent via max_llm_tokens_per_hour

Next Steps

Creating Agents

Build custom agents for your workflows

Event System

Learn about the event bus architecture