Recommended resources
The freely available resources this lesson will direct you to.
Hello! Last time, you identified an agent’s goal, state, actions, observations, and stopping condition. Now we can ask a more practical question: does this task need an agent at all?
By the end of this lesson, you should be able to choose among an ordinary program, a fixed workflow, and an agent—and explain your choice. The aim is not to rank them from “simple” to “advanced.” It is to give each task the least complicated system that can do it reliably.
The deciding question: who chooses the next step?
An ordinary program follows rules written in code. Given the same inputs and rules, its decisions are predictable. If a table contains two Saturday opening times, a program can compare them and report which is earlier. It needs neither a language model nor an agent.
A fixed workflow carries out a process whose route has been designed in advance. It might retrieve a page, ask a language model to extract its opening hours, check the result, and format an answer. The workflow may have branches: if extraction fails, it can send the result for review or stop with an error. What makes it fixed is not that it always performs exactly the same number of operations. It is that the available routes and the rules for taking them are specified ahead of time.
An agent has a goal and some permitted actions, but the language model helps decide which action to take next as the task unfolds. After a search returns irrelevant weekday hours, it might try a Saturday-specific query. If that finds only one garden’s hours, it might search for the other. Those choices depend on what it observed, rather than on a complete search plan written in advance.
Watch Jeff Su’s AI Agents, Clearly Explained for a concrete contrast between these designs.
Jeff Su uses familiar information-finding and content-production examples to distinguish a single model response, a preset workflow, and an agent.
Watch responses and routes for the difference between a model replying and a system following a prescribed route. Then watch workflow versus agent: focus on who decides how to proceed and who handles a disappointing intermediate result. Finish with the visual recap.
There is a useful qualification to the video’s contrast: a feedback loop alone does not make an agent. A developer can prescribe “draft, check, revise once if the check fails.” That is still a fixed workflow. Likewise, a model that sorts a request into one of three predefined routes is helping within a workflow; it is not necessarily free to plan the whole task. Ask how much control the model has over the process, not merely whether a model or a loop appears somewhere in it.
Why a fixed workflow can be the better choice
Suppose every garden publishes hours in a known format. You always need to compare exactly two gardens, and the approved process is the same each time: obtain both schedules, extract the Saturday opening times, verify that both values were found, then compare them. Even if extraction calls for a language model, the route is known. A fixed workflow makes each stage easier to inspect and test.
The diagram below shows a related pattern. A preset sequence contains a gate: depending on a check, the system either continues through the next model calls or exits. That branch does not, by itself, turn the system into an agent.
Anthropic’s Building Effective AI Agents makes this distinction precise and recommends starting with the simplest workable design.
Read the selected parts of Anthropic’s article to connect the examples in this lesson to a design rule: use a predictable route when it is sufficient, and reserve an agent for decisions that cannot readily be prescribed.
Under “What are agents?”, read the distinction between workflows and agents. Under “When (and when not) to use agents”, start at simplest first, then continue through the next paragraph on predictability and flexibility. Finally, under “Agents”, read the paragraph beginning “Agents begin their work” through its discussion of stopping conditions, then read the “When to use agents” paragraph. Focus on why an unpredictable number of steps changes the design choice.
A fixed workflow is not automatically the right answer whenever a task has multiple steps. First ask whether ordinary code could do the job. If opening times are already stored as reliable, structured values, using a model to “read” them adds a chance of error to a comparison that code can perform exactly. If the times are buried in differently worded pages, a model may help extract them—but the overall process can still remain fixed.
The same request, three sensible designs
Consider the garden question from the previous lesson: “Which opens earlier on Saturday, Garden A or Garden B? Give both times and supporting passages.” The best design depends on what information is available and how variable the task is.
| Situation | Better starting choice | Why |
|---|---|---|
| Both Saturday times are supplied as validated fields | Ordinary program | Comparing two times is a clear, exact rule. |
| Each garden has a known hours page, but its wording varies | Fixed workflow | Retrieval, extraction, evidence checking, and comparison can follow a prescribed route. |
| Sources are unknown; searches may return irrelevant pages, missing hours, or conflicting passages | Constrained agent, if the extra flexibility is worth it | What to search next depends on what earlier searches reveal. |
Notice that the user’s sentence barely changes across these rows. The available data and the uncertainty about the next step change. “Use an agent for research questions” is therefore too broad a rule. A well-organized source might make the question a straightforward workflow. Conversely, an apparently simple question can require adaptive investigation when sources are difficult to locate.
For the third row, the five labels from the previous lesson help explain the choice. The goal is a supported comparison. The state records which Saturday times and passages have been found. Searching is an available action; returned passages or errors are observations. After each observation, the system may need to choose a different search. It should stop when both times have adequate support—or when a limit is reached and it must report that it cannot verify the answer. That need for observation-dependent choices is the reason to consider an agent.
An agent would not get unlimited freedom. Its application could permit only source searches, cap the number of searches, and require supporting passages before it answers. Agent describes who directs the permitted steps during the run; it does not mean “no rules.”
Make the choice with cost and risk in mind
Adaptability has a price. More model-directed steps can take longer, cost more, and give an early mistake more opportunities to affect later decisions. An agent that misreads a weekday passage might search for the wrong thing next and eventually produce a convincing but unsupported answer. For a routine task with a known route, that extra freedom offers little benefit.
IBM Technology’s Knowing When Not to Use AI: AI Agents vs Rules vs ML reinforces the point that reliable code and flexible AI solve different kinds of problems.
Knowing When Not to Use AI: AI Agents vs Rules vs ML
IBM Technology contrasts clear, stable rules with tasks that require flexible interpretation, then shows why a practical system may combine approaches.
Watch rules and code for tasks where explicit logic is preferable. Watch flexible interpretation for both the appeal and the reliability costs of language models. In combined approaches, focus on giving exact operations to code even when a broader system uses AI.
One practical way to decide is to ask, in order:
- Are the inputs and rules clear enough for ordinary code? If so, start there.
- If some interpretation is needed, can you prescribe the stages and acceptable branches? If so, start with a fixed workflow; a model can serve as one component.
- Must the system choose new steps based on unpredictable findings? If so, consider a constrained agent—but specify its tools, evidence requirements, and stopping limits.
- What happens if it is wrong? For consequential actions, uncertainty may call for human review rather than more autonomy.
These are design questions, not rigid labels for whole applications. A research agent, for example, can use ordinary code to enforce its search limit and compare extracted times. Choosing an agent for the uncertain search does not mean asking the model to do exact comparison or safety checks by guesswork.
Takeaways
Choose an ordinary program for explicit, stable rules; a fixed workflow for a process whose stages and branches can be specified; and an agent when the next useful action genuinely depends on unpredictable observations. The strongest test is: who decides what happens next, and does that decision need to be made during the task? Start with the simplest reliable option, then add flexibility only where it solves a real problem.
That completes the module’s picture of what an agent is—and when not to build one. In the next module, you will examine the language model itself, beginning with why its answers can vary or be wrong even when you give it the same prompt.