Concepts
What is an AI workflow?
An AI workflow is several agents and steps run in a defined order, as one recorded unit of work. The useful part is not the chaining — it is that the whole thing has one run record, so you can ask what happened rather than reconstructing it from four places.
I built the engine described here, and the failure section at the bottom is one I shipped on my own product rather than a cautionary invention.
What you get that a single agent does not give you
| What it buys you | |
|---|---|
| One run record | Every step in order, with what it received, what it returned, its tokens and its cost |
| Focused agents | Four agents doing one job each are easier to fix than one prompt doing four |
| Structured hand-off | An agent can return JSON so the next step reads fields by name instead of parsing prose |
| Steps that cost nothing | Condition, Delay and Transform never call a model, so they add no token cost |
| Automation | The same workflow runs on a cron schedule, or when an inbound webhook fires |
The shapes available
Sequential runs Free. Parallel, conditional, fan-out and loop need Pro, and a dependency graph comes from giving individual steps a depends_on list rather than from picking a mode.
Most workflows worth building are sequential. Reach for the others when you have a reason: parallel for speed, conditional when two cases genuinely diverge, fan-out for a list, a graph when steps have real dependencies rather than an order you happened to type them in.
What a workflow costs
Each agent step spends tokens; the control steps do not. A two-step worked support example comes to $0.0144 at our real rates, and a real logged support run with a third step that escalated to a human came to $0.0204. Source: two runs costed step by step, readable without an account.
So step count is the cost lever. Reshaping data with a Transform instead of asking an agent to reformat something is both cheaper and more predictable.
The failure a workflow makes easier to hide
Every step succeeded and nothing happened
A workflow can finish as COMPLETED having skipped everything that mattered, because a condition that never matches is not an error. Source: I had 27 branches doing this for weeks while every run reported success.
One empty step poisoned the rest
A step that receives nothing usually still succeeds — it does its job on the nothing it was handed, and passes more nothing along. This is why a run records what each step received, not only what it returned: the step that looks wrong is rarely the one that broke.
The count is the check, not the status
If a workflow matters, have it report how many items it processed and compare that against what the source says it handed over. A status tells you nothing threw. A count tells you work happened.
Next
- Build one — see Build a multi-agent workflow.
- Run it without you — see Automate: schedules & webhook triggers.