DEV Community

Cover image for Workflow Series (01): Foundations — Three Execution Models and Anthropic's Five Patterns
WonderLab
WonderLab

Posted on

Workflow Series (01): Foundations — Three Execution Models and Anthropic's Five Patterns

#ai #workflow #claude #agents

Workflows Are Not Flowcharts

Traditional workflows are deterministic: each node is code, branch conditions are boolean expressions, failures are predefined exception types. Same input, same output, every time.

Agent Workflows break those three assumptions:

Traditional Workflow (Airflow / n8n):
  Node             = Python function / API call (deterministic)
  Branch condition = x > 0 (boolean expression)
  Failure handling = try/except (predefined exception types)

Agent Workflow:
  Node             = LLM + tools (non-deterministic output)
  Branch condition = confidence ≥ 95% (semantic judgment)
  Failure handling = retry + human escalation + semantic fallback
Enter fullscreen mode Exit fullscreen mode

Agent Workflows are one of three fundamentally different execution models, not an upgraded flowchart.

Three Execution Models

DAG (Directed Acyclic Graph)

Control flow is fully determined before execution begins. Nodes only move forward — no loops.

Examples: Airflow, n8n, GitHub Actions
Use case: data pipelines, ETL, scheduled jobs

Properties:
  → Structure is visualizable, execution order is transparent
  → No cycles (retry logic requires workarounds)
  → Right for deterministic data processing, wrong for AI tasks requiring dynamic branching
Enter fullscreen mode Exit fullscreen mode

State Machine

The system has a finite set of states. Events trigger state transitions: current state + event → next state.

Examples: LangGraph, custom workflows with JSON state files
Use case: business processes with branching, retries, and human approval gates

Properties:
  → System state is serializable at any moment (supports interrupt and resume)
  → Cycles are native (retry = state rollback)
  → workflow_state.json is the state file; approval gates are waiting-for-event states
Enter fullscreen mode Exit fullscreen mode

A Bug fix workflow as a state machine:

States: analyzing / fixing / reviewing / waiting_human / done / failed
Events: analyze_done / fix_passed / human_approved / timeout
Transitions:
  analyzing + analyze_done      → fixing
  fixing    + fix_passed        → reviewing
  reviewing + human_approved    → done
  reviewing + timeout           → waiting_human (escalate)
Enter fullscreen mode Exit fullscreen mode

Event-Driven

Nodes communicate through messages. Each node subscribes to messages, processes them, and publishes new ones. Naturally asynchronous and long-running.

Examples: Temporal, AWS Step Functions, Apache Kafka Streams
Use case: long-running workflows (> 1 hour), enterprise-grade transactions

Properties:
  → Nodes are loosely coupled — independently deployable and scalable
  → Built-in persistence and Durable Execution guarantees
  → High operational complexity; not right for fast iteration
Enter fullscreen mode Exit fullscreen mode

Which Model to Use 

Data pipeline, deterministic nodes      → DAG
Branching / retries / approval gates    → State Machine
Runtime > 1 hour, strong consistency    → Event-Driven
Enter fullscreen mode Exit fullscreen mode

Most AI Agent Workflows use the state machine model: it supports retry loops, serializable state, and interrupt-and-resume — all essential properties for AI workflows.

Anthropic's Five Core Patterns

Any Agent Workflow can be described using these five patterns. This vocabulary lets you communicate system architecture clearly with any engineer or stakeholder.

Pattern 1: Prompt Chaining 

A → B → C
each step's output is the next step's input
Enter fullscreen mode Exit fullscreen mode

When to use: Tasks decompose into ordered steps where each step's quality directly affects what follows.

Example: Bug fix workflow main chain
  Phase 1 (gather info) → Phase 2 (log analysis) → Phase 3 (root cause)
  → Phase 4 (code fix) → Phase 5 (submit) → Phase 7 (notify)
Enter fullscreen mode Exit fullscreen mode

Key constraint: One step fails, the whole chain stops. Every step needs a defined on_failure behavior.

Pattern 2: Routing 

Input → Classifier → [type A] → Agent A
                  → [type B] → Agent B
                  → [default] → Agent C
Enter fullscreen mode Exit fullscreen mode

When to use: Different input types need different processing paths.

## Routing design example (Workflow Markdown format)

After Phase 3, route based on root cause confidence:

- confidence ≥ 95%         → proceed to Phase 4 (code fix)
- 60% ≤ confidence < 95%  → trigger Gate A (human confirms root cause)
- confidence < 60%         → retry Phase 3 (different angle, max 3 times)
- still < 60% after 3 tries → escalate to human
Enter fullscreen mode Exit fullscreen mode

Key design requirement: The router must output an enumerated type, not free text. confidence < 60% is computable. "Analysis wasn't deep enough" is not.

Pattern 3: Parallelization 

         → B1 →
A → split → B2 → merge → C
         → B3 →
Enter fullscreen mode Exit fullscreen mode

When to use: Subtasks are independent and can run concurrently, or you need multiple perspectives to compare and select the best result.

# Fan-out: run 3 fix candidates concurrently
from concurrent.futures import ThreadPoolExecutor, as_completed

candidates = ["candidate_a", "candidate_b", "candidate_c"]

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = {
        executor.submit(run_fix_candidate, c, bug_info): c
        for c in candidates
    }
    results = {}
    for future in as_completed(futures):
        candidate = futures[future]
        results[candidate] = future.result()

# Fan-in: select the best passing candidate
best = max(
    (r for r in results.values() if r["passed"]),
    key=lambda r: r["test_coverage"],
    default=None,
)
Enter fullscreen mode Exit fullscreen mode

Important caveat: Parallelization speedup is capped by Amdahl's Law. Three concurrent branches plus one sequential merge step typically yields ~1.5x speedup, not 3x. (See Skill Series Article 05 for measured data.)

Pattern 4: Orchestrator-Subagents 

Orchestrator (main Agent)
  ├── spawn Subagent A (isolated session)
  ├── spawn Subagent B (isolated session)
  └── collect results → make decision
Enter fullscreen mode Exit fullscreen mode

When to use: Tasks decompose into independent subtasks, each needing focused context without access to the main Agent's full history.

Three design principles for subagents:

Principle 1: Input completeness
  The task prompt contains everything the subagent needs.
  It cannot depend on "implicit context from the main Agent."

Principle 2: Output contract strictness
  Output must conform to the declared JSON schema.
  {"passed": bool, "result": {...}, "error": str | null}

Principle 3: Structured failure output
  Even on failure, write {"passed": false, "error": "specific reason"}.
  A missing output file looks like a timeout to the main Agent.
Enter fullscreen mode Exit fullscreen mode

Pattern 5: Evaluator-Optimizer 

Generator → Evaluator → [score ≥ threshold] → output
                ↓
         [score < threshold] → feedback → Generator (retry)
                                          max_retries = 3
Enter fullscreen mode Exit fullscreen mode

When to use: Output quality matters and the first attempt may not meet the bar. Iterative improvement is viable.

# Evaluation loop definition in workflow YAML
phase_4_fix:
  generator: write-android-code
  evaluator: run-unit-tests
  quality_threshold:
    min_test_coverage: 80%
    all_tests_passed: true
  on_fail:
    max_retries: 3
    feedback_to_generator: true   # pass failure reason back to generator
  on_max_retries_exceeded:
    action: human_escalation      # escalate after 3 tries, never infinite loop
Enter fullscreen mode Exit fullscreen mode

Anti-pattern: An evaluation loop without max_retries runs forever. Evaluator feedback must name a specific problem. "Make it better" is not feedback.

Patterns Compose Into Real Workflows

Real production workflows combine multiple patterns. A Bug fix workflow contains all five:

Overall structure:    Prompt Chaining (main chain, Phase 1→7)

Phase 3 internally:   Evaluator-Optimizer (root cause analysis, max 3 retries)

Phase 3→4 transition: Routing (route by confidence score)

Phase 4 internally:   Parallelization (3 candidates concurrently)
                      + Evaluator-Optimizer (test each candidate)

Phase 5/7 writes:     Routing (human approval gate = special routing branch)

Overall control:      Orchestrator-Subagents (main Agent runs the state machine,
                      spawns a subagent for each Phase)
Enter fullscreen mode Exit fullscreen mode

Mapping each part of your system to a pattern is the starting point for design review.

Workflow Expression Formats

A workflow's "code" can take many forms. There's no single right answer:

Format Example Best for
Markdown + YAML workflow.md + config.yaml Frequent iteration; readable by non-engineers
Python code (LangGraph) StateGraph + node functions Complex state machines; code-level testing
Visual configuration (n8n) Canvas + JSON API integration-heavy; AI is just one step
Natural language AGENTS.md + task prompts Early exploration; rapid prototyping

The choice affects maintainability, testability, and execution engine selection. The next article (W2: Design Patterns) covers how to structure these files.

Summary

  1. Agent Workflows are state machines: non-deterministic nodes, semantic branching, semantic fallback — the three assumptions of traditional DAGs all fail
  2. Five patterns are a shared vocabulary: Prompt Chaining, Routing, Parallelization, Orchestrator-Subagents, Evaluator-Optimizer — any workflow can be described with these five
  3. Real workflows combine patterns: identifying which part of your system maps to which pattern is what system design ability looks like in practice

References

Check out PrimeSkills — a curated marketplace of AI agents and skills that have been validated in real-world, enterprise-grade workflows. No fluff, just what actually works.

Find more useful knowledge and interesting products on my Homepage

Top comments (0)