Skip to content

Workflow reference

Eight workflow definitions ship with the runtime today — six production workflows plus two deterministic test fixtures. Each is a real, runnable YAML file under agentic-workflows-v2/agentic_v2/workflows/definitions/. They are deployed alongside the runtime and exercised by the test suite, so they double as the canonical examples for every grammar feature the engine supports.

At a glance

Workflow Pattern Steps Agents Typical use case
code_review Fan-out / fan-in 5 5 Multi-perspective review of a single file with synthesis
bug_resolution Sequential with verification 5 4 Triage → root-cause → fix → regression check → write-up
fullstack_generation Parallel sub-DAG with rework 8 6 Generate API + frontend + tests in parallel, then review and rework
iterative_review Bounded loop with rework gate 5 4 Review/rework until quality gate passes or loop_max trips
conditional_branching Conditional fan-out with assembly 6 4 Branch on requirements; only execute the gates that matter
consensus_review Ensemble with majority vote 5 3 Three independent reviewers vote; summarize only on agreement
test_deterministic Tier-0 only (no LLM) 2 2 Smoke test for the executor itself; no provider needed
test_workflow Tier-0 only (no LLM) 2 2 Fixture for server and evaluation tests

Steps counts entries under steps:; Agents counts the unique agent: values referenced; and Pattern is the dominant control-flow shape — every workflow combines features, but each leans on one shape more than the others.

code_review

Multi-tier code review with a fan-out / fan-in shape. The first step parses the source file; three downstream steps run in parallel — style, complexity, and a tier-2 reviewer; the final step is a tier-2 summarizer that consolidates the three reviews into a single report.

  • Pattern: Fan-out / fan-in
  • Steps: parse_code → (style_check ‖ complexity_analysis ‖ review_code) → generate_summary
  • Agents: tier0_parser, tier1_analyzer, tier1_linter, tier2_reviewer, tier2_summarizer
  • Inputs: code_file, review_depth
  • Outputs: review, summary
  • Rubric: code_review_v1
  • When to reach for it: you want multiple specialist perspectives on a single artifact and a synthesized verdict, not three independent reports

View YAML →

bug_resolution

End-to-end defect resolution: triage classifies the bug, root-cause analysis isolates the failing module, the fix step generates a code patch, the regression-check step proposes targeted tests, and the verification step writes the human-readable report.

  • Pattern: Sequential with verification
  • Steps: triage → root_cause_analysis → generate_fix → regression_check → generate_verification
  • Agents: tier0_parser, tier1_analyzer, tier2_reviewer, tier2_summarizer
  • Inputs: bug_report, code_file, resolution_depth
  • Outputs: root_cause, fix, verification_report
  • Rubric: bug_resolution_v1
  • When to reach for it: you have a stack trace or repro and you want a scored, auditable trail from observation to fix

View YAML →

fullstack_generation

The widest workflow shipped with the runtime. After an architect designs the feature, four generators run in parallel — API, frontend, migrations, integration tests — and feed into a tier-3 reviewer. If the reviewer flags issues, a developer_rework step kicks in before the final assembler packages the artifact bundle.

  • Pattern: Parallel sub-DAG with rework
  • Steps: design_architecture → (generate_api ‖ generate_frontend ‖ generate_migrations ‖ generate_integration_tests) → review_code → developer_rework → assemble_feature
  • Agents: tier1_assembler, tier1_generator, tier2_coder, tier2_tester, tier3_architect, tier3_reviewer
  • Inputs: feature_spec, tech_stack
  • Outputs: feature_package, review_report, all_code
  • Rubric: fullstack_generation_v1
  • When to reach for it: you want to demonstrate that the runtime can drive a full-stack feature from spec to packaged artifact in one DAG

View YAML →

iterative_review

Demonstrates the loop_until: + loop_max: pattern. A tier-2 coder implements; a tier-3 reviewer scores; the loop body keeps reworking the implementation until the score crosses a quality threshold or the iteration count hits loop_max. An escalation_notice step fires if the loop exits on max-iterations rather than passing the gate.

  • Pattern: Bounded loop with rework gate
  • Steps: design → implement → review_rework_loop (looped) → escalation_notice → package
  • Agents: tier1_assembler, tier2_coder, tier3_architect, tier3_reviewer
  • When to reach for it: the artifact has a measurable quality gate and you want bounded retries before paging a human

View YAML →

conditional_branching

Showcases the when: conditional gate. After parsing requirements, the workflow branches on input parameters — depth of review, whether deployment readiness is in scope, whether a security scan is required. Only the branches whose when: expression evaluates true run; the assembler at the end coalesces whatever results are present.

  • Pattern: Conditional fan-out with assembly
  • Steps: parse_requirements → (quick_review | deep_analysis | security_scan | deployment_readiness)* → assemble_report
  • Agents: tier1_assembler, tier2_coder, tier3_architect, tier3_reviewer
  • When to reach for it: the same workflow shape applies to multiple request shapes; you want a single definition rather than four near-duplicates

View YAML →

consensus_review

A self-consistency / ensemble review pattern. Three independent tier-2 reviewers answer the same prompt in parallel; a deterministic tier-0 aggregator majority-votes their verdicts; a final summary step runs only when the vote clears the min_agreement threshold (default 0.66). The workflow's own description calls it "a usable production pattern, not a demo" — point any verdict-producing reviewer agents at it and tune min_agreement.

  • Pattern: Ensemble with majority vote
  • Steps: (reviewer_a ‖ reviewer_b ‖ reviewer_c) → vote → summarize (gated on meets_threshold)
  • Agents: tier0_consensus, tier2_reviewer, tier2_summarizer
  • Inputs: code_file, min_agreement
  • Outputs: verdict, agreement, summary (optional)
  • When to reach for it: a single reviewer's verdict is too noisy and you want agreement across independent samples before acting on it

View YAML →

test_deterministic

The smallest workflow: two steps with two tier-0 agents and no LLM calls. Used by the test suite to assert the executor, contract validator, and run recorder all work in isolation. It is also the workflow the Quick Start page asks you to run first.

  • Pattern: Tier-0 only (no LLM)
  • Steps: step1 → step2
  • Agents: tier0_counter, tier0_process
  • Inputs: input_text (required)
  • Outputs: processed_text, step_count
  • When to reach for it: smoke-testing a fresh install before swapping in real provider keys

View YAML →

test_workflow

A test fixture that mirrors test_deterministic — the same two tier-0 steps (process, then count) — but with input_text optional and defaulting to an empty string, so server and evaluation tests can run it with no inputs at all.

  • Pattern: Tier-0 only (no LLM)
  • Steps: step1 → step2
  • Agents: tier0_counter, tier0_process
  • Inputs: input_text (optional, default "")
  • Outputs: processed_text, step_count
  • When to reach for it: you need a zero-input, zero-key workflow as a fixture in server or evaluation tests

View YAML →