Agents vs workflows

1 · The word "agent" hides a decision essential

"We should build an agent for this" is where a lot of LLM projects go wrong. In Anthropic's published engineering writing (the Building Effective Agents post), the useful split is between workflows — systems where you code the path and the LLM fills in the steps — and agents — systems where the LLM decides the path at runtime, directing its own tool use in a loop. Both are "agentic systems"; only one is an "agent." The decision between them is the first and most consequential design choice you make.

Per Anthropic's current guidance (verify in their docs, as wording evolves), the headline advice is deliberately unglamorous: find the simplest solution possible, and only increase complexity when it demonstrably improves outcomes. A single well-prompted call beats a workflow when it suffices; a workflow beats an agent when the steps are knowable. You climb that ladder only as far as the problem forces you.

2 · The decision, in one picture essential

The fork is about how well you can specify the task. If you can write down the steps up-front, you want a workflow: predictable, cheap, testable. If the task is open-ended — the steps depend on what the model discovers as it goes — you may need an agent. Everything else is choosing which workflow pattern fits.

Read it left-to-right. The middle node is the only real question: can you enumerate the steps before you run? If yes, pick a workflow pattern (§4–§8) — you keep control, the system is debuggable, and each step is independently testable. If no — the path truly varies with the input and can't be scripted — that's the narrow case where an agent (§9) earns its cost.

3 · Why autonomy is expensive intermediate

Why is "workflow first" the default rather than a stylistic preference? Because an autonomous agent pays real, compounding costs a fixed workflow avoids. A workflow makes a known number of calls on a known path; an agent loops an unknown number of times, each turn re-sending a growing context.

cost_model.pydef workflow_cost(steps, cost_per_call):
    """A workflow makes a FIXED number of calls."""
    return steps * cost_per_call

def agent_cost(avg_loops, cost_per_call, context_growth=1.0):
    """An agent loops an unknown number of times; each turn re-sends a
    growing context, so later calls cost more."""
    total = 0.0
    for turn in range(avg_loops):
        total += cost_per_call * (context_growth ** turn)
    return total

wf = workflow_cost(steps=3, cost_per_call=0.01)
ag = agent_cost(avg_loops=8, cost_per_call=0.01, context_growth=1.2)
print(f"workflow (3 fixed calls): ${wf:.3f}")
print(f"agent  (8 growing loops): ${ag:.3f}")
print(f"agent is ~{ag/wf:.1f}x the workflow here")

workflow (3 fixed calls): $0.030
agent  (8 growing loops): $0.165
agent is ~5.5x the workflow here

4 · Pattern 1 — Prompt chaining intermediate

When to use: the task splits cleanly into fixed, ordered subtasks, each easier and more reliable than doing it all in one shot — and you can check the work between steps. Anthropic's canonical example: draft, then translate; or outline, then write. Each step's output is the next step's input.

Spot it in the wild: any "first do X, then do Y with the result" pipeline — generate-then-format, extract-then-summarize. If you find yourself asking one prompt to do three things, that's usually a chain wanting to be split — with an optional gate between steps that bails early if a step fails a check.

chaining.pydef step(name, text):
    """Offline stand-in for an LLM call: deterministic, no network."""
    return f"[{name}] {text}"

def gate_ok(text):
    """A cheap check between steps (e.g. 'did the outline have >=1 section?')."""
    return "outline" in text

def chain(topic):
    outline = step("outline", topic)
    if not gate_ok(outline):                 # gate: stop early if step 1 failed
        return "ABORT: outline failed its check"
    draft = step("draft", outline)           # each step feeds the next
    polished = step("polish", draft)
    return polished

print(chain("a blog post about caching"))

[polish] [draft] [outline] a blog post about caching

5 · Pattern 2 — Routing intermediate

When to use: inputs fall into distinct categories that are each handled better by a specialized prompt (or a different-sized model), and you can classify the input reliably. Anthropic's example: route customer queries to the right specialized handler; send easy cases to a small cheap model and hard ones to a big one.

Spot it in the wild: a classify-then-dispatch shape. The win is separation of concerns — each handler stays simple because it only sees its own kind of input — plus a cost lever: most traffic is easy and can go to a cheaper model.

routing.pydef classify(query):
    """Offline classifier — a real one would be a cheap model call."""
    q = query.lower()
    if "refund" in q or "charge" in q: return "billing"
    if "error" in q or "crash" in q:   return "technical"
    return "general"

def handle_billing(q):   return f"BILLING desk: {q}"
def handle_technical(q): return f"TECH desk: {q}"
def handle_general(q):   return f"GENERAL desk: {q}"

ROUTES = {"billing": handle_billing, "technical": handle_technical,
          "general": handle_general}

def route(query):
    kind = classify(query)               # cheap step decides the path
    return ROUTES[kind](query)           # specialized handler does the work

for q in ["I want a refund", "the app crashed", "what are your hours"]:
    print(route(q))

BILLING desk: I want a refund
TECH desk: the app crashed
GENERAL desk: what are your hours

6 · Pattern 3 — Parallelization (sectioning & voting) advanced

When to use: the work can be split into independent pieces that run at once. Anthropic describes two flavors. Sectioning: break a task into subtasks that don't depend on each other and run them in parallel (e.g. one call per document, or one guardrail check running alongside the main answer). Voting: run the same task several times and aggregate — majority vote or best-of — to raise reliability on a hard judgment.

Spot it in the wild: a fan-out/fan-in shape. Sectioning cuts latency (pieces run concurrently); voting trades extra cost for confidence. Both need an aggregation step — the design choice is how you combine the partial results.

parallel.pyimport hashlib
from collections import Counter

def step(worker, item):
    """Offline stand-in for a per-piece model call."""
    return f"{worker}:{item}"

def sectioning(docs):
    """Independent subtasks -> run each, then combine (fan-out / fan-in)."""
    partials = [step("summ", d) for d in docs]      # would be concurrent
    return " | ".join(partials)                      # aggregation step

def one_run(task, i):
    """Deterministic stand-in for one model verdict (stable across runs)."""
    h = int(hashlib.md5(f"{task}:{i}".encode()).hexdigest(), 16)
    return "flag" if h % 4 == 0 else "safe"

def voting(task, runs=5):
    """Same task many times -> majority vote for reliability."""
    votes = [one_run(task, i) for i in range(runs)]
    winner, n = Counter(votes).most_common(1)[0]
    return f"verdict={winner} ({n}/{runs} agreed)"

print(sectioning(["doc1", "doc2", "doc3"]))
print(voting("is this comment abusive?"))

summ:doc1 | summ:doc2 | summ:doc3
verdict=safe (4/5 agreed)

7 · Pattern 4 — Orchestrator-workers advanced

When to use: you can't enumerate the subtasks up-front — the number and shape of the pieces depend on the input — but a central LLM can decompose the problem, and the pieces are still done by directed worker calls. Anthropic's example: a coding change that touches an unknown set of files, where an orchestrator decides which files and dispatches a worker per file, then synthesizes the results.

Spot it in the wild vs. parallelization: in sectioning you fix the split in code; in orchestrator-workers the model decides the split at runtime. It's the bridge toward agency — dynamic decomposition — but the workers are still bounded, directed calls, not a free-running loop. That's what keeps it a workflow.

orchestrator.pydef step(role, payload):
    """Offline stand-in for a model call."""
    return f"[{role}] {payload}"

def orchestrator(task):
    """A central step decides the subtasks at RUNTIME (count varies)."""
    if "refactor" in task:
        subtasks = ["rename symbols", "update imports", "fix tests"]
    else:
        subtasks = ["do it"]
    return subtasks

def worker(subtask):
    return step("worker", subtask)

def run(task):
    subtasks = orchestrator(task)                    # model picks the pieces
    results = [worker(s) for s in subtasks]          # a directed call each
    return step("synthesize", " + ".join(results))   # combine

print(run("refactor the auth module"))

[synthesize] [worker] rename symbols + [worker] update imports + [worker] fix tests

8 · Pattern 5 — Evaluator-optimizer professional

When to use: there are clear evaluation criteria and iteration measurably improves the output — and, crucially, a critic can articulate why a draft falls short. Anthropic's examples: literary translation, or deep search where a second pass catches what the first missed. One call generates; another evaluates against the criteria and hands back feedback; the generator revises; repeat until it passes or you hit a cap.

Spot it in the wild: a generate → critique → revise loop with a bounded number of rounds. It looks agent-ish, but the control flow is fixed: two roles, a scoring function, and a hard iteration cap. Don't confuse it with a full agent — the loop is your loop, not the model's.

evaluator.pydef generate(prompt, feedback=""):
    """Offline stand-in — appends any feedback to simulate improvement."""
    base = len(prompt)
    return {"text": prompt + feedback, "quality": base + len(feedback)}

def evaluate(draft, target=30):
    """Score against clear criteria; return pass + actionable feedback."""
    if draft["quality"] >= target:
        return True, ""
    return False, " [add detail]"

def optimize(prompt, max_rounds=5):
    feedback = ""
    for r in range(max_rounds):                  # HARD cap -> always terminates
        draft = generate(prompt, feedback)
        ok, feedback = evaluate(draft)
        if ok:
            return f"passed on round {r+1}: {draft['text']!r}"
    return "hit round cap without passing"

print(optimize("translate this line"))

passed on round 2: 'translate this line [add detail]'

9 · The autonomous agent — and when it's justified professional

When to use: the task is open-ended, you can't predict the number or order of steps, and the model needs to act on feedback from a real environment (tools, files, shell) over many turns. Anthropic's framing: agents are for problems where you can't hard-code the path, and where the value justifies higher cost, higher latency, and lower predictability. The model plans, acts, observes the result, and decides the next action — in a loop — until it judges the task done.

Anthropic's published "should this be an agent?" check has four gates: complexity (is it genuinely hard to script?), value (does the autonomy pay for its cost?), model capability (is the model actually good at this task?), and cost of error (are mistakes recoverable, or gated by a human?). If any gate is "no," compose the workflow patterns above instead.

agent.pydef model_decides(observations):
    """Offline stand-in for the LLM choosing its OWN next action.
    Returns ('act', tool) to keep going, or ('done', answer) to stop."""
    if len(observations) < 3:                    # pretend it needs 3 lookups
        return ("act", f"lookup_{len(observations)}")
    return ("done", f"answer from {observations}")

def agent(goal, max_steps=10):
    """The MODEL owns the control flow — path varies per run."""
    observations = []
    for step in range(max_steps):                # cap = the only safety rail
        action, payload = model_decides(observations)
        if action == "done":
            return f"[{step} steps] {payload}"
        observations.append(payload)             # act -> observe -> loop
    return "stopped: hit step cap"

print(agent("investigate the alert"))

[3 steps] answer from ['lookup_0', 'lookup_1', 'lookup_2']

10 · Recognizing the patterns — a field guide tech-lead

A lead's real skill here is naming the pattern behind a vague request and pushing the design down the complexity ladder. Most "build an agent" asks decompose into one or two workflow patterns that are cheaper, faster, and testable. Use this as the translation table:

The tech-lead move is not to pick the most powerful pattern; it's to pick the simplest pattern that meets the bar, and to say no to premature autonomy. A composed set of workflows you can test beats an impressive agent you can't reproduce.

11 · Check yourself tech-lead

Orchestrator (LLM): given a company name, decides which sub-tasks are needed,
                    e.g. [funding history, product line, recent news, headcount].
      |  spawns (in parallel)
      v
Worker 1: search + summarize funding
Worker 2: search + summarize product line
Worker 3: search + summarize recent news
      |  results returned
      v
Orchestrator: synthesizes workers' outputs into one brief, drops empties.