Recipes Don't Lose Work

Multi-agent workflows as durable YAML

Amplifier · Recipes & Workflows

The Frame

Multi-step AI workflows chain specialized agents to do real work — and Recipes make that coordination durable.

A Recipe is declarative YAML that orchestrates a multi-step AI agent workflow — it defines what should happen, not how to implement it. The engine that runs them is Amplifier's tool-recipes module.

Doing that coordination by hand is fragile. Here's the machinery that replaces it.

Proof

This isn't a sketch — it's a shipped engine.

The tool-recipes engine on origin/main is a substantial, well-tested module with a large library of example workflows already in the repo.

Real machinery exists. So why is hand-coordination still the problem?

2,425

lines in executor.py

49

example recipe .yaml files

354

test functions across 18 test files (static grep count)

909

lines in models.py

The Tension

Hand-coordinating a chain of agents is fragile — a transient error mid-run loses the work already done.

RECIPES_GUIDE frames recipes as the fix for exactly this: teams that want repeatable multi-step workflows, consistent process enforcement, and resumability on interruption. Without them, there's no repeatable process to lean on.

So the workflow gets encoded — starting with the declaration itself.

Mechanism · Declare it

A Recipe declares the workflow as YAML: "what should happen, not how."

Steps come in three mutually-exclusive types — agent (default; spawns an LLM agent), recipe (runs a sub-recipe), and bash (a shell command, no LLM overhead) — making the process an inspectable, repeatable artifact.

Declaring it is half the answer. Durability is the other half.

# Recipes are declarative YAML specifications
# that orchestrate multi-step AI agent workflows.
# They define what should happen, not how.

steps:
  - id: review
    type: agent      # spawn an LLM agent
  - id: build
    type: bash       # shell, no LLM overhead
  - id: sub
    type: recipe     # run a sub-recipe

Mechanism · Never lose work

The engine checkpoints after every step, so a failed run resumes from the last successful step.

executor.py: "Executes recipe workflows with checkpointing and resumption." After each step it appends the step id to a persisted completed_steps list and saves state; on resume, completed steps are skipped.

Now layer human control on top of that durable engine.

1Run a stepagent, recipe, or bash
2Append step.id to completed_stepsseeded as [] at session start
3Checkpoint after each stepsave_state persists progress
4On resume, skip completed stepsno lost work from transient errors

Setup · The example

A shipped recipe chains distinct agents and requires human approval between each phase.

The dependency-upgrade-staged-recipe stages Assessment → Validation → Phase 1/2/3, using agents like integration-specialist and zen-architect. Every stage after Assessment sets approval: required — the recipe pauses at each gate until a person says go.

Approval pauses and cancellation share one trait: durability.

Assessment — no approval; runs the specialist agents
Validation — approval required
Phase 1 / 2 / 3 — approval required each
ApprovalConfig timeout 0 = wait forever; the executor raises "Execution paused at stage … awaiting approval"

The Payoff

An interruption costs nothing — a cancelled or paused recipe resumes from the last checkpoint.

Cancellation is handled the same durable way as an approval pause. The executor's CancellationRequestedError notes it is "similar to ApprovalGatePausedError … The recipe can be resumed later from the last checkpoint." Completed steps are skipped; no work is lost. The manual dance is now a durable, resumable artifact.

That's the whole pattern — here's how to keep it.

The Takeaway

Encode the workflow, checkpoint every step, gate on humans.

Do those three things and multi-agent work becomes repeatable instead of hand-coordinated — the pattern RECIPES_GUIDE recommends for repeatable multi-step workflows, consistent process enforcement, and an audit trail of executions.

A fragile manual dance becomes a durable, resumable artifact.

Encode the workflow as declarative YAML — what, not how
Checkpoint after every step — resume from the last successful one
Gate stages on human approval — pause until a person says go

Sources

Research Methodology & Sources

Feature status: SHIPPED on origin/main

Primary source: microsoft/amplifier-bundle-recipes, branch of record origin/main, HEAD 9a1d8e0 (2026-03-01), 104 commits, first commit 9919a8d (2025-12-15). All engine claims derived from origin/main blobs, not local off-branch HEAD.

Commands run:

git show origin/main:docs/RECIPES_GUIDE.md | sed -n '18,40p' — "declarative YAML … what should happen, not how"
git show origin/main:…/executor.py | sed -n '237p;665,690p' — checkpointing/resumption + "# Checkpoint after each step" → save_state
git show origin/main:…/session.py | grep -n 'completed_steps' — completed_steps seeded [] and skipped on resume
git show origin/main:…/models.py | sed -n '220,246p' — Step.type Literal['agent','recipe','bash']
git show origin/main:…/models.py | sed -n '119,152p' — ApprovalConfig (timeout 0 = wait forever) + ApprovalGatePausedError
git show origin/main:examples/dependency-upgrade-staged-recipe.yaml | grep -n 'stages|approval|agent:' — staged agents + approval gates
git show origin/main:…/executor.py | wc -l (2425), …/models.py | wc -l (909), git ls-tree -r origin/main | grep -c '^examples/.*\.yaml$' (49), aggregated def test_ across 18 test files (354)
git shortlog -sn origin/main — contributor commit counts

Gaps: pytest was NOT run — 354 is a static grep of def test_, not a passing-test count. On origin/main parallel: true remains unbounded; there is no engine cap-to-3 (that lives only on an off-branch commit that changes no engine code) — no such claim is made in this deck.

Primary contributor: Brian Krabach (92 of the counted commits); also Marc Goodner (3), Diego Colombo (2), Mollie Munoz (2), Salil Das (2).