TL;DR
You want to automate one business task without paying for, or babysitting, an unpredictable system where a predictable one would do. Split the task into steps. A step whose input, rule and correct output are known in advance belongs in ordinary code or a simple automation. Give a model only the steps where someone now reads, interprets or decides, and choose an agent only when the path itself depends on what is found. You end with mostly predictable software and judgment only where it pays.
In this article
8 min read
Ask the question of each step, not of the whole task
List today’s steps and ask: could you write the rule before seeing the case? If so, use ordinary software or a simple automation. A step needing interpretation may need a model. Use an agent only when the system must choose its next source or tool and decide when it has enough.
That gives three forms, and many real tasks end up as the middle one:
- Ordinary software or a simple automation. Fixed steps and no model, in code or a workflow tool such as Zapier, Make or n8n. Given the same input and unchanged external state, a deterministic rule gives the same output. Technical failures often show up at a known step, though a wrong rule can still produce a plausible wrong answer.
- A fixed workflow with one model step. Your code sets the path; at one point a model reads an email, sorts a note or drafts a reply, and the code checks the answer before anything else happens.
- An agent. The model decides what to look at next and which tools to use, inside limits you set.
These categories follow Anthropic’s engineering guide Building effective agents (December 2024). It calls systems whose models and tools follow paths written in advance workflows, and keeps the word agent for systems in which the model directs its own process and tool use. For your decision, what matters is whether control sits in code you can read or in the model’s choices at run time.
The model providers advise starting smaller
Anthropic’s guide recommends the simplest solution that works, adding complexity only when needed. It notes that agentic systems usually buy better task performance with extra latency and cost, and that autonomy brings errors that compound from step to step.
OpenAI’s A practical guide to building agents (April 2025) names three signs that an agent is worth building: decisions that depend on nuance, exceptions and context, such as refund approval; rule sets so large that changing them is costly or error-prone; and heavy reliance on unstructured material such as documents or conversation. If a use case does not clearly meet them, the guide says, “a deterministic solution may suffice.”
Microsoft’s Cloud Adoption Framework page on planning for AI agents (dated February 2026) starts with when not to use one: clear, repeatable, rule-bound steps go to regular code or non-generative models, which it calls faster, cheaper and more reliable, and answering questions from a fixed set of documents needs retrieval, not an agent.
All three companies earn more when customers make more model calls, so their agreement on restraint is worth noticing. It is still vendor guidance, not an independent study.
Three tasks, worked through
The question appears in public forums in nearly these words. In July 2024 the manager of a mid-sized e-commerce business asked on the OpenAI developer forum whether to build an agent for order processing, inventory and customer support, or use another approach. In July 2026 someone asked on Hacker News what workflow automation still does better than agents. A September 2026 thread in Reddit’s r/automation forum asked where routine sales data updates end and account research for an agent begins.
The examples below are illustrations built from those questions, not a real company’s systems.
Comparison
| Task | Steps that are rules | Step that may need judgment | Suggested form | How a failure shows |
|---|---|---|---|---|
| Update CRM fields when a deal is marked won | Set close date, owner and stage; create the invoice task | None | Simple automation | A run error, or a wrong value you can trace to one rule |
| Process a web order | Check payment, reserve stock, print the label, send the confirmation | Reading a free-text delivery note | Fixed workflow; a model sorts the note into a short list of actions, one being “send to a person” | Code errors are logged; a misread note looks like a normal order |
| Research an account before a sales call | Fetch the CRM record, store the briefing | Which sources to read and what in them matters | Agent that drafts a briefing a salesperson reads | A plausible but wrong briefing that only a reader notices |
The first task gains nothing from a model, which would only add cost and variation to a rule that is already right. In the second, the order flow stays in code and the model does one narrow reading job whose answer the code can check; reordering stock at a threshold is a rule too. Customer support splits the same way. Answering “where is my order?” is a lookup in order data plus a template. Approving a refund is the kind of judgment the OpenAI guide describes, but it moves money, and the same guide advises human oversight for high-risk actions such as cancelled orders, large refunds and payments until reliability is established.
Only the third task has a path that depends on what is found: one account needs its annual report read, another a news search, a third almost nothing. That is agent work, and its output is a draft for a person, who keeps the next-step decision until the briefings have proven themselves. Review effort follows the same order: an automation is reviewed when built and when it fails, a model step needs regular sampling, and an agent’s output is read every time at first.
Where the line between code and model breaks
Splitting a task creates a boundary with two weak points. The first is unusual input reaching the fixed part: an empty field, a new product type, an address format the rule never saw. Code that guesses here makes quiet errors, so write the unknown path explicitly: reject, log and route the case to a person.
The second is model output passed on unchecked. The OWASP Top 10 for LLM applications lists this as LLM05:2025 Improper Output Handling and advises treating the model like an untrusted user: validate its output before another system acts on it. In practice, ask the model to answer from a closed list (categories, allowed actions, required fields), have the code confirm the answer is on that list, and send anything else to a person.
Validation catches malformed answers, not a well-formed wrong one, such as a delivery note sorted into the wrong valid category. Only checking the model step against real cases with known outcomes finds those, so a model’s judgment needs its own evaluation, separate from the code’s tests. Deterministic proof and model judgment are different evidence explains why the two should not be reported as one green signal.
Four constraints that can settle the choice
- The cost of an error, and whether it can be undone. If a wrong action is expensive or irreversible, a person approves it first, whichever form you choose.
- How fast you must see what broke. Fixed code often fails with an error at a known step, but a wrong rule can fail silently too; a model step can produce a plausible wrong answer, and an agent’s failure can sit several decisions back. If you must explain a wrong order within the hour, keep that path in code and log the model’s input and output.
- Running cost. A rule costs little per run once built. Each model call is billed by usage, and an agent may make several calls per case.
- Who may approve an action. Name the person who owns the result and can stop it; without that authority, approval is a formality, as human-in-the-loop done right argues for AI coding.
Run a trial that could prove you wrong
Before building in full, collect recent real cases with known right outcomes, including the awkward ones. Try the cheapest form that might work, often a fixed workflow with one model step, and record four things: the error rate against the known outcomes, the minutes of review each case needs, the cost per handled case, and the name of the person who owns the result. Microsoft’s guidance says the same in business terms: use the agreed metrics as go or no-go gates and pilot the hardest steps first.
Decide before the trial what result would make you simplify. If the plain automation handles most cases and the rest go to a person at an acceptable cost, that is a good answer, and it needs no agent.
Eliyce starts every agent request by agreeing the task, its success criteria and acceptance checks, including whether an agent is needed at all, and proposes fixed steps as ordinary code. No customer agent built by Eliyce is in production yet, so the method is what can be shown. If you want a second view of where the line sits for your task, see how we build and run agents.
Frequently Asked Questions
How do I know whether a task in my business needs an AI agent, a simple automation or ordinary software?
Judge each step, not the task: rules go to code, interpretation goes to a model step, and only a path that depends on what is found goes to an agent. Between a workflow tool and ordinary code, choose by how much logic the steps hold and who maintains them; once a flow grows many branches, it usually deserves version control and tests.
How can I tell whether a step’s inputs, steps and correct output are fixed in advance?
Ask the person who does the work now to write the rule for that step, then hand it to a colleague to apply to last month’s cases. Where the rule holds, the step is fixed. Where both of them keep saying “it depends”, or the exceptions pile up in a separate inbox, someone is exercising judgment.
What has to stay true whatever I choose?
Write the limits down as pass or fail criteria before choosing: the highest acceptable cost per case, how quickly a failure must be noticed, which actions need approval and by whom. A form that cannot meet one of them is ruled out, however capable it looks in a demonstration.
If a model handles only the judgment step, where can that boundary fail later?
Over time. Providers update and retire models, so the judgment step can change behaviour while your code stays the same. Keep the real cases from your trial as a fixed test set and rerun them before any model, prompt or provider change reaches users.
What evidence after a trial shows the choice was right?
A comparison, not a single number. Set the error rate, review minutes, cost per handled case and owner against the manual baseline or the simpler version you ruled out. If the more complex form does not clearly beat the simpler one on the measures you agreed beforehand, keep the simpler one.
