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.
2 articles · ~16 min, in reading order
The 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.
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 →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 →When does a task justify an autonomous AI agent?
When four things hold at once: the action is reversible or cheaply corrected, the blast radius of a bad run is bounded by real limits rather than good intentions, the exception rate is low and understood from evidence rather than assumed, and someone in the control environment owns the outcome by name. Add a fifth practical test — the remit has to be narrow enough to write down in a sentence. Most enterprise work fails at least one of these, usually the exception rate, and the honest response is to run it as augmentation until the evidence changes.
Full article →Why can a chat window not replace an enterprise application?
Because a conversation has no state that survives it. Enterprise work is resumable — someone picks up on Thursday what someone else left on Monday — and that needs things a chat window does not hold: a record with an owner and a status, versions of what changed and why, an audit trail that ties an action to a person and a time, and a queue everyone is looking at rather than a private transcript. The model can live inside the application and do the reading and drafting. What it cannot do is be the place the work lives.
Full article →Follow the build → — one practical finance-systems pattern, product decision or build lesson every two weeks.