AI automation or workflow automation: which does the process need?

Start with the work, because the labels overlap

A vendor may call a fixed sequence an AI workflow. Another may call a language-model step an agent. The useful distinction is what the process asks the software to decide.

Workflow automation follows explicit rules: when this event happens, validate these fields, create that record and notify this person. AI automation handles an input where the exact words or layout vary and the result must be inferred. Many dependable systems use both, but not in equal measure.

Use ordinary automation when the rule can be stated

Dates, totals, permissions, status changes and record movement usually belong in conventional logic. The same input should produce the same answer. Tests can cover the rule directly.

For example, a signed contract can create an onboarding case, copy approved fields, assign tasks and wait for required documents. No model needs to guess whether the contract is signed when the source already provides that status.

Give AI a bounded question

AI becomes useful when the input varies in a way that rules handle poorly. An incoming email may need a category. A supplier document may contain the same fields in different places. A long client note may need a short draft summary for review.

Bound the question and the allowed answer. Ask for one of six known categories rather than an open recommendation. Validate extracted values against the source. Send low-confidence or high-consequence cases to a person.

• Classification into a fixed set of routes
• Extraction from varied but recognisable documents
• Drafting from approved facts for human review
• Finding likely duplicates for a person to confirm

Keep the business decision outside the model

A model can prepare a case without owning the promise. It might summarise the request and show the relevant account history. The owner or account lead still decides the price, exception or sensitive response.

This split also makes failures easier to recover. If the model produces an uncertain classification, the process can stop at that step. If the model controls the whole route through an undefined instruction, nobody knows which part to trust after a strange result.

Plan for changing models and providers

Model behaviour changes. Prices, limits and data-handling options change. The process needs a known model role, test cases and an alternative route when the provider is unavailable.

Do not judge health from a successful API response. Check the business result. Was the document classified into an allowed route? Were required fields present? Did a person review the cases above the risk threshold?

A mixed process in practice

Consider a shared enquiries inbox. Conventional automation records the message, matches an existing customer and checks for required contact details. AI proposes a category from a fixed list and extracts a short issue summary. A person reviews unusual or high-value enquiries. Conventional automation then creates the task, records the decision and sends the approved response.

Only one part needed inference. The rest needed a reliable route. That proportion is common and healthy.

Choose by failure behaviour

Ask what a wrong answer looks like and whether it will be noticed. Use fixed rules when silent variation would damage records, money or customer promises. Use AI where variation is unavoidable, the output can be checked and a safe fallback exists.

The best architecture may contain very little visible AI. If the administrative queue moves and the responsible person sees the right exception, the process is doing its job.