A team is asked to make the weekly sales report “agentic.” The steps have not changed in two years: three queries, a chart, a paragraph of narrative, sent on Monday. The agent version makes eleven model calls, costs far more, and sometimes reorders the sections. The engineering was fine. Nobody asked the design question.
That question cuts through every agent pitch and roadmap slide: who decides the next step, your code or the model? That is all an agent is. A loop where the model picks the next action from what it has seen. It observes the goal and the last result, decides, your system runs the action and records it, then checks the limits.
Autonomy is a cost. Pay it only where fixed code can’t cover the cases.
A spectrum, not a switch
| Design | Who picks the next step |
|---|---|
| Single call | Your code. One model call fills in one step |
| Fixed chain | Your code, in an order you wrote down |
| Router | The model picks one branch, then fixed code runs |
| Bounded agent | The model, inside step, budget and time limits |
| Autonomous agent | The model, including the decision to stop |
Count the decisions the model makes, not the number of model calls. A pipeline with six calls in a fixed order is still a workflow. And note that the model never acts: it requests, your code executes. A plan is text it wrote and reads back, so nothing holds it to that plan unless you build something that does.
Why a chain of good steps still fails
- A misread result enters state, and every later step treats it as an established fact.
- An early wrong plan keeps steering the run even as the results disagree with it.
- A failing action gets retried without progress until some limit finally stops it.
- An email sent or a record deleted stays wrong after you fix the underlying bug.
The arithmetic is unforgiving, and worth doing on the back of an envelope. Take steps that each succeed nine times in ten, where one miss ruins the run, and ten of them in a row finish clean about a third of the time. The number is illustrative. The shape is the lesson: fewer uncontrolled steps beats a better model.
Where human approval belongs
| Action | Sensible default |
|---|---|
| Read, search, summarize, draft | Runs automatically, with the output shown before use |
| Reversible changes: labels, notes | Automatic, logged, and genuinely easy to undo |
| Anything a customer receives | A person approves, at least until you have measured it |
| Money, deletion, permissions | Always approved, or never exposed as a tool at all |
Approval follows risk and reversibility, and it has a budget. Every low-stakes confirmation you add spends attention that the high-stakes one will need. Approve few things, show the evidence and the exact diff, and make saying no as easy as saying yes.
- If every input takes the same steps, write a workflow and let the model fill in steps.
- If inputs fall into a few known paths, use a router: one model decision, then fixed code.
- If the path depends on what it finds and the tools are read-only, use a bounded agent with caps.
- If you cannot yet measure whole runs, stay one level less autonomous until you can.
ExplAIn has a module on this: the loop, the spectrum, how errors compound, and how to redesign a real use case at three levels of autonomy so the trade-offs are on the table before anyone builds.