How to automate business solutions, and when an AI agent is the wrong answer

The short version

• Automate one process with clear inputs and a checkable outcome before you automate anything broader.
• Fixed rules are easier to test and cheaper to run than an AI agent, so use them wherever the steps never vary.
• An AI agent earns its extra cost only where inputs vary and the next step depends on reading them.
• Actions that are hard to reverse, such as payments and customer messages, should need a person's approval until the correction rate is known.
• Adoption surveys show what other firms are doing, but they cannot tell you whether your own process will pay back.

Which business process should you automate first?

Automate the process that repeats often, follows a recognisable pattern, has an outcome you can check and does limited harm when it goes wrong. That is rarely the process causing the most frustration. The most painful work is often painful because it is full of exceptions, and exceptions are what automation handles worst.

Good first candidates tend to be dull. Copying invoice details into an accounting system, routing incoming requests to the right team, drafting a reply for a person to approve, or pulling the same report together each week. Each has a clear start and end, and somebody can look at the result and say whether it is right.

Write the process down before you choose anything. Follow a few real cases from start to finish and record every decision, every system touched and every point where someone asks a colleague. Projects often stall here, because the process people describe is not the one they actually run. If nobody can describe the steps, software will not settle the argument. It will just encode one side of it.

What should a process pass before you automate it?

• •Volume: it happens often enough that the saved time outweighs the build and the upkeep.
• •Consistency: most cases follow the same path, and you can list the exceptions.
• •Checkability: a person or a test can tell whether a result is correct.
• •Recoverability: a wrong result can be caught and undone before it does lasting damage.

Should you use fixed rules, a workflow tool or an AI agent?

Use the simplest one that handles the process. Fixed rules suit steps that never vary. A workflow tool suits several systems connected in a known order. An AI agent suits work where the inputs vary and the next step depends on reading them. Each step up adds cost and makes behaviour harder to predict.

The three are not rivals, and a working system often mixes them. A workflow tool moves the request along, a model reads the messy email and extracts the fields, and rules decide what happens next. Using a model only at the step that needs it keeps the rest of the process predictable, testable and cheap to run.

Which approach fits which kind of work?

When is an AI agent the wrong choice?

An AI agent is the wrong choice when the steps are fixed, when volume is low, when a mistake costs more than the work saved, or when nobody can check its output. In those cases a rule, a simple workflow or a person will do the job better, with far less effort.

The reason is mechanical. An agent decides its next step from what the model produces, and that output can differ between runs with the same input. That is useful when the input really is unpredictable. It is a liability when the right answer is already known, because you have swapped a step that always works for one that usually does.

Errors also compound. An agent that takes several actions in a row depends on every one of them being right, so a small failure rate at each step becomes a larger one across the whole task. A demo rarely shows this, because a demo runs the cases that work. Production is where the odd attachment, the missing field and the ambiguous instruction all turn up.

It is fine to conclude that a process is not worth automating. If the honest answer is that it happens twice a month and takes ten minutes, leave it alone.

What should you check before buying automation software?

Check what the software does when it is wrong, not what it does when it is right. Every product demonstrates the normal path well. The useful questions concern failed steps, visibility, access, running cost and how you would leave.

What should you ask an automation vendor?

• •What happens when a step fails: does it retry, stop, or carry on with bad data?
• •Can we see every action it took on a given case, and why?
• •Can we limit its access to exactly the records and actions this process needs?
• •Can a person approve an action before it happens, and can we switch it off quickly?
• •What does one completed case cost at our volume, including model usage and retries?
• •Can we export our data, logs and process definitions if we leave?
• •Can we test a change against real past cases before it goes live?

Should you buy a tool or build a custom system?

Buy when an existing product covers your process and connects to the systems you already use. Build when the process depends on your own data, rules or internal systems in ways no product handles, or when the data cannot go where a product sends it. Try buying first, because it is the cheaper mistake.

We build custom systems, so weigh that advice accordingly. A subscription tool you abandon after a month costs little. A custom build brings upkeep: models change, connected systems change their interfaces, and someone has to own the fixes. That ongoing cost belongs in the decision from the start, and it is often the part left out of the quote.

The signs that a tool has run out are practical. People keep a spreadsheet beside it to handle the exceptions. Someone checks every output because they cannot tell which ones to trust. The logic now lives across dozens of fragile steps nobody wants to touch. Those are reasons to look again, and none of them means you chose wrongly at the start.

How do you keep business automation safe once it is running?

Give the automation only the access the process needs, require a person's approval for anything hard to reverse, log every action, and keep a way to stop it quickly. Those four controls limit the damage from a wrong decision, whichever model or tool made it, and they work without assuming the software will behave.

Approval is the control to relax last. Start with a person signing off every payment, customer message and record deletion. Once you have a history of how often they correct it, remove approval from the low-risk actions first. That decision should rest on measured corrections, not on how confident the demo made everyone feel.

Keep testing after launch. Build a small set of real past cases with known correct results, including the awkward ones, and run it whenever a prompt, a model or a connected system changes. Behaviour can shift after a change that looked unrelated, and nothing will fail loudly to tell you. A wrong answer looks much like a right one in the logs.

How do you tell whether automation is paying back?

Compare the same process before and after, using the same measures: time per case, error rate and cases completed. Count the time people now spend checking and correcting, along with subscriptions, model usage and upkeep. If checking takes about as long as doing the work by hand, it is not paying back yet.

Take the baseline before you start, because it cannot be reconstructed afterwards. Many teams skip this, and then 'it feels faster' becomes the only available evidence. A rough baseline from a couple of weeks of real cases is enough, as long as you measure the same things afterwards.

Decide in advance what result would make you stop. A pilot with no stopping condition tends to continue by default, because nobody wants to be the one who ends it. Naming the threshold early, such as an error rate you will not accept, makes the decision about the evidence.

What do adoption surveys tell you about automating your business?

Adoption surveys tell you what other firms are doing or planning, not whether your process will pay back. That is useful context, but it is not a reason to buy. A survey of other firms says nothing about your volumes, your exceptions or your cost of a mistake, and those decide the outcome.

Each survey measures a different population at a different time, so their figures should not be added together or compared directly. Eurostat's EU survey ran in the first months of 2025, and 157,000 of 1.53 million EU enterprises with at least 10 employees and self-employed persons were surveyed. Smaller firms fall outside that population.

The Federal Reserve Banks' Small Business Credit Survey was fielded from 3 September to 14 November 2025, with 6,525 responses. It is a nationwide convenience sample, which limits how far it generalises, and its 'small' employer firms have 1-499 employees. Its AI figure covers only firms planning to use AI in the next 12 months, which is intent rather than use.

The U.S. Census Bureau working paper CES-26-25 uses nationally representative data from the 2026 AI supplement to the Business Trends and Outlook Survey, with a reference period of November 2025 to January 2026. It looks at firms, business functions and worker tasks. The CFO Survey is older: about 450 financial executives at companies of all sizes, closing on 3 June 2024, with no separate figure for small firms on the page.