Topic
AI Workflow Design: Redesigning Complex Work
The method that separates a redesigned workflow from an automated one. Every complex process is a mix of things that must stay deterministic (rules, calculations, controls), things AI is genuinely good at (reading, synthesising, classifying, drafting), and decisions that belong to a named human — and the design work is deciding which is which, on purpose.
These notes take real processes apart and put them back together: where the hours actually go, what needs to remain a rule, what state and data an application has to hold that a chat window never will, and what the redesigned version is worth. Examples come from finance, treasury and enterprise delivery because that is where I have done the work.
6 articles · ~60 min, in 2 sections — each in reading order
Method
4 articles · ~38 minThe Anatomy of an AI-Native Enterprise Workflow
Take a complex process apart: what must stay deterministic, what AI genuinely does well, what a named human decides, and the state the work has to hold.
AI Automation vs Augmentation vs Autonomy
Three genuinely different designs, not three rungs of a ladder. The criteria that decide which one a piece of enterprise work actually deserves.
Human Decision Rights in AI-Native Workflows
The useful question is not what AI can automate. It is who is allowed to decide what — a rights matrix over every action a workflow contains.
Designing the Exception Path
Demos are built on the clean case; enterprise work lives in the other one. Detection, queue, escalation, resolution and the write-back almost everyone omits.
Teardown
2 articles · ~22 minAI Workflow Teardown: Cash Forecasting
A corporate cash forecast, taken apart: where the elapsed time really sits, what stays deterministic, what AI genuinely does, and what a named human decides.
AI Workflow Teardown: Bank Reconciliation
Bank reconciliation taken apart: why the matching engine was never the bottleneck, what AI does with the residue, and which breaks need a named human.
Free tools for this topic
Frequently asked questions
What makes a workflow AI-native rather than AI-assisted?
An AI-assisted workflow keeps its original shape and adds a model to one step — the same handoffs, the same approvals, one of them now faster. An AI-native workflow is redesigned around what each part of the work actually is: the calculations and controls stay deterministic code, the reading and drafting and classifying go to a model, the decisions that carry consequence go to a named human, and the whole thing runs inside an application that holds state, versions and an audit trail. The test is simple. If you removed the model, would the process be the old process again? If yes, it was assisted, not redesigned.
Full article →What is the difference between AI augmentation and AI autonomy?
Augmentation means the machine prepares the work and a person decides: it reads the inputs, assembles the evidence, drafts a recommendation, and a named human accepts, changes or rejects it. Autonomy means the machine decides and acts inside a bounded remit — defined limits, defined data, defined actions — and the human moves from deciding each case to setting the boundary and reviewing what came out of it. The distinction is not how capable the model is. It is where the decision sits, and who is answerable for it when the decision turns out to be wrong.
Full article →What are decision rights in an AI-native workflow?
Decision rights are the explicit statement of which actor may take which action, and under what condition. They attach to verbs, not to processes: read, extract, classify, recommend, approve, execute, override a control, change policy. For each verb you state what the AI may do, what a named human must do, and the condition that decides — a value threshold, how reversible the action is, whether the consequence lands outside the company, and who is answerable when it turns out wrong. Written down, most of the argument disappears, because the disagreements were about bundles of verbs rather than the verbs themselves.
Full article →What is the exception path in an AI workflow?
The exception path is everything that happens to an item that does not go straight through: how it is detected, where it queues, who owns it, how it ages and escalates, what the person resolving it sees, how the resolution is recorded, and what gets changed so the same thing happens less often. Straight-through items were never expensive — they already flow. The exception path is where the elapsed time, the specialist effort and the risk actually sit, which is why designing it first tends to produce a better workflow than designing the clean case first and bolting on a queue.
Full article →Which parts of an enterprise process should stay deterministic?
Anything whose answer must be identical every time it is asked, and anything a control depends on. That means calculations and totals, limit and threshold checks, entitlement and segregation-of-duties rules, postings to a system of record, and the routing logic that decides who sees what. These are cheap to express as code, easy to test, and easy to audit — and a probabilistic component adds nothing to them except a new failure mode. Keeping them deterministic is also what makes the AI parts safe to use, because the model's output has something firm to be checked against before it moves.
Full article →Work with me → — an opportunity scan, a redesign sprint, or an architecture review before AI meets your real landscape.