Lesson 2 - Agents vs. Workflows
Welcome to Agents vs. Workflows
In the last lesson you learned what an agent is: a model in a loop that chooses its own next step. This lesson is about the judgment that matters even more — knowing when you actually need that loop, and when something simpler will do the job better. It’s the single most important decision in applied AI, and getting it wrong is the most common mistake newcomers make. The instinct is to reach for an agent because agents are exciting. The discipline is to reach for one only when the task truly demands runtime decision-making. The two patterns to weigh are the workflow — a fixed path you code, the same steps every time — and the agent — a path the model decides as it goes.
By the end of this lesson, you will be able to:
- Distinguish a workflow (a fixed path you wrote) from an agent (a path the model decides at runtime)
- Explain the trade-offs: predictability and cost vs. flexibility and open-endedness
- Apply a four-part checklist — complexity, value, viability, cost of error — to choose between them
- Default to the simplest pattern that solves the problem, and reach for an agent last
Let’s start by drawing the line clearly.
The Distinction: A Path You Code vs. a Path the Model Chooses
A workflow is a sequence of steps you wrote in code, run in a fixed order. You decide, in advance, exactly what happens: first extract the fields, then summarize, then save. The language model might be doing the heavy lifting inside one or more of those steps — but the path is yours. Run it a thousand times and it takes the same route every time. The model fills in the blanks; it doesn’t choose the route.
An agent hands the route to the model. Instead of coding “do A, then B, then C,” you give the model a goal and a set of tools and let it decide, at runtime, what to do next based on what it has seen so far. One run might call three tools; the next, faced with a different question, might call one or seven, in a different order. The path isn’t written down anywhere in your code — it emerges, step by step, from the model’s decisions.
A quick way to feel the difference: imagine two tasks. “Extract the vendor, date, and total from this invoice.” The steps never change — read the document, pull three fields, return them. That’s a workflow, or even a single LLM call. Now: “Research whether this vendor is a reliable supplier.” You don’t know in advance how many lookups it will take or which ones — it depends entirely on what each search turns up. You might need a credit check after seeing one result, a news search after another. That’s a task where the path can’t be written ahead of time. That’s where an agent earns its place.
The Trade-offs of Each
Neither pattern is “better” — they trade off against each other, and the right choice depends on the task. Here’s what you’re trading.
Workflows win on everything you care about in production except flexibility:
- Predictable. The same input takes the same path, so behavior is repeatable.
- Cheap and fast. You only spend the model calls you coded — no extra round-trips while the model “thinks about” what to do next.
- Easy to test and debug. A fixed path means you can write tests for each step and know exactly where something broke.
Their one weakness is the flip side of all those strengths: they’re rigid. A workflow only handles the cases you anticipated. Hand it a situation you didn’t code for, and it has no way to adapt.
Agents win on exactly that one thing — flexibility — at a real cost:
- Flexible and open-ended. They handle tasks where the right steps depend on what’s discovered along the way, including paths you never explicitly coded.
- More expensive and slower. Every loop is at least one more model call. A task that takes a workflow one call might take an agent five or ten, each adding latency and cost.
- Harder to test and predict. Because the path emerges at runtime, the same goal can produce different routes on different runs. That makes behavior harder to reproduce, test, and reason about — and harder to guarantee.
Read those two lists side by side and the rule of thumb almost writes itself: pay the agent’s costs only when you genuinely need its one advantage.
The Decision Checklist
So when do you need that advantage? Use this four-part checklist. Favor an agent only when you can answer yes to all four. If even one answer is “no,” prefer a workflow or a single call.
Complexity — is the task genuinely multi-step and hard to fully specify in advance? If you can write down the steps ahead of time, write them down — that’s a workflow. You only need an agent when the steps themselves depend on what you discover along the way, so no fixed sequence would cover every case.
Value — does the outcome justify the higher cost and latency? Agents cost more per task and take longer. For a high-value or hard-to-automate-any-other-way task, that’s an easy trade. For something you run millions of times where a workflow would do, the math rarely works.
Viability — is the model actually capable at this task? An agent is only as good as the model’s judgment at each step. If the model can’t reliably choose the right tool, interpret results, or recover, the loop just compounds its mistakes. Be honest about whether the model is genuinely good at this before you hand it the wheel.
Cost of error — can mistakes be caught and recovered from? Because an agent’s path is unpredictable, it will sometimes go wrong in ways you didn’t foresee. That’s acceptable when errors are visible and reversible (a draft a human reviews, a search you can rerun). It’s dangerous when a wrong step is silent or irreversible (sending money, deleting records). The higher and more permanent the cost of a mistake, the more you want a constrained, predictable path.
Notice the through-line: an agent is the right choice only when the task is too open-ended to script, valuable enough to justify the cost, something the model can actually do well, and safe enough that its mistakes can be caught. Miss any one of those, and a simpler pattern serves you better.
Start Simple: Default to the Lowest Tier
There’s a hierarchy of solutions, and you should always start at the bottom and only climb when the rung you’re on can’t do the job:
- A single LLM call — one prompt, one response. Handles a surprising amount: classification, extraction, summarization, drafting, answering.
- A workflow — a fixed chain of calls and steps you coded, for tasks that need several stages in a known order.
- An agent — the model decides the path, for tasks that are genuinely open-ended.
Most problems are solved at the first or second tier. The agent is the powerful, expensive option at the top — and the experienced builder reaches for it last, not first, because flexibility you don’t need is just cost, latency, and unpredictability you’ve signed up for. When you’re tempted to build an agent, first ask: could a single call do this? Could a fixed workflow? Only when the honest answer to both is “no” should you climb to the top rung.
Reach for the agent last, not first
Start with the simplest thing that works. Try a single LLM call; if that’s not enough, try a fixed workflow; only if that can’t handle the task should you build an agent. An agent is the most powerful tool you have — and also the most expensive, slowest, and hardest to predict. Treat it as the option of last resort for tasks that genuinely demand runtime decision-making, not the default starting point. The best agent builders write surprisingly few agents.
Practice Exercises
Exercise 1: Workflow or agent?
For each task, decide whether it’s better served by a workflow (or single call) or by an agent, and say why: (a) translate every incoming support email into English; (b) investigate why a specific customer’s account was flagged, where the next check depends on what each previous check reveals.
Hint
(a) is a workflow / single call — the steps never change (take text in, translate, return), so there’s nothing for the model to decide about the path. (b) is an agent — the investigation branches based on what each lookup turns up, so you can’t write the sequence in advance. The test is always: can I write down the steps ahead of time? If yes, it’s a workflow.
Exercise 2: Run the checklist
A team wants to build an agent that automatically issues customer refunds end to end, with no human review. Run the four-part checklist on this idea. Should they build it as proposed?
Hint
It likely fails on cost of error: issuing money is irreversible and a wrong refund is costly, yet there’s no review step to catch mistakes from an unpredictable path. Even if complexity, value, and viability looked fine, that one “no” is enough to stop. A better design constrains the path (a workflow) or keeps a human approving each refund — restoring the ability to catch errors before they’re permanent.
Exercise 3: Why start simple?
Explain why an experienced builder reaches for an agent last rather than first, even though agents are the most capable pattern.
Hint
Capability you don’t need isn’t free. An agent’s flexibility comes bundled with higher cost, more latency, and unpredictable behavior that’s harder to test and debug. If a single call or a fixed workflow solves the problem, the agent’s extra power buys you nothing but those downsides. Starting simple means you only pay for flexibility when the task actually requires it.
Summary
A workflow runs a fixed path you coded — the same steps every time — while an agent lets the model decide each next step at runtime based on what it has seen. That difference drives the trade-offs: workflows are predictable, cheap, fast, and easy to test and debug, but rigid; agents are flexible and handle open-ended tasks, but cost more, run slower, and are harder to test and predict. To choose between them, run the four-part checklist and favor an agent only if all four are “yes”: complexity (the task is multi-step and can’t be fully scripted), value (the outcome justifies the higher cost and latency), viability (the model is genuinely good at the task), and cost of error (mistakes can be caught and recovered from). Above all, start simple: try a single call, then a workflow, and reach for an agent last — because flexibility you don’t need is just cost and unpredictability you’ve signed up for.
Key Concepts
- Workflow — a fixed sequence of steps you coded; predictable, cheap, testable, but rigid.
- Agent — a path the model decides at runtime; flexible and open-ended, but costlier, slower, and harder to predict.
- The four-part checklist — complexity, value, viability, cost of error; build an agent only when all four hold.
- Start simple — single call → workflow → agent; reach for the agent last, not first.
Why This Matters
This is the judgment that separates builders who ship reliable systems from those who burn time and money on agents that didn’t need to exist. Reach for an agent when a single call would do and you’ve traded a cheap, testable, predictable solution for an expensive, flaky one. Refuse to use an agent when the task genuinely needs runtime decision-making and you’ll keep writing brittle workflows that break on every case you didn’t anticipate. The checklist and the “start simple” default give you a repeatable way to make the right call. Next, you’ll open up the agent itself — the anatomy of the parts that make the loop work — so that when the checklist says “agent,” you know exactly what you’re building.
Next Steps
Continue to Lesson 3 - The Anatomy of an Agent
Open up the agent and learn the parts that make the decide-act-observe loop work.
Back to Module Overview
Return to the Agent Foundations module overview
Continue Building Your Skills
You now hold the most important judgment call in applied AI: workflows for fixed, predictable paths; agents only when the task is too open-ended to script — and even then, only when value, viability, and the cost of error all line up. With that discipline in hand, you’re ready to look inside the agent itself and meet the parts that make the loop run.