The Anatomy of an AI-Native Enterprise Workflow

The textbook version of "adding AI" to a complex process is a copilot bolted onto one step: same intake, same handoffs, same approvals, one of them now faster. On programme after programme I have watched what that actually produces — a step that used to take twenty minutes now takes five, sitting inside a process that still takes eleven days, because the eleven days were never in that step. The hours live in the waiting, the chasing, the re-keying, and the exceptions nobody owns.

An AI-native workflow is a different exercise. You take the process apart into what its pieces really are, and you decide, deliberately, which pieces stay as rules, which go to a model, which belong to a named human, and what has to be held in an application so the work can be picked up again next week. That decision — which is which — is the design work. Everything else is tooling.

This is the method I use, and it fits on a whiteboard.

First, find where the hours actually go

Before anything is redesigned, map the process as it runs, not as the procedure document describes it. Two columns: the step, and the honest reason it takes as long as it does.

You will nearly always find that the elapsed time is not in the work. It is in someone waiting for a file, someone reading a mailbox to find out which of forty replies matters, someone copying figures into a spreadsheet that a third system will later import, and someone with a queue of exceptions they get to on Friday. Take a cash forecast cycle: the arithmetic is trivial and instant, but collecting and reconciling the inputs from entities on different systems is where the week goes.

That map also tells you where a redesign is worth doing at all. If the hours sit in a step you cannot change — a bank's cut-off, a regulator's window — no amount of AI moves it, and the honest answer is to redesign something else.

The part that must stay a rule

Now split the work. The first pile is everything that must be deterministic, and the rule for what goes in it is short: anything whose answer must be identical every time it is asked, and anything a control depends on.

In practice that is:

• Calculations. Totals, allocations, interest, valuations, tax. A number that can vary between two runs on the same inputs is not a number a controller can sign.
• Limits and thresholds. Credit lines, approval bands, exposure caps. These are policy expressed as code, and they are checked, not judged.
• Postings and writes to a system of record. What lands in the ledger is generated by code from validated data, on a defined path, with a reversal path.
• Entitlement and segregation of duties. Who may see, who may approve, who may release — and the rule that they are not the same person.
• Routing and status transitions. What moves where, and what state a record is allowed to be in next.

None of this is a candidate for a model, ever. It is cheap to write, easy to test, and — the part people miss — it is what makes the AI parts usable. A drafted journal entry is only safe to put in front of a human because the totals it is checked against are calculated deterministically. The rules are the firm ground the probabilistic parts get measured on.

The part AI is genuinely good at

The second pile is real, and it is bigger than sceptics think. Models are strong at the work that has always been done by an experienced person reading things:

• Reading unstructured input. The email with the amount in the third paragraph, the PDF confirmation, the free-text remittance line, the attachment someone sent instead of filling in the form.
• Classifying. This is a rate query, that is a dispute, this belongs to the entity in Poland.
• Synthesising. Twelve replies from six entities into one summary of what changed and what is still missing.
• Drafting. The chaser, the memo, the proposed mapping, the first version of the answer.
• Spotting the odd one out. Not "computing the variance" — that is a rule — but noticing that the explanation attached to a variance does not match the pattern of the last six months.

What these have in common is that a wrong answer is visible and recoverable. A misclassified email gets reclassified. A weak draft gets rewritten. That is the real test for putting a model on a task: when it is wrong, does someone notice cheaply, and is the cost of being wrong small? Where the answer is no, you either move the task back to rules, or you put a human decision immediately after it — which is the next pile.

"

The test for handing a task to a model is not whether it can do it. It is whether being wrong is visible and cheap.

Design the boundary properly while you are here. The model's output should have a defined shape the surrounding code can validate and reject — the same discipline as output contracts and failure handling in a product — and the workflow should have a defined behaviour for the day the model returns nothing useful.

The decisions that need a name on them

The third pile is decisions, and the question is not "can AI do this?" but "who is answerable when it is wrong?"

Some decisions have consequence that is hard to reverse, or that lands on someone outside the process: releasing a payment, accepting a counterparty, agreeing a write-off, approving a change to a control. Those get a named human, not a role, not a committee — one person whose name is on it. This is the same reason an owner is a person, not a team, and the same line I hold when I build: the machine executes; the judgement stays mine.

The redesign is not about removing that person. It is about making their decision cheap. If the model has read everything, assembled the evidence, drafted the recommendation and flagged what does not fit, the human's job shrinks from four hours of assembly to five minutes of judgement — and the judgement is better, because they are looking at a complete picture instead of the three tabs they had time to open. Which of the three modes a given piece of work deserves is the subject of the automation, augmentation and autonomy split.

The state the workflow has to hold

Here is where most AI redesigns quietly fail, and it has nothing to do with models.

Enterprise work is resumable. It is started by one person on Monday, continued by another on Thursday, questioned by an auditor in March, and it must survive all of that. That requires state a conversation does not have:

• A record with an owner and a status, visible to everyone in the queue rather than living in one person's transcript.
• Versions. What the figure was, what it is now, who changed it and why.
• An audit trail. Which action, by which identity, at which time, on which data.
• Reference data and entitlements, so the same question asked by two people gets two correctly scoped answers.
• Resumability. Someone opens it next week and sees exactly where it stopped and what it is waiting for.

This is the whole reason an AI-native workflow ends up as an application with a model inside it, rather than a chat window with a clever prompt. The model does the reading and the drafting; the application is where the work lives. Conflating the two usually shows up three months in, when the pilot cannot answer "what happened, and who approved it?"

The exception path is the workflow

Every enterprise process has a happy path that everyone designs and an exception path where the work actually is. Straight-through items were never the problem — they already flow. The cost sits in the items that do not match, do not balance, arrive late, or arrive in the wrong format.

So design the exception path first, and be specific about four things: how an exception is detected, who it is routed to, what information travels with it, and what the resolution writes back so the next one is handled better. This is where AI earns most of its value, because assembling the context around a broken item — the related documents, prior cases and correspondence, in one place — is exactly the reading and synthesising work models do well, and it is the part that currently eats a specialist's afternoon.

Run your own process through it

On a whiteboard, five columns. Take one real workflow and place every step:

If a step cannot be placed, it is not understood well enough yet, and that is a finding rather than a failure. If everything lands in "model", the design is wishful. If nothing does, you have written a requirements document for software you already have.

The last question decides whether any of it gets funded: what is true when this works, stated as something you can measure before and after. Days in the cycle, items touched by hand, exceptions still open at close. A redesign that cannot name its number is a demo with a business case bolted on afterwards, and it gets reorganised away a year after go-live. More of this method sits in the AI workflow design notes.

See also automation, augmentation and autonomy and how to define a measurable outcome.