- An agent costs time, money and control, so add one only when a simpler model call does not pass your test.
- Anthropic advises finding the simplest solution and adding complexity only when needed.
- For me simplicity is a rule about time: fewer parts, less to watch.
Texts about agents usually encourage building ever more elaborate setups: several models, planners, memory and tools. This essay defends the opposite thesis. Before you build an agent, check whether one well-described model call is enough. It is an opinion, but it rests on guidance published by the people who build these systems.
Why simplicity is about time
In the text Building effective agents Anthropic distinguishes workflows, in which code leads a model along a predefined path, from agents, in which the model decides the next steps itself. The authors advise finding the simplest solution and increasing complexity only when it is needed. They also note that agentic systems usually trade speed and cost for a better result, so you must be able to answer whether that trade pays off.
For me this is an argument about time. Every extra part is something to understand, run, fix after an update and watch when it starts behaving strangely. The rule from my Philosophy page says technology should give time back, not take it. An agent you supervise every hour takes more time than it saves.
How I check whether an agent is needed
I start from the simplest version of the task: one prompt, one model, twenty real examples and a pass criterion written before the run. If the result is good enough, I stop there. If not, I look for the cause before adding anything: is context missing, is the prompt unclear, does the task need several steps? Only the last case justifies a flow with several calls, and a full agent is needed when the number and order of steps depend on what the model finds along the way.
You can see a similar emphasis on verification in the Claude Code guidance: the best practices open with the advice to give the agent a way to verify its own work, for example tests. What improves the result is a clear goal and the ability to verify, not another layer.
What you lose by adding an agent too early
The first loss is predictability. A simple flow can be described on a sheet of paper and tested on examples; an agent that chooses steps itself may do something different on each run. The second is cost, because more steps mean more tokens, which I describe in the article Task cost in tokens. The third is control: the more independence, the more decisions that should pass through a person, which I write about in the approvals checklist.
When an agent makes sense
I am not saying agents are not worth building. Open-ended tasks in which the number of steps cannot be predicted, such as fixing a bug in unfamiliar code, are a natural place for an agent. There is one condition: you have a way to check the result. A test that passes or fails will do more than the most elaborate plan. How such a coding agent works is explained in the article How coding agents work.
My rule for today
I write it briefly: start with one call, measure, add one part, measure again. If the measurement did not improve the result, the part goes. It sounds modest, but it saves weeks of maintaining a setup nobody needed.