Workflows or Agents? How to Decide What to Build

You now know what an agent is and how its loop works. This lesson asks a more useful question: should you build one at all? Many tasks that people reach for an agent to solve are better served by a single well-written prompt or a fixed workflow. The right choice gives you something cheaper, faster, easier to test and more reliable. After this lesson you will have a ladder of options, a four-question checklist to decide between them, a feel for what each costs, and a habit that will save you time: start simple and measure before you add complexity.

Two meanings worth keeping apart

Anthropic, in its guide "Building effective agents", draws a clear line between two kinds of system, and both belong under the wider heading of "agentic systems":

• A workflow is a system where language models and tools follow paths that your code defines in advance.
• An agent is a system where the model directs its own process and tool use, deciding for itself how to get the task done.

The words matter because the two behave differently in practice, as the picture from the first lesson showed. If you want a refresher, see What an AI agent is.

The ladder of complexity

Think of your options as rungs on a ladder. Each rung up gives you more flexibility and costs you more in tokens, time and ways to fail.

Rung 1: One model call. You send a good prompt, perhaps with a few examples or some retrieved text, and use the answer. It is the cheapest, fastest and easiest to test. For many real tasks, this is all you need. Anthropic's guide says that for many applications, optimizing single calls with retrieval and in-context examples is enough.

Rung 2: A workflow. Several model calls in a fixed order, with your code deciding the route. For example: draft an email, check its tone, translate it. You will learn the standard patterns in Chaining, routing and parallelization.

Rung 3: An agent. The model runs in a loop and picks its own steps and tools, as in The agent loop.

Rung 4: Several agents. A lead agent hands parts of the work to others. This is covered in Orchestrator-workers and multi-agent systems.

The advice that follows from this picture is short: start at the bottom and climb only when you have a reason. The same guide says to find the simplest solution possible and add complexity only when needed, which may mean not building an agentic system at all.

What each rung costs

Agents are powerful because they spend more. Each step is another model call, and each call carries the whole growing conversation, as you saw in How LLMs work. Anthropic reported figures from its own multi-agent research system: agents typically used about 4 times the tokens of a normal chat, and multi-agent systems about 15 times. Those numbers come from one system and will differ for yours, but the direction is reliable.

The same write-up found that token usage alone explained about 80 percent of the performance differences in one of its evaluations. In other words, agents often do better because they are allowed to spend more effort. That is a fair trade when the task is valuable enough, and a poor one when it is not.

Here is how the rungs compare in practice:

That last row deserves a second look. Because an agent chooses its own path, a mistake early on can carry through every later step. Anthropic's guidance is to test agents extensively in sandboxed settings and to put guardrails around them.

Four questions to ask

When a task lands on your desk, work through these in order.

1. Can one prompt do it? Try it honestly, with clear instructions, a few examples, and any needed text pasted in. If the result is good enough, stop. You are done, and you did not build anything complicated.

2. Can you write the steps down in advance? If you can list the steps, even when the content changes each time, build a workflow. "Read the email, label its topic, pick a reply template, fill it in" has known steps. A workflow is more predictable and costs less.

3. Is each run worth the extra cost and time? An agent makes sense when the task is valuable enough. Fixing a production bug may justify dozens of model calls. Labeling a thousand support tickets a day usually does not.

4. Can you check the result and limit the damage? If a wrong action is hard to undo, such as sending money or deleting data, you need approvals, limits or a sandbox before an agent is safe. If you cannot tell whether the agent succeeded, you cannot improve it either.

If you answer no to the first two and yes to the last two, an agent is a fair choice. Even then, start small.

Examples, sorted

Anthropic's guide gives two applications where agents have worked well. Customer support combines a chat conversation with tools that pull customer data, order history and knowledge-base articles, and can take actions such as issuing a refund, with success measured by whether the issue was resolved. Coding agents work well because solutions can be checked with automated tests, and the agent can use test results as feedback. Notice what both have in common: there is a clear way to tell whether the agent did the job.

Mixing the two

You do not have to pick one for the whole system. Real products often combine them:

• A workflow with an agent inside. A fixed pipeline handles the predictable parts, and one step, such as "investigate this error", hands off to an agent.
• An agent that calls workflows as tools. The agent decides when to run a dependable, tested routine.
• A router in front. A small step sends easy requests to a single call and only hard ones to an agent, so you do not pay agent prices for easy work.

A good rule: use the lowest-cost structure that works for each part, and keep the agent where flexibility is truly needed.

A support assistant, built up in stages

To see the ladder in use, picture an assistant for an online shop. A sensible build order:

1. One call. Answer common questions with a well-written prompt and the shop's policy pasted in. Test it on real questions.
2. One call plus retrieval. When the policy grows too long, fetch only the relevant parts and pass those in.
3. A workflow. Add a routing step that sorts messages into "order status", "returns" and "other", each with its own prompt.
4. An agent for the hard cases. Give it tools to look up orders and start returns, with a person approving refunds above a set amount.

Each stage is shipped and measured before the next. You may find that stage 2 or 3 is enough, which saves you the cost and risk of stage 4.

Start simple and measure

The most practical advice from Anthropic's engineers is to measure early and often.

• Write a small test set at the start. In its multi-agent research write-up, the team describes beginning with about 20 queries drawn from real usage. Early changes tend to have large effects, so a few cases are enough to show them. In one example, a single prompt change took the success rate from around 30 percent to around 80 percent.
• Do not wait for a perfect test suite. Waiting until you can build hundreds of cases is a mistake. Start small now, and grow it as you learn.
• Add complexity only when it helps. Their summary is that the goal is the right system for your needs, not the most sophisticated one. Measure performance, iterate, and add multi-step systems only when simpler ones fall short.

You will build this habit in Evaluating agents.

A note on frameworks

Many libraries promise to make agents easy. They can speed up the basics, such as calling a model, defining tools and chaining calls. The same guide warns that they can add layers that hide the prompts and responses, which makes debugging harder, and that they can tempt you into complexity you do not need. Its suggestion is to start by calling the model's API directly, since many patterns take only a few lines of code, and to understand what a framework does underneath if you use one. You will compare them in Frameworks compared.

Three principles to keep

Anthropic's guide ends with three ideas that apply to every rung:

1. Simplicity. Keep the design as simple as the task allows.
2. Transparency. Show the agent's planning steps, so you can see what it is doing.
3. A careful tool interface. Design, document and test the tools the agent uses, because they are how it acts. You will spend a whole module on this.

Mistakes beginners make

1. Starting with an agent because it sounds impressive. Try one call, then a workflow.
2. Calling a fixed chain an agent. If your code sets the path, it is a workflow, and it needs different testing.
3. Ignoring cost. An agent that costs more than the task is worth is a bad design, even if it works.
4. Giving an agent hard-to-undo power with no approval step. Add a check first.
5. No way to measure success. Without a test set, you are guessing whether a change helped.
6. Adding a framework before you understand the loop. Build one by hand first.
7. Making everything an agent. Use agents only for the parts that need flexibility.

Quick recap

• A workflow follows paths your code defines. An agent chooses its own path.
• Climb the ladder only when needed: one call, then a workflow, then an agent, then several agents.
• Each rung costs more. Anthropic reported roughly 4 times a chat's tokens for agents and 15 times for multi-agent systems, in its own system.
• Ask four questions: can one prompt do it, can you write the steps, is it worth the cost, and can you check the result and limit damage.
• Mix the structures: workflows for predictable parts, agents for the flexible ones.
• Start with a small test set, measure, and add complexity only when it improves the results.

Try it yourself

Pick three tasks from your own work. For each, run the four questions and decide which rung fits. For the one you place highest on the ladder, write down how you would check that it worked and what the worst possible mistake would be. Then do the opposite for one task: describe the simplest version that could possibly work, and try it as a single prompt in any chat tool. Compare how far the simple version gets.

Next lesson: Your first agent from scratch.