workflow-creator

Composing Workflows with workflow_create

A workflow is a named, persisted sequence of steps that dispatches each step to an agent and threads the outputs together. workflow_create registers one; workflow_run / workflow_start execute it afterwards, and it outlives the conversation that created it.

Decide whether a workflow is the right shape

Reach for workflow_create when the same multi-agent sequence is worth repeating, when it needs to be startable later by a cron job or another agent, or when the steps should run as a DAG rather than one long turn. For something you will do once, message the agents directly with agent_send — a workflow you never run again is a name permanently taken on the daemon.

Call workflow_list before creating. Names are unique across the daemon and the comparison is case-insensitive, so Deploy collides with an existing deploy. A collision is rejected outright and nothing is overwritten; the error names the workflow that already holds the name.

The step shape

Every step requires name, agent, and prompt_template.

• name is unique within the workflow and is how depends_on addresses the step.
• prompt_template is the text sent to the agent. {{input}} interpolates the previous step's output; {{whatever}} interpolates a declared input parameter or an earlier step's output_var.
• output_var stores this step's output under a name later steps reference as {{that_name}}. Without it, only the immediately following step can read the output, via {{input}}.
• depends_on lists step names that must finish first. A step may name one declared later in the array — execution is topological, not positional.
• timeout_secs is the wall-clock budget for the step: default 120, ceiling 3600.
• error_mode is "fail" (default, abort the run), "skip" (continue without this step's output), or {"retry": {"max_retries": 3}}. The retry form also accepts backoff_ms and jitter_pct.
• mode is "sequential" (default), "fan_out" to run alongside the following fan_out steps, or "collect" to gather them. Richer nodes take a tagged object, such as {"conditional": {"condition": "APPROVED"}}.