Part one designed the loop. Part two laid down what the loop stands on — the map and the rails. What remains is the part that stops most companies before they start: actually building it. The good news is that the build is smaller than the ambition suggests. You do not need an enterprise program, a two-year roadmap, or a transformation office. You need one workflow, the people who already run it, and a few disciplined weeks.
Pick the Workhorse, Not the Flagship
Choose a workflow with real volume, real error cost, and an owner who wants it fixed.
Invoice exceptions.
Access requests.
Claims triage.
Customer refunds.
The candidates share a profile: they run every day, they hurt when they go wrong, the rules mostly exist, and every system they touch is reachable. Do not pick the flagship transformation — the one with nine stakeholders and a steering committee. Pick the workhorse. The point of the first workflow is not glory; it is to teach your organization the method on work that matters enough to be honest about.
Describe the Work Before You Automate It
Then comes the step most programs skip, and it is the step everything else depends on: describe the work as it actually runs, with the people who run it. Not the process chart — the chart shows how the work was designed years ago.
Ask about the exceptions: the invoice missing its purchase order, the vendor that is blocked but critical, the request that looks routine until one document changes everything. Every company’s real operations are made largely of exceptions, and the knowledge of how to handle each one lives in the heads of the people who have seen it before. The map from part two is where that knowledge finally gets written down: the normal path, the exceptions and how each is resolved, the rules in force, who decides what, and what happens when an action goes wrong.
Use AI generously here. Models are good at drafting a description of work from observations, interviews, tickets, and the traces the work leaves in systems. People then do what only they can: validate it, argue with it, and correct it. The draft is cheap now. The truth still comes from your people.
Divide the Work Among the Three Actors
With the work described, divide it honestly. The repetition — the lookups, the matching, the postings that run the same way every time — goes onto rails, exactly as part two argued. The judgment — reading the messy case, weighing the exception, assembling the evidence — goes to the agent. And the consequence — approving the payment, denying the claim, making the commitment stays with a person, at the gate part one designed.
The division has a plain form, and it is the operating model of the whole series: AI proposes, humans decide, automation executes. The agent prepares the case and recommends the path. A named person decides where the decision carries weight. The rails carry out what was decided, exactly, with the audit trail writing itself.
Launch It Supervised, and Keep Everything
Do not launch autonomously. For the first weeks, a person who knows the work invokes the agent and watches it: redirects it, corrects it, accepts its results. This feels slow. It is actually the fastest thing you will do, because of what it produces — evidence.
Part one made the distinction: approvals are not data; verifications are. The supervised period is where verifications come from. Every correction — this proposal was wrong, here is why, here is the right answer — is a piece of your institution’s judgment, captured with its reason. Keep all of it, attached to the case it came from. Those corrections are the curriculum: they tell you which rules were unclear, which exceptions the map missed, and — decision by decision — which parts of the work the agent handles as well as your people do.
Promote on Evidence, Demote on Evidence
When the record shows a kind of decision handled consistently, correction-free, over enough cases to mean something, promote it: let a business event trigger the work, with the person’s role narrowing to the gate. When the record says otherwise, do not promote — and when performance falls after promotion, demotion is automatic, not a meeting. This is part two’s rule doing its job in production: a better model earns nothing by itself. Do not promote the model. Promote the workflow.
The fear that stops teams here is predictable, and it deserves a straight answer: if every consequential case needs a human decision, won’t the people at the gate drown? Ten thousand exceptions a day and a reviewer clicking through them — that is not governance, that is a queue.
But ask how those ten thousand exceptions are handled today: by people, end to end. Someone gathers the evidence, chases context across five systems, makes the call, and keys in the result — every case, every time. The gate does not add a human to that pipeline. It removes the human from everything except the decision. A reviewer who receives a prepared case — evidence assembled, rules checked, consequence stated — spends minutes of judgment where the whole case used to take an hour of work.
And the design spends that judgment deliberately, because not every case deserves the same depth of review. Route the routine, high-confidence stream through a lighter look and the uncertain or novel cases through a full one. Force a full review, regardless of confidence, for the moves that are irreversible or above a threshold. And measure the gate itself — review time, edit rates, escalations — so you can tell verification from rubber-stamping while it is happening, not after. Reviewer attention is the scarcest resource in the system. The whole architecture exists to spend it where consequence lives, and nowhere else.
Keep the Map True
The build is not done at go-live, because the business does not stand still. Policies change. Systems get upgraded. New suppliers, products, and regulations arrive every quarter, and every one of them quietly bends the work away from its description. So give the map an owner. Someone — at one workflow it is usually a person who already knows the work, not a new hire — is accountable for keeping the description true as the business changes: the mapmaker of the operation, the role I call the cartographer. A project builds the first map. The cartographer keeps it true. Cartography is never finished.
Then It Compounds
The second workflow is cheaper than the first. It reuses the entities, the rails, the gate design, the review habits, and a team that has done it once. The third is cheaper still. And notice what you are accumulating besides software: a written map of how your business actually works, and a growing record of decisions and their reasons — your institution’s judgment, in a form that survives every model upgrade and every vendor change. Models will keep improving, and you will keep renting them. The map and the record are yours. That is the asset no competitor can buy, and no platform shift takes away.
Three essays, one architecture: the loop, the map and the rails, and the first workflow. Reading them back, something else is visible in them — they keep issuing rules. Do this. Do not do that. What those rules add up to is the subject of a short addendum.
