What an AI Automation Agency Should Ask Before Writing Code

There is a pattern in automation projects that is easy to spot once you have seen it a few times. The technology works exactly as designed, and the project still fails, because the process it automated was never worth automating in the first place.

An AI automation agency that starts by asking which tools you use is starting in the wrong place. Here is where the conversation should actually begin.

"Walk me through the last ten times this happened"

Not the process as documented. The process as performed.

The gap between those two is where automation projects die. The documented version has four steps. The real version has four steps plus a spreadsheet someone maintains privately, plus a message to a colleague who knows the exceptions, plus a rule that nobody wrote down about which customers get treated differently.

Automate the documented version and you have built something that handles the easy cases and breaks on everything else, while the humans quietly keep doing the real process alongside it.

"What happens when it gets it wrong?"

Every automated system produces wrong output eventually. The question is what the wrong output does next.

If a misclassified invoice quietly posts to the wrong account, that is a problem you discover at year end. If it lands in a review queue with an explanation, that is a system you can trust.

Design the failure path first. It is the part that determines whether people keep using the system after the first bad week.

"Who owns this in six months?"

Automation creates a new thing that needs looking after. Someone has to notice when it stops working, understand why, and fix it.

If the answer is "the agency", make sure that is written down and paid for. If the answer is someone internal, they need to be in the room during the build, not handed a document at the end.

The most common way automation dies is not dramatic failure. It is a small breakage that nobody owns, so people route around it, and within a month everyone is doing it manually again while still paying for the tool.

"What is this worth if it works?"

A process that takes twenty minutes a week is not an automation candidate, no matter how annoying it is. The build, the maintenance, and the failure handling will cost more than the twenty minutes forever.

The honest calculation is time saved per month, times how long the process will exist in its current form, minus the cost of keeping the automation alive. A lot of tempting projects do not survive that arithmetic, and it is better to find out in the first meeting than the fourth.

"Does this need AI at all?"

This is the question a good agency asks against its own interest.

A large amount of what gets sold as AI automation is a scheduled job, a well-designed form, or a rule engine. Those are cheaper to build, cheaper to run, and far easier to debug, because their behaviour is deterministic.

AI earns its place where the input is genuinely unstructured: free text, documents in inconsistent formats, conversation. When the input is already structured, adding a language model adds cost and unpredictability in exchange for nothing.

The order that works

Process first, failure path second, ownership third, arithmetic fourth, technology last.

Reversing that order is the single most reliable way to build something impressive that nobody uses six months later.

That order, process first and technology last, is how our AI automation engagements are scoped. Often the honest answer at the end of it is that the problem needs ordinary software rather than a model, which is cheaper to build and far easier to debug.