- "Agent" is not one thing. It is a spectrum from fixed workflows, where code chains the LLM steps, through LLM-routed branching and tool-using agents, up to autonomous agents that plan and loop on their own. Conflating the ends is the root cause of most over-engineering.
- The single trade that governs the spectrum: more autonomy buys more capability but costs predictability, testability, money, and failure modes. The discipline is to start at the lowest autonomy that solves the problem and climb only when open-endedness genuinely forces it.
- Workflows are testable like software; agents need evals, guardrails, and observability. The higher you climb, the more operational scaffolding you are signing up to build, so place each use case on the spectrum deliberately rather than reaching for the autonomous loop by fashion.
Not all agents are agents
Sit in enough architecture reviews and you notice the word "agent" doing an enormous amount of undeclared work. One team means a fixed pipeline that calls a model twice and formats the result. Another means a system that decides for itself which tools to invoke, in what order, until it judges the goal met. Both say "we built an agent," and because the word is the same, everyone assumes the engineering, the risk, and the operational burden are the same too. They are not close.
What the label actually spans is a spectrum of autonomy, meaning how much of the control flow is decided by your code versus decided by the model at runtime. At one end, code holds the reins and the model fills in the blanks between steps you defined in advance. At the other, the model holds the reins, choosing its own steps in an open-ended loop, and your code mostly sets boundaries and watches. Everything interesting lives between those poles, and the position of a system on that line predicts more about its cost and behavior than the model inside it does.
The reason this matters commercially is that conflation runs in one expensive direction. Teams rarely under-build here; they over-build. Presented with a task a deterministic workflow would handle cleanly, they reach for an autonomous loop because that is what "building an agent" has come to mean, and they inherit non-determinism, a harder test story, higher token bills, and a longer list of ways to fail, all for a problem that never needed them. The spectrum is the corrective. Before arguing frameworks or models, an architect's first move is to ask where on this line the use case genuinely sits, because that single placement decides how much machinery you are about to take on.
The levels of the spectrum
It helps to name the levels, because the jump in autonomy from one to the next is also a jump in what you must build around it. Four positions cover most real systems, and the boundary between them is always the same question: who decides what happens next?
A fixed workflow is LLM steps chained by code. You wrote the sequence, and the model does bounded work inside each step, extract these fields, summarize this passage, classify this ticket. The path is deterministic even though each step is probabilistic. An LLM-routed workflow hands the model one narrow decision: which branch to take, from a set of branches you defined. The model routes; your code still owns the map. A tool-using agent widens that decision to tool selection. Given a goal and a set of tools, the model chooses which to call and with what arguments, though the loop and its stopping condition are usually still yours. An autonomous agent takes the loop itself: it plans, acts, observes, and re-plans toward a goal you stated, deciding its own steps and when it is done.
| Level | Who decides the next step | Control | Capability |
|---|---|---|---|
| Fixed workflow | Your code; model fills each step | Highest | Narrow, well-specified tasks |
| LLM-routed workflow | Model picks a branch you defined | High | A few known paths |
| Tool-using agent | Model picks tools; loop is yours | Medium | Variable inputs, known toolset |
| Autonomous agent | Model plans and loops to a goal | Lowest | Open-ended, unpredictable paths |
Read the table as a dial, not four boxes. Each step down concedes a decision you used to hold to the model, and buys reach in return: the ability to handle inputs and paths you could not enumerate in advance. Notice that capability and control move in strict opposition down the column. That is not incidental to the technology, it is the trade-off itself, and the next section is about pricing it honestly.
Autonomy versus control
The whole spectrum is governed by one relationship, and it is worth stating without softening it: autonomy and control are inversely related, and every step you take toward capability is paid for in predictability. A fixed workflow does the same thing on Tuesday that it did on Monday because the path is yours. An autonomous agent chooses its own path each run, which is exactly why it can handle cases you never anticipated, and exactly why you cannot fully anticipate what it will do.
That single move ripples into four costs that tend to arrive together. Predictability drops, because the same input can produce different traces. Testing gets harder, because there is no fixed path to assert against, so you move from checking outputs to evaluating behavior over distributions. Cost rises, because open loops mean variable and sometimes large numbers of model calls, each carrying accumulated context. And the surface area for failure widens: a fixed workflow can fail in the ways you enumerated, while an autonomous agent can fail in ways you did not, looping, wandering, misusing a tool, or confidently pursuing a wrong plan.
capability ^ . autonomous | . - | . - tool-using | . - | . - routed | . - | . - fixed +---------------------------------------> autonomy (control high) ----------------> (control low) each step right: more reach, less predictability, harder tests, higher cost, more failure modes
The curve is not an argument against autonomy. It is an argument for buying it deliberately. Each position on the line is the right answer for some class of problem, and the failure is not choosing a high position, it is choosing one you did not need and cannot pay for. Hold this trade in view and the design rule in the next section stops sounding like caution and starts sounding like arithmetic.
Do not build an agent when a workflow will do
Everything above converges on one discipline, and it is the most useful rule in this entire corner of the field: start at the least autonomy that solves the problem, and add autonomy only where the problem genuinely demands it. Most enterprise tasks that get described as needing "an agent" are, on inspection, a known sequence of steps with a couple of branches. That is a workflow. Building it as an autonomous loop does not make it more capable, it makes it less predictable and more expensive at the same job.
This mirrors a discipline the Atlas returns to elsewhere. The adaptation ladder says to climb from prompt engineering to few-shot to retrieval to fine-tuning only as high as the problem requires, because teams habitually reach for the heavy rung too early. Autonomy is the same shape of mistake in a different domain. The autonomous agent is the fine-tuning of architecture: powerful, occasionally necessary, and the option teams grab first when they should grab it last. In both cases the cheap rung is not a compromise, it is frequently the correct answer, and the burden of proof sits on the expensive one.
The practical test is concrete. Can you enumerate the steps in advance? Build a fixed workflow. Are there a handful of known paths and the model just needs to pick one? Route with the model, keep the branches in code. Is the toolset known but the order of use varies with the input? A tool-using agent with a bounded loop. Only when you genuinely cannot write down the path ahead of time, because the problem's shape changes per instance, does the autonomous loop start earning its keep. If you can describe what the system should do as a flowchart, you do not have an agent problem. You have a workflow, and you should be glad, because a workflow is the version you can test, price, and trust.
When autonomy earns its cost
None of this says autonomy is a mistake. It says autonomy is an investment, and like any investment it pays off in specific conditions and destroys value outside them. The conditions are the mirror image of what makes a workflow work: a workflow wins when you can write the path down, so an autonomous agent wins precisely when you cannot.
Three signals mark the territory where genuine autonomy earns its cost. The first is open-endedness: the goal is clear but the work to reach it varies so much per instance that enumerating steps ahead of time is impossible. Investigating an incident from an ambiguous alert, or researching a question whose answer determines the next question, has this shape. The second is unpredictable solution paths: not just many branches, but branches you cannot know until you are in them, where each observation reshapes what to do next. The third is dynamic tool use: the agent must decide, at runtime, which tools to compose and in what order, because the right sequence depends on intermediate results you could not foresee.
- Open-ended goal, variable work. The objective is stable but the route to it differs every run and cannot be scripted in advance.
- Paths that emerge, not paths you list. Each step's result genuinely determines the next, so no fixed flowchart captures the task.
- Composition decided at runtime. Which tools to use, and in what order, depends on what earlier steps returned.
When two or three of these hold, the lower levels stop being cheaper and start being inadequate, forcing you to hard-code paths that do not generalize and that break on the first case you did not foresee. There the autonomy is not fashion, it is fit, and the operational cost of the loop buys real capability you could not get otherwise. The architect's job is to tell fit from fashion honestly: match the level to the problem's actual shape, not to what sounds ambitious in a roadmap. A tool-using agent chosen because the toolset varies is sound engineering; an autonomous loop chosen because "agentic" polls well is the over-engineering this whole article is trying to prevent.
Testing across the spectrum
The hidden cost of climbing the spectrum is not the model bill, it is the scaffolding you must build to run the thing responsibly, and that cost scales with autonomy far faster than most plans account for. A fixed workflow is testable the way ordinary software is testable: the path is deterministic, so you write assertions against known inputs and outputs, catch regressions in CI, and reason about behavior the way you reason about any pipeline. The probabilistic step inside each node needs its own checks, but the shape of the system is one you already know how to verify.
Move up and that comfort erodes. Once the model decides the path, there is no single trace to assert against, so testing shifts from example-based checks to evaluation over distributions of inputs, scoring behavior and outcomes rather than exact outputs. Because the agent can act in ways you did not enumerate, you need guardrails that constrain what it may do regardless of what it decides, and a sandbox that bounds the blast radius of a wrong decision. And because you cannot predict the path, you need observability into every step it actually took, since a run you cannot inspect is a run you cannot debug or trust in production.
This reframes the build-versus-buy-autonomy decision in a way CTOs feel directly. The question is never only "can the model do this," it is "am I prepared to stand up and maintain the eval harness, the guardrail layer, and the observability that a system at this level requires." Often that honest accounting is what pulls a design back down the spectrum: the workflow is not just cheaper to run, it is dramatically cheaper to own, because you can test it with tools your organization already has. Climb only when the capability is worth the operational weight, and know before you commit that the weight is real and recurring, not a one-time setup you can defer.
The architect view
The spectrum is a design tool, and using it well is mostly a matter of resisting a default. The industry's gravity pulls every use case toward the autonomous end, because that is where the excitement is and where the word "agent" points. An architect's contribution is to place each use case on the line deliberately, from the problem's actual shape rather than from the current fashion, and to make the burden of proof sit on autonomy rather than on restraint.
Three commitments carry the discipline, and they belong in the design phase, not in the post-incident review:
- Place every use case on the spectrum explicitly. Before choosing a framework or model, decide whether the task is a fixed workflow, a routed workflow, a tool-using agent, or an autonomous one, and record why. An unstated position is almost always an over-estimated one.
- Default to the lowest autonomy that works. Start at the bottom of the spectrum and move up only when a lower level is genuinely insufficient, the same climb-as-needed logic the adaptation ladder applies to model tuning. Cheap and predictable is the target, not the fallback.
- Add autonomy only where it clearly earns its cost. Reserve the open-ended loop for open-ended problems, and pair every step up with the evals, guardrails, and observability that level requires. If you cannot fund the scaffolding, you cannot afford the autonomy.
This placement is one decision inside a larger, risk-first design process: understand the use case, check that the data is ready, then choose the pattern before touching a model, and design against a reference architecture from day one. The spectrum is the vocabulary for that pattern choice on the agentic side of the house. It also sets up the next question. Once a task genuinely needs autonomy, decomposing it across specialized components leads to multi-agent systems, and structuring the loop leads to planning and decomposition, both of which are ways to buy back some control at high autonomy. But those are refinements of a decision you make first and here: where on the spectrum this problem actually lives. Get that placement right and the rest of the design follows. Get it wrong, reach for an autonomous agent when a workflow would do, and no amount of downstream cleverness recovers the cost. To feel the levels rather than read about them, the Agent Studio in the Lab lets you build the same task at different points on the spectrum and watch what each one costs.