Workflow vs Agent: When Do You Actually Need One?

Introduction

You can now build an agent from scratch (L111) and you know the architectures (L112). This lesson asks the question that should come before any of that — and the one most teams skip straight past: do you actually need an agent at all?

It matters because "agent" is the most over-applied word in the field. The autonomous loop is powerful, but it's also the most expensive, least predictable, hardest-to-debug way to use an LLM. Reaching for it by default is how projects end up slow, costly, and flaky. The discipline that separates strong engineers here is captured in one line from Anthropic's Building Effective Agents: find the simplest solution possible, and only increase complexity when needed — "this might mean not building agentic systems at all."

In this lesson:

The precise line between a workflow and an agent (it's about who controls the control flow)
The autonomy ladder — agency is a spectrum, not a yes/no
The decision: when to climb to a full agent (the four criteria) — and when a workflow wins
The honest cost of autonomy, and the red flags that you built an agent you didn't need

An infographic titled 'Workflow vs Agent — When Do You Actually Need One?'. The most-skipped decision in agent engineering, framed by Anthropic's rule: find the simplest solution possible and add complexity only when it demonstrably improves outcomes — often that means NOT building an agent. Two definitions: a Workflow runs LLMs and tools on predefined code paths (you write the control flow, the LLM fills the steps; predictable, testable, roughly fixed cost); an Agent lets the LLM dynamically direct its own process and tool use in a loop (it decides the path; flexible, open-ended, far costlier). The autonomy ladder (after HuggingFace smolagents), climbed only as far as the task forces you: Single LLM call (no orchestration — one prompt plus retrieval or examples; most tasks live here) → Router (the LLM picks one of a few known branches; still a workflow) → Workflow chain or tool calls (a predefined multi-step path; the LLM fills each step) → Agent (the LLM controls iteration, its own steps until done; only when the path can't be hardcoded). Stay a workflow when you can map the steps in advance, the path is fixed or has a few known branches, and steps are known and repeatable — if you can map the decision tree, build it: more accuracy, more control, lower cost than any agent. Go agent only when all four hold: Complexity (path can't be hardcoded — open-ended, unknown number of steps), Value (the outcome justifies the cost), Viability (the model is actually good at it), Cost of error (mistakes are catchable and recoverable). The honest cost: agents cost about 3 to 10 times a chat call because the loop re-bills the growing transcript, add latency, and compound errors; they're harder to test and debug than a fixed path. Red flags that you built an agent you didn't need: a rule-based workflow already works; you're encoding rules like do X if value greater than Y in the prompt; you rely on a fixed step sequence in the system prompt; you're constantly constraining the agent's behavior. Banner: don't ask how do I build an agent, ask what's the simplest thing that works; climb the ladder one rung at a time and stop the moment the task stops forcing you higher.

Two Definitions: Workflow vs Agent

Anthropic draws the line cleanly, and it's worth memorizing:

Workflow — "systems where LLMs and tools are orchestrated through predefined code paths." You write the control flow; the LLM fills in the steps (classify this, draft that, pick branch A or B).
Agent — "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." The LLM decides what to do next, in a loop, until it's done.

The single distinguishing question is who owns the control flow — your code, or the model? Same task, two ways:

# WORKFLOW — YOU own the control flow. Predictable, testable, ~fixed cost.
def handle_ticket(ticket):
    category = classify(ticket)                       # fixed step 1
    priority = score_priority(ticket)                 # fixed step 2
    draft    = draft_reply(ticket, category, priority)# fixed step 3
    return route(category, priority, draft)           # plain code decides where it goes

# AGENT — the LLM owns the control flow. Flexible, open-ended, far costlier.
run_agent("Resolve this support ticket end to end.",
          tools=[search_kb, lookup_order, issue_refund, escalate, draft_reply])
# ↑ the model decides WHICH tools, in WHAT order, and HOW MANY steps — you don't.

Both use the same LLM and the same tools. The difference is agency: in the workflow, the sequence is yours and the LLM is a component; in the agent, the sequence itself is the model's to decide. That shift — from "LLM as a step" to "LLM as the orchestrator" — is what buys flexibility and what costs you predictability, money, and easy debugging.

Agency Is a Spectrum — The Autonomy Ladder

"Workflow vs agent" sounds binary, but it's really a continuum of how much control you hand the model. HuggingFace's smolagents frames it as levels of agency — and seeing them as code makes the ladder concrete:

# "Agency" is a SPECTRUM — how much does the LLM control your program's flow?
process(llm(x))                                # ☆☆☆  no agency — you just use the output
if llm_decides(x):  path_a()                   # ★☆☆  Router — LLM picks a branch (still a
else:               path_b()                   #        workflow: you wrote the branches)
run(llm_chosen_tool, **llm_chosen_args)        # ★★☆  Tool call — LLM picks the action
while llm_should_continue():                   # ★★★  AGENT — the LLM controls the LOOP:
    do_the_next_step_it_chose()                #        its own steps, until it decides "done"

Each rung gives the LLM more control over your program's flow:

☆☆☆ Single call — the LLM's output has no control over flow; you use the result. Most tasks (classification, extraction, summarization, Q&A) are genuinely here.
★☆☆ Router — the LLM picks one of a few known branches. Still a workflow — you wrote the branches.
★★☆ Workflow (chain / tools) — a predefined multi-step path; the LLM fills each step or picks a tool, but the structure is yours. (These are the 5 patterns in the next section.)
★★★ Agent — the LLM controls the loop itself: its own steps, in its own order, until it decides it's done. This is the autonomous loop from L110–L111 (The Agent Loop → Building a ReAct Agent From Scratch).

(Beyond this sits multi-agent — one loop spawning others — which we cover later in the container.) The whole skill is this: climb only as far up the ladder as the task forces you, and not one rung higher.

The Decision: Should You Build an Agent?

Here's the test, and it's refreshingly blunt. Can you map the steps in advance?

Yes (the path is fixed, or has a handful of known branches) → build the workflow. As the field's consensus puts it: "if you can map the decision tree, build it and optimize each node — you'll get more accuracy, more control, and lower cost than any agent will give you."
No (the path is open-ended; you genuinely can't predict the steps, their number, or their order) → an agent may be warranted.

Before committing to the agent, run Anthropic's four-part check — all four must hold:

Criterion	The question	If "no" →
Complexity	Is the task genuinely open-ended / impossible to hardcode a path for?	a workflow is simpler & better
Value	Does the outcome justify higher cost & latency?	stay cheaper
Viability	Is the model actually good at this task?	don't ship an unreliable loop
Cost of error	Are mistakes catchable & recoverable (tests, review, rollback)?	too risky to let it run free

Fail any one and you drop back down the ladder. An agent is the right tool for "turn this vague design doc into a working PR" — open-ended, valuable, the model is capable, and a CI/review safety net catches errors. It's the wrong tool for "extract the invoice total from this PDF" — which is a single call.

Decide It for Your Own Task

Stop guessing and run your task through the ladder. Answer the four questions below for something you're actually building — the guide sums the signals (can you map it? how many steps? how dynamic? how risky?) and shows the lowest rung that will serve you. Watch how often the honest answer is lower than your instinct:

Answer the four questions for a task you actually have. The guide sums the signals and shows how far up the autonomy ladder you really need to climb — and flags when a simpler rung would serve you better. The honest default sits lower than most people reach for.

The pattern you'll notice: it takes real, irreducible unpredictability to justify the top rung. If your task has a knowable shape, the ladder keeps you in workflow territory — which is exactly where you want to be for cost, reliability, and your own debugging sanity.

The Honest Cost of Autonomy

Why be so reluctant to climb? Because autonomy is expensive in every dimension that matters in production:

Money: ~3–10× a single chat call. The loop re-sends the growing transcript every step (the triangular cost from L110 — The Agent Loop), and the model often takes more steps than a hardcoded path would. A workflow has a roughly fixed token budget per run; an agent's is open-ended.
Compounding errors. In a long autonomous run, a small early mistake snowballs — the agent builds its next step on a flawed observation, and minor failures cascade into catastrophic ones. A fixed workflow has far fewer places to go wrong.
Latency. More steps, each a round-trip, means seconds-to-minutes instead of one call.
Testability & debuggability. A workflow is deterministic-ish code you can unit-test node by node; an agent's trajectory varies run to run, so you're debugging a distribution of behaviors, not a path.

This is why the 2026 consensus is blunt: most production systems should default to workflows, adding agents only where genuine autonomous decision-making is necessary and has been thoroughly tested. Predictability is a feature. Sometimes the cheapest, most reliable "agent" is plain code with a rule — even classic RPA — for narrow, structured work.

Red Flags: You Built an Agent You Didn't Need

Watch for these symptoms — each one means the ladder is telling you to drop a rung:

🚩 A simple rule-based workflow already solves it reliably. If if priority == 'high': escalate() works, you don't need a reasoning loop to decide that.
🚩 You're encoding rules in the prompt — "do X if the value is over Y", "always check the database first." Rules belong in code, where they're testable and free, not in a prompt you hope the model follows.
🚩 You rely on a fixed sequence baked into the system prompt — "first do A, then B, then C." If the sequence is fixed, write the sequence — that's a chain (a workflow), not an agent.
🚩 You're constantly fighting to constrain the agent's behavior. If most of your prompt engineering is stopping the model from doing things, you wanted a workflow with guardrails, not an open loop.

The tell across all four: you already know the control flow — so encode it. Handing a known procedure to an autonomous loop just adds cost, latency, and a chance for the model to deviate from the plan you already had. (Next lesson, Anatomy of Agent Failure, dissects what goes wrong when an agent is warranted but still breaks.)

🧪 Try It Yourself

Classify each system — single call, workflow, or agent — and defend it in one line. Then use the widget to check your instinct.

Extract name, email, and total from an invoice PDF.
Support triage: classify a ticket, score priority, draft a reply, route it — the same three steps every time.
"Investigate why this flaky test fails and open a PR with the fix" — unknown root cause, unknown steps.
Customer query that's either an order-status lookup OR a return request — two known paths.

→ (1) Single LLM call — one extraction, no orchestration. (2) Workflow (prompt chain) — a fixed, known three-step sequence; write the sequence, don't hand it to a loop. (3) Agent — genuinely open-ended (you can't map the steps), valuable, model-capable, and errors are caught by CI/review: all four criteria hold. (4) Workflow (router) — two known branches; the LLM just picks which, then a fixed path runs.

The lesson in the set: only #3 earns an agent. If you reached for one on #2 or #4, you felt the pull this lesson is inoculating you against.

Mental-Model Corrections

"Agents are the advanced/modern way; workflows are old-fashioned." No — they're different tools. A workflow you can fully specify is better than an agent on that task: cheaper, more reliable, more controllable. Defaulting to agents is an anti-pattern.
"Workflow vs agent is a binary choice." It's a spectrum of autonomy (single call → router → chain → agent → multi-agent). Pick the lowest rung that does the job.
"More autonomy = more capable." More autonomy = more cost, latency, and variance. Capability comes from the model + tools + context, not from removing your control over the flow.
"If it uses an LLM and tools, it's an agent." Only if the LLM controls the flow. A pipeline of LLM calls on a path you wrote is a workflow, no matter how many tools it touches.
"Build the agent first, simplify later." Backwards. Start at the simplest rung, climb only when it measurably falls short. Add complexity only when it demonstrably improves outcomes.
"We need an agent because the task is important." Importance argues for reliability — which usually means a workflow. Reserve agents for tasks that are genuinely unpredictable, not merely valuable.

Key Takeaways

Ask "what's the simplest thing that works?" before "how do I build an agent?" Anthropic's rule: find the simplest solution; add complexity only when it demonstrably improves outcomes — often that means no agent.
Workflow vs agent = who owns the control flow. Workflow: you orchestrate predefined paths (predictable, testable, ~fixed cost). Agent: the LLM dynamically directs its own loop (flexible, open-ended, costlier).
Agency is a ladder: single call → router → workflow (chain/tools) → agent → multi-agent. Climb only as far as the task forces you.
Go agent only when all four hold: Complexity (can't hardcode the path), Value (justifies the cost), Viability (model is capable), Cost of error (mistakes are recoverable). If you can map the decision tree, build it.
Autonomy's honest cost: ~3–10× the price, compounding errors, more latency, harder to test. Most production systems should default to workflows.
Red flags you over-built: a rule works · you're encoding rules in the prompt · you rely on a fixed sequence in the system prompt · you keep fighting to constrain it.
Next: Anatomy of Agent Failure — when an agent is warranted, here's how it still breaks, and how to see it coming.