Every Department's AI Problem Is the Same Problem
Five briefings, five departments, five vendor decks. By the fourth one I stopped writing notes. Every deck framed the work as that department's AI strategy. The question underneath was the same in every room, and nobody was asking it.
Five briefings, five departments, five vendor decks. By the fourth one I stopped writing notes. Sales had a forecasting copilot. Finance had an FP&A agent. Legal had a contract-review tool. Support had a deflection bot. Procurement had source-to-pay. Every deck framed the work as that department's AI strategy. But the question underneath was the same in every room, and nobody in any of the rooms was asking it. The question is not which tool. The question is where the decision right now lives.
Every business department's AI problem is the same problem: the company has not decided where the decision right lives once an agent can execute the decision. The autonomous / approve-before / review-after taxonomy is the language for answering it. Until each workflow has a named archetype, the company has installed AI activity, not AI capability.
The misdiagnosis: five departments, five different problems
The pattern is familiar to anyone watching an enterprise AI program unfold. Each function brings its own vendor selection. Each function runs its own pilot. Each function builds its own dashboard. Each function reports its own progress in its own quarterly review. The CFO sees the FP&A agent's variance commentary. The general counsel sees the contract-review tool's flagged clauses. The CRO sees the forecasting copilot's pipeline accuracy. Five conversations, five sets of slides, five stand-alone narratives of progress.
There is something the per-department frame gets right. It tracks how budgets are allocated. It matches how teams organize themselves. It lets each function move at its own pace, which is the politically realistic thing to do when the technology is new and the appetite for risk varies by leader. The framing is not wrong because it is illogical. It is wrong because it answers the wrong question.
The first signal that something is off is structural rather than financial. Every department's program looks healthy on its own dashboard, and yet the company itself does not feel different. The board asks what has shifted at the company level. The honest answer is that activity has shifted at five department levels, and none of the five compounds into a different operating model. The McKinsey QuantumBlack survey on the state of AI calls this kind of moment a rewiring problem, and the framing is correct as far as it goes. What it stops short of naming is what unit of analysis the rewiring should operate at. The rewiring is real. The unit is wrong.
There is a quieter signal worth attending to. When a department's program looks healthy and the company does not feel different, the unit of analysis is almost always wrong. The fix is not to assign that department a clearer AI strategy or to find a better vendor. The fix is to step back one altitude and look at what is common to all five.
The reframe: one decision-right problem, expressed five ways
The pattern, once you see it, is hard to unsee. Every department's AI problem is not five different problems. It is the same underlying problem, expressed five ways. The same underlying problem is decision-right placement: for any workflow an agent can touch, the company has to answer two questions. Who or what takes the decision. Who or what reviews the action that follows.
A Sales forecast that the agent generates and a human approves is the same operating-model decision as a Finance accrual that the agent generates and a human approves. The vertical changes. The architecture does not. A Support tier-1 response that the agent executes and a human samples after the fact is the same operating-model decision as a low-value Procurement purchase order that the agent executes and a human samples after the fact. The product categories are different. The decision-right placement is identical.
This is not a regulatory-compliance question, although compliance constrains the answer in some workflows. It is not a vendor-selection question, although vendor selection sits downstream of the answer. It is a workflow-architecture question. Where does the decision live once an agent is in the loop. That is the load-bearing variable for whether the AI program compounds or stalls.
The reason the per-department frame is so durable is not that the buyers and analysts and consultants are unaware of the cross-cutting pattern. The reason is that the department-first framing serves the selling motion. Vendor decks compare departments because that is how budgets are allocated. Analyst frameworks compare maturity stages because that is what subscribers want. Consultancy frameworks compare role-redesigns because that is what gets sold by the seat-hour. Deloitte's piece on operating models for humans and AI agents gets closest to the architecture question, and even there the framing stops one layer short of naming decision-right placement as the unit of analysis. The competing material almost never says decision-right placement is the cross-cutting frame, because doing so would contradict the department-first selling motion. The misdiagnosis is structural. It is not accidental.
The reader who is in this situation already feels the cross-departmental pattern. What is usually missing is the language for naming it. That is what the rest of this essay supplies.
The taxonomy: autonomous, approve-before, review-after
Three archetypes carry the AI operating model at the workflow layer. Naming them is the first piece of work. The names matter because each archetype carries its own architecture, and the architecture is where the AI program either compounds or fragments. The archetypes are not three tools. They are three different homes for the decision right.
Autonomous
In the autonomous archetype, the AI takes the decision, executes the action, and the human reviews exceptions or aggregates only. The decision right has moved fully to the agent. The human is in the loop on exceptions, not on actions.
The required architecture is specific. Outcome KPIs replace input controls, because the input is no longer where the human attention lands. Exception-surfacing mechanisms have to be designed deliberately, because the volume of routine action is too high to inspect. Escalation paths for surfaced exceptions need named owners with named response windows. The definition of what counts as an exception needs to be explicit, or the agent runs free and nobody sees the systemic failures until they are systemic. The failure mode of autonomous is straightforward and common. A team installs autonomous without exception-surfacing, the agent operates for weeks or months, and the first sign of a problem is a board-level escalation rather than an operational signal.
Autonomous fits high-volume, low-individual-stakes, well-bounded decisions. Support tier-1 deflection. Low-value Procurement spend categories. Certain Sales lead-routing decisions where the cost of misrouting is recoverable within a week. The shared feature across these workflows is that the unit decision is low-stakes and the aggregate decision is high-stakes, which means the architecture has to monitor the aggregate without bottlenecking the unit.
Approve-before
In the approve-before archetype, the AI proposes the decision, a named human approves before the action executes. The decision right stays with the human. The AI is a proposal engine.
The required architecture is different. A queue is needed. An approver role with a named SLA is needed. A measurement of approver throughput is needed, because the moment the queue depth exceeds approver capacity, the queue itself becomes the new bottleneck. The failure mode is rubber-stamping. The approver receives too many proposals, says yes to all of them by default, and the decision right de facto migrates to the agent without the surrounding architecture catching up. Approve-before that has become rubber-stamping is worse than autonomous, because it costs the company the latency of the approval step without delivering the control the approval step was supposed to provide.
Approve-before fits high-individual-stakes, irreversible-or-expensive consequences, regulated decisions. Legal contract execution above a value threshold. Large Finance journal entries that affect external reporting. Procurement purchases above a spend threshold. The shared feature across these workflows is that the unit decision is high-stakes enough that the reversal cost exceeds the latency cost of waiting for the approver.
Review-after
In the review-after archetype, the AI takes the decision, executes the action, and a named human reviews a sample (or all of them) after the fact. The decision right is shared on a delayed loop.
The required architecture has its own shape. A sampling rule (or a full-review rule) is needed, with explicit criteria for what enters the sample. A feedback loop that updates the agent's behavior on rejected reviews is needed, because review without feedback is audit theater. A definition of reversal cost is needed, so the company knows what it is exposed to during the window between agent action and human review. The failure mode is that the review loop is real but slow, and the agent takes thousands of actions before the review surfaces a systemic error.
Review-after fits moderate stakes, partial reversibility, decisions that benefit from agent speed but tolerate delayed correction. Most Sales forecasting workflows. Most Finance accrual entries below a materiality threshold. Support tier-2 agent assistance. The shared feature across these workflows is that the speed gain from delegating execution outweighs the cost of a slightly delayed correction, provided the correction is real.
The reference card form of this taxonomy is the citable artifact the field has been missing. Three columns, three archetypes, four rows per column: who holds the decision right, what architecture is required, what failure mode is most common, what example workflow fits. The card is the asset.
Why this is the missing operating-model language
The reason this taxonomy is load-bearing is not that the three labels are catchy. It is that each label carries the architecture it requires. Once you name the archetype, you know what to install.
Each archetype needs its own KPIs. Autonomous needs outcome KPIs and exception rates. Approve-before needs approver-throughput KPIs and queue depth. Review-after needs sample-review rates and reversal rates. A program that runs autonomous on a workflow but measures it with approve-before KPIs will appear stalled in metrics that no longer describe what the workflow does.
Each archetype needs its own governance. Autonomous needs an exception-escalation policy with named owners. Approve-before needs approver SLA enforcement and queue-depth alarms. Review-after needs feedback-loop governance, so rejected reviews actually update the agent rather than vanishing into a quarterly review deck. The governance is different because the failure modes are different, and the failure modes are different because the decision-right placements are different.
Each archetype needs its own management cadence. Autonomous: weekly outcome review, monthly exception-pattern review. Approve-before: daily queue-depth review, weekly approver-throughput review. Review-after: weekly sample-review, monthly reversal-rate review. A management cadence that reviews approve-before queues without ever inspecting autonomous outcomes is structurally blind to a large class of failure.
There is one specific reason the default keeps drifting toward approve-before across vendors and departments. Vendors ship audit trails because compliance buyers ask for audit trails, and an audit trail is most naturally produced by an approve-before flow. The default vendor UI almost always assumes approve-before. For high-volume, low-individual-stakes workflows, approve-before is the wrong default, and installing it as the default produces the result the department AI transformation programs keep complaining about. The agent is fast, the approver is human, the queue is the bottleneck, the velocity does not change.
Naming the archetype is not three labels. It is the architecture you are choosing to install. Until the archetype is named, the architecture is whatever the vendor's default happens to imply, and the vendor's default is almost never right for the workflow.
The five departments, mapped to the taxonomy
A short tour across the five departments is enough to show the pattern without exhausting any single one. The downstream pieces of this Pillar 2 cluster will walk through each department's instantiation in operator detail. The point of the tour here is to make the cross-departmental fit feel concrete.
Sales: forecasting, lead routing, opportunity scoring
Lead routing belongs in autonomous for most pipelines. The unit decision is low-individual-stakes, the volume is high, and the cost of misrouting is recoverable inside a week. Forecast generation belongs in review-after. Speed matters, and the reversal is updating next week's number. Opportunity scoring is mixed. For top-tier accounts, approve-before. For the long tail, review-after. The failure mode that recurs across Sales is treating forecasting as approve-before, which bottlenecks the weekly cadence the forecasting agent was supposed to accelerate. The bottleneck is structural, not technological.
Finance: accruals, variance analysis, vendor payments
Routine accruals below materiality threshold belong in review-after with sampled QA. Accruals above threshold belong in approve-before with a named controller as approver. Variance commentary belongs in autonomous, with the agent flagging variances above tolerance and the human reviewing the flags rather than every variance. Vendor payments belong strictly in approve-before, with a clear segregation-of-duties policy. The recurring failure mode in Finance is installing approve-before across all accruals, which makes the close cycle worse rather than better, because the controller becomes the queue bottleneck.
Legal: contract review, NDA execution, regulatory monitoring
Standard NDAs belong in autonomous, with exception-surfacing on non-standard clauses. Master service agreements and contracts above a value threshold belong in approve-before. Regulatory horizon scanning belongs in autonomous reporting, with approve-before on the response actions the report recommends. The recurring failure mode in Legal is the general counsel's office treating every workflow as approve-before to preserve liability posture. The contract pipeline stays the same speed it was before the AI investment, and the AI investment registers as a sunk cost rather than a capability.
Support: tier-1 deflection, tier-2 assistance, escalation routing
Tier-1 deflection belongs in autonomous, with exception escalation on identified frustration signals. Tier-2 agent assistance belongs in review-after, with sampled quality assurance. Escalation routing belongs in autonomous. The recurring failure mode in Support is installing approve-before on tier-1 deflection. Every response is reviewed by a human agent before it goes out. The deflection use case is structurally defeated, because the human cost per response stays the same and the AI adds a step rather than removing one.
Procurement: source-to-pay routine, large-value purchases, vendor onboarding
Below-threshold spend belongs in autonomous, with anomaly surfacing for the long tail. Above-threshold spend belongs in approve-before, with a named approver per spend band. Vendor onboarding belongs in review-after, with sampled compliance checks. The recurring failure mode in Procurement is installing review-after across the entire spend range. The company discovers its non-compliant vendor onboarding only when the auditor surfaces it, which is later and more expensive than the sampling rule would have caught.
The cross-departmental pattern is now visible at the workflow layer. Decision-right placement is the unit. Department is the costume.
What the C-suite actually has to do
The implications are operational, not strategic in the consulting-deck sense. Four moves carry the weight.
The first move is naming the decision-right owner per department-workflow-archetype combination. The CFO does not own decision-right for AI-driven accruals by virtue of being the CFO. The general counsel does not own decision-right for AI-driven contract review by virtue of holding the title. The decision-right owner is whoever the company explicitly names. Most companies have never named anyone. That is the work. Until the name exists, the workflow has no owner of the architectural decision, which means it has no owner of the failure mode that decision implies.
The second move is installing the matching governance per archetype, not per department. This is the part the cross-departmental frame makes possible. Approve-before workflows across Finance, Legal, and Procurement share a governance pattern: queue depth, approver SLA, throughput measurement. Review-after workflows across Sales, Finance, and Support share a different governance pattern: sampling rule, reversal rate, feedback loop. Autonomous workflows across Support, Procurement, and lead-routing share a third governance pattern: exception-surfacing, outcome KPIs, escalation paths. Installing governance by archetype rather than by department is what makes the cross-departmental pattern operational rather than theoretical.
The third move is redesigning the manager's measurement system around the archetype. A sales manager whose forecasting workflow is review-after is not measured the same way as a sales manager whose forecasting workflow is approve-before. The measurement system has to follow the decision-right placement, not the historic management cadence. This is the move that quietly fails most often, because the historic management cadence is invisible to the people inside it.
The fourth move is making decision-right placement a board-level question. The board does not need to know which vendor or which model. The board needs to know which workflows have been explicitly mapped to which archetype, and who is the named owner of the answer per workflow. The BCG survey on CEO accountability for AI investment correctly identifies that the CEO is now the responsible party at the executive layer. What the survey does not name is what specifically the CEO is now accountable for at the workflow layer. The decision-right map is the answer. The CEO is accountable for the existence and the accuracy of the map.
The anti-pattern to flag is the company that announces an "AI strategy" without a decision-right map. The strategy is downstream of the map. Without the map, the strategy is vendor selection in nicer language. The vendors are happy to fill the gap. The company is the one left holding the cost of the misdiagnosis.
Closing implication
When AI lands in a department, the question is not which tool to deploy or which use case to pilot. The question is where the decision now lives. The autonomous / approve-before / review-after taxonomy is the language for answering it.
Five rooms, five vendor decks, five different conversations, one question underneath. Until the question has a named owner per workflow at your company, you are funding AI activity. You are not funding AI capability.
The map is the work. The taxonomy is the language for drawing it.
Key Takeaways
- Every business department's AI problem is the same problem: decision-right placement once an agent can execute the decision.
- The taxonomy has three archetypes: autonomous, approve-before, review-after.
- Each archetype requires different KPIs, governance, escalation paths, and management cadence.
- The default vendor UI assumes approve-before, and approve-before is the wrong default for most high-volume departments.
- The map of decision-right placement per workflow is the work. The strategy is downstream of the map.
