When someone comes to us with a process they want to automate, one of the first things we figure out together is whether they actually need an agent. Sometimes they do not. Sometimes a Zapier workflow or a scheduled script is the right answer, and building an agent on top of it would add complexity without adding value.
This distinction matters practically. Agents cost more to build, require more ongoing monitoring, and introduce a category of failure — the agent making a contextually plausible but incorrect decision — that rule-based automations simply cannot produce. If you do not need that decision-making capability, you should not pay for it.
The rule-based approach: when it is right
A rule-based automation works well when the following conditions hold:
- The inputs are structured and consistent
- The decision logic can be expressed as a finite set of conditions
- The edge cases are rare enough to handle manually without significant cost
- The output format is fixed
A good example: moving data between two systems when a form is submitted. The form fields map to the destination fields. There is no ambiguity about what goes where. The only interesting question is what to do if a required field is missing — and that can be handled with a simple fallback rule.
If your process matches this description, build the automation. It will be faster to build, cheaper to run, and easier to debug. An agent will not make it better.
Where rule-based breaks down
Rule-based systems break down when the inputs are unstructured, when the right action depends on context that cannot be reduced to discrete conditions, or when the process has to handle a long tail of situations that nobody anticipated when the rules were written.
A common failure mode: a company builds a rule-based automation for something like triage or classification. It works well for 90% of cases. But the remaining 10% require someone to make a judgment call — and because the automation is handling the 90%, no one is watching the queue closely enough to catch the 10% before they become a problem. The automation did not fail. It just was not the right tool for the whole job.
This is where agents become worth the additional complexity. An agent can read an unstructured email, understand that it is a cancellation request despite the fact that the word "cancel" does not appear anywhere in it, extract the relevant account details, check whether the account is in a grace period, and decide whether to process the cancellation directly or route it for review. A rule-based system cannot do this without an extremely long chain of conditions that will inevitably miss cases.
The decision framework we use
We ask three questions to decide which approach fits:
- Can you fully describe the decision logic with a flowchart where every branch terminates? If yes, the automation is probably sufficient.
- How often does a human currently override or supplement the automated step? If it is more than 10–15% of cases, that is a signal that the rule set is incomplete.
- What is the cost of a wrong decision — both the direct cost and the cost of not catching it quickly? Higher stakes usually justify the additional control that an agent with a defined escalation path provides.
If the answers point toward an agent, the next question is what the agent's scope should be — but that is a different note.
The practical takeaway: do not let the current excitement around AI agents push you toward using one where a simpler tool is right. Agents are a specific solution to a specific class of problem. When that class of problem is what you have, they are genuinely useful. When it is not, they are overhead.