Agentic Workflows

Not every useful AI system should decide everything for itself. Some tasks need fixed rails; others need freedom to choose the next step. An agentic workflow mixes those two ideas deliberately.

Fixed workflow:  A → B → C → D

Agentic workflow: A → agent chooses B or C → approval → D

What You Will Learn

• How a deterministic workflow differs from an autonomous agent loop.
• What makes a workflow “agentic” even when many steps remain fixed.
• How routing, parallel work, retries, approvals, and handoffs fit together.
• How to choose the smallest amount of autonomy that solves the problem.
• How hybrid workflows improve control, cost, debugging, and reliability.

A Real Production Pattern

Anthropic separates workflows, where code chooses predefined paths, from agents, where the model dynamically directs its process. Its examples include routing, parallelization, orchestrator-worker systems, and evaluator-optimizer loops. (Anthropic, Building Effective Agents)

Many production systems deliberately combine these patterns: code controls sensitive boundaries while a model makes only the decisions that truly require flexible judgment.

Seven modules in, you now know how to build a fully autonomous agent — a loop that reasons, plans, calls tools, and decides its own next step. This module is almost a corrective to everything that’s come before it, and it’s worth saying that plainly up front: most tasks you’ll build for a business don’t need any of that. Autonomy is a dial, not a destination, and this module is about learning to read a task correctly enough to know how far to turn it.

The full spectrum, named precisely

Deterministic workflow
        ↓
LLM-powered workflow
        ↓
Conditional workflow
        ↓
Tool-using workflow
        ↓
Agent
        ↓
Autonomous agent

A deterministic workflow has every path known in advance — no model involved in deciding what happens next, at all. Processing an invoice is the canonical example: extract the vendor, the amount, the line items, check them against a purchase order, route for approval if they don’t match, pay if they do. Every branch is knowable before you write a single line of code, and if an LLM appears anywhere in this pipeline at all, it’s doing narrow, bounded work — reading text off a scanned document, say — not making decisions about what happens next.

An LLM-powered workflow adds a model for one specific, well-defined transformation, with still no branching based on the model’s output — summarizing a long document into a short one, or drafting a reply based on a template. One input, one predictable kind of transformation, one output.

A conditional workflow is where things start to get more interesting: the model makes one real, meaningful judgment call at a specific point, and the system routes based on that judgment — but the possible destinations are still fixed and known in advance. Support ticket triage is the clean example here: the model classifies an incoming ticket as billing, technical, or sales, and the system sends it down one of three predetermined paths. The model is deciding something real. It is not deciding what the available paths are.

A tool-using workflow goes one step further — the model can call a tool to gather information partway through an otherwise fixed sequence, but the overall shape of the process still doesn’t change based on what that tool returns. Check inventory before confirming an order is a workflow like this: the tool call happens at a fixed point, for a fixed reason, and the result feeds into an otherwise predetermined next step.

An agent, as you know deeply by now from Modules 1 through 7, is where the model decides what happens next, based on what it observes, for however many steps the task requires — Module 1’s example of researching an unfamiliar topic and deciding which sources to check, in what order, based on what earlier searches reveal, is the clean illustration.

The autonomous agent at the far end of this spectrum is the same mechanism with the human-approval dial turned as far down as it goes — operating with minimal or no real-time human oversight, which you’ll study properly and carefully in Module 9.

The most important question this module asks

Here’s the question worth holding onto more than any diagram: when should you use a workflow instead of an agent?

The honest answer, stated as plainly as this course has stated anything: whenever the task’s structure allows it. If every path through a task can be drawn out as a flowchart before you write any code — even a complex flowchart, with many branches — you have a workflow problem, not an agent problem, regardless of how sophisticated the task feels.

Invoice processing can involve dozens of edge cases and still be a deterministic or conditional workflow, because every one of those edge cases is knowable in advance, even if there are many of them. Researching an unfamiliar topic cannot be reduced to a flowchart, because the actual sequence of searches depends on what earlier searches turn up — that dependency, not the task’s apparent complexity, is the real signal that something needs agent-level flexibility.

This isn’t a minor stylistic preference. Every step down this spectrum toward more autonomy trades away predictability, speed, and cost, in exchange for flexibility — and that trade is only worth making when the task requires the flexibility you’re paying for.

What Anthropic’s own engineers say about this, directly

This exact question — when workflows beat agents — is, remarkably, the central argument of one of the most widely cited pieces of practical guidance in this entire field, and it’s worth quoting closely rather than paraphrasing, because the source is about as authoritative as this topic gets: written by the company building Claude, for engineers building on top of it.

Anthropic draws precisely the architectural line this module has been building toward: “Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” And their practical recommendation is stated with a directness worth sitting with: “When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.” (Anthropic, Building Effective Agents)

Notice they go further than just “workflows versus agents” as a binary. They name several distinct patterns within the workflow side of this spectrum because “workflow” is not one undifferentiated thing any more than “agent” is.

Those patterns include prompt chaining (a fixed sequence of LLM calls), routing (sending an input to a specialized path), parallelization (running independent calls simultaneously), orchestrator-workers (one central call creates subtasks), and evaluator-optimizer (one call generates while another critiques and refines).

We’re deliberately not implementing any of these here — they get the full, proper treatment they deserve in the AI Design Patterns module later in this learning path. What’s worth taking from this now is simpler and more important: even the disciplined, structured end of this spectrum has real internal variety, and reaching for the right specific pattern — not just “workflow versus agent” as a binary choice — is itself a design skill.

And their stated reasoning for favoring the simpler end whenever possible is worth repeating directly, because it’s the exact trade-off this entire module is organized around: “Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense. When more complexity is warranted, workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.”

Watching the spectrum in one real, familiar product

It’s worth seeing this exact spectrum show up within a single system you’ve already studied in this course, because it demonstrates something important: a well-designed real product doesn’t just pick one point on this spectrum and stay there — it moves along it deliberately, depending on what a given moment in a task requires.

Recall Claude Code’s Plan Mode from Module 6. During that phase, the system is operating closer to the conditional-to-tool-using end of this spectrum than the fully autonomous end — it explores using read-only tools, produces a structured plan, and then hits a hard, designed stopping point: ExitPlanMode, which requires your explicit approval before anything changes.

That’s a deliberate constraint, not a limitation of the underlying model — Claude is fully capable of operating with more autonomy, and the product chooses to restrict it during this phase, because a coding task’s planning stage benefits from exactly the predictability and checkpoint-based structure a pure agent doesn’t naturally provide.

Once you approve the plan and execution begins, the system shifts toward the agent end of the spectrum — deciding which specific tool call happens next based on what each edit or test result reveals, autonomously within the bounds of the approved plan.

Contrast that with Anthropic’s Computer Use, covered back in Module 4 — the same underlying model, operating with meaningfully more continuous autonomy throughout, precisely because browsing an arbitrary, unpredictable website doesn’t have the kind of structure that makes an upfront, approvable plan practical the way a codebase change does. Same company, same underlying model family, two different points on this spectrum — chosen deliberately based on what each task’s actual structure supports, exactly the judgment this module is trying to teach you to make yourself.

A more everyday version of the same spectrum is worth naming too, because it’s something you’ve likely encountered directly: a CI/CD pipeline like GitHub Actions is about as clean a real-world instance of a deterministic workflow as exists in software engineering — every job, every trigger condition, every step is fully specified in advance, with zero model-driven decision-making anywhere in the pipeline.

Sit that directly next to GitHub’s own Copilot coding agent, operating within the very same platform, deciding what code to write and which files to touch based on an issue’s description — and you have the two far ends of this module’s entire spectrum, living inside one company’s product line, each one deliberately matched to a different kind of problem.

Why the mistake runs in both directions

It’s worth being explicit that this isn’t only a warning against over-using agents — under-using them is a real, if less commonly discussed, mistake too.

A task that has unpredictable, information-dependent branching — Module 1’s research example, or the support agent’s payment investigation from Module 4 — forced into a rigid conditional workflow will either fail to handle the novel cases it encounters, or require an ever-growing, increasingly brittle set of hand-written branches trying to anticipate situations that were never fully anticipatable in the first place.

That’s precisely the brittleness problem Module 2 traced all the way back to 1980s expert systems — the same failure mode, showing up again, simply because a task that needed dynamic decision-making got forced into a shape that doesn’t have any.

The engineering skill this module is building isn’t “prefer workflows” or “prefer agents” — it’s correctly reading which category a specific task falls into, and having the discipline to build for that category rather than whichever one feels more impressive or more familiar.

A practical checklist for reading a task correctly

It helps to have something more concrete than “think carefully about it,” so here’s a, workable checklist worth running through before committing to a point on this spectrum.

Ask first whether the task’s steps and their order are knowable in advance, even if there are many of them — if yes, you’re looking at a deterministic or LLM-powered workflow, and reaching for anything more autonomous is pure, unnecessary cost. If the steps are fixed but one specific point needs a judgment call the code itself can’t make — classifying intent, assessing sentiment, deciding which of several known categories something belongs to — you’re looking at a conditional workflow, and the model’s job is narrow and specific: make that one judgment well, not decide anything about the surrounding structure.

If the task needs to reach outside itself for information partway through, but that information doesn’t change what happens next, only what value gets used, you’re still in tool-using workflow territory — checking current stock before confirming an order doesn’t change the shape of the order-confirmation process, it just supplies a number the fixed process needs.

Only once you reach a task where the next action itself is undetermined until a previous result comes back — where “checked the gateway” versus “didn’t need to” is a real fork in the actual sequence of things that happen, not just a fixed step that always runs — are you looking at agent territory.

And it’s worth asking one more question honestly, because it cuts against the instinct to reach for more sophistication by default: even if a task could technically benefit from agent-level flexibility, does it benefit from it enough to justify the real cost — more latency, more spend, less predictability, harder testing — compared to a well-designed conditional workflow that handles, say, 90% of real cases cleanly, with the remaining 10% routed to a human rather than to a fully autonomous decision-maker?

That last question doesn’t have a universal answer, and it shouldn’t — it’s a, case-by-case engineering judgment, exactly the kind Module 15 will give you a full, formal framework for making at the very end of this course.

When to Use Each Shape

Use a fixed workflow when the path and rules are known. Use an agent inside a workflow when one bounded step needs flexible judgment. Use a more autonomous loop only when the system must repeatedly discover its own next action.

Common Misconception

Incorrect idea: A workflow becomes agentic merely because one step calls an LLM.

Why it is incorrect: An LLM can fill a fixed step without controlling the process. The agentic part begins where the model chooses among actions or changes the path using observations.

Key Takeaways

• The spectrum runs from deterministic workflow (no model-driven decisions at all) through LLM-powered, conditional, and tool-using workflows, to agent and finally autonomous agent — and every step toward more autonomy trades away real predictability, speed, and cost for real flexibility.
• The signal that a task needs a workflow, not an agent, is whether every path through it can be drawn as a flowchart in advance — regardless of how many branches that flowchart has.
• The real signal that a task needs an agent is that the correct next step depends on information you don’t have until a previous step has already run — exactly Module 1’s original test, still holding up here.
• Anthropic’s own engineering guidance draws precisely this architectural line and recommends the simplest solution that works — “this might mean not building agentic systems at all” — with agentic complexity justified specifically when flexibility and model-driven decision-making are needed at scale.
• Even the structured, workflow end of this spectrum has real internal variety — prompt chaining, routing, parallelization, orchestrator- workers, and evaluator-optimizer are distinct named patterns, each suited to a different shape of well-defined task, properly covered later in this learning path.
• A single well-designed real product can deliberately occupy different points on this spectrum for different phases of the same task — Claude Code’s constrained planning phase versus its more autonomous execution phase is a direct, real illustration of exactly this judgment being applied.
• The mistake runs in both directions: forcing a unpredictable, information-dependent task into a rigid workflow reproduces the same brittleness that limited hand-written rule systems decades ago.

Think Like an AI Engineer

• Take the invoice-processing example from this module and try to break it — describe a specific edge case realistic enough that it might occur, and decide honestly whether handling it correctly still fits within a deterministic or conditional workflow, or whether it’s evidence the task needs agent-level flexibility after all.

• A team wants to build a system that drafts a personalized welcome email for each new customer, using their signup details and which plan they chose. Walk this task through the six-point spectrum in this module. Where does it land, and why?

• Anthropic names five distinct workflow patterns rather than treating “workflow” as one thing. Pick two of them — even just from their one-sentence descriptions in this module — and describe a real task from your own domain that would fit one pattern clearly better than the other.

• Think of a real system you’ve used that felt like it was forcing a unpredictable task into a rigid, scripted flow — a phone tree, a support form with fixed dropdown categories that never quite fit your actual issue. Using this module’s vocabulary, what would need to be true about that system for moving it toward the conditional-workflow or agent end of the spectrum to be worth the added cost and unpredictability?

Module 9 goes deep on the dial this module has been gesturing at throughout — autonomy — and specifically on human involvement: the real difference between human-in-the-loop, human-on-the-loop, and human-out-of-the-loop, and the engineering question of which specific actions should require a human checkpoint, rather than applying one blanket policy to everything an agent does.