Which workflows actually suit AI automation

The question we hear most often is not “can AI do this?” but “should it?”. Language models are good at a specific set of things: reading unstructured text, classifying it, summarising it, drafting from it and following a defined format. They are unreliable at exact arithmetic, at remembering facts they were not given, and at decisions where being confidently wrong is expensive. Choosing the right workflow is most of the work.

Five signs a workflow is a good fit

• It happens often. A task done ten times a day repays the effort of building, testing and reviewing. A task done twice a quarter does not.
• The input is text or documents, not numbers that must be exactly right.
• The output can be described as a fixed structure: a category, a priority, a summary, a draft, a list of extracted fields.
• A person can check the result quickly, and the cost of a wrong result before that check is low.
• The rules are fuzzy but the examples are plentiful. If you can show twenty good examples, a model can usually learn the shape.

Common candidates

In most small and medium businesses the same handful of jobs come up: triaging inbound enquiries into category and priority with a suggested next step; summarising long email threads or meeting notes; extracting fields from invoices, forms and supplier documents; drafting first replies to routine questions; tagging and routing support requests; turning free-text feedback into themes. Each has a clear input, a describable output and a natural review point.

Signs to leave it alone

• The decision is rare and high-stakes: a pricing call on a large contract, a hiring decision, a legal or medical judgement.
• The answer depends on information the model does not have and cannot be given safely.
• Exactness is the whole point: totals, dates, legal wording, regulatory references.
• Nobody can review the output before it reaches a customer, and a wrong output causes real harm.
• The real problem is that two systems do not talk to each other. That is an integration job, not an AI job.

How we scope a candidate

We watch the job being done, count the steps and the exceptions, and write down the output as a schema before writing a single prompt. We decide what happens when the model is unsure, when the service is unavailable and when a person disagrees. Then we run the automated version alongside the manual one for a while and compare. That comparison, not the demo, is what tells you whether the workflow suits automation.

What a good deployment looks like

The model is called from a server, never from a browser, with credentials kept in environment variables. Inputs are validated and size-limited. Outputs are checked against the schema before they are stored. Requests are rate-limited. If the model is unavailable, the work is queued for a person rather than lost. And the data-handling note says, in plain language, what is sent where and for how long.

Pick a frequent, text-heavy, reviewable job. Build the review step before the automation. Measure it against the manual process. That sequence turns AI from an experiment into a tool the team trusts.

Written by the AFTERLIGHT studio team.