Somewhere in your organization, a request that falls outside standard terms is passing through four pairs of hands before anyone decides anything. The first packages it. The second routes it. The third checks the packaging is complete. The fourth belongs to the person who actually decides.
Three of the four add no decision. They add coordination... and until recently, coordination was expensive enough to be worth organizing around. It costs a great deal less now.
The decision is. Start there.
This is Part 6, the one the other five pointed at. They established what changed and why the obvious response fails. This is the prescription: take the decision, not the task, as the unit of redesign, and the redesign takes a determinate shape.
What Parts 1 through 5 established
The org chart is a priced response to expensive information; four of those prices fell while four others rose. Cheap generation moved the binding constraint from producing work to accepting it; the approval queue is where that shows. The evidence about where work breaks lives with the people doing it, while the architecture decision belongs to whoever is accountable for the outcome. Coordination work compresses and consequence does not; a layer removed for its automated coordination takes accountability with it that was never automated. And an approval is not a control: volume degrades the gate, and the replacement is layered controls with a named, equipped owner.
The arc closes where Part 1 said it would: the structure gets re-derived from the decisions it exists to make, at today's prices.
The unit of redesign is the decision
A task is a unit of production. A decision is a commitment with an owner and consequences.
Almost everything we have measured about AI at work is measured at the level of the task. Almost everything your organization is made of lives at the level of the decision, and the gap is where the bad strategy of this moment hides. Task-level thinking produces tool adoption and a queue. Decision-level thinking produces a structure.
The diagnosis is not new, and it gets its credit and its caution together. In 1990, Michael Hammer's Harvard Business Review article carried the instruction in its title: "Don't Automate, Obliterate." Layering technology onto an unredesigned process preserves its waste, and he was right about that. The movement that followed had a poor implementation record and degenerated into a euphemism for layoffs. This essay takes the diagnosis and refuses the cure.
My claim, labeled as a synthesis rather than a finding: the decision, not the task, is the correct unit of redesign. Task-level automation leaves the handoff structure intact, and the handoffs are where both the coordination cost and the accountability live. A decision already has the four things a redesign needs (an owner, an input set, an escalation path, and a record), so working at that level forces coordination and accountability to be answered together.
One thing this claim is not: an argument that task-level automation is worthless. Those gains are real, this series opened with them, and nothing here takes them back.
The Decision Architecture
Here is the shape. Six elements, each with a named owner and a test, applied to one decision at a time. Not a program.
Three things it is not, because the corpus already contains them. It is not the agent loop: the deterministic shell governs what a machine does, this governs what an organization commits to. Its output is an action, where the decision loop's is a commitment someone answers for, and it terminates when the task completes, where the decision loop persists because the ledger feeds learning and learning re-prices autonomy. Nor is it process decomposition: the FIXR pattern corroborates the Verify stage and the evidence gate but supplies none of the organization around them. And it is not an enterprise-architecture playbook: an earlier post of mine maps the systems, where this maps the commitments.
The decision. Name the decision and the single person accountable for it. If you cannot name the owner, that is the finding, usually the one Part 3's breakage exercise produced. The named owner is not a compliance decoration: NIST's AI Risk Management Framework and ISO/IEC 42001 both make named accountability structural, and Article 14 of the EU AI Act enumerates five oversight capacities for high-risk systems as the Act defines them. Part 5 carries the enumeration, its scope caveats, and the citations. Owner: the accountable person, named. Test: can you name the single person accountable?
The loop. Element two replaces the handoffs: Sense, Interpret, Decide, Act, Verify, cycling continuously and living at the work rather than above it. The placement comes from Cherns' principle that variance should be controlled where it arises.
The verbs are deliberately unoriginal. Organizations have run sense-decide-act cycles as long as they have existed; Boyd's OODA and Deming's PDCA are the famous versions. The claim is the coupling, not the cycle: most of what gets called a loop has no named owner, no written escalation condition, no ledger, no learning cadence, and no evidence gate before autonomy.
- Sense — assemble the evidence the decision requires, continuously, from where the work happens; this is where the removed handoffs go. Test: does the evidence arrive before it is asked for?
- Interpret — reconcile the evidence against context only the work holds: variance or exception, signal or noise. Test: is it done with the context to tell exception from noise?
- Decide — the owner commits, the loop's one mandatory human act on the normal path. Test: is the commitment made by the named owner, with the evidence in front of them?
- Act — execute the mechanical residue: the document, the record, the system update, the notification. Agentic tooling belongs here first, inside the shell. Test: does execution follow the decision without a fresh round of packaging?
- Verify — confirm the action produced the intended outcome and that the decision's basis still holds, and write the check to the ledger. Verification design is per-task, matching its position on the jagged frontier. Test: what would tell you this decision was wrong, and when?
The decision owner owns the loop, and the people closest to the work operate Sense and Interpret. Which is the limit on the word owner: a single accountable owner is not unilateral control. Part 3's rights carry forward intact. The people whose work the decision changes hold concurrence over monitoring, over individual-performance use of telemetry, and over material job-content changes, and standing to stop an experiment. Where law, collective bargaining, works councils, professional standards, or existing policy grant stronger rights, those govern. Sense is evidence about the work, not telemetry pointed at people, and an owner nobody can argue with is the failure mode, not the design.
Escalation. Element three is cross-cutting: the stated condition under which the decision leaves its normal path, written down in advance, naming who receives it. A sensing anomaly, an interpretation conflict, an execution failure, a verification surprise all route by the same condition to the same named place, and one nobody wrote down is not a control. Owner: the decision owner writes it; the recipient is named in it. Test: is it written down, and does everyone in the loop know it before they need it?
The Decision Ledger. Element four is the durable record: what was decided, by whom, on what evidence, under what escalation condition, and what happened. Keep Part 5's distinction exact: the control plane's audit record evidences accountability, while the Decision Ledger makes the decision learnable. The control plane is the infrastructure underneath. Owner: the decision owner is accountable for its completeness. Test: could someone who was not there reconstruct why?
Learn. Element five is a named reader, a stated cadence, and the authority to change the loop or the escalation condition because of what the ledger shows. Without it the ledger is storage. This is Cherns' other principle arriving at the operating model: design is continuing, never finished. Owner: a named person with standing to change the design. Test: what changed last quarter because someone read the record?
Autonomy. Element six adopts the published L0–L5 ladder rather than inventing a rival. The new rule: movement up it is earned per decision, from ledger evidence at the current rung, not granted per system, vendor claim, or quarter. And design for modifiability rather than approval: people exercise oversight more when they can adjust output than when they can only accept or reject it. The finding is established (Dietvorst, Simmons and Massey, 2018); the design implication is mine. Owner: the decision owner proposes, and the evidence decides. Test: can the human adjust the output, or only accept and reject it?
The decision operating loop
Six stages, in order, with a gate before the last one: the sequencing is the prescription.
Six stages applied to a single decision, with a sequencing gate that must be cleared before autonomy is extended. Decision, Loop, Escalation, Ledger, Learn, then a barrier, then Autonomy; a return path runs from Learn back to Loop. Each stage carries a one-line test: name the owner; evidence arrives before it is asked for; the escalation condition is written down; someone could reconstruct why; something changed last quarter; the human can adjust the output, not only accept or reject it.
Decision
the commitment being made
Test: can you name the single person accountable?
Loop
evidence assembled continuously rather than on request
Test: does the evidence arrive before it is asked for?
former handoffs
Escalation
the stated condition under which the decision leaves its normal path
Test: is it written down?
Ledger
the decision and its basis, recorded
Test: could someone reconstruct why?
Learn
someone reads the ledger on a cadence and changes the loop or the escalation condition
Test: what changed last quarter because of it?
verification capability before generation scale · ownership before autonomy
Autonomy
extended only where the previous five hold; designed for modifiability rather than approval
Test: can the human adjust the output, or only accept and reject it?
Return path: Learn feeds back into Loop, which makes the cycle explicit without drawing a circle.
The gate the figure draws between Learn and Autonomy is the sequencing rule as a barrier. I made the artifact-layer version of that claim in the AGENTS.md post: "Context without verification is Potemkin agent-readiness." Same claim, one layer up, and this time it has an owner.
One warning, aimed at my own published advice. One of its five translations is "Status meetings → observability streams." It is correct, and it removes coordination work, which is this series' prescription. It also removes the room where a specific person, out loud, in front of peers, said yes, I own that. Coordination and accountability were bundled there; automating the meeting unbundles them, and the ledger is where the noticing has to go.
The questions and the instruments
Seven questions locate the constraint. Which decision is this, and who is the single person accountable? No answer to the second is itself the finding. How many times does the evidence change hands before the owner decides, and what does each hand add: packaging, routing, completeness, or judgment? Only the judgment is load-bearing. Does evidence arrive before it is asked for, and does interpretation happen where the variance arises? What condition sends the decision off its normal path, and who receives it? Could someone who was not there reconstruct why? Who reads the record, and what changed last quarter because of it? What would have to be true before any part of it runs without a person?
Eight instruments tell you whether the architecture is holding. Handoff count per decision (down). Evidence latency, from evidence existing to evidence in front of the owner (down). Decision cycle time (down, without rework rising; if it falls while rework rises, the queue moved rather than shrank). Escalation coverage, the share of recurring decisions with a written condition (up). Escalation precision, both error types down: of escalations fired, how many were worth firing, and of non-escalations sampled, how many should have. Ledger reconstructability, the share of sampled decisions a third party can reconstruct from the record alone (up). Learning yield, changes traceable to a ledger review (above zero). Rework rate (down).
Each is a measurement instruction, not a result: no targets, no benchmarks, no claimed magnitudes. One rule binds the set: none converts into headcount, capacity, or savings, and using one that way turns it into the arithmetic this series rejects.
Sequencing is the strategy
The order is the strategy, and I put my name on it as a recommendation rather than a finding: verification capability before generation scale, ownership before autonomy. It is a gate, not a maturity model. A maturity model is a ladder of worth; this is a sequence of prerequisites.
Then the part an executive under margin pressure will not want to hear: capacity recovered from automating coordination should be reinvested in verification capability and explicit ownership. Not booked as savings.
The honest reply is the evidence, and Part 4 lays it out at length. Twenty-five years of complements research found that returns to information technology depend on the organizational redesign, with reorganization as the mechanism rather than a side effect, and the J-curve explains the timing: measured returns lag the intangible investment, so you cannot skip the reorganization and book the gain. In the sharpest large-sample evidence available, Humlum and Vestergaard's Danish working paper, the observed early result is a null on earnings and hours, with time savings reallocated into task reorganization rather than staffing reduction. The reallocation is correlational and the window is early, so the study does not establish what employers could have done instead. Their phrase is the setup for the prescription: the null results are "not evidence of inaction but of a specific mode of adjustment."
Which mode is the design question. Booking the gain is betting against that evidence; reinvesting it is how the return gets earned.
The prior art, taken seriously
The oldest objection is the one with teeth. We have seen this film: Hammer said don't automate, obliterate in 1990, the industry spent a decade redrawing process maps, and the movement ended as a euphemism for layoffs. You have renamed the process a decision and the redesign a loop. Why is the ending different? The history is not in dispute; it is my own evidence. Three differences. The unit: reengineering redesigned end-to-end processes, an enterprise program with budget and consultants attached, where this redesigns decisions one at a time, so the first unit can be deliberately small. A program you must fund is easy to refuse; a single decision is not. Recovered capacity: reengineering booked the gain as headcount, which is how it became the euphemism, and the rule here is the opposite. The evidence: reengineering ran on assertion and case anecdote, where this carries the complements literature, the J-curve, and the Danish record, and states its falsification conditions in public.
The second objection is also true. The decision has been a named unit of analysis for decades: decision support, decision management, decision modeling, a whole decision-intelligence category. Naming it is not the contribution, and I will not pretend to a literature review I did not perform. Three things are added. The decision is the unit of organizational redesign in response to cheap generation, where prior practice optimized the decision itself and left the handoff structure intact. The owner is not a process role but a named, equipped human, held against the oversight capacities Part 5 enumerated. And the autonomy ladder is gated on ledger evidence, which no decision-management methodology carries, because none was built against machine generation this cheap.
The third objection is partly true: nobody has the budget or the political capital to re-derive their decisions from first principles. Fair. This is not a program you fund. It is a shape you apply to one decision that runs more than weekly and that somebody cares about.
So, precisely. Established and cited as such: Hammer's diagnosis, the complements literature, the J-curve, the Danish record, the modifiability finding, Cherns' design doctrine. Borrowed and credited: the loop verbs, the ladder, the shell, and the decision as a unit of analysis. What is new is the coupling, assembled for the moment generation stopped being the constraint.
One decision, worked through
Back to the four pairs of hands: a request outside standard terms, passing through packaging, routing, and a completeness check before anyone decides.
The exception decision gets one named owner. Not a queue, not a function: a person who answers for whether exceptions are granted well. The evidence it requires (the request's terms, the precedent set, the exposure it creates) is assembled continuously, at the work, by the people who used to package it, and they reconcile each request against prior exceptions, because the context lives with them. The owner commits with the evidence in front of them, not a packet that waited on three desks. The mechanical residue executes without repackaging, the outcome is checked against the decision's intent, and the check goes to the ledger. One written condition states when an exception leaves the normal path. On a stated cadence, someone with standing to change the design reads the ledger and adjusts the loop or the condition, so precedent stops being folklore. Where the ledger shows the loop holding, the mechanical stages earn autonomy first, rung by rung, with the owner able to adjust output rather than only accept or reject. The decision itself stays with the person until the record says otherwise.
Note what this does not say: nobody was removed. That is deliberate, and it is the point of the series. What changed is what the roles do. The people who did the packaging hold the context the loop needs, and treating packaging as the whole of the role destroys it.
This example is illustrative and sanitized: no employer, system, person, proprietary process, metric, interval, volume, proportion, threshold, or staffing outcome, and its only quantity is the structural count of hands.
The Monday decision test
Pick one decision your organization makes more than weekly and genuinely cares about, then write six lines.
Who owns it. What evidence it requires, and where that evidence comes from today. What condition sends it up. Where the decision and its basis are recorded. Who reads that record, and how often. What would have to be true before any part of it runs without a person.
If you cannot fill in the fourth line, you do not have a ledger, so you cannot do the fifth, and the sixth is not available to you yet. That is not a failure. That is your sequence, and it is the same for everyone.
Six lines, one decision, no budget.
What would falsify this
This series opened by extending a claim I made in late 2025: superworkers, not replacements. AI amplifies the individual rather than removing them. That was right, and this is the structural half it left open: amplified individuals still get routed, still escalate, still have their work checked, and still need someone accountable for the result.
A series that argues from evidence should name the evidence that would beat it. Three conditions. Credible firm-level evidence that generative AI adoption produced sustained headcount reduction in coordination-heavy layers without a matching investment in verification would undercut the core claim. Evidence that verification cost falls at a rate comparable to generation cost in domains lacking machine-checkable ground truth would collapse Part 2. Regulatory movement away from named-human-oversight requirements toward outcome-only accountability would weaken the governance floor Part 5 stands on.
None of those has happened as of this writing. If one does, the series is wrong, and it should say so. Until then: one decision, six lines, and let the record tell you what to do next.
Sources
- Hammer, Michael. "Reengineering Work: Don't Automate, Obliterate." Harvard Business Review 68, no. 4 (July–August 1990): 104–112. Publisher.
- Brynjolfsson, Erik, and Lorin M. Hitt. "Beyond Computation: Information Technology, Organizational Transformation and Business Performance." Journal of Economic Perspectives 14, no. 4 (Fall 2000): 23–48. Publisher.
- Bresnahan, Timothy F., Erik Brynjolfsson, and Lorin M. Hitt. "Information Technology, Workplace Organization, and the Demand for Skilled Labor: Firm-Level Evidence." Quarterly Journal of Economics 117, no. 1 (February 2002): 339–376. Publisher.
- Brynjolfsson, Erik, Lorin M. Hitt, and Shinkyu Yang. "Intangible Assets: Computers and Organizational Capital." Brookings Papers on Economic Activity 2002, no. 1 (2002): 137–198. Publisher.
- Brynjolfsson, Erik, Daniel Rock, and Chad Syverson. "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies." American Economic Journal: Macroeconomics 13, no. 1 (January 2021): 333–372. Publisher.
- Humlum, Anders, and Emilie Vestergaard. "Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI." NBER Working Paper 33777, May 2025, revised March 2026. DOI.
- Dietvorst, Berkeley J., Joseph P. Simmons, and Cade Massey. "Overcoming Algorithm Aversion: People Will Use Imperfect Algorithms If They Can (Even Slightly) Modify Them." Management Science 64, no. 3 (2018): 1155–1170. DOI.
- Cherns, Albert. "The Principles of Sociotechnical Design." Human Relations 29, no. 8 (August 1976): 783–792. Publisher. Cited as design doctrine, paraphrased.
- Cherns, Albert. "Principles of Sociotechnical Design Revisited." Human Relations 40, no. 3 (March 1987): 153–161. Publisher. Cited as design doctrine, paraphrased.
Operate. Publish. Teach.