Workflows vs agents

Now you know what a workflow is, you know what an agent is, and you know how to design both. The final question is the one that actually lands on your desk when you start building a feature: which should I use? This lesson is the short, opinionated comparison — what each approach is good at, what each is bad at, and the default posture an engineer building production Claude applications should take.

The short version of each

Workflows are a predefined series of Claude calls designed to solve a known problem through a fixed sequence of steps. You write the code that orchestrates the calls; Claude just fills in the work at each step.

Agents give Claude a goal and a set of tools and expect the model to formulate its own plan and execute it. Your code provides the tools; Claude decides the order and the number of calls.

If you can picture the flow of steps on a whiteboard before writing any code, you have a workflow. If you can't — because the steps depend on the input, the environment, or the user's intent — you probably have an agent.

Workflow benefits

• Higher accuracy per step. Claude focuses on one subtask at a time. Focus produces quality. A workflow step doesn't have to juggle the whole task — just the one slice in front of it.
• Easier evaluation and testing. You know each step. You can eval each step independently against its own test cases. You can catch regressions at the step level before they propagate.
• Predictable and reliable execution. The flow is the same every time. No surprises about tool order or which prompt got invoked. When something breaks, you know exactly which step broke.
• Better suited for well-defined problems. Anything where the process is known and repeatable benefits from being codified.
• Easier to cache and optimise. Known steps mean you can cache the stable parts (system prompts, tool definitions) and aggressively short-circuit repeat work.

Workflow downsides

• Less flexible. A workflow is dedicated to a specific type of task. Vary the input too far from what the workflow was designed for and it breaks.
• Constrained UX. Users have to shape their requests to fit the flow. "What can I do?" becomes a small menu of features, not an open prompt.
• Upfront design cost. You have to figure out the exact sequence, the prompts for each step, the error handling between steps. That's real engineering effort.

Agent benefits

• Flexible user experience. Users can ask for almost anything and the agent adapts. The UX is "type what you want," not "pick from this list."
• Handles novel situations. An agent built for general code editing handles code-editing tasks you never explicitly planned for.
• Creative problem-solving. Claude can combine tools in unexpected ways — chaining actions you wouldn't have thought to pre-wire.
• Can ask for clarification. A well-designed agent asks the user for additional input when it needs it, rather than guessing and failing.

Agent downsides

• Lower successful task completion rate. An agent trying to solve a novel problem with general tools will sometimes get lost, pick the wrong tool, retry too many times, or give up. The success rate on any individual task is usually lower than a workflow tuned for that same task.
• Harder to evaluate and debug. You don't know in advance which sequence of tool calls the agent will produce, so writing mechanical tests is harder. Debugging failures means reading multi-step tool-use traces and figuring out where reasoning went sideways.
• Less predictable. The same input can produce slightly different tool sequences on different runs. Sometimes that's fine; sometimes it's a compliance or observability problem.
• Higher cost per successful task. Agents typically consume more tokens — they think, they retry, they inspect environment, they change their minds. Measure before you ship.

The production posture

Here's the honest recommendation for engineers building real applications: default to workflows and only reach for agents when workflows can't do the job.

Users don't care whether you built a fancy agent — they care that the feature works. Workflows, being more reliable and more predictable, tend to produce features that work. Agents produce features that can work but are harder to get to "works consistently" quality.

This isn't an argument against agents. There are tasks where agents are genuinely the right answer — Claude Code is an agent and it should be. Computer Use is an agent and it should be. A generic "do anything with my data" assistant is an agent because you can't enumerate the use cases. When the task is too open-ended to enumerate, agents are the only viable approach. But that condition is rarer than it looks.

For most production features:

• Is the task type well-defined? Workflow.
• Do users hit the same kinds of requests repeatedly? Workflow.
• Does the UX route users to a finite set of features? Workflow per feature.
• Can you draw the process on a whiteboard? Workflow.
• Is the task open-ended enough that users could ask anything? Agent (maybe).
• Does the solution require creative tool combinations you can't predict? Agent.

When in doubt, start with a workflow. You can always pull the workflow apart into an agent later if the flexibility turns out to matter. Going the other direction — replacing a fragile agent with a reliable workflow — is much more painful because you've committed design decisions to the open-ended approach.

The mixed pattern, because real systems are mixed

You don't have to pick one. Real production systems commonly have:

• A router at the top (workflow pattern) dispatching user requests to specific handlers.
• Workflow-based handlers for the common, well-defined cases (schedule a meeting, summarise a document, generate a report).
• An agent fallback for the open-ended "none of the above" bucket.

This gives you reliability where reliability is possible and flexibility where flexibility is required. 80% of requests go through tight, well-eval'd workflows; the long tail gets routed to a single agent handler that can do anything. Best of both worlds, assuming you build both well.

Wrapping the module

You now have the full playbook: the four workflow patterns (evaluator-optimizer, parallelisation, chaining, routing), the two agent design principles (abstract tools, environment inspection), and a clear framework for choosing between them. Combined with everything from Modules 3 through 10, you have everything you need to design and build production-grade Claude applications.

The remaining modules are a final quiz on everything and a short wrap-up. The real test is the code you'll write next.