Augmented LLM: Agent vs. Workflow – Five Design Patterns Explained

Augmented LLM Basics

Anthropic defines an Augmented LLM as a standard large language model enhanced with three core capabilities: Retrieval (the model generates its own search queries), Tools (the model can invoke external APIs such as code execution or file I/O), and Memory (state is preserved across multiple interactions). The model is proactive—it decides when to retrieve, which tool to use, and what information to retain.

Workflow vs. Agent

The key distinction is autonomy . A Workflow follows a predefined code path, while an Agent is driven by dynamic LLM decisions.

Control flow: Workflow – predefined; Agent – LLM‑driven.

Step predictability: Workflow – fixed; Agent – open.

Typical scenario: Workflow – tasks with clear structure and high consistency; Agent – open‑ended problems requiring model judgment.

Execution: Workflow – LLM invoked at set nodes; Agent – LLM decides when to call which tool.

Reliability: Workflow – high (deterministic path); Agent – lower (introduces uncertainty).

Flexibility: Workflow – low; Agent – high.

Complexity Ladder – When to Choose Which Solution

Anthropic advises a "start simple, add complexity only when necessary" principle.

Level 1: Single LLM call + retrieval + few‑shot examples
   ↓ (if a single call cannot satisfy the need)
Level 2: Workflow (fixed or semi‑fixed pipelines)
   ↓ (if task steps cannot be predetermined)
Level 3: Agent (full autonomy with tool loops)

Conditions for each level:

Single LLM call : task completes in one interaction, context can be enriched with retrieval/examples, low latency and cost are required.

Workflow : task can be broken into fixed sub‑steps, steps have clear dependencies, high consistency and repeatability are needed, error cost is high.

Agent : problem is open, solution path cannot be predetermined, dynamic adjustment based on feedback is essential, higher latency and cost are acceptable for stronger capability.

Minimal Agent Implementation (Pure Anthropic API)

"""Minimal Agent: loop LLM + tools until task is done."""
import json
from anthropic import Anthropic

client = Anthropic()

tools = [{
    "name": "calculator",
    "description": "Perform basic arithmetic. Input: a mathematical expression string like '2 + 3' or '10 * 5'.",
    "input_schema": {
        "type": "object",
        "properties": {"expression": {"type": "string", "description": "The math expression to evaluate"}},
        "required": ["expression"]
    }
}]

def execute_tool(tool_name: str, tool_input: dict) -> str:
    if tool_name == "calculator":
        allowed = set("0123456789+-*/.() ")
        expr = tool_input["expression"]
        if all(c in allowed for c in expr):
            return str(eval(expr))
        return "Error: invalid expression"
    return f"Error: unknown tool {tool_name}"

def run_agent(task: str, max_turns: int = 10) -> str:
    messages = [{"role": "user", "content": task}]
    for _ in range(max_turns):
        response = client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if response.stop_reason != "tool_use":
            final = "".join(block.text for block in response.content if hasattr(block, "text"))
            return final
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = execute_tool(block.name, block.input)
                tool_results.append({"type": "tool_result", "tool_use_id": block.id, "content": result})
        messages.append({"role": "assistant", "content": response.content})
        messages.append({"role": "user", "content": tool_results})
    return "Error: max turns reached"

Prompt‑Chaining Pattern

Break a complex task into a fixed sequence of sub‑steps, inserting LLM‑based quality gates between steps.

Input → [Step A] → Gate → [Step B] → Gate → [Step C] → Output
          ↓                ↓
   retry if failed   retry if failed

Typical use cases: generate marketing copy → translate to multiple languages; generate outline → expand each chapter; extract key info → produce structured summary.

Pros: reduces per‑step difficulty, improves overall accuracy, gate checks catch errors early.

Cons: adds latency (multiple LLM calls), flexibility limited to the predefined order.

Routing Pattern

Classify input and dispatch to specialized downstream processors.

Input → [Classifier LLM]
          ├─ Category A → [Expert A]
          ├─ Category B → [Expert B]
          └─ Category C → [Expert C]

Typical examples: customer‑service ticket routing, language‑specific handling, model size selection (small model for simple queries, large model for complex ones).

Pros: each expert can be optimized independently, easy to extend with new categories.

Cons: overall performance hinges on classifier accuracy; mis‑classification propagates errors.

Parallelization Pattern

Run independent sub‑tasks concurrently and aggregate the results.

Input → [Task A] ──┐
        ├─ [Task B] ──→ [Aggregate] → Output
        └─ [Task C] ──┘

Variants: Sectioning (independent branches) and Voting (multiple runs of the same task with majority voting).

Pros: reduces total latency, multiple views increase reliability.

Cons: requires aggregation logic, higher token and API cost.

Orchestrator‑Workers Pattern

A central LLM (the orchestrator) dynamically decomposes a task and delegates sub‑tasks to worker LLMs, then merges their outputs.

Input → [Orchestrator]
          │
          ├─ Dynamically split into sub‑tasks
          │
          ├─ [Worker 1] → Result 1
          ├─ [Worker 2] → Result 2
          └─ …
          ↓
   [Orchestrator aggregates] → Output

Best for open‑ended problems where the number and type of sub‑tasks cannot be known beforehand.

Pros: high flexibility, can handle complex, multi‑source research tasks.

Cons: added orchestration complexity, orchestrator must be strong enough to split tasks correctly.

Evaluator‑Optimizer Pattern

A generation LLM produces output, a second LLM evaluates it against explicit criteria, and the generator revises until the evaluator approves.

Task → [Generator LLM] → Output
               ↑          │
               │          ▼
          [Evaluator LLM] ← Feedback
               ↑
               └── REVISE ──→ loop
               (if score ≥ 8 → APPROVE)

Typical use cases: literary translation with quality checks, code generation with automated review, iterative research refinement.

Pros: markedly improves final quality; evaluation criteria can be precisely defined.

Cons: incurs extra latency and cost per iteration; requires a reliable evaluator.

Key Insights

Simplicity is a competitive advantage – most real‑world problems are solved best with a well‑tuned single LLM call plus retrieval.

Tool design is as important as model prompting; clear documentation and edge‑case handling are essential.

Frameworks accelerate development but add abstraction layers that can hide bugs; understand the underlying primitives first.

The three major frameworks differ mainly in who owns the control flow: Anthropic (code‑first), OpenAI Agents SDK (hand‑off), LangGraph (graph‑based).

Every additional LLM call adds latency, token cost, and potential failure points – weigh quality gains against these costs.

Framework Comparison (Anthropic, OpenAI Agents SDK, LangGraph)

Design philosophy : Anthropic – simple first, no forced framework; OpenAI – Python‑first with balanced simplicity; LangGraph – graph‑oriented, state‑persistent.

Core primitives : Anthropic – Augmented LLM → Workflow Patterns → Agent; OpenAI – Agent + Tool + Handoff; LangGraph – StateGraph, Node, Edge, State.

Orchestration style : Anthropic – code‑first, optional framework; OpenAI – native Python code with built‑in Agent loops; LangGraph – declarative graph execution with conditional edges.

Typical scenarios : Anthropic – any scale, high controllability; OpenAI – production‑grade apps needing handoff; LangGraph – complex stateful multi‑step workflows requiring persistence and visual debugging.

Decision Tree for Choosing a Pattern

Can the task be completed in a single LLM call?
├─ Yes → No Workflow needed, use a single call.
└─ No → Are the steps fixed?
    ├─ Yes → Do steps have dependencies?
    │   ├─ Yes → Prompt Chaining.
    │   └─ No → Parallelization.
    └─ No → Need type‑based routing?
        ├─ Yes → Routing.
        └─ No → Need iterative improvement?
            ├─ Yes → Evaluator‑Optimizer.
            └─ No → Orchestrator‑Workers.

Practical Takeaway

Start with the simplest viable architecture, measure latency, cost, and quality, and only graduate to more complex patterns when the simpler solution proves insufficient. This disciplined approach keeps systems maintainable while still allowing the power of autonomous agents when truly needed.