The question is never whether AI can do a job. It usually can, in a demo. The question is whether doing it that way is worth the cost, the review, and the new work it creates. Those are different questions and only the second one matters.
Here is how we work out the answer before anyone builds anything.
The shape of a task worth automating
Four things have to be true. Not three.
It happens a lot, and it is nearly the same every time. Two hundred invoices a month beats four contracts a year, every time.
There is a right answer, and a person could check it in under a minute. If checking the output takes as long as producing it, you have moved the work, not removed it.
The input is already digital, or can be photographed. Paper is fine, and a phone camera plus document reading handles most of it. A filing cabinet nobody has time to open is not.
Somebody currently hates doing it. This one sounds soft and it is the best predictor of the project surviving. Automating work people find satisfying goes badly.
Tasks that usually meet all four: reading supplier invoices and matching them to a purchase order, sorting an inbox and drafting first replies, rebuilding the same report every Monday, pulling data off submitted forms, answering repeat questions from your own written material. That last one is worth doing properly -- an agent that answers only from your documents and links to the source, and says it does not know when the answer is not there. More on the shape of those builds in AI agents and automation.
The shape of a task that is not worth it
Rare and expensive to get wrong. Done four times a year, with big consequences. There is not enough of it to justify the build, and not enough repetition for anyone to get good at spotting the mistakes.
Judgement that depends on knowing the person. Whether this particular customer gets the discount. Whether this family needs a phone call rather than a letter.
Anything your own team disagrees about. If two experienced people would handle it differently, there is no right answer to automate towards. Settle the disagreement first; you may find that was the actual problem.
Where the typing is not the cost. A task with three minutes of data entry and forty minutes of deciding is a forty-three minute task. Automating the three minutes saves three minutes.
The rule about money, health and contracts
Anything that moves money, affects someone's health, or creates an obligation gets reviewed by a person before it takes effect. No exceptions, and we build the review step in rather than offering it as an option.
This is not about whether the software is clever enough. It is about the asymmetry. A wrong payment costs you the money plus the hours of getting it back plus the supplier relationship. A person spending fifteen seconds approving it costs fifteen seconds.
The review has to be built so it stays cheap, or it will be abandoned within a month. That means the agent presents the work already done -- extracted, matched, drafted -- and the person approves, corrects, or rejects with one action. If your reviewer has to re-do the work to check it, you have built a duplicate, not a control.
Two things to watch. Confidence scores are useful: let the agent mark what it is unsure about and send only those to a person, once you have evidence that its confidence means something. And beware bulk approval. When somebody approves eighty items in under a minute, the review step has quietly stopped existing. If that is happening, either the task is genuinely safe to run unattended -- decide that deliberately -- or the review needs to be smaller and more frequent.
The two-week silent trial
This is the part we insist on, and it is the reason we can say honestly whether something works.
Build the agent, then run it beside your team without changing anybody's job. The team does the work exactly as they do now. The agent does the same work in parallel, and its output goes into a file that nobody acts on.
After two weeks, compare. Three things come out of it.
Agreement. How often the agent and the team produced the same answer, checked by hand on a real sample rather than by the agent scoring itself.
The type of disagreement. This is more useful than the rate. Systematic errors -- it always misreads one supplier's invoice layout -- are fixable in an afternoon. Random errors, with no pattern, are much harder and tell you the task may not be a fit.
Time, measured on a clock. Not estimated. How long the task takes now, and how long the review version takes. The difference is the only saving you may count.
You also find out where your team disagrees with itself, which is uncomfortable and valuable. Sometimes the agent is right and the current process is wrong. That is a finding, not an embarrassment.
Do not skip this and go straight to a pilot with real customers. The silent version costs you two weeks and tells you nearly everything.
Counting the saving honestly
Take the hours the task takes now. Subtract the hours the reviewed version takes. That is the saving -- not "productivity", not "freeing people up for higher-value work", just the hours.
Price them at what those people cost. Then subtract the running cost of the agent and the ongoing maintenance, because both are real and neither is zero.
If the remaining figure does not clear the build cost inside a year, we will tell you not to do it. The arithmetic is not complicated and it is better done before the project than after.
Count the new work too. Someone has to review. Someone has to notice when it breaks. Someone has to answer the question of what happens to the flagged items on a day when that person is off.
What actually goes wrong
Something upstream changes and nobody notices. A supplier redesigns their invoice; the agent starts getting a field wrong; three weeks pass. This bites hardest in engineering and trade back offices, where the paperwork arrives from dozens of different suppliers in dozens of different layouts. This is why an alert on the failure rate is part of the build rather than a nice extra.
One bad week ends the project. Trust is not proportional to accuracy. Agree in writing, before you start, what error rate is acceptable and what happens when it is exceeded. Without that, the first visible mistake decides everything regardless of the average.
It gets used for something it was not built for. An agent trained on your policies starts being asked legal questions. Set the boundary and make it say no.
Nobody owns it. Same failure as any system. Name the person.
Where we would tell you no
If the aim is to reduce headcount, say so at the start. We will do the arithmetic with you honestly, and quite often the honest answer is that it does not reach that far -- it removes hours, not people.
If the task happens twice a month. If your process is about to change anyway. And if the agent would need broad access to your systems in order to save twenty minutes a day, because the security exposure is a real cost even when nothing goes wrong.
The projects worth doing are usually smaller and duller than the ones people arrive asking for. One task, high volume, checkable, with a person still deciding the things that matter.
Filed under
- ai agents
- automation
- process
- human review