Know when an agent is the wrong answer
Comparing agents, plain automation and a single well-aimed prompt on the things that actually differ.
Before you start
- A task you are considering automating
What you will be able to do
- Apply the one test that separates agent problems from workflow problems
- Compare cost and reliability honestly across the three options
- Recognise the tasks that should not be automated at all yet
Agents are the interesting architecture, which is why they get chosen for problems that did not need one.
The question is not whether an agent could do the job. It is whether the job has the property that makes an agent worth its cost — an unknown number of steps.
The test: do you know the steps in advance?
If you can draw the flowchart, you do not need an agent.
Write down the steps for a typical case. If you can list them, and they are the same every time, that is a workflow — and a workflow with a model call in the middle will be cheaper, faster and far more debuggable.
An agent earns its cost when the sequence genuinely varies by input: sometimes three lookups, sometimes eleven, and you cannot tell which until you start.
Compare the three honestly
One prompt, a workflow, an agent — cost, reliability and debuggability.
One prompt: one call, fully predictable cost, trivial to debug, cannot gather anything it was not given. Workflow: fixed calls in a fixed order, predictable cost, each step independently testable, cannot adapt. Agent: variable calls, unpredictable cost, hard to debug because no two runs are alike, and the only one that adapts.
Note that "hard to debug" is not a minor entry. It is the property that determines whether you can keep the thing running in six months.
Consider the hybrid, which usually wins
A workflow with one agentic step where the variability actually lives.
Most real problems are a fixed pipeline with one genuinely open step in the middle — research this specific claim, work out which of these records match.
Making that one step agentic and leaving the rest as ordinary code gives you the adaptability where it is needed and predictability everywhere else. This is the shape most successful deployments converge on, usually after trying the fully agentic version first.
- Start as a workflow. Promote a step to an agent when you observe it failing on variability, rather than predicting that it will.
Know the "not yet" category
Unknown steps plus an unverifiable result is not an automation problem.
If the path varies and you cannot cheaply tell whether the output is right, an agent will produce confident results at a quality you cannot measure.
That is worse than no automation, because it looks like it is working. Either find a verification method first — which is often the real project — or leave the task alone.
Known steps, use a workflow. Unknown steps and a checkable result, consider an agent. Unknown steps and no way to verify, do not automate it yet.
Common questions
Was this guide useful?
94% of readers found this useful
Read next
Build your first agent that does one thing reliably
Agent demos look magical and agent deployments mostly fail on the same three things: unbounded loops, unverified tool output, and…
Give an agent tools without giving it your whole account
An agent with your API key has your permissions. Since its instructions can come from text it reads, those permissions are effecti…
Connect two apps with an AI step in the middle
The genuinely useful automations are not the clever ones. They are a trigger, one AI step that makes a small judgement, and a writ…
Write ad variants and test them properly
AI removes the cost of writing variants, which makes it very easy to run tests that cannot teach you anything. The discipline is i…
