Refactor the Workflow, Not the Worker

Most conversations about AI and work start with the wrong unit. The first version of the question is which jobs AI will replace. The better version, which economists have been asking for more than twenty years (Autor, Levy and Murnane, 2003, Quarterly Journal of Economics 118(4), 1279-1333), is which tasks. Both treat work as a pile of separable pieces, each of which a machine either can or cannot do. The interesting gains, and the interesting dangers, are not in the pieces. They are in the wiring between them: who needs what information from whom, at what point, and whose judgement has to be exercised independently of whose.

The argument of this essay is that the right unit of AI redesign is the dependency structure of a workflow, and that dependencies come in two kinds that need opposite treatment. Informational dependencies, where one step needs a fact that another person has, can be reordered, moved upstream, merged and deleted when they duplicate each other. Authority dependencies, where one step's approval must be independent of another's, cannot be merged, however much the data flow says they could. A redesign is justified when it preserves the workflow's observable obligations, and the most consequential decision in any redesign is the choice of what counts as observable, because that choice decides what the redesign is allowed to destroy.

AI matters here for an asymmetric reason. It makes informational redesign far cheaper than it was, because a system can now read what a person submits, notice what is missing, and ask for it in plain language at the moment they submit. It also turns authority collapse into a configuration change, because one agent can be granted the permissions of every approver in a chain. The first is the opportunity. The second is the hazard, and it is attractive for the same reason the first is: both remove a wait. My most contestable claim follows from that. In most approval workflows, the best place to put an AI is at the front, asking questions, not in the middle, approving things.

I build AI systems for law firms, so I have an interest in organisations redesigning work with AI. Read what follows with that in mind. I have tried to compensate by naming the prior work this rests on, and by stating predictions that could prove me wrong.

Why "which tasks" is still the wrong question

In From Roles to Morphisms I argued that a role is not a person but a bundle of typed transformations, and that AI acts on the whole category of professional work rather than on job titles. That essay decomposed roles. This one is about rewiring what the decomposition reveals.

Task-level thinking has a characteristic failure, and I described it in Systemic Coping Syndrome: an organisation that is better at accommodating its dysfunction than fixing it will use AI to perform its workarounds faster. Ask "which tasks can AI do?" in such an organisation and the answer will be the tasks people already resent, which are very often the workarounds. The step that should not exist gets automated, and so it lives for ever. Michael Hammer gave this warning its slogan in 1990: "Don't Automate, Obliterate" (Hammer, 1990, Harvard Business Review 68(4), 104-112).

The question that avoids this failure is not about any single task. It is about the edges between tasks. For every hand-over, ask what flows across it. If what flows is information, the hand-over can usually be moved, merged or removed. If what flows is authority, it usually cannot.

Ford, more than forty years ago

The best illustration is old, and it is in Hammer's article. In the early 1980s Ford's accounts payable department in North America employed more than 500 people. Management hoped to cut that by about 20% with better systems, until it looked at Mazda, whose accounts payable organisation consisted of five people. Ford's analysis of its own process found the shape that every slow approval workflow has. Purchasing sent a copy of each purchase order to accounts payable. Material control sent a copy of each receiving document. The vendor sent an invoice. Accounts payable matched the three, and in Hammer's words "the department spent most of its time on mismatches".

Hammer then states the method: "One way to improve things might have been to help the accounts payable clerk investigate more efficiently, but a better choice was to prevent the mismatches in the first place." Ford introduced what it called invoiceless processing. Purchasing entered each order into a shared database. The receiving clerk checked arriving goods against it and refused anything that did not match an outstanding order. Matching fell from 14 data items to three, the computer prepared the cheque, and vendors were asked to stop sending invoices. Where the new process was in place, Hammer reported a 75% reduction in head count, against the 20% Ford had first hoped for.

Now notice what Ford did and did not do. It did not merge purchasing and receiving. Payment still required an order placed by one department and goods accepted by another, and anyone auditing a payment could still see who ordered and who received. What disappeared was the invoice, a third copy of facts the organisation already held, and with it accounts payable's matching, which moved to the receiving dock and the computer. But Ford also changed the rule. In Hammer's words, Ford "had operated under the old rule that 'We pay when we receive the invoice'", and replaced it "with a new one: 'We pay when we receive the goods.'" That is not a refactoring. It is a change to the obligation, made in an effort Ford's top management launched, and imposed on its vendors, who were asked to stop sending invoices and, as Hammer puts it, "had to adjust"; at least one kept printing invoices and threw them away. Ford's redesign was an informational refactoring plus one deliberate, owned change to what counted as grounds for payment.

That combination is the whole method in one case. The rest of this essay tries to make it precise enough to apply with AI, where the temptation to do the opposite is much stronger.

Two kinds of dependency

Computer science has a clean answer to the question of when two steps can be reordered. Arthur Bernstein gave it in 1966 for programs: two segments can run in either order, or in parallel, with the same result, if neither reads what the other writes and they do not write to the same place (Bernstein, 1966, IEEE Transactions on Electronic Computers EC-15(5), 757-763). Compilers and parallel schedulers have relied on conditions of this kind ever since.

Apply Bernstein to a workflow and most of it turns out to be more movable than it looks. A question that finance asks on day four, about the cost centre or the attendee list, reads nothing that the budget holder wrote on day two. It reads facts the claimant had on day one. So it can move to day one.

But Bernstein's conditions miss something that every accountant knows. In a workflow, an approval is a write whose author matters. Two approvals may read and write entirely different data, so the data-flow analysis says they can be done in any order or in parallel. It is silent on who does them, and that silence is the gap. The principle of segregation of duties exists to stop one person controlling every stage of a transaction. One university finance office lays it out as five functions, initiating, authorising, recording, reconciling and holding the asset, and spreads each transaction across at least three people, so that the person who requests a purchase is never the one who approves it (University of California, Berkeley, Office of the CFO, "Segregation of Duties"). Its everyday form is the four-eyes rule, under which nobody approves their own claim and certain transactions need two independent approvers.

Those rules are not decoration. The Association of Certified Fraud Examiners' 2024 survey of 1,921 occupational fraud cases found expense reimbursement schemes in 13% of them, with a median loss of $50,000, and found that a lack of internal controls was the primary weakness in 32% of cases and an override of existing controls in another 19% (ACFE, 2024, Occupational Fraud 2024: A Report to the Nations). The cases are frauds investigated by its members, so they cannot by themselves show that controls prevent fraud. The report's own comparison comes closer: where management review was in place, the median loss was $100,000, against $250,000 where it was not. That is an association, not an experiment, and it points the same way. The same report found that frauds with three or more perpetrators caused median losses more than four times those of a single perpetrator. Segregation stops one person, not collusion, and an agent that holds every approval is collusion without the trouble of recruiting anyone.

So a workflow has two dependency graphs laid on top of each other, and they license different moves.

The parallel row is worth pausing on. Authority dependencies can often be run in parallel even though they cannot be merged. If the budget holder and finance do not read each other's decisions, they can decide at the same time. Parallelising two approvers keeps two pairs of eyes. Merging them does not.

The expense claim, before and after

Take an ordinary expense claim. A claimant, Alice, submits it. A budget holder, Bob, approves the spend. Someone in finance, Carol, checks it against policy and approves payment. An audit record is written and the money is paid.

In practice the claim rarely goes straight through. Bob sends it back because the business purpose is missing. Carol sends it back because the receipt does not show the VAT, or because the client attendees are not listed. Each send-back is an informational dependency discovered late: a fact that Alice had on the day she submitted, which nobody asked for until a reviewer needed it. The only survey I know of is sponsored and reports what travel buyers estimate, with no published sample size, so treat its numbers as indicative. A 2015 study by the GBTA Foundation, the research arm of the Global Business Travel Association, sponsored by the hotel-booking firm HRS, reported that 19% of expense reports contained errors or missing information, that each took 18 minutes to correct, and that the travel buyers it surveyed found the first steps (setting up the report, entering the data and attaching receipts) the most troublesome part of the process (GBTA Foundation, 2015, Expense Reporting: Global Practices and Pain Points). Each send-back puts the claim back at the end of somebody's queue, and my bet, which prediction 2 tests, is that the minutes of correction are the small part and the wait is the large one.

There are two obvious ways to redesign this with AI.

Redesign A moves the questions upstream. When Alice submits, a system that knows the expense policy and the reviewers' usual reasons for sending a claim back asks her for the business purpose, the attendees and a receipt that shows the VAT, before the claim goes anywhere. Bob and Carol still approve, separately, and if neither needs the other's decision they can approve at the same time.

Redesign B removes the wait directly. An agent is given the permissions of both the budget holder and finance, and approves claims that fit the policy. Nobody waits for anyone.

Both are faster. Only one of them is the same workflow.

The same split applies to the workflow a law-firm partner actually signs. In new-matter intake, the client's identity documents, its owners, the matter description and the names of the other parties are informational: the client or the fee earner has them on day one, and each is a familiar reason a matter stalls. Clearing conflicts, signing off client due diligence and accepting the matter are authority edges, held by the risk team, compliance and a partner, and they stay separate. An intake assistant that asks for the first set before the matter is opened is Redesign A. An agent that clears conflicts and accepts matters is Redesign B, and the partner whose name is on the acceptance carries its errors.

What "the same workflow" means

Software engineering has a word for changing the structure of something without changing what it does. Martin Fowler's definition of refactoring is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior" (Fowler, 1999, Refactoring: Improving the Design of Existing Code, Addison-Wesley; definition restated at martinfowler.com). Everything turns on the last two words. Behaviour is observable only relative to an observer, so a refactoring is only well defined once you have said what is being observed.

The theory behind that is Robin Milner's. In his calculus of communicating systems, two processes are observationally equivalent when an outside observer, who sees their visible actions but not their internal ones, cannot tell them apart (Milner, 1980, A Calculus of Communicating Systems, Springer LNCS 92). Internal steps can come and go without changing anything visible, as long as they do not quietly decide which visible step happens next. Milner's relation is stricter than what I check below. The Lean compares only the visible steps of a single run, which is enough to show what an observation lets through, and too weak to certify a process that branches, where an approver can reject or a claimant can withdraw.

For a workflow, that gives a precise version of the question every redesign should answer: which events are visible, to whom, and which must the redesign preserve? For an expense claim I would say at least these: that a claim was submitted and by whom, that each required approval was given and by whom, that an audit record was written, and that payment happened only after the approvals. The send-backs, queries and replies are internal. Nobody outside the process needs them to happen; they are the cost of having asked late.

Here is that example in Lean, a proof assistant whose kernel checks every step. The three blocks below are one file, and the file compiles on Lean 4.29.1 with no libraries.

inductive Actor | alice | bob | carol | agent
  deriving DecidableEq, Repr

inductive Role | budgetHolder | finance
  deriving DecidableEq, Repr

inductive Step
  | submit  (by_ : Actor)
  | query   (to : Actor)              -- a question sent back for missing information
  | reply   (by_ : Actor)             -- the answer to it
  | approve (r : Role) (by_ : Actor)  -- an approval: which role, and who gave it
  | log                               -- audit entry written
  | pay
  deriving DecidableEq, Repr

-- What the redesign must preserve, including who approved.
def visible : Step → Bool
  | .query _ => false
  | .reply _ => false
  | _        => true

def observe (w : List Step) : List Step := w.filter visible

-- A careless observation that records the role but forgets the actor.
def roleOnly : Step → Option String
  | .submit _    => some "submit"
  | .approve r _ => some (match r with | .budgetHolder => "approve:budget" | .finance => "approve:finance")
  | .log         => some "log"
  | .pay         => some "pay"
  | _            => none

def observeRoles (w : List Step) : List String := w.filterMap roleOnly

-- Today: Alice claims; Bob and Carol each send it back once.
def before : List Step :=
  [.submit .alice,
   .query .alice, .reply .alice, .approve .budgetHolder .bob,
   .query .alice, .reply .alice, .approve .finance .carol,
   .log, .pay]

-- Redesign A: the questions are asked at submission.
def redesignA : List Step :=
  [.submit .alice, .approve .budgetHolder .bob, .approve .finance .carol, .log, .pay]

-- Redesign B: one agent identity gives both approvals.
def redesignB : List Step :=
  [.submit .alice, .approve .budgetHolder .agent, .approve .finance .agent, .log, .pay]

-- Redesign C: an agent approves using Bob's and Carol's delegated credentials.
def redesignC : List Step :=
  [.submit .alice, .approve .budgetHolder .bob, .approve .finance .carol, .log, .pay]

def approvers (w : List Step) : List Actor :=
  w.filterMap fun | .approve _ a => some a | _ => none

-- Segregation of duties: approvers pairwise distinct, and none is the claimant.
def segregated (claimant : Actor) (w : List Step) : Bool :=
  decide ((approvers w).Nodup ∧ claimant ∉ approvers w)

theorem A_preserves       : observe before = observe redesignA := by decide
theorem A_segregated      : segregated .alice redesignA = true := by decide
theorem B_looks_the_same  : observeRoles before = observeRoles redesignB := by decide
theorem B_is_not_the_same : observe before ≠ observe redesignB := by decide
theorem B_breaks_sod      : segregated .alice redesignB = false := by decide
theorem C_passes          : observe before = observe redesignC ∧
                            segregated .alice redesignC = true := by decide

-- For every workflow: preserving `observe` preserves segregation of duties.
theorem approvers_observe (w : List Step) : approvers (observe w) = approvers w := by
  induction w with
  | nil => rfl
  | cons s t ih =>
    cases s <;> simp_all [observe, approvers, visible, List.filter, List.filterMap]

theorem sod_respects_observe (c : Actor) {w w' : List Step}
    (h : observe w = observe w') : segregated c w = segregated c w' := by
  unfold segregated
  rw [← approvers_observe w, ← approvers_observe w', h]

-- The role-only observation guarantees no such thing.
theorem sod_not_respects_roles :
    ¬ ∀ w w' : List Step, observeRoles w = observeRoles w' →
        segregated .alice w = segregated .alice w' := by
  intro h
  have := h before redesignB B_looks_the_same
  revert this; decide

The theorems in the second block are proved by decide, which means the kernel evaluated them on these particular lists. The third block is different: sod_respects_observe holds for every pair of workflows in the model, and sod_not_respects_roles shows that the role-only observation offers no such guarantee. sod_respects_observe is easy precisely because observe keeps every approval together with its actor, which is what makes the careful observation carry segregation. The model still leaves out everything that makes real workflows hard: timing, branching, exceptions, amounts, partial approvals. What it shows is four things.

First, Redesign A is a refactoring under the observation I chose. Four of its nine steps are gone and nothing visible has changed.

Second, Redesign B is also a refactoring, if you choose the careless observation that records which role approved but not who. Under observeRoles, the kernel cannot tell the original process from the agent version, because there is nothing to tell. Both show a budget approval, a finance approval, a log entry and a payment.

Third, under the observation that records the actor, Redesign B is a different workflow, and it fails segregation of duties. In general, any redesign that preserves observe preserves segregation, which is why the careful observation is worth writing down.

Fourth, the careful observation has a blind spot of its own, which the model shows by what it cannot show. Actor records whose credential was on the approval, not who decided. An agent given Bob's and Carol's delegated permissions produces Redesign C, which is character for character Redesign A, and it passes both checks. That is a common way to deploy an assistant: acting on a person's behalf, with that person's access. Microsoft's documentation for its Copilot, for instance, says it "only surfaces organizational data to which individual users have at least view permissions" (Microsoft Learn, "Data, Privacy, and Security for Microsoft Copilot"). To catch it, the observation must record the acting party as well as the credential. Identity standards already have the field. OAuth token exchange's "act" claim exists "to express that delegation has occurred and identify the acting party to whom authority has been delegated" (Jones et al., 2020, RFC 8693, section 4.1).

The lesson is not that Lean is needed to approve an expense claim. It is that "the redesign preserves the process" is not a property of the redesign. It is a property of the redesign and the observation, and whoever writes the observation decides what the redesign may destroy. A review that checks whether "the approvals are still there" has silently chosen observeRoles. That choice is invisible in a slide deck. It is one line in a specification.

I made the general version of this point in Floating Theories: a proof secures its conclusion relative to its statement, and says nothing about whether the statement describes the world. Here the statement is the observation function. A green check on the wrong observation is a floating theory with an audit trail.

The method

Put together, the method is short.

1. Map the workflow as it actually runs, not as it is documented. Every hand-over, every send-back, every wait. If the workflow is run through a system, its event log will show the real sequence. Process mining, the field Wil van der Aalst did most to build, exists to recover exactly this from logs. The documented process is a claim about the work, and often a floating one.
2. Label every edge as informational or authority. Ask of each hand-over: is something being known here, or something being decided by someone who must be independent? A few edges are both, and those need the most care.
3. Write down the observation. List the events the redesign must preserve, including who performs each authority step and on whose behalf. This is the specification of the redesign, and it is a short list.
4. Move predictable questions upstream. If a reviewer sends an item back for a fact the submitter already had, ask for it at submission. Hammer's version was "capture information once and at the source". When the submitter does not have the fact, the assistant forwards the item with the gap flagged and lets the approver decide. It never blocks submission.
5. Merge duplicated informational checks. If three reviewers each check the receipt, one check at intake is enough, provided it really is the same check.
6. Keep independent approvals independent, and parallelise them where you can. Two approvers who do not read each other's decisions can decide at the same time.
7. Treat any change to the observation as a policy decision, not a redesign. Auto-approving claims under a threshold may be exactly right. It is not a refactoring, because it removes a visible approval. Someone with the authority to change the control, usually the financial controller or whoever signs off the control framework, should decide it, knowingly, and the decision should be recorded. Ford's move from paying on the invoice to paying on receipt is the model: explicit, owned by management, and carried through with the suppliers on the other side of it.
8. Measure what changed. Human touches per item, send-backs per item, and elapsed time split into working time and waiting time, before and after. Track, too, how often each approver disagrees with the intake check, for the reason given under the objections below.

None of steps 1 to 6 requires AI. What AI changes is step 4. Moving questions upstream used to mean a longer form or a conditional questionnaire, and every extra field is a cost to the person filling it in, so organisations sensibly asked for less at the start and paid for it later in send-backs. A system that can read the receipt, notice that the VAT is missing, ask one question in plain language, and ask a different question of the next claimant makes the upstream move cheap for inputs that were never structured: the receipt image, the free-text purpose, the attendee list typed from memory. That is the opportunity, and it is large precisely because the send-back is where the waiting lives.

Why the front, not the middle

Return to the two redesigns. Both remove waiting. The difference is in what each needs in order to work.

An intake assistant needs the policy, the reviewers' common reasons for sending items back, and the claim. It needs no approval authority. It can go wrong in three ways: it can ask a wrong question, miss one, or describe a claim as complete when it is not. The first two cost time. The third is the dangerous one, because the assistant reads documents the claimant controls, and a receipt or a free-text purpose can carry text written to steer it. That is prompt injection, and as I argued in CaMeL and the Future of Prompt Injection Defense, detection does not reliably stop it; the defence has to be structural. So the design rule is that approvers see the claim itself, the receipt and the claimant's own words, and not only the assistant's account of them. With that rule, its errors are informational and recoverable. Without it, the assistant becomes the approvers' only view of the claim, and Redesign A turns into Redesign B by another route.

An approving agent needs the authority of every approver it replaces. It is, by construction, the capability union I described in Nobody Authorised the Combination: a set of permissions, each of which some reasonable person granted, combined in one identity that nobody would have authorised as a whole. Its errors are authority errors, and they are the kind that fraud examiners count.

There is a second, quieter reason to prefer the front. An approving agent that works well removes the pressure to fix the inputs. Claims arrive as badly as before, and the agent copes with them. That is systemic coping syndrome in its newest form: the dysfunction is still there, it has merely become cheap. An intake assistant does the opposite. It changes what arrives, and once it is in place the send-back rate is visible, and can be pushed down.

This does not make every AI approver wrong. An organisation can decide that claims under some amount need only one human approver, or none, and that an agent's policy check is a sufficient control below that amount, with sampling afterwards. Auditors call this kind of arrangement a compensating control, and it is a legitimate choice. My claim is narrower: it is a change to the obligation, not a refactoring of the workflow, and it should be made by whoever owns the control, deliberately, rather than arriving as a side effect of a speed project. Who that owner is, and who gets to write the observation in the first place, is a harder question than it looks, and one I do not answer here.

What exists and what does not

• What exists: the Ford case as Hammer reported it; the GBTA and ACFE figures, each from its own survey, with the limits noted; the Lean file above, which compiles. Six of its nine theorems are about four specific lists; three (approvers_observe, sod_respects_observe and sod_not_respects_roles) are general within the model, which has no timing, branching or amounts.
• What does not exist: any measurement of my central claim. I have not compared intake-side and approver-side AI deployments, and I do not know of a study that has. The asymmetry argument is an argument.
• What is a proposal: the method, the two-graph classification, and the rule that changing the observation is a policy decision.

What is new here, and what is not

Almost none of the parts. Hammer's 1990 article contains the Ford case and "capture information once and at the source". Mike Rother and John Shook codified value stream mapping, which grew out of Toyota's material and information flow diagrams, in Learning to See (Lean Enterprise Institute, 1998); it made waiting time visible on a single page, and Niklas Modig and Pär Åhlström's This Is Lean (2012) separated flow efficiency from resource efficiency. Van der Aalst defined soundness for workflow nets in 1997 (van der Aalst, 1997, "Verification of Workflow Nets", LNCS 1248, 407-426). Barbara Weber, Manfred Reichert, Jan Mendling and Hajo Reijers catalogued behaviour-preserving refactorings for process models (Weber et al., 2011, Computers in Industry 62(5), 467-486). Elisa Bertino, Elena Ferrari and Vijay Atluri formalised separation-of-duty constraints in workflow systems (Bertino, Ferrari and Atluri, 1999, ACM Transactions on Information and System Security 2(1), 65-104), and Jason Crampton's work on constrained task execution helped found what is now called the workflow satisfiability problem: whether any assignment of people to steps can satisfy all the constraints at once (Crampton, 2005, SACMAT, 38-47).

What I think this essay adds is narrower.

1. The default for authority edges. Hammer drew the line himself. He asked of a manager's signature, "Is it a control mechanism or a decision point?", and "What if the manager reviews only requisitions above $500?" His answer leaned towards removal: "Put the decision point where the work is performed, and build control into the process", and organise around outcomes, "to have one person perform all the steps in a process". In an approval chain that is the collapse segregation of duties forbids. My addition is the opposite default: informational edges may be moved, merged or deleted freely, and authority edges may be parallelised but never merged without an owned decision to change the obligation. AI makes that default urgent, because Hammer's "build control into the process" is now an agent.
2. The asymmetry. AI lowers the cost of both moves at once, the good one (asking at the source) and the dangerous one (one identity holding every approval). The second is not new in kind. Robotic process automation let one bot account hold elevated, shared access, and an ISACA industry-news article lists "unnecessarily providing elevated levels of access" among the most common pitfalls of bot implementation (Gupta, 2022, "The Risky Business of Bots", ISACA). What is new is that an agent's permissions are granted for its usefulness across many tasks, not scripted for one, so the collapse arrives as a side effect rather than a design.
3. The observation is the specification. The process-model literature defines behaviour preservation formally. The point I want practitioners to take from it is operational: the choice of observation is where a redesign's risk lives, a careless observation makes the dangerous redesign provably "equivalent", and even a careful one must record the acting party, not only the credential.

The strongest objections

"Moving questions upstream just moves the work onto the person submitting." This is the strongest objection, and it is partly right. Cass Sunstein's term for excessive or unjustified frictions, such as paperwork, that stand between people and what they are trying to do is sludge (Sunstein, 2022, "Sludge Audits", Behavioural Public Policy 6(4), 654-673), and a badly designed intake step is sludge with a friendly face. Where I come down: the upstream move is justified only for facts the submitter already has, and only when it is asked as a question rather than added as a field. It can be measured. If submitter time rises by more than reviewer time and waiting time fall, the redesign has shifted cost rather than removed it, and it fails my own test.

"Redesign A is Redesign B with extra steps. Once the AI has checked the claim, the approvers stop looking." This is the objection I take most seriously, because it is my own argument turned on my own preference. Automation bias is well documented: people given pre-checked work check less (Parasuraman and Manzey, 2010, Human Factors 52(3), 381-410). Under observe, two distinct people still approve, and the log is satisfied while the independence it records has gone. Where I come down: the objection is right about the observation and wrong about the remedy. The fix is to observe review, not just approval: sample approved claims, track how often each approver disagrees with the intake check, and treat an approver who never disagrees as a finding. The same logic guards the metric in step 8. Send-backs per item can be driven to zero by approvers who stop sending things back, so a falling send-back rate counts only alongside a disagreement rate that has not collapsed. If organisations that deploy intake assistants show approver disagreement falling to zero, the front is less safe than I claim.

"Hammer said all of this in 1990, and re-engineering failed." The famous figure that 50 to 70% of re-engineering efforts failed came from Hammer and James Champy's 1993 book Reengineering the Corporation, where they called it "our unscientific estimate", and in The Reengineering Revolution Hammer and Steven Stanton later wrote that "this simple descriptive observation has been widely misrepresented" and that "there is no inherent success or failure rate for reengineering" (both as quoted in "Debunked: The Myth That 70 Percent of Change Initiatives Fail", Entrepreneur). So the failure rate is folklore. What is not folklore is that wiring changes jobs, and I should be honest about it: where Ford's new process was in place, its head count fell by three quarters. The method here redesigns the wiring rather than the worker, and what Ford's redesign did not lose was the separation between the people who ordered and the people who received. It also differs from Hammer's method on the one point that mattered for control, the default for authority edges.

"Segregation of duties is overhead that a well-logged AI approver makes unnecessary." Logs detect; segregation prevents. A complete log of an agent approving its own operator's claims records the problem without stopping it. Small organisations often cannot staff full segregation, and the standard answer is a compensating control such as supervisory review. That is a legitimate choice, and it is a choice about the obligation, which is my point.

"Real workflows are not the documented ones; people's workarounds are the real process." Agreed, which is why step 1 maps the process as it runs. Resilience engineers make the stronger version of this point, that everyday adaptations are often what keeps a system working (Hollnagel, 2014, Safety-I and Safety-II, Ashgate). Some send-backs encode judgement that no intake question can capture. Those stay, and the measure of a redesign is how many of the rest it removes.

"A formal model of an expense form is overkill." For one expense form, probably. The observation list can be a table in a document. Formality starts to pay when redesigns are proposed and implemented by agents at volume, because then the check that a redesign preserves the observation has to run without a person reading every change, and a table cannot run.

"You sell this." I do, which is why the claims below are stated so that they can fail.

Predictions

Each needs a measure and a horizon to be testable.

1. Intake beats approval. Define the arms by permissions. An approver-side deployment gives the agent's identity an approval permission, so that some approvals complete with no human approval event. An intake-side deployment gives the agent no approval permission at all. A deployment that both asks at intake and approves counts as approver-side. Compare each workflow with itself, from its event log, for six months before and six months after deployment, and compare the change between the two groups. Intake-side deployments will show the larger fall in median elapsed time and in send-backs per item, without a rise in control exceptions. The mechanism: an approving agent cannot supply a fact the claimant did not give, so it still has to send claims back, while an intake assistant removes the send-back before it happens. (Redesign B in my model omits those send-backs, which is generous to it.) If approver-side deployments achieve the larger fall in elapsed time or in send-backs, this prediction is wrong. If they do so with no rise in control exceptions, measured as in prediction 3, the case for the front is wrong as well. If intake-side deployments show a rise in control exceptions against their own six months before, measured the same way, the prediction is wrong on its safety half, and so is my claim that the front is the safer place for an AI. (The comparison assumes the two groups were on similar trends before deployment; the six months before are there to check it.)
2. Most of the saving is waiting, not working. Decompose the reduction in elapsed time from a redesign that moves questions upstream, using an event log that records when each step starts as well as when it ends, into touch time saved and waiting time removed, over the first twelve months after deployment. At least two-thirds of the reduction will be waiting time that disappeared with the send-back loops, not faster execution of the remaining steps.
3. Merged authority shows up in control testing. Redesigns that give one agent identity the permissions of two or more independent approvers will, within 24 months, show a higher rate of control exceptions per 1,000 items, in control testing of equal coverage, than redesigns that keep a separate identity per approver. Equal coverage matters, because a workflow run by an approving agent will attract more audit attention, and raw counts of findings would measure that attention as much as the risk. If the rates are the same or lower, the risk I am describing is smaller than I think.

What to do on Monday

1. Pull one workflow's event log and count send-backs per item. That number is the size of the informational opportunity.
2. Classify the send-back reasons. Those that ask for a fact the submitter had are candidates for an intake question. Those that need judgement stay.
3. Write the observation down before anyone proposes a redesign: which events, which actors, in what order. Make the list short enough to fit on a page.
4. Put the AI at the front first. Let it ask, not approve. Measure the send-back rate for a quarter.
5. Give every agent its own identity, with the permissions of one role at most, and never the permissions of two approvers in the same chain. Make the log record the agent, not only the person it acts for.
6. Route any change to the observation to the owner of the control. Thresholds, auto-approvals and compensating controls are decisions, not optimisations.

Steps 1 to 3 require no purchase, no proof assistant and no change to who approves what: they need a spreadsheet and an afternoon. Step 4 needs an intake assistant, bought or built, and still changes nobody's right to approve.

Not the worker

The phrase "AI will replace workers" invites the image of a person removed from a chair and a machine sat in it. The more useful picture is Ford's. The clerks were not slow, and nothing about the people needed fixing. They spent most of their time reconciling copies of facts that should only ever have been written down once. The redesign moved a check to the point where the fact was created, removed a document, cut head count by three quarters where it was in place, and left the people who ordered and the people who received where they were, their records still matched against each other before anyone was paid. "Not the worker" is a claim about what gets redesigned, not a promise about head count.

AI makes that kind of redesign cheaper than it has ever been. It also makes the opposite redesign cheaper than it has ever been: one tireless identity holding every approval, under an observation careless enough to call it the same process. The difference between the two is not in the technology. It is in one line of the specification, the one that says whose decision has to be seen.

About the author: Eduardo Aguilar Pelaez is CTO and co-founder at Legal Engine Ltd. He writes on formal methods, AI agents, and the discipline of building systems that survive being walked away from.