Skip to main content
AgentFlow runs agents as sequential steps, passing each output into the next as context.
AgentFlow(model="gpt-4o") is now accepted (canonical) as the default model for steps that did not name one. llm= still works as a deprecated alias — see Model Parameter.

Quick Start

1

Sequential pipeline

2

Parallel research

3

Conditional routing


How It Works

Each step receives the previous step’s output as context. Context passing is automatic — no extra code required.

Which Pattern to Use?


Pattern Helpers


parallel() and max_workers

max_workers caps concurrent steps in parallel() and loop(parallel=True).

Workflow Hooks

WorkflowHooksConfig options:

Planning & Reasoning

Pass planning=True to enable it, or a dict to tune the planner:
Prefer the bool or dict form above. Use WorkflowPlanningConfig when you want typed, IDE-friendly configuration.

Memory Integration

Pass memory=True for the default file backend, or a dict to pick a backend:
Prefer the bool or dict form above. Use WorkflowMemoryConfig when you want typed, IDE-friendly configuration.

Guardrails & Validation


Output Modes


Async Execution


Status Tracking


Variable Substitution

Every action string processes placeholders in this order:
For YAML workflows loaded via YAMLWorkflowParser, the top-level input: field is stored as workflow.default_input and used automatically when start() / run() is called with no argument. See Workflow Input Resolution for the full precedence ladder.
{{today}}, {{now}}, and {{uuid}} are provided by the separate Dynamic Variables mechanism, not the workflow template engine.

WorkflowManager

WorkflowManager discovers and executes markdown-defined workflows from .praisonai/workflows/.
AgentFlow is the primary workflow surface. WorkflowManager is a secondary API for running markdown-defined workflows.

Checkpoints

Save progress with checkpoint= (saved after each step), continue an interrupted run with resume=, and — only when a real edit happened — override a fingerprint mismatch with rebase_checkpoint=True.
Definition fingerprint. Each checkpoint stores a stable content hash of the workflow’s steps (each step’s name, action, agent name, and full agent config). Whitespace- or comment-only edits keep the same fingerprint, so a resume still works. Adding, removing, or reordering steps — or changing an agent config value such as instructions, model, tools, condition, or routing — produces a new fingerprint. Fail-closed on a missing checkpoint. Resuming onto a name that does not exist refuses to run rather than silently restarting from step 1:
Fingerprint mismatch. After a real edit, resume refuses and the error names both fingerprints and points at the remediation:
Pass rebase_checkpoint=True to continue at the same step index against the edited workflow (a warning is logged naming both fingerprints):
For a full walkthrough — CLI flags, the workflow checkpoints command, the checkpoint-file schema, and a decision diagram — see Workflow Checkpoint & Resume.

Async

aexecute() accepts the same checkpoint, resume, and rebase_checkpoint parameters (and returns the same resumed_from_step field) and supports loop_over and branch_condition routing with full parity to execute().

Loop Steps: Error Handling & Checkpoints

A loop_over step runs its step once per item. Two behaviors apply on both execute() and aexecute():
  • Stop-on-error aborts the workflow. When a loop_over step fails on any iteration and its on_error="stop" (the Task default), the entire workflow aborts — not just the loop. result["success"] becomes False and no later steps run.
  • Completed loop steps checkpoint once. With checkpoint= set, a loop_over step persists a checkpoint after the whole loop completes (matching single-step behavior). On resume=, the loop is not re-run — execution continues from the next step.

Error Handling Across Patterns

As of PraisonAI #4194, the same failure rules now apply inside every nested pattern (loop, parallel, when/if_, route, repeat), not just loop_over:
  • on_error="stop" (the Task default) inside any nested pattern halts the whole workflow — the stop signal propagates out of the pattern to the top level.
  • on_error="continue" keeps the workflow running, but the final result["status"] is "failed" if any step failed.
  • Downstream steps never receive the exception text as input; the error is recorded on the step, not folded into its output.
See Error Handling for the full guide, including parallel(on_failure=...) modes.

Workflow File Format

Markdown files with YAML frontmatter define multi-step workflows for WorkflowManager:
if_() is deprecated. Use when() instead for conditional steps. if_() will be removed in a future release.

Best Practices

Give each step a distinct agent with a focused role — Researcher, Analyst, Writer. Agents with clear instructions outperform generalist ones.
LLM-backed parallel steps hit rate limits fast. Start with max_workers=3 and increase only after testing.
Use Task(name="...") for every step. Named steps appear in workflow.step_statuses and execution history.
Add guardrails= to steps that produce structured output (reports, JSON, code). Short feedback loops via max_retries cost less than prompt engineering.
Use when(condition="{{score}} > 80", ...) for simple thresholds. Reserve route() for multi-branch decisions.
One step → one responsibility. Easier to debug, retry, and replace.

YAML Workflows

Define complex workflows in YAML files

Nested Workflows

Combine loops, parallel, and routing patterns

Hybrid Workflows

Mix deterministic shell steps with agent steps

Job Workflows

Ordered pipelines of shell commands and agent steps