The question that should come before handing a job to AI usually gets skipped. Does this job actually need an agent?
We sell agents, and we are the ones saying it. Most work does not want an agent, it wants a rule. An agent in the wrong place is expensive, and it is hard to be sure it is even working.
The shape of the input decides
If you can write the order of the steps in advance, code is enough. If the content of the input changes that order, you need an agent.
Reading fields out of an invoice file and writing them to a database is rule work. The fields are always in the same place, the process always runs in the same order and the result has to come out identical every time.
Reading a free-text request and deciding which team it goes to is a different kind of work. The shape of the request changes every time, the exceptions are too many to count and the decision depends on the content itself.
The three-question test
Could you explain this job to a new hire as "first do this, then do that"? If you can, that explanation is already code. Take the model out.
Does the input arrive in a regular shape? If the same fields sit in the same places, no discerning intelligence is needed.
Does the same input have to give the same output every time? If so, stay away from the model. Models by their nature can answer the same question by different routes, and there is no way to suppress that completely.
If you answered yes to all three, the job in front of you is an automation job. Adding an agent only makes the bill bigger.
What an agent really costs
The most visible line is token spend. By Anthropic's own measurement, agents use roughly four times the tokens of a chat interaction, and multi-agent systems roughly fifteen times (Anthropic, How we built our multi-agent research system). That difference does not show up in a single call. It shows up on the invoice at the end of the month.
Latency works in the same direction. A job measured in milliseconds on the code path is measured in seconds on the agent path. Anywhere a user is waiting at a screen, that gap becomes a problem in its own right.
The line least often counted is the supervision load. You can tell a rule-based job ran correctly from a log line. To know an agent ran correctly you have to read the steps of the run, define an acceptance criterion and keep a set of examples. If nobody does that, the system looks like it is working and nobody can be sure.
Why "start simple" keeps getting repeated
The same warning appears in the engineering post of the company that makes the model. Multi-step agent systems should be added "only when simpler solutions fall short", and for most applications "optimizing single LLM calls" is often enough (Anthropic, Building Effective Agents).
It is striking to hear that from a company selling agents, but an agent in the wrong place produces the kind of failure that shakes trust in the whole technology.
The right answer is usually both
In solid setups, code holds the skeleton of the work and the model is placed only where the decision gets made.
Think about an incoming support request. Receiving it, recording it, finding who it came from and sending a notification are code work. Deciding what the request is about is model work. The routing after that decision goes back to code.
In a system built this way the surface the model touches shrinks. A smaller surface is cheaper, and when something goes wrong you know where to look.
We had the chance to build the same job both ways and compare. Fixing the step order and leaving only the variable part to the model turned out both cheaper and more repeatable than having the agent reinterpret a recurring job from scratch every time. The agent's real value showed up when the shape of the input broke down.
Five signs you think you want an agent but actually want code
If your prompt has turned into a list of "if this, then do that", writing that list as code is both cheaper and more reliable.
If you count it as a bug when the same input gets a different answer, you are really expecting a rule from the model.
If you force the output into a rigid template every time, the thing producing the template does not need to be a model.
If the agent's tool list has one tool in it, there is no choice to make, and with no choice there is no need for an agent.
If you are calling the model only to convert text from one format to another, the libraries for that already exist.
The opposite is expensive too
Clinging to rules is not free either. As the list of exceptions grows the maintenance cost climbs, and past a certain point nobody wants to touch that piece of code.
If a routing table with hundreds of rules can no longer be read, that is where a model genuinely earns its keep. A model can tell similar cases apart without every exception being written out.
If the person who writes the rules keeps saying "I need to add this case too" every week of the month, the job has outgrown what a rule can carry.
When you cannot decide
Try the cheap option first. Write the rule, note where it fails for a month, then look at the notes and decide.
If the failures look alike, one more rule will do. If every failure is different from the last, you have found the place where an agent will pay off.
Sources
Anthropic, Building Effective Agents
Anthropic, How we built our multi-agent research system