Agents vs workflows

1 · The word "agent" hides a decision essential

Picture the kickoff meeting you've probably sat in. Someone with budget says "let's build an AI agent that handles our support tickets," everyone nods, and a few months later you have a slow, expensive system that loops unpredictably, is painful to debug, and does a job a handful of scripted LLM calls would have done cheaper and more reliably. The failure didn't happen in the code — it happened in that first sentence, when a single word ("agent") smuggled in an architecture decision nobody actually made on purpose.

Here's the analogy that unlocks it: think of a train on rails versus a self-driving car. The train is powerful precisely because it can't improvise — it follows a fixed track, so it's predictable, cheap to run, and you always know where it will be. The self-driving car can go anywhere, but you pay for that freedom in complexity, cost, and the constant worry about what it'll do at the next intersection. Most business problems are train problems wearing a car costume. The engineering skill this whole lesson teaches is telling them apart before you lay the track — or worse, before you buy a fleet of cars.

So here is the precise distinction, the one Anthropic's Building Effective Agents guidance turns on: it's about who owns the control flow — who decides what happens next. In a workflow, you own it: you write the path in code and the LLM fills in each step (draft this, classify that, summarize the other). In an agent, the model owns it: at runtime it chooses its own next action, calls tools in a loop, and decides when it's finished. Both are "agentic systems" — both put an LLM to work on cognition — but only the second is an "agent." The common mistake is treating "agentic" and "agent" as the same word and reflexively defaulting to the car; the disciplined move is to name the control-flow owner out loud, because that one choice cascades into every cost, latency, and reliability property you will then have to live with. Everything below is really about pushing that decision toward the simplest thing that still works.

"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

When people get this decision wrong, it's almost always because they started from the technology instead of the task. "Should we use an agent, or LangGraph, or a workflow engine?" is the wrong opening question — it's like walking into a hardware store and asking "should I buy the drill or the saw?" before you've said whether you're hanging a picture or building a deck. The tool falls out of the job, not the other way around. So the picture below deliberately starts with the task and pushes technology to the very last box.

There's exactly one question that does all the work, and it's worth internalizing as a reflex: can I write down the steps before I run? Think of the difference between a recipe and a detective. A recipe is fully knowable up front — crack eggs, whisk, pour, bake — so you write it once and it runs the same every time; that's a workflow. A detective can't script the case in advance, because each clue changes what to investigate next; the path only reveals itself in motion. That's an agent. Most tasks that feel like detective work turn out to be recipes once you actually try to enumerate them — which is exactly why the "start simple" instinct pays off. When you truly cannot list the steps ahead of time, and the input genuinely dictates a different path each run, you've found the narrow case that earns an agent. Read the diagram with that single fork in mind: everything to the left is "what do I need," the middle is the one real decision, and everything to the right is a consequence of it.

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

"Workflow first" can sound like timid engineering — until you get the bill. The first time a team ships an agent to production and watches the token spend climb without a ceiling, the abstract advice suddenly becomes concrete. The reason isn't that agents are wasteful by nature; it's that autonomy has a specific, compounding cost structure, and if you can't see the shape of that structure you can't reason about when it's worth paying.

Here's the mental picture. A workflow is a taxi with a fixed route: three stops, a known fare, and you can predict to the dollar what the trip costs before you leave. An agent is a taxi with the meter running while the driver figures out the route as they go — and, crucially, the meter speeds up the longer the trip runs. That second part is the piece beginners miss: it's not just that an agent makes an unknown number of calls. It's that every turn re-sends the whole growing conversation (the observations so far, the tool results, the reasoning), so a call on turn 8 is processing far more tokens than the call on turn 1. Unknown length times growing cost-per-step is why agent spend curves upward rather than climbing in a straight line.

That single fact ripples into four properties, which the table below lays out side by side. Cost is bounded for a workflow (you can count the calls) and unbounded for an agent (it loops until done or capped). Latency is predictable and often parallelizable in a workflow, but a chain of serial round-trips in an agent — each turn waits for the last. Reliability favors the workflow because every step is testable in isolation, whereas an agent's errors compound: a wrong turn on step 3 poisons every step after it. And debuggability collapses in an agent because the path varies per run — the exact failure you saw yesterday may be unreproducible today. None of this makes agents bad; it makes them expensive, and expensive things need to earn their place. Read the code sketch after the table as a model of the shape, not a benchmark — the numbers are illustrative, but the upward curve is real.

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

You've felt the failure this pattern fixes. You write one big prompt asking the model to "read this document, pull out the action items, prioritize them, and draft an email" — and the output is a muddle: it half-does each part, drops one entirely, and you can't tell which instruction it fumbled. Cramming several tasks into a single call is the LLM equivalent of asking someone to juggle while reciting poetry: possible, but everything gets a little worse. Prompt chaining is the fix, and it's the simplest step up from a single call.

The analogy is an assembly line. Instead of one worker building the whole car, each station does one job well and passes the result to the next: outline, then draft, then polish. Each step is smaller, so the model does it more reliably; and because the output of step one becomes the input of step two, the sequence composes into the full task. The precise definition: prompt chaining decomposes a task into a fixed, ordered series of LLM calls where each call's output feeds the next. "Fixed and ordered" is the whole point — you wrote the sequence in code, so it's a workflow, not an agent deciding the order at runtime.

The feature that turns a chain from a toy into something production-grade is the gate — a cheap check between steps that bails out early if a step produced junk. Think of it as quality control on the assembly line: if the outline came back empty, there's no point spending money drafting from it, so you stop and flag the failure. The common mistake here is the opposite of over-engineering — it's forgetting the gate entirely, letting a bad step-one output silently corrupt everything downstream until you're debugging a polished essay built on a broken outline. Add the gate, and each link in the chain becomes independently checkable, which is exactly the reliability property a single mega-prompt can never give you.

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

Here's the trap chaining doesn't solve. Suppose your support inbox gets billing questions, bug reports, and "what are your hours?" all mixed together. Write one prompt to handle all three and you're forced to stuff every instruction — refund policy, debugging steps, store hours — into one enormous system prompt, and the model does each job a little worse for the distraction. Worse, you're paying for a big, capable model on the trivial "what are your hours?" query when a tiny cheap one would nail it. Different kinds of input want different handling, and one prompt can't gracefully be all things at once.

The analogy is a hospital triage nurse. The nurse doesn't treat anyone — their entire job is a fast, cheap classification: chest pains go to cardiology, a broken wrist to orthopedics, a cold to the general clinic. The expensive specialists only ever see the cases meant for them, so each stays focused and efficient. Routing is that nurse: a cheap up-front classify step decides the category, then dispatches to a specialized handler built for exactly that category. The precise definition: routing classifies an input, then sends it down one of several distinct, specialized paths.

Two wins fall out of this, and naming them helps you spot when routing is the right reach. First, separation of concerns: each handler only ever sees its own kind of input, so its prompt stays small, focused, and testable — you can improve the billing path without touching the technical one. Second, a cost lever: since most real-world traffic is easy, you can route the bulk to a small cheap model and reserve the big expensive one for the genuinely hard cases. The common mistake is skipping the classifier and building one god-prompt with a pile of if-this-then-that instructions inside it — that's routing done badly, buried in a single call where you can't measure or tune it. Pull the classification out into its own explicit step and the whole thing becomes a debuggable dispatch table, as the lab shows.

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

Two very different problems, one shape. First problem: you need to summarize 200 documents, and doing them one after another means your user stares at a spinner for two minutes while calls that have nothing to do with each other wait politely in line. Second problem: you're asking the model a genuinely hard judgment call — "is this comment abusive?" — and a single answer feels like a coin flip you can't fully trust. Both are solved by running LLM calls at the same time rather than in sequence, and Anthropic splits this into two flavors worth keeping straight.

Sectioning is the first: break a task into pieces that don't depend on each other and run them concurrently. The analogy is a newspaper — you don't wait for the sports section to be written before starting the business section; different reporters write different sections simultaneously, and an editor staples them together at the end. Summarize each of the 200 documents in parallel, then join the results. The payoff is latency: the whole job takes about as long as the single slowest piece, not the sum of all of them.

Voting is the second, and it feels backwards until you see it: run the same task several times and aggregate the answers — majority vote, or best-of. The analogy is a panel of judges rather than a lone referee; any single judge can have an off moment, but the majority is far more stable. Here you deliberately spend more calls to buy confidence on a call that's too important to get wrong once. The key insight that ties both flavors together — and the design decision you can't skip — is the aggregation step: fan work out, then decide how you fan it back in. Concatenate for sectioning, take the majority for voting. The common mistake is treating the two as interchangeable: sectioning divides different work to save time; voting repeats the same work to raise reliability. Reach for the one whose payoff — speed or confidence — matches what your problem actually lacks.

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

Sectioning had a quiet assumption baked in — and this is the pattern for when it breaks. When you summarize 200 documents, you already knew there were 200 pieces and what each piece was; the split lived in your code. But consider "refactor the auth module": you genuinely cannot know up front how many files it touches, or which ones, until something intelligent looks at the codebase. You can't write the fan-out in advance because the fan-out depends on the input. That's the gap orchestrator-workers fills.

The analogy is a general contractor on a renovation. The homeowner says "update the kitchen"; the contractor walks the site and decides what the job actually decomposes into — call a plumber for the sink, an electrician for the outlets, a tiler for the floor — dispatches each specialist, then assembles the finished result. The homeowner never listed those subtasks; the contractor figured them out on arrival. The precise definition: a central orchestrator LLM decomposes the task at runtime into a variable number of subtasks, dispatches a directed worker call for each, and synthesizes the results into one answer.

Now the subtle part, because this is exactly where people start calling things "agents" that aren't. Compared to sectioning, the difference is who decides the split: in sectioning you fixed it in code, here the model decides it at runtime. That dynamic decomposition is genuinely a step toward agency — the model is making a real planning decision. But it is still a workflow, and the reason is precise: the workers are bounded, directed calls, not a free-running loop. The orchestrator says "summarize file X" and gets exactly that back; there's no worker deciding on its own to go investigate three more files. The common mistake is seeing "the model decides" and concluding "it's an agent" — no. The model deciding the decomposition while you still control that each worker is a single directed call is the bridge between the two worlds, and keeping the workers bounded is what keeps you on the workflow side of it.

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

Some outputs are never right on the first try, and you know it. A literary translation, a tricky piece of copy, a deep research answer — the first draft is a starting point, not a finish. A human writer knows this instinctively: they write, step back, critique their own work ("this paragraph is vague, the ending is weak"), and revise. The mistake is expecting a single LLM call to produce polished work when even skilled humans iterate. Evaluator-optimizer bottles that write-critique-revise cycle into a controlled loop.

The analogy is a writer with a demanding editor. The writer produces a draft; the editor reads it against clear standards and hands back specific, actionable notes ("add a concrete example here, tighten the intro"); the writer revises; the cycle repeats until the editor signs off. Two distinct roles, real feedback flowing between them. The precise definition: one LLM call generates, a second evaluates against explicit criteria and returns feedback, the generator revises with that feedback, and you repeat until it passes or you hit a cap. It only works when the criteria are clear enough that a critic can articulate why a draft falls short — vague "make it better" feedback gets you nowhere.

And here is the point that this section exists to hammer home, because it's the single most common confusion in this whole lesson: this has a loop, but it is still a workflow, not an agent. The distinction is who owns the loop. In evaluator-optimizer you own it — you wrote two fixed roles, you defined the scoring function, and above all you set a hard round cap so the loop is guaranteed to terminate whether or not the output ever passes. The model never decides to keep going; your for loop does. Contrast that with the agent in §9, where the model itself decides each next action and when it's done. The rule to carry away: a bounded, self-terminating loop with roles you defined is a workflow; a model-directed loop that stops only when the model says "done" is an agent. Keep the cap, and you keep control.

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

We climbed the whole ladder to get here, and that was the point. Every pattern so far kept you in charge of the path — even the ones with loops and runtime decisions. The autonomous agent is the moment you finally hand the steering wheel to the model, and it belongs at the top of the ladder precisely because you should reach it last, after the cheaper patterns have failed to fit. This is the detective from §2 made real: a system that plans, acts, observes what happened, and decides its own next move, turn after turn, until it judges the job done.

The defining mechanic is the act-observe loop owned by the model. It picks an action (call a tool, read a file, run a command), sees the result, and feeds that observation back into its own next decision — no path you wrote, no fixed number of steps. That's genuine power: it can handle tasks you truly cannot script, like "investigate this alert" where each finding changes what to look at next. But it's also why the agent inherits every cost from §3 at full strength — unbounded loops, compounding errors, a path that differs each run — and why its only guaranteed brake is a step cap you impose from outside.

So the real skill isn't building the loop (Chapter 4 did that); it's the discipline to run the gate check before you build it. Anthropic's published "should this be an agent?" test has four gates, and the mental move is to treat any single "no" as a veto that sends you back down to compose workflows instead. Complexity — is the task genuinely un-scriptable, or does it just feel that way until you try to enumerate it? Value — does the autonomy actually pay for its higher cost and latency, or are you buying a Ferrari to fetch groceries? Model capability — is the model reliably good at this specific task, or will it confidently wander off? Cost of error — are mistakes cheap and recoverable, or does a wrong action delete data with no human in the loop? The common mistake is running this check after falling in love with the agent idea and rationalizing the answers; run it honestly first, and most "agent" requests resolve into a couple of workflow patterns you can actually test.

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

The requests never arrive labeled. No stakeholder walks up and says "I'd like a routing workflow with a voting step." They say "can we get AI to just handle the returns queue?" or "build me something that reads the contracts and tells me what's risky." The whole value you add as a lead is translation — hearing the vague ask and naming the concrete pattern hiding inside it, then pushing the design toward the simplest rung on the ladder that still clears the bar. Doing that well is worth more than knowing any single framework.

The trick is to listen for the verbal tell, because natural language leaks the control flow. "First do X, then Y" is someone describing an ordered pipeline — that's prompt chaining. "Handle each type differently" is categories wanting specialized handlers — routing. "Do all of these" or "be more sure about this" is independent work or a confidence problem — parallelization. "Break it up, but it depends on the input" is runtime decomposition — orchestrator-workers. "Keep improving it until it's good" is iterate-against-criteria — evaluator-optimizer. Only "just figure it out and handle it," with a path nobody can enumerate, points toward an actual agent — and even then you run the four-gate check from §9 before committing. The table below is that translation reflex written down; internalize it and you'll classify most requests in the meeting they're raised.

One warning that separates senior judgment from enthusiasm: the tech-lead move is not to reach for the most powerful pattern that could work. It's to reach for the simplest pattern that meets the bar, and to say "no" — clearly and early — to premature autonomy. A set of composed workflows you can test, reproduce, and cost out beats an impressive agent you can't debug at 2am. And remember these patterns nest: a mature system might route an input, chain the handling of it, run a guardrail check in parallel alongside, and escalate only the genuinely open-ended sliver to an agent. You are assembling composable pieces, not declaring the whole thing "an agent" from the outset — that composition, not the autonomy, is where the engineering maturity shows.

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.