Point of View
Most of What You Want Automated Is a Rule, Not a Judgment
Most of the work businesses want automated is repetitive and already decided, so a written rule handles it better than something that decides fresh each time. Capability you do not need becomes supervision you pay for as long as the tool runs.
You asked whether something could handle the twelve refund requests that arrive every day. They are nearly all the same, and they eat an afternoon. What came back was a proposal for a system that reads each request, works out what the customer wants, picks the right action and carries it out.
What you asked for and what came back
The proposal was more impressive than the question. It also cost several times what you had in mind, which is what tends to happen when a conversation drifts from the job you described toward a demonstration of what the technology can do. Nobody was being dishonest. The bigger version simply sounded like the safer one, and safer is easy to sell.
Six months on, someone opens the queue every morning and checks each decision before it goes out. Not because the tool is bad. Because a wrong refund costs real money, and the output sounds equally confident whether it got the case right or not. So the build works and the day looks much the same. The afternoon you wanted back did not come back. It changed hands.
Judgment is a running cost
Anything that can reach a different conclusion on Tuesday than it reached on Monday brings three obligations with it, and they last as long as the tool does. Someone has to watch a portion of the output. There has to be an agreed answer for what happens when it is wrong. And there has to be some way to reconstruct why it did what it did, because a customer will eventually ask. None of that appears on the invoice. It appears in somebody’s week.
A rule carries very little of that. A rule tends to fail in more predictable ways, which makes it easier to test and correct. And when a rule meets a case it does not cover, it stops and puts the item in a pile for a person. A system designed to decide may keep producing an answer unless you explicitly build in a handoff. The cases that most need a human are often the ones that come back looking exactly like the rest.
Ambiguous, or simply undecided?
Here is the sorting question worth carrying into any vendor call. Is this work genuinely ambiguous, meaning two experienced people could look at the same request and land in different places? Or does your most experienced person give the same answer every time and explain it in one sentence? If it is the second, the work is not ambiguous. The answer exists. It has just never been written down anywhere a system could use it.
Writing it down is unglamorous, and it usually surfaces arguments that have been sitting unresolved. Refunds past thirty days. Damage that happened in shipping. The customer on their fourth request this quarter. Buying something that decides lets you postpone those arguments, which is part of the appeal, but you do not avoid them. They come back as a review queue.
The common advice runs the other way: pick the most capable option so you do not limit yourself later. Gartner has noted that many use cases being positioned as agentic today do not actually require an agentic implementation. That matches what the work looks like from the inside. Capability you do not need does not sit quietly in the background. It becomes variability, and variability is something a person has to supervise.
What this changes in the next conversation
Before you approve anything, ask which of these cases are genuinely ambiguous, who will check the output and for how long, and what happens the first time it is wrong in front of a customer. A vendor who has thought about the work can answer all three. A vendor selling capability will usually answer the first one by telling you the model is very good.
Then spend an afternoon trying to write the rule yourself. If most of the cases fall out as plain conditions and a small remainder is genuinely hard, what you need is a rule plus a clean hand-off to a person. That is the work that belongs before a build, not after it, and it is the cheapest part of the whole project.
The real choice is between a decision you could write down and one you have quietly handed to a machine. The second looks more modern, and it is the one that keeps costing you after go-live. Buy the least capable thing that reliably does the job. Sophistication you did not need does not stay inside the software. It ends up on somebody’s calendar, every morning.
How we architect AI systems
How we architect AI systems
About the author
Missy Ross
Missy Ross is the Founder and AI Architect of Vero Dawn, an AI architecture and solutions company that helps businesses see what could work better, determine the right solution, and bring it to life. Before founding Vero Dawn she spent 21 years in internal audit across banking and manufacturing, at Audit Director level.