Agents and workflows

Every non-trivial Claude application you'll build falls somewhere on a spectrum. On one end are workflows: predefined sequences of Claude calls that you orchestrate explicitly in code. On the other end are agents: Claude is given a goal and a toolbox, and your code steps back while the model figures out how to get there. Knowing which end of the spectrum a given task belongs on — and having a few named patterns for the workflow case — is most of what "designing with Claude" actually means.

The defining difference

Workflows are a series of Claude calls orchestrated by your code to solve a specific problem through a predetermined set of steps.

Agents give Claude a goal and a set of tools, and let Claude figure out the path to the goal through its own reasoning and tool-use loop.

You've actually built both already. Module 6's reminder project was an agent — you gave Claude three tools and a user request and let it chain them autonomously. The model decided which tool to call in what order. Module 4's eval pipeline was a workflow — the steps (generate dataset → run prompt → grade → aggregate) were fixed in code, not left to the model.

Both patterns are legitimate. Neither is inherently better. The right choice depends on how well you understand the task.

When to use a workflow

Use a workflow when you can picture the exact flow or steps Claude should take. If you could sketch the process on a whiteboard as a sequence of boxes — "first do X, then Y, then if Z do A, otherwise do B" — that's a workflow.

Two symptoms that you're looking at a workflow problem:

• The task structure is fixed. The steps don't change based on user intent. Every user who uploads a CAD image gets the same "describe → model → render → grade" sequence.
• Your UX constrains users. Users don't type freeform prompts; they pick from a finite menu of features. Each feature has its own known path through Claude.

Workflow advantages: predictable, debuggable, easy to cache, easy to parallelise, easy to reason about when something goes wrong. You know exactly which Claude call produced which output because the code said so.

When to use an agent

Use an agent when you don't know in advance what task or what task parameters you'll get. If users can ask arbitrary questions that route to different capabilities, or if the task requires the model to inspect the environment and decide what to do next based on what it finds, an agent is probably the right shape.

Symptoms:

• The task structure is open-ended. A user asks "fix this bug" or "research this topic" — the model has to decide what steps those require.
• Multiple tools are available and the model picks. No predetermined call order. Claude decides whether it needs to read a file, run a test, or search the web based on the situation.

Agent advantages: flexible, general-purpose, handles cases you didn't anticipate. Agent costs: harder to predict, harder to debug, harder to cache, more tokens and latency per run because the model has to reason about its own next step.

A concrete workflow example: image to CAD

Let's walk through a workflow concretely to see why naming the pattern is useful. Imagine a web app where users drag in an image of a metal part and get a STEP file (an industry-standard 3D CAD format) back.

The process is fixed and we can describe every step:

1. Feed the image to Claude and ask it to describe the object — geometry, dimensions, features.
2. Ask Claude to use the CadQuery library (a Python CAD-modelling library) to produce a 3D model matching the description.
3. Render the model to a 2D image.
4. Ask Claude to grade the rendering against the original image. If there are discrepancies, feed the diff back to step 2 for a revision.

Four steps, all orchestrated by your code. The flow is a loop with an exit condition. Nothing about this needs the flexibility of a true agent — you know the shape of the problem well enough to hard-code it.

The Evaluator-Optimizer pattern

What makes the CAD example interesting is that steps 2–4 form a named, reusable pattern that appears everywhere in AI systems: the evaluator-optimizer pattern.

• Producer — creates an output from an input. In the CAD example, Claude taking a description and generating a CadQuery model.
• Grader — evaluates the output against some criterion. In the CAD example, Claude comparing the rendering to the original image.
• Feedback loop — if the grader rejects the output, feedback from the grader goes back to the producer for a second attempt.
• Iteration — the cycle repeats until the grader accepts the output (or you hit a retry limit).

Producer-grader loops are one of the most effective patterns in AI engineering. The producer is optimising for quality and the grader is a completely fresh perspective that only cares about whether the output is good. Neither has to think about both at once. You can tune them independently — different prompts, different models, different temperature settings.

This pattern is reusable everywhere. Code review of AI-generated code. Content moderation of AI-generated content. Spec compliance of AI-generated documents. Any time you want to keep iterating until an output clears a bar, you can shape it as producer + grader + loop.

Why workflow patterns matter

The goal of learning a handful of named workflow patterns — evaluator-optimizer, parallelisation, chaining, routing — is to give you a repertoire of recipes for features. When a new product requirement comes up, instead of designing a workflow from scratch you recognise, "oh, that's a routing problem" or "that's parallelisation," and you already know what the code is going to look like.

The next three lessons cover the other three patterns:

• Parallelisation — split a task into independent sub-tasks, run them concurrently, aggregate results.
• Chaining — run subtasks sequentially where each step's output is the next step's input, often to break up long prompts that Claude is struggling with.
• Routing — categorise incoming requests and send each one down a specialised pipeline.

After those, Module 11 pivots to agents specifically — the principles that make agents work and the trade-offs against workflows. Most production Claude systems are a mix of workflows and agents, so knowing both well is the thing that matters.

The important caveat

Recognising a workflow pattern doesn't write the code for you. You still have to implement it — manage state, pass data between steps, handle errors, retry on failure, deal with rate limits, log and observe. Identifying the pattern just tells you the shape to aim for.

But the shape matters. "This is producer-grader with up to three iterations" is a concrete, actionable design statement. "I need to make a call to Claude that does the thing" is not. Naming patterns is how you move from the second kind of statement to the first.