"Agent" has become one of the most overused words in applied AI, applied equally to a fixed three-step script that calls a model once and to a genuinely autonomous loop that plans, acts, observes results, and re-plans repeatedly with no fixed number of steps. These are architecturally very different things, with very different failure modes, and one of the most common and costly mistakes in AI automation is reaching for the second when the first would do the job more reliably and more cheaply.

The fixed script: deterministic steps, an AI call inside one or more of them

A fixed script has a predetermined sequence of steps that always executes in the same order, where one or more individual steps happens to call an AI model — summarize this text, classify this category, draft this response. The control flow is entirely deterministic and written by a human in advance; the AI's role is narrow and bounded to specific steps, not deciding what happens next.

This is the right architecture for the large majority of business automation, because the actual task has a known, stable shape. Our earlier example of an email-triage system — read email, categorize it, draft a reply, save for review — is exactly this: the sequence of steps never changes, only the content the AI processes at each step varies. There's no need for the system to "decide" what step comes next, because the process itself is fixed.

The agent loop: the AI decides what happens next, not just what content to produce

A true agent loop is architecturally different: instead of a human specifying the sequence of steps in advance, the model itself decides, at each point, what action to take next based on what's happened so far — it might decide to search for more information, call a specific tool, ask a clarifying question, or conclude the task is done, and it makes that decision itself rather than following a predetermined script. This is genuinely necessary for tasks where the right sequence of steps can't be known in advance because it depends on what's discovered along the way — an open-ended research task, a complex troubleshooting process where the next diagnostic step depends on what the previous one revealed.

Important

The test for whether you need a real agent loop rather than a fixed script: can you write down, in advance, the actual sequence of steps this task requires? If yes — even if some steps have simple branches ("if category is billing, do X, else do Y") — a fixed script with AI calls inside specific steps is almost always the better choice. Reserve a true agent loop for tasks where the necessary sequence of steps genuinely can't be determined until the task is already underway.

Why defaulting to an agent loop when you don't need one causes real problems

Agent loops are structurally harder to make reliable than fixed scripts, for a specific reason: because the model itself is choosing what happens next, an agent loop can take an unexpected path through the problem, call the wrong tool, get stuck in an unproductive cycle of the same action, or simply take far more steps (and cost) than a human would ever choose to take by hand for the same task. A fixed script cannot do any of these things, because there's no decision-making step where the model can choose a path a human didn't already anticipate and constrain.

This means agent loops need substantially more safeguards to run safely in production — a hard limit on the number of steps or the total cost incurred before the loop is forced to stop, monitoring to catch the specific failure mode of the agent repeating the same unproductive action, and usually a human review step before any consequential final action, since the path the agent took to get there wasn't fully predictable in advance. A fixed script needs almost none of this, because its behavior was fully specified by the human who wrote it.

The cost dimension people underestimate

An agent loop making its own decisions about what to do next typically makes many more model calls than a fixed script accomplishing an equivalent task, because each decision point in the loop is itself a model call, and a complex task might require the loop to make that decision many times before concluding. This cost difference is often underestimated when a team chooses an agent architecture for a task a fixed script could have handled — the flexibility of an agent loop is genuinely valuable for tasks that need it, and genuinely wasted expense for tasks that don't.

A practical decision framework

Ask, honestly, whether the task's steps can be enumerated in advance, even with reasonable branching logic. If they can, build a fixed script with AI calls at the specific steps that need judgment or language understanding — this will be cheaper, more predictable, easier to debug when something goes wrong, and easier for a colleague who didn't build it to understand and maintain. Reserve a genuine agent loop for the smaller set of tasks where the actual path through the problem can't be known until the system starts working on it — and when you do build one, invest the extra safeguards (step limits, cost caps, human review before consequential actions) that a loop's unpredictability genuinely requires.

Why this distinction matters more than most tooling choices

Choosing between these two architectures matters more for reliability and cost than almost any other decision in building an AI automation, including which specific model or vendor to use. A fixed script built on a mediocre model configuration will usually still behave predictably; an unconstrained agent loop built on an excellent model can still produce unpredictable, expensive, or unsafe behavior if it was the wrong architectural choice for the task in the first place.

AI Agents for Small Business uses this exact framework throughout — the book's own worked examples deliberately favor fixed scripts with narrow AI calls wherever the task allows it, reserving real agent-loop architecture for the smaller number of genuinely open-ended cases where it's actually earned, rather than defaulting to the more exciting-sounding architecture by default.