Let the model read it. Let a person commit it.
An AI workflow is an automated process with one step performed by a language model — reading unstructured input and turning it into a structured, checkable result. The model classifies and extracts; it does not decide. Anything carrying judgement or money stops at a person before it commits to anything.
Personal reply from Andrew within one business day.
What is an AI workflow?
An AI workflow is an automated process in which one step is performed by a language model — usually the step that reads something a person wrote and turns it into a structured record the rest of the process can act on.
Conventional automation needs structured input, which is why so much manual work survives in businesses that have already automated everything they could: the work that is left arrives as prose. An email that says the usual, but bring it Thursday. A supplier statement as a scanned PDF. A note explaining why the job took two days longer. No rule can be written against any of those, so a person reads them, and the reading is the job.
What the model is for is conversion. It turns unstructured input into structured output — a category, a set of fields, a reference, a flag saying this one is unusual. That is a narrower trick than the marketing suggests. Everything downstream of it is ordinary software: validation, a rule, a queue, a posting. The model is one step in a process, not the process.
Which is why letting the model decide is the wrong architecture. A language model is an excellent reader and an unreliable rule engine. If the business rule is that anything above the approval threshold goes to a manager, that belongs in code, where it can be read, tested and pointed at during an audit — not in a prompt, where it is a suggestion a different model version may interpret differently. Keeping the reading and the deciding apart is the difference between a finance team trusting the output and quietly checking every line of it.
The failure mode that matters is confidence. A model produces a fluent answer whether or not it had the information to produce a right one, and a wrong answer is formatted exactly like a correct one. Nothing downstream can tell them apart. So the design has to create the signal that does not exist naturally: a fixed output structure with an explicit unsure value the model may use, a check against something external wherever one exists, and a person at the end of anything that does not come back clean.
Workflows of this shape are already running in New Zealand businesses — among them a research agent reporting monthly to a trades business on what its market is searching for, with the site changes that follow made through the client’s own content management system, and a support assistant answering from a client’s own knowledge base. A third set works on stock, weighing replenishment timing and the holding-against-stockout trade-off across a multi-site distributor and proposing what to move where — with the call itself left to a planner, which is the same division of labour this page argues for throughout.
Where the input is already structured, an ordinary automation is cheaper — see process automation. Where the result has to be written into a business system, the hard part is the posting rather than the reading, covered on systems and API integration, or Accredo API integration where the destination is Accredo Saturn. And where the question is whether any of it is worth doing, that is AI consulting.
Where does the human sit?
The question asked of every candidate task: may the model act on its answer, or may it only propose one? These are not a hierarchy. They are two different jobs with two different designs.
Most tasks are not cleanly one or the other, and the useful move is to split them. Very few real jobs sit entirely on the left, which is why so many pilots stall at the demonstration: the task was assessed whole, judged too risky whole, and abandoned whole. Read it as a sequence and it usually separates. Matching a supplier statement against what was received is judgement-light and dull. Deciding what to do about the three lines that did not match is judgement-heavy, and is the part the person was being paid for.
The human check has to be worth a human’s attention. A workflow that asks a person to approve every result is the original task with a screen in front of it, and it will be clicked through without being read within a fortnight — worse than not building it, because it produces the appearance of oversight. A check worth reading is one a person sees only when the model said it was unsure, when an external check disagreed, or when the case is one the business has decided always gets human eyes.
The count of cases the workflow refuses to answer is the health measure. A workflow that never says it is unsure is not accurate; it is unmeasured. There has to be a way for the model to decline, a place declined cases go, and a named person who opens that queue. If the count falls to zero, something has been configured to stop asking. If it climbs, the input has changed.
Does this need a model at all?
Four routes, and the second is the one almost nobody checks. It is already paid for, it is nobody’s project, and it is frequently one setting away from doing the job.
| A person reads it | The assistant you own | A model call in your process | A specialist product | |
|---|---|---|---|---|
| What it is | Somebody opens each item, reads it, and does the next thing. The default, and rarely a decision anyone made. | The AI already built into products you pay for — Copilot in Microsoft 365, capture in the accounting package. | A step in an automated process that calls a model, gets back a fixed structure, and hands it to ordinary code. | A product built for one job — invoice capture, document classification — sold as a finished thing. |
| Where it wins | Low volume, genuine judgement, or input that changes shape constantly. | Worth exhausting first. Already paid for, no build, frequently one setting away. | Real volume, input arriving in a predictable place, and a result something downstream can check. | Where the job is exactly the job the product was built for, and volume justifies a per-document fee. |
| What it costs | A recurring slice of somebody’s week, and a single point of failure who takes leave. | Licences you are probably already paying, and the time to find out what they do. | A build, a measurement exercise, and a small per-item running cost that grows with volume. | A subscription that scales with volume, and a second place your business logic lives. |
| How it fails | Predictably and slowly. Backlogs, transcription errors, and the week nobody is available. | By being generic. Good at helping a person, poor at running unattended inside a process. | Confidently. A wrong answer is formatted like a right one, which is why the check and the queue are the design. | At the edges of its assumptions, and you cannot see inside to find out why. |
| What it needs from you | A written procedure and somebody cross-trained. | Willingness to change how a screen is used, which is a larger ask than it sounds. | A labelled sample of your own inputs, an agreed threshold, and a named person on the exception queue. | Data in the shape the product expects, and acceptance that its logic is not yours. |
The second column deserves far more pressure than it gets. Most businesses already pay for AI features they have never switched on, in products they already run. Turning one on costs an afternoon and no new supplier. It stays unused because it is nobody’s project — no invoice, no launch, nothing to point at in a board pack — which is a poor reason to be paying twice.
The difference between the second and third columns is unattended running. An assistant helps a person who is present, and a human is in the loop because a human asked. A model call inside a process runs when nobody is watching, which is why it needs the structure the second column does not: a fixed output shape, a permitted unsure, an external check, and somewhere for failures to go. Buying the second and expecting the third is one of the more expensive misunderstandings in this market.
There is a column zero worth naming. If a process is fully repeatable and needs no judgement, a model is the wrong instrument regardless of volume — that is ordinary process automation, and it does not change its mind between versions. Whichever column is chosen, the calls run under your own commercial account rather than through XBA, so the data relationship stays between you and the provider.
How does an AI workflow get built?
Three phases in a fixed order. The first is the unglamorous one, it is regularly the one that gets skipped, and it is the only honest source of an accuracy number.
Collect a real sample by hand
- Actual inputs, from the actual inbox
- Including the messy ones
- Right answers decided by the business
- Disagreements written down, not settled quietly
It routinely settles arguments nobody knew they were having: two experienced people will label the same items differently, and that disagreement was in the process all along.
Constrain the output, then test it
- A fixed structure, never prose
- An explicit value for unsure
- Compared line by line against the labels
- External checks applied where they exist
A check the business already trusts is worth more than any confidence score the model reports about itself. The threshold for going live is set against what being wrong costs, by the business rather than by whoever built it.
Run it beside the person
- Both answers recorded and compared
- The person still in charge
- The narrowest slice unattended first
- Handover to a named owner
Disagreements are investigated rather than explained away, and the line between what runs unattended and what does not moves outward only as the disagreement rate stays boring.
- Cases clearing without a personon real volume, not the pilot
- Model and person disagreement rateduring the parallel run
- Cases the workflow declinednever zero
- Time from arrival to actionmeasured both ways
The fourth needs a baseline, and the baseline stops being available the moment the old process is switched off. The third is deliberately awkward: a workflow that never declines is not confident, it is unmeasured. How much accuracy is enough is a business decision taken per process — where a lower bar is acceptable, everything under it is flagged for a person rather than waved through. No figures appear on this page. The only accuracy worth anything is the one measured on your own inputs, and you will have it before you decide.
Not sure whether a task is judgement-light or judgement-heavy? That is exactly what the free audit is for.
Book a free process auditWhen is an AI workflow the wrong answer?
Often enough that it is worth checking before anything is scoped. Four situations account for most of them, and all four are recognisable early.
The input is already structured. If the data arrives in fields, no model is needed to read it. A rule is cheaper, faster, testable, and does not change its mind between versions. Reaching for a model on structured input is the most common way to spend real money on a problem ordinary automation had already solved.
The volume is small. A model workflow carries a build cost, a measurement cost and a running cost per item, and a task that happens a handful of times a month will not repay any of the three. Volume decides this, not difficulty — a hard task done rarely is still a person’s job.
Nobody can say what the right answer is. If two experienced people label the same sample differently, there is no target to measure against. That is the same unsettled-definition problem that stops reporting projects, described on data and reporting, and it is settled the same way: on paper, by the people who disagree, before anything is built.
The cost of being wrong lands on somebody outside the business. A customer, a patient, an applicant. Then the model may draft and a person must send. That is not caution for its own sake: the person who bears the error had no say in the design and no way to see it coming.
- No unmonitored agent writing to a live ledgerledgers
- No model deciding about a person — credit, employment, tenancy, or pricing that varies by customer without a stated ruledecisions about people
- No customer-facing chatbot without a visible, one-click route to a humanchatbots
- No published content generated by a model and not read by a person before it goes outpublished content
- No training or fine-tuning on client data without written instruction from the clienttraining
- No model handling health, biometric or similarly sensitive personal informationsensitive data
- No agent holding standing permission to spend money or send external email unattendedstanding permission
- No accuracy figure quoted that was not measured on your own dataaccuracy claims
These are refusals rather than preferences, and they are published so they can be held to. The first has been stated on the XBA homepage since the site was built. A list written down is considerably harder to abandon quietly under commercial pressure than one that is merely believed.
Questions about AI workflows.
Will it make things up?
Sometimes, and the design has to assume it will. A language model produces a fluent answer whether or not it had the information to produce a correct one, and the wrong answer arrives formatted exactly like a right one. What reduces it to a manageable rate is not a better prompt but a narrower job: one thing to extract rather than a paragraph to compose, a fixed output structure with an explicit value for unsure, a check against something external wherever one exists, and a person at the end of anything that does not come back clean. A workflow built that way still gets things wrong. The difference is that it says so.
Does our data get used to train the model?
No. Your data is not used to train a language model, and that is a condition of how these workflows are built rather than a hope about a provider. Production calls run under your own commercially acquired account unless you direct otherwise, so the data relationship is between you and the provider rather than between you and XBA. Development and sandbox work happens in a safeguarded test environment, with nothing released to external parties and nothing retained afterwards. The working preference is to build the structure and the flow first and route confidential content only through your own environment, so the least possible amount of it is ever surfaced outside the building. Harder residency or confidentiality constraints are settled in writing before anything is built.
What happens when it gets something wrong?
It goes where wrong answers were always going to go, which is why that place gets designed first rather than last. Every workflow has an exception queue: cases the model declined, cases an external check disagreed with, and cases the business decided always get human eyes. Three questions get settled before anything is built — which named person opens that queue, how often, and what they are empowered to do about what they find. If the answer to the last is to email whoever built it, the work has not been automated; it has been handed to somebody else on a delay.
Do we need to buy an AI platform?
Usually not, and it is worth finding out before anybody signs anything. Most businesses already pay for AI features inside products they run — Copilot in Microsoft 365, capture in the accounting package, summarising in the mail client — and a surprising number of tasks are one setting away from being handled by something already on the invoice. Where that genuinely cannot do the job, the next step is a model call inside a process you already own rather than a new platform with its own subscription, its own connectors and its own place for business logic to hide. A platform earns its cost where a named non-technical person will genuinely maintain the workflow afterwards, and that person should be named before the licence is bought.
How long does it take, and what does it cost to keep running?
The build is rarely the long part. Collecting a real sample and having somebody label it by hand takes longer than writing the workflow, and the parallel run afterwards is measured in weeks because it needs a full business cycle to disagree with you. The running cost is the part most often left out of a quote: a model call costs a small amount per item and that amount grows with volume, the workflow needs somewhere to run and credentials that expire, and somebody has to be told when it stops. The default is full handover, so you own the keys and the bill, with an optional support arrangement for monitoring and changes, or hosting as a service where you would rather not carry it. None of that is large. None of it is zero either, and a quote that does not mention it is quoting about two thirds of the job.