Strip the marketing and an agent is a loop. A model receives a goal, picks a tool, sees what came back, and picks again until it decides it is finished. That is the whole idea. It is a genuinely useful pattern, and its useful range is much narrower than the way it is being sold.
What the loop actually buys you
The value is that you no longer have to write down every step in advance. A conventional program needs the path specified: fetch this, check that, branch here. An agent works the path out at runtime, from the goal and from whatever it finds along the way. Where the path genuinely differs case by case, that flexibility is worth real money.
The cost is that you gave up knowing what it will do. Every step is a decision made by something that is right most of the time. “Most of the time” is a very different property from “always”, and it compounds.
The arithmetic nobody puts on the slide
Say each step in your loop is right ninety-five percent of the time. That sounds strong. Chain five steps where each one depends on the last and you land near seventy-seven percent. Ten steps takes you to roughly sixty. Twenty steps and fewer than four runs in ten finish correctly.
This is arithmetic, not pessimism. It also explains why every impressive agent demo you have watched is short. A better model raises the per-step number without changing the shape of the curve, because ninety-nine percent per step still decays over a long enough chain. What helps is fewer steps between checks.
Where agents earn their keep
The task has edges
There is a clear finish line and a small set of tools. Triage an inbound message and route it. Take a failing test and try fixes until it passes. The loop has somewhere to stop, and it knows when it has got there.
The work repeats without being identical
If every case were the same you would write a script, and the script would be cheaper, faster, and easier to debug. Agents pay off in the middle ground where the shape of the work repeats and the details change every time.
Mistakes are cheap to undo
Drafting, tagging, summarising, opening a pull request. Anything where a wrong output costs somebody thirty seconds of review and nothing else.
A machine can check the result
This is the condition people skip, and it is the one that decides whether the project works. If a test passes or a total reconciles, the agent can tell whether it succeeded and go round again. With no automatic check, the loop is guessing, and it will report success either way.
Where they fall over
- Long chains with no checkpoint. See the arithmetic above.
- Irreversible actions. Sending email to customers, moving money, deleting records, publishing anything. Every action that ends up outside your own system.
- Work that needs accountability. If an auditor or a regulator would ask who decided, an autonomous loop is a poor answer. Someone has to own the decision, and it cannot be a loop.
- Anything where being confidently wrong is worse than being slow. The agent will not tell you it is unsure. It produces a plausible result and moves on.
Three deterministic steps and one model call
The best implementations of this pattern barely look like agents at all.
Take an inbound support message. The fully autonomous version reads it, decides what to look up, decides what to do, and acts. The version that holds up in production does the lookup in code, because you already know which record you need. It calls the model once, to classify and draft. Then it applies the routing rules in code, because a routing table is a routing table. One model call, three deterministic steps, and a system you can write tests for.
The difference shows up the day something breaks. In the deterministic version you can point at the step that failed and fix it. In the autonomous version you get a transcript of the model's reasoning and a shrug. Being able to debug the thing is a feature, and handing the model fewer decisions is how you buy it.
Give the model the judgement call and give the code everything else. Every decision you hand to the loop is a decision you can no longer test.
The rule about undo
A person approves anything you cannot take back. That is the whole rule, and it holds up better than any policy document you could write around it.
In practice the agent prepares and a person commits. It drafts the email and a person sends it. It stages the refund and a person releases it. It opens the pull request and a person merges it. The agent does the ninety percent that is tedious and stops at the boundary where a mistake becomes permanent.
Approval fatigue is the failure mode here, so make approving cheap. A person clicking approve two hundred times a day without reading is worse than no approval at all, because now the mistakes carry a signature. Batch them, and let the obvious cases through on rules you wrote deliberately and can point to later.
Scoping a first agent so failure is cheap
- Pick a task that is annoying rather than critical. If it fails quietly for a week, someone is mildly irritated and nobody is calling a lawyer.
- Cap the loop. A hard limit on steps and on spend per run. Ten steps is plenty for a first project, and when it hits the cap, that is information about the task.
- Give it read access to what it needs and write access to almost nothing. Let it propose changes into a queue.
- Write the success check before you write the agent. If you cannot describe how a machine would know it worked, you are not ready to build it.
- Run it in shadow mode for two weeks. It does the work, a person does the work, and you compare the two. It is the cheapest evaluation available.
None of this is an argument against agents. The loop is a real capability and it does things that no amount of hand-written logic can reach. The position worth holding is that its range is narrower than the current conversation implies, and the teams getting value from it are the ones who drew the boundary tightly and then put a person on the edge of it.