The Five-Layer Activity Model: Why Enterprise Transformation Addresses Two Layers and Misses Three
v3.2 · 19 October 2026 · First issued 1 April 2026 · Custodian: BusinessGPS · Version index and changelog
Executive summary
All enterprise work sits across five layers. Transformation programmes address two of them. The other three go unaddressed — not because they are hidden, but because no standard delivery model is scoped, paid or equipped to make them visible.
The Five-Layer Activity Model places every activity in every enterprise function on one of five layers, each with its own ownership, documentation state, technology footprint, data types and AI deployment pattern:
| Layer | What it is | Who addresses it | AI pattern (reliability: our working threshold) |
|---|---|---|---|
| L1: Standard Software Process | Process the system enforces (ERP) | Every transformation | Delegation (99.99%) |
| L2: Standard Operating Procedures | Documented procedures | Most transformations | Delegation (99.9%) |
| THE BLIND SPOT LINE | |||
| L3: Contextual Workarounds | What people actually do (spreadsheets, manual fixes, local practice) | Not scoped by standard delivery | Augmentation (80–95%) |
| L4: Managerial Judgment | Decisions and tacit knowledge | No standard delivery method has a step for it | Augmentation (human decides) |
| L5: Agentic Potential | Agent orchestration, and the authority over what agents may do | Orchestration not built; delegation unwritten | Orchestration |
McKinsey’s The state of AI in 2025: Agents, innovation, and transformation (November 2025) reports that 88% of surveyed organisations report regular AI use in at least one business function, up from 78% a year earlier, and that about 6% qualify as high performers (significant value, with more than 5% of EBIT attributable to AI). The model’s reading of that 88/6 gap is simple: AI has been deployed at Layers 1 and 2, and much of the value lives at Layers 3 to 5.
Value is lost below the line in two ways. It dies at Layer 4, where judgement is never articulated and so never changes when the system does. And it fossilises at the boundary between Layer 3 and Layer 1, where workarounds built to bridge a gap are coded into the core system and compound there for years. A programme that addresses only one of the two leaves the other in place.
This paper defines each layer, maps the technology and agent patterns that apply at each, explains the structural forces that keep the blind spot in place, sets out the Core/Context/Signature classification, gives the complete 27-question articulation method, and connects the model to ambidextrous leadership and to the O2O method.
A note on scope: the model is a diagnostic for any enterprise transformation — ERP migration, operating-model redesign, post-merger integration, digital transformation. It uses AI as the instrument (agents that support the discovery and classification work), not as the destination. Organisations whose goal is AI adoption will find that articulating Layers 3 to 5 is the prerequisite for it: you cannot automate work you have not described.
A note on terms. Four words are kept apart in this paper. A layer is a place in this stack, L1 to L5, from transactions at the bottom to agentic orchestration and authority at the top. A level is a place in a process hierarchy such as APQC’s, where Level 3 is a process and Level 4 its activities. Depth is how tacit a piece of work is, a separate axis. Maturity is how well an organisation cycles through change. A layer is a locus, not a grade: work sits at a layer; an organisation does not climb to one.
1. The problem
Most organisations now use AI somewhere; few capture significant value from it — the 88/6 gap.
That gap is not a technology gap. Every major enterprise has access to the same models, the same platforms and the same hyperscaler partnerships. The technology is the commodity. The organisations that capture value are the ones that build their capacity to absorb it.
So where does the value disappear?
Every transformation programme addresses two things: the system (what the software does) and the procedures (how people are supposed to use it). These are the visible layers — the ones that get scoped, budgeted, delivered and billed. They sit above what this paper calls the Blind Spot Line.
Below that line sit contextual workarounds, managerial judgement and agentic potential. These layers are invisible to every standard delivery model — not because they are hidden, but because no standard delivery model has a step, a budget or an incentive to make them visible.
Why it matters now
The human core becomes the scarce part. Dave Blundin of Link Ventures said on the Moonshots podcast (episode 242, recorded 23 March 2026) that his firm’s companies are targeting 80% token cost to 20% salary. The point survives any exact ratio: the remaining human core is the most valuable part of the company — not because it does the work, but because it directs it. It is the articulation layer.
The fit-to-standard trap. The dominant enterprise transformation approach — fit-to-standard — pushes the way an organisation performs its distinctive capabilities out of the standard system. When you adopt vendor-standard processes, the generic activities get configured; the activities that make a capability distinctive migrate below the Blind Spot Line, into workarounds. Agentic AI changes the economics of addressing those workarounds — but only once they are articulated.
The cheap brain. The raw token cost of a year’s human-scale cognitive output is small beside a salary. Real agentic operating cost is dominated by orchestration and verification, not tokens. The technology is not the bottleneck. Describing what to do with it is. Agents can only do what you can describe, and the description of Layers 3 to 5 — the fine grain of how work actually happens — is what does not exist.
2. The five layers
The Five-Layer Activity Model places all enterprise work on five layers, each with its own ownership, documentation state, technology footprint, data types and AI deployment pattern. It builds on business process outsourcing practice, the articulation-gap thesis, and Geoffrey Moore’s Core/Context framework, extended with the Signature concept.
Layer 1: Standard Software Process
What it is. The work the system enforces. When the ERP says “this is how order-to-cash works”, that is Layer 1. The process is configured into the software, and users follow it because the system gives them no alternative. It is the most rigid layer and the most visible: every ERP implementation, system migration and go-live is primarily concerned with it.
Who owns it. IT and the system integrator; in operation, IT operations and the business process owners who govern configuration.
How it is documented. Extensively — configuration documents, process flows, test scripts, technical and functional specifications. It is the most-documented layer because it is the primary deliverable of every implementation.
What technology sits here. ERP systems (SAP S/4HANA, Oracle Cloud, Microsoft Dynamics 365), CRM platforms, HCM systems, supply-chain platforms: the core transactional systems.
What data lives here. Transactional data, master data, system-enforced workflows, configuration parameters.
AI pattern. Agentic automation — delegation. Agents execute standard transactions the system already enforces: posting entries, processing orders, reconciling against defined rules. We set the working requirement at 99.99% per task, because errors compound along a sequence. At 80% per task, a 50-step run succeeds about 0.0014% of the time (0.8^50, about one run in 70,000). At 99.99% it succeeds 99.5% of the time; at 99.9%, 95%; at 99%, 61%. The thresholds in this paper are our own working figures, not measured results.
Finance example. Order-to-cash enforced by configuration; record-to-report with system-mandated close steps; three-way match driven by configured tolerances.
When transformation ignores it. It does not. This is where every transformation starts. The problem is not that Layer 1 is ignored; it is that transformation stops here, or at most at Layer 2.
Layer 2: Standard Operating Procedures
What it is. The written procedures that tell people how to use the system — the bridge between what the software can do and what people need to do with it. The outsourcing world runs on Layer 2: operators who are not expected to improvise are given procedures precise enough to execute consistently.
Who owns it. Process owners, business analysts and procedure writers. In an outsourced model a dedicated team maintains procedures and superusers resolve exceptions. Elsewhere ownership is often diffuse: procedures sit in folders nobody reads, maintained by nobody in particular.
How it is documented. Variably. In mature outsourced operations, with version control and regular validation against practice. In most enterprises, procedures exist but are outdated, incomplete or contradicted by practice — and that gap is one of the earliest signals that Layers 3 and 4 are carrying load.
What technology sits here. Business process management and workflow tools, documentation systems, process mining, RPA that automates documented procedures, learning systems.
What data lives here. Procedure documentation, training material, compliance records, workflow definitions, audit trails.
AI pattern. Delegation, as at Layer 1, with one addition: exception handling. A Layer 2 agent must know not only how to follow the procedure but when to escalate. The outsourcing parallel is exact: operators execute procedures, superusers handle exceptions, and management governs the boundary between them.
Finance example. The month-end close checklist; reconciliation procedures with tolerances and escalation paths; approval workflows for journals above a threshold; intercompany elimination procedures.
When transformation ignores it. People do the work but nobody knows how. New systems are installed without corresponding procedures, and the organisation relies on tribal knowledge to bridge the gap.
The transition-state problem. Steady state is the easy case. During deployment, Layer 2 takes the most violent disruption: dual systems, dual data models, dual reporting structures and dual procedures, with the close running across two system states. The manual reconciliation effort in that period can destroy value on its own.
The critical failure is that temporary workarounds built to manage the transition become permanent. They are written into operations manuals or simply become “how we work”. Large spreadsheets of manual reconciliations persist because the new system cannot handle an edge case — perhaps because no procedure covers a recurring edge case, so the same mismatches break the automation each cycle. Where the software touches a distinctive process or an industry non-negotiable and cannot bend, the workaround becomes structural.
The last 10%. The design aspiration is touchless operations: collapsing Layer 3 workarounds and Layer 2 manual procedures into a fully automated Layer 1. But as the Secret CFO has put it, ERP did not deliver the last 10% — the technical debt carried forward wherever the system does not meet real-world requirements. And the last 10% is often not merely undone but hidden: a workaround can absorb a variance so that the visible figure looks smaller and cleaner than reality. A gap that presents as a smaller number does not announce itself, so a scan of the visible layers reads healthier than the operation is.
Layer 3: Contextual Workarounds
What it is. The work people actually do because the system cannot do it for them — the spreadsheets, manual processes, email chains, shadow IT, the “we do it this way because the system can’t”. Layer 3 is the scar tissue of every incomplete implementation: known by the people who do the work, rarely documented, and invisible to anyone who looks only at Layers 1 and 2. The companion paper Layer 3: The Workaround Layer treats it in depth.
Who owns it. The people who do the work — finance analysts, operations managers, supply-chain coordinators, the specialists who bridge what the system delivers and what the business needs. They are often the hardest people to replace, because their value is the workaround knowledge.
How it is documented. Rarely. In spreadsheets on personal drives, in email chains, in the heads of the three people who know how to run the monthly reforecast because the planning tool does not handle the edge cases.
What technology sits here. Layer 3 is not just spreadsheets. It is where much of the real analytical work of the enterprise happens: consolidation systems, planning tools, forecasting platforms, data warehouses and lakes, BI and analytics platforms. These exist because the core system cannot do what the business needs. As the Secret CFO puts it, “Excel is the pain relief for tech debt, not the cure.” Whole product categories — planning, consolidation, business intelligence — exist because Layer 1 systems do not deliver the analysis that Layer 4 decisions require.
The in-system workaround. Every example so far sits beside the core system. Some of the most consequential workarounds sit inside it: custom code, bespoke mechanisms and workaround objects created so that transactions the standard would not accept could be pushed through. Each was built because the standard could not do what the business needed — the definition of a Layer 3 workaround — but each runs as code and configuration at Layer 1, with a change record and a place in the system of record. A sweep that looks only for spreadsheets and shadow IT will miss them. A workaround that runs as system code is still a workaround. What makes work Layer 3 is not where it runs but whether the reasoning behind it has been articulated. A custom mechanism whose rationale lives only in the head of whoever built it is Layer 3 work in Layer 1 clothing.
What data lives here. Analytical data, consolidated views, forecasts, budget scenarios — data extracted from Layer 1 into something the business can use. A large spreadsheet that corrects system data because a master-data set was never loaded correctly. A workbook that maps between account structures because the global template does not fit the local business.
AI pattern. Decision support — augmentation. Agents that can read the spreadsheet, understand why it exists, and either fix the upstream Layer 1 problem or automate the workaround. The reliability requirement changes at Layer 3: agents work iteratively with people, so 80–95% accuracy is workable because a person validates the output. The agent proposes; the person validates.
Finance example. The Secret CFO’s Tech Debt series reads as a Layer 3 catalogue: RPA applied to reconciliation exceptions, automating the downstream consequences of a problem rather than its cause; a planning system selected before requirements were written, abandoned without a post-mortem, with a division still waiting twenty years later.
When transformation ignores it. Workarounds multiply, technical debt compounds, and the gap between what the system does and what people do widens with every release. The Secret CFO’s account of the attempt to bend the business to the system’s rules is that “Most got 90% there”, and that 90% is not enough: the way out runs through the last 10%. That last 10% is Layer 3.
Layer 4: Managerial Judgment
What it is. The decisions people make using the information from Layers 1 to 3. When to override the forecast because a customer relationship is souring. Whether to accelerate a supplier payment because the supply chain is fragile. How to prioritise five initiatives when the organisation can absorb two. Which exceptions to escalate and which to absorb.
Layer 4 is largely unarticulated. It is the accumulated institutional memory, political intelligence and professional judgement that experienced managers bring to their work — the reason a finance director of twenty-five years produces different decisions from the same data than a manager of three. The data is the same; the judgement is different.
This is where the “frozen middle” sits: the point in the organisation where the capacity to change is most concentrated and most easily lost. Middle management is the recognised bottleneck in transformation, and the model explains why. Middle managers are Layer 4 operators. Programmes address Layers 1 and 2 (new system, new procedures), sometimes Layer 3 (new BI tools), but not Layer 4. The manager is asked to make the same decisions with a new system — and does. New inputs, same judgement, same outputs. This is the first way value is lost: it dies at Layer 4.
The second way: value fossilises between Layer 3 and Layer 1. Workarounds automated into the core years ago go on compounding: more logic is built on top of them every year, so the cost of the original shortcut does not stay fixed — it grows as the estate hardens around it. The first mechanism loses value that was never captured. The second loses value that was captured, in the worst form: a compensating fix cemented into the layer that is hardest and most expensive to change. A programme that fixes only the Layer 4 side — better decision support, codified judgement — leaves the fossilised core untouched.
The practical consequence is for anyone choosing to “freeze the core and modernise around it”. Every layer interposed over a frozen system is a Layer 3 workaround with a longer fuse. Its first-order saving is easy to price; its cost in year five, and the cost of removing it, usually are not. The freeze/flex boundary should be a governed decision with a costed year-five position and a named removal trigger, not a permanent default — because the fossilised core is what a permanent interposition becomes twenty years on.
Who owns it. Middle managers, department heads, function leads — the people whose daily and weekly decisions determine whether strategy executes.
How it is documented. Almost never. Decision patterns are not written down; exception heuristics are not codified; institutional memory is not captured. When a senior manager leaves, an irreplaceable body of Layer 4 knowledge leaves too, and no document, system extract or successor can reconstruct it.
What technology sits here. Decision-support tools, dashboards, scenario modelling, AI copilots — but mostly nothing, because the decisions have never been articulated. You cannot build technology for work you have not described.
What data lives here. Tacit knowledge, institutional memory, exception patterns, decision heuristics, relationship maps, risk intuitions.
AI pattern. Decision augmentation. Agents surface options, model scenarios and present trade-offs; people decide. The question is not “is the agent right?” but “does the agent help the person make a better decision?”
Finance example. The CFO overriding the forecast because the customer relationship is souring. The finance director accelerating one entity’s close because the group consolidation has a deadline the system does not enforce. The controller approving a manual journal that breaks the automated reconciliation because they understand the commercial context behind the exception. The Secret CFO calls finance teams’ response to repeated technology failure “learned helplessness” — a rational response to repeated failure. In this model, that is what happens to Layer 4 judgement when it is never articulated.
When transformation ignores it. New systems go in, new procedures are written, new BI tools are deployed — and the decisions do not change. Delivery methodologies rarely have a step for “articulate the managerial judgement that makes this system valuable”. Together with fossilisation at the Layer 3–Layer 1 boundary, this is why so many organisations adopt AI and so few capture value from it.
Layer 5: Agentic Potential
Layer 5 is the top layer of the stack: the layer where agents are orchestrated across everything beneath it, and where authority sits over what they are allowed to do. It has two faces. Agentic Potential is what becomes possible once the work at Layers 3 and 4 is described clearly enough for agents to take part, and the orchestration that coordinates them. Trusted Agency is the authority that makes that potential usable: who may delegate a decision or an action to an agent, what accountability they accept in doing so, and the trust, permission and right of escalation that keep the delegation standing. Potential without trusted agency is capability nobody is permitted to use; trusted agency without potential is authority over nothing. Layer 5 is a place in the stack, not a level an organisation graduates to, and it is not a maturity score.
Who orchestrates, settled in one sentence: agents orchestrate; the authority to let them act is delegated by people and answered for by people.
Agentic Potential
Agent orchestration across the stack is emerging. It becomes available as Layers 2 to 4 are articulated at agent resolution, and its pace depends on the pace of that articulation.
What it is. The orchestration that coordinates agents across all the other layers, manages the workflow of the whole system and learns from each cycle — the potential that opens once the work at Layers 3 and 4 is described clearly enough for agents to participate in it.
Who owns it. Often, nobody. Where Layers 3 and 4 have begun to be articulated, it sits with the transformation architect, the enterprise architect, or whichever role governs the intersection of technology capability and operating model.
How it is documented. As codified expertise: agent definitions, knowledge graphs, decision frameworks, structured knowledge stores. This is capability documentation — what the system knows, how it reasons, which judgement frameworks it applies — rather than procedure documentation.
What technology sits here. Agent orchestration platforms, multi-agent systems, workflow engines and knowledge architectures. The data type is neither transactional nor analytical; it is knowledge.
AI pattern. Orchestration: agents coordinating agents and managing the system of tasks, analysis and decisions beneath them — not just doing tasks (Layers 1–2), supporting analysis (Layer 3) or advising decisions (Layer 4).
Finance example. An agent system that orchestrates the month-end close across entities, currencies and regulatory regimes: it knows which entities are ready and which are blocked, what exceptions are flagged, which human decisions are pending and what the timeline looks like, and it coordinates transaction, procedure, analytics and decision-support agents into one workflow. It becomes possible where Layers 3 and 4 have been articulated.
When transformation ignores it. The opportunity cost is invisible, because the opportunity is not yet real for most organisations. Organisations that never articulate Layers 3 and 4 will not be able to build it, and will go on deploying AI at Layers 1 and 2 and wondering why so little value is captured.
Trusted Agency
What it is. The authority face of Layer 5: delegated authority to decide and act, the accountability accepted with it, stakeholder trust, rights of escalation, and permission to make consequential commitments. The question is not merely who — or what — can perform the task, but who is authorised and trusted to act, and who answers for it.
When it applies. Unlike orchestration, this face is not a future question. Wherever an agent has been put to work anywhere in Layers 1 to 4, someone’s delegation — written or not — is already carrying it. The authority question exists from the first deployment.
What it decides. Which decisions and actions may be delegated to agents, within what limits; who accepts accountability for each delegation; when an agent must escalate, and to whom; and who may extend, restrict or withdraw the delegation.
When it is missing. Potential without trusted agency is capability nobody is permitted to use, or — worse — capability used under authority nobody granted. Where the enterprise does not set this authority deliberately, the defaults of whatever platform is in use set it instead — a decision taken by default rather than by the enterprise. Whatever platforms it uses, the authority at Layer 5 is the enterprise’s to hold.
How it differs from authority at Layer 4. A manager’s decision rights over their own operations are a Layer 4 matter. Trusted Agency is authority delegated to act through agents. They are different questions, and an organisation can settle one without the other.
3. Technology and agent patterns by layer
Every enterprise has technology at every layer, but it is rarely understood as a layered stack with different deployment patterns at each. Treating “AI deployment” as a single category is the category error behind much of the 88/6 gap.
| Layer | Agent type | AI pattern | Reliability need (our working threshold) | Human role |
|---|---|---|---|---|
| 1 | Transaction agents | Automation (delegation) | 99.99% — sequential tasks | Monitor |
| 2 | Procedure agents | Automation (delegation) | 99.9% — with exception handling | Exception handler |
| 3 | Analytics and planning agents | Augmentation | 80–95% — a person validates | Validator and director |
| 4 | Decision-support agents | Augmentation | Not applicable — agent advises, person decides | Decision-maker |
| 5 | Orchestration agents | Orchestration | System-level governance | Delegates authority and answers for it |
Where the work gets done: sourcing by layer
Beyond what (the layer the activity sits at), why (Core, Context or Signature) and when (current, transition, target), there is where: who does the work.
| Layer | Context sourcing | Core sourcing | Signature sourcing |
|---|---|---|---|
| L1 | Standard configuration; shared service or outsource | System-enforced, in-house | Custom configuration, protect |
| L2 | Standard procedures; outsourcing candidate | Documented, maintained in-house | Procedures are IP, protect |
| L3 | Outsource or automate | Articulate and make agent-ready | Keep in-house, articulate |
| L4 | Simplify or eliminate | Decision-support agents | Never outsource |
| L5 | Automate fully | Augment and govern | Augment carefully, protect IP |
4. The Blind Spot Line
What the line divides
The Blind Spot Line sits between Layer 2 and Layer 3. It is easy to read it as a boundary between technologies — enforced systems and documented procedures above, spreadsheets and shadow tools below. That reading misses the in-system workaround, which runs inside the core system and so plots above a technology line.
The line is better read as a boundary of articulation state: not where does the work run? but has the reasoning behind it been made explicit? Above the line sits work whose logic is documented and describable, whether the system enforces it or a procedure records it. Below the line sits work whose logic lives only in someone’s head or in unexplained custom code, whether it runs in a spreadsheet or in a resident system module.
This changes the diagnostic. A sweep that looks for shadow IT will pass a heavily customised core system as clean. A sweep that looks for unarticulated reasoning finds the in-system workarounds and the custom logic — the work built because the standard could not do it, then buried inside the standard where a location-based scan will not look. And before any such exception path is stripped out of a core system, someone has to decide which paths are the moat: that is a Layer 4 judgement.
Why the line persists
The Blind Spot Line is not an accident. Four structural forces keep it in place, and none is a conspiracy; each is the predictable result of how the work is scoped and paid for.
Economics. Layers 1 and 2 are where the billable work is: ERP migrations and process redesign are large, scoped, priced engagements. Layers 3 to 5 are messy, unarticulated and hard to scope. Nobody writes a statement of work for “articulate the judgement your managers carry in their heads”.
Methodology. As we read them, the major delivery methods — SAP Activate, Oracle’s Unified Method, agile frameworks, PRINCE2, MSP — are designed for Layers 1 and 2, with no step for “discover what people actually do that is not in the procedures” or “codify the judgement that makes this system valuable”. That is the gap Transformation Capability Management is defined to fill.
Incentives. Delivery contracts are usually scoped to systems (Layer 1) and user training (Layer 2). Nobody, buyer or integrator, is usually asked to scope Layers 3 to 5.
Dependency. An organisation that never articulates its Layers 3 and 4 cannot carry its own change alone, and depends on outside help for it. The aim is a buyer’s own capacity, with integrators alongside it.
A convergent reading
In a four-part Tech Debt series (March 2026), the Secret CFO, a practitioner, describes a four-layer finance stack: transactions, an accounting system of record, a data integration layer and an intelligence canvas. He treats agents as workers inside those layers, not as a layer of their own. Three of his phrases map onto this paper: “Excel is the pain relief for tech debt, not the cure” (Layer 3), “learned helplessness” (Layer 4) and “Most got 90% there… the last 10%” (below the line). His stack is not our five layers, and he does not describe orchestration across layers. The overlap is in the diagnosis, not the structure.
5. The articulation gap
Definition. The articulation gap is the difference between what people actually do (Layers 3 and 4) and what is documented and codified (Layers 1 and 2). Closing it is the work of Transformation Capability Management.
The gap has always existed. What makes it critical now is that AI requires description to function. An agent can only do what you can describe. Layers 1 and 2 are described; Layers 3 and 4 are not. That is where the 88/6 gap lives.
The outsourcing parallel
Business process outsourcing closed the articulation gap for Layers 1 and 2 because its economics demanded it. Its hierarchy maps directly onto an agentic architecture:
| Outsourcing role | Function | Agentic equivalent |
|---|---|---|
| Procedure writers | Articulate the work | The articulation layer |
| Operators | Execute the procedures | Agents executing codified procedures |
| Superusers | Resolve exceptions | People in the loop, handling what agents cannot |
| Management | Decide and prioritise | Governance and the authority to delegate |
The agentic era demands for Layers 3 to 5 the articulation that outsourcing demanded for Layers 1 and 2.
The expert window
There is a window during which experienced practitioners can still direct AI better than AI directs itself. Organisations that articulate their Layers 3 and 4 while those people are still in the building capture their expertise in a form agents can use. Organisations that wait risk losing it as people retire, move on or burn out — and the knowledge goes with them, unarticulated and unrecoverable.
Articulation is not a one-time capture. An articulated Layer 3 or 4 artefact that is never refreshed becomes a confident source of ageing answers — call it context rot — its rules and definitions drifting out of step with the reality they describe. Judgement tied to a role tends to stay stable until the role-holder leaves, then goes stale in a single event. Articulation opens the window; maintaining the articulated truth keeps it open.
6. Core, Context and Signature
Geoffrey Moore’s Core vs Context framework (Dealing with Darwin, 2005) classifies business activities as core or context. BusinessGPS extends it with a third category, Signature, and applies the classification to capabilities and to the processes and activities that realise them:
- Signature is exclusive to the business and cannot be replicated in any system or platform. It must be owned. It may be a competitive moat (a unique method, proprietary IP, firm-defining judgement) or a constraint-born necessary uniqueness (bespoke statutory or compliance architecture that the firm’s situation requires). The second matters for multi-jurisdictional firms whose legal or regulatory structure does not fit standard tooling.
- Core covers capabilities whose design and ownership materially affect business outcomes, even where standard tooling exists for execution. Revenue-facing and back-office capabilities can both be Core; what makes them Core is the strategic weight of the ownership decision. Core is where rent, buy, borrow or build is decided deliberately, capability by capability.
- Context is commodity: standardised, with no differentiation value in the design or ownership decision. Rent it at the lowest credible cost.
Renting Context is the rational choice. Renting Signature is existential. The Core decision is where the strategic choice lives.
The classification is firm-specific, not capability-generic. Pricing is Context for a commodity retailer, Core for most mid-sized firms, and Signature for a specialist insurer whose risk model is the business. Every organisation needs its own map.
It is also a snapshot plus a trend. Every capability carries a current label and a direction of travel. Four movements matter: Core to Context (commoditisation), Signature to Context (leakage — the sovereignty risk), Context to Core (re-strategisation under regulatory or geopolitical pressure), and unclaimed to Signature (emergence).
The classification cascade
Which layer is the activity at? → Which classification? → Which change mode? → Where does it get done?
- Layer 3 workaround → Signature → disruptor mode → bring in-house, articulate, build agents
- Layer 1 transaction → Context → continuity mode → shared service or outsource, automate
- Layer 4 decision → Core → growth mode → augment with AI, person in the loop
The Signature boundary shift
AI moves the Signature boundary. What was Signature — “our people are really good at X” — may become Context when agents can do X. The new Signature becomes “our ability to articulate and orchestrate X at scale”: a capability performed through Layer 4 and 5 activities rather than Layer 1 and 2 ones.
That creates an opportunity. Standard software at Layer 1 plus a custom agentic layer for Signature work at Layer 5 gives a commodity foundation with proprietary intelligence on top — and now that AI-assisted development has made custom code cheaper, Signature processes that were once too expensive to build can be built.
Where to start
- Start with Signature. Which two or three processes embody your competitive strategy?
- Find the largest articulation gap. Where is the difference between documented (Layers 1–2) and actual (Layers 3–4) largest?
- Find the highest-value agent opportunity. Score it on the cost of current human effort, the value of the output, the risk if an agent gets it wrong, and the ease of articulation.
Capabilities, processes and activities
The Five-Layer Model works at the activity level, but activities have to be read within the wider enterprise architecture. Four views describe how an enterprise creates and delivers value:
- Value streams describe how value is created and delivered to customers and stakeholders.
- Capabilities describe what the enterprise must be able to do to create and sustain that value.
- Processes describe how work is organised and carried out to deliver outcomes.
- Activities are the individual units of work performed within processes. This is where the five layers apply.
Capabilities and processes are distinct but connected, and the relationship is many-to-many: a capability may support several processes, and a process may draw on several capabilities. Neither is a decomposition of the other. Processes do decompose into activities — in the APQC hierarchy, processes at Level 3 are made up of activities at Level 4 — but a capability is not broken down into processes; it is realised through them, with the people, information and technology they use.
Core, Context and Signature classify capabilities first, and the classification is carried by the processes and activities that realise them. A process can also be Signature in its own right. It sets how the work is handled. Context is simplified, standardised and automated, and rented at the lowest credible cost. Core is decided deliberately — rent, buy, borrow or build — because its design and ownership shape outcomes. Signature is articulated, owned and protected, whether it is a competitive moat or a necessary uniqueness. So you do not classify an individual journal entry as Signature — you classify the planning and analysis capability, and that classification is carried by the processes and activities that realise it, at whichever layer they sit. That is how the model connects value creation, capability requirements and process execution to decisions about automation, AI augmentation and agent orchestration.
Tools that work with the model
| Tool | What it does | Where it applies |
|---|---|---|
| Theory of Constraints (Five Focusing Steps) | Finds the binding constraint in a system | All layers — which layer is the bottleneck? |
| Logical Thinking Process (CRT, FRT, TT, PRT) | Maps cause and effect and designs transitions | Layers 3–5 — transition-state management |
| Value stream mapping | Shows flow and waste across a process | Layers 1–3 — where does value leak? |
| Wardley maps (evolution axis) | Places components by visibility and evolution | All layers — commodity or custom? |
| Cognitive P&L | Scores activities for automation or augmentation | Layers 2–4 — where should agents go? |
| Process mining | Discovers actual execution from system logs | Layer 3 — what do people actually do? |
| Decision mapping | Maps who decides what, with what information | Layer 4 — articulating judgement |
7. Four public failures, read through the five layers
The model can be tested against transformations that failed in public view. The Business Transformation World Summit published four such cases in its Failure First content bundle, each disclosed by the leader who lived it. In each, the presenter locates the failure in people, ownership or authority rather than in the solution itself. The account of each case below is the presenter’s. The five-layer reading after it is ours, not theirs.
Dentsu: the Identity Violation
Kartick Kalaimani, Vice President at Dentsu, describes “a global initiative to streamline project operations and financial reporting across multiple markets”. The goal was to move from fragmented, Excel-based local processes to an integrated enterprise platform. The team developed a global process blueprint and launched a phased rollout across finance, delivery and operations. Each market, he notes, “worked differently, with its own tools, KPIs, and reporting cycles.”
Within months of launch, adoption stalled: teams started creating workarounds, and confidence in the new system dipped. Local teams felt the change was being “done to them” rather than “done with them”, and limited two-way communication produced what he calls “silent resistance”, where people did not object but did not adopt either. A later finance transformation took a different approach, and adoption exceeded 90% within the first year. His summary: “Transformation fails when it’s tech-led, but it thrives when it is trust-led.”
Our reading. The programme addressed Layer 1 (the platform) and Layer 2 (the global blueprint). The local Excel processes were not simply deficiencies: they were Layer 3 adaptations to each market’s way of working, and they carried Layer 4 judgement about how that market ran. A programme that treats them as waste displaces knowledge it has not captured, and “silent resistance” is what defending that knowledge looks like. The technology did not change between the two programmes; what changed was how the people who held Layers 3 and 4 were brought in.
Archetype: Identity Violation — a transformation that displaces Layer 3 and 4 knowledge without recognising it as part of how the organisation works.
The Champion Trap: an operational excellence programme
Iván Céspedes, a continuous-improvement expert at Roche, describes a programme at a previous employer: “a billion-dollar company that I previously worked for, which had several manufacturing plants and operations across multiple countries, employing over 4,500 people in the region.” He designed and deployed an operational excellence programme built on a balanced scorecard, process improvement and Lean Six Sigma capability building. Over several years it produced “tens of millions of dollars in savings” and certified “over 150 Yellow and Green Belts”.
It did not last. In his account the effort “lacked proper change management” and was not intentional about developing the required behaviours and habits. “Consequently, once the program leader (me) left the company due to personal reasons, the program disintegrated, and the team was disbanded.” The first lesson he draws is behavioural clarity: defining the expected behaviours at every level of the organisation.
Our reading. By every Layer 1 and 2 measure — savings, certifications, projects completed — the programme succeeded. What it never did was move the Layer 4 judgement that ran it (how to sequence improvement, how to work with resistant functions, what good behaviour looks like) out of its leader and into the organisation. When the leader left, that judgement left with him. Output metrics can all read green while the capability that produced them lives in one person.
Archetype: Champion Trap — a programme that produces results through one person’s Layer 4 judgement and never transfers it.
The Sovereignty Violation: a global IT support model
Mike Jefferson, now VP and Head of Business Operations for Technology at Volvo Group, describes a case “from my management consultancy days”. The customer, “a global food producer with over 300,000 employees across 50+ operating companies”, set out to replace its fragmented local IT support with one global model: a central service desk, standardised onsite support and new models for smaller locations. “The contract for this transformation was signed centrally.”
The local CIOs of each operating company had not been involved in the contract and were now asked to give up support models they had designed and controlled. Bypassing them created distrust, resentment and outright pushback; the rollout had to be paused and restructured. “A modular, franchised deployment model was introduced”, giving each operating company a controlled level of flexibility over how and when it adopted each component, while the core structure stayed the same. His lesson: “Buy-in can’t be assumed just because something is centrally approved.”
Our reading. The programme addressed Layer 1 comprehensively. The CIOs’ local models were years of Layer 3 and 4 work — adaptations to local requirements and judgement about what worked in their context — and none of it was captured or negotiated; it was overridden. The franchised model succeeded because it restored decision rights at Layer 4 while keeping the standard at Layer 1. The remedy was architectural, not motivational.
Archetype: Sovereignty Violation — a transformation that centralises Layer 1 in a federated organisation without negotiating Layer 4 decision rights.
The Leadership Vacuum: an innovation programme that stalled
Gerald F. Lackey, now Commissioner of the Virginia Department of Motor Vehicles, describes work from about fifteen years ago as an external adviser to a West Coast company that specialised in digital transcription. The company needed to move from incremental updates to bolder strategic bets, and his team set out to assess its innovation system. Executives asked for more data, more interviews and more analysis, but did not move toward decisions. The CEO “rarely attended the briefings he had requested”, and the team “settled into a routine of weekly reviews that produced no real movement.” The work was paused: “In reality, it had failed.”
Years later, leading the Virginia DMV, he took the opposite position: “I owned the transformation, I showed up, and I made it safe for others to do the same.” His conclusion: “you cannot outsource ownership.”
Our reading. Layer 1 and 2 analysis was plentiful. Layer 4 — the executive judgement needed to commit to a direction, accept risk and force trade-offs — was vacant, because the person who held that authority was absent. Analysis continued because nothing required a decision. The same adviser, later in a position that held Layer 4 authority, produced the opposite result. The variable was not capability; it was whether Layer 4 was occupied.
Archetype: Leadership Vacuum — a transformation in which Layer 1 and 2 analysis continues because Layer 4 decision authority is absent.
Five archetypes
The four cases give four archetypes. The model predicts a fifth, which none of these cases shows: Governance Theatre, where governance structures exist without Layer 4 authority behind them.
| Archetype | What happens | Layer failure | Signal |
|---|---|---|---|
| Identity Violation | Layer 3–4 knowledge is displaced and treated as waste | Layers 3–4 ignored | Silent resistance; workarounds recreated |
| Champion Trap | Results come through one person’s judgement, never transferred | Layer 4 concentrated | The programme collapses when that person leaves |
| Sovereignty Violation | A central Layer 1 model is imposed on federated Layer 4 owners | Layer 4 overridden | Immediate, structural resistance |
| Leadership Vacuum | Layer 1–2 analysis continues with no Layer 4 decisions | Layer 4 absent | Analysis paralysis; comfortable reviews |
| Governance Theatre (predicted) | Governance structures exist without Layer 4 authority | Layer 4 performative | Meetings without decisions; escalation without resolution |
In all four cases, on our reading, the systems and procedures were not where the programme failed. The failure sat at Layers 3 and 4 — the layers a standard transformation programme does not scope.
8. The articulation method: discovery from Layer 4 down
The earlier sections define what exists at each layer and how to classify it. This section defines how to find it.
Start at Layer 4 and work down
The industry default — start at the system and work up — tends to leave Layers 3 and 4 invisible. The articulation method reverses the direction. It starts where the knowledge lives and works down to where the systems sit.
When an organisation adopts standard processes, the activities that carry its Signature capabilities are pushed into workarounds (Layer 3) and undocumented judgement (Layer 4). Agentic AI makes automating a workaround far cheaper than custom development once was — but agents cannot automate what has not been articulated. Articulation has to start where the unarticulated knowledge lives, at Layer 4.
Classification rule. As each finding surfaces, tag it Core, Context or Signature. The tag decides what happens next: standardise (Context), automate (Core), protect and codify (Signature).
Layer 4: Managerial Judgment
What to look for. Decisions made regularly but never documented; overrides of standard process; judgement calls that depend on experience; institutional memory that would be lost if a key person left.
| # | Question | What it surfaces |
|---|---|---|
| 4.1 | “When the system tells you one thing but your experience tells you another, what do you do?” | Override patterns, trust boundaries |
| 4.2 | “If [key person] left tomorrow, what decisions would nobody know how to make?” | Single points of failure |
| 4.3 | “What do you check before signing off on [critical process]? Not the procedure — what do you actually look at?” | Judgement criteria held in heads |
| 4.4 | “When did you last approve an exception to standard process? Walk me through your reasoning.” | Exception logic, risk assessment |
| 4.5 | “What information do you wish you had when making [decision X] that the system does not give you?” | Data gaps that force judgement |
| 4.6 | “Which of your team’s decisions have the biggest financial impact but the least documentation?” | High-value undocumented judgement |
| 4.7 | “What patterns do you recognise from experience that a new person would miss for two years?” | Tacit pattern recognition |
| 4.8 | “If you could teach an AI assistant to handle one recurring decision, which one would free the most time?” | Automation candidates |
Question 4.2 tends to surface the highest-value, least-documented judgement in a function.
Method. Agent-guided conversation; judgement cannot be captured in multiple-choice forms. Output. A decision inventory: decisions, decision-makers, criteria (stated and actual), frequency, financial impact, documentation state, each tagged Core, Context or Signature.
Layer 3: Contextual Workarounds
What to look for. Spreadsheets that supplement or replace system function; manual data transfers; reconciliations outside official procedures; shadow IT; custom mechanisms inside the system whose rationale nobody can state; “the way we actually do it”.
| # | Question | What it surfaces |
|---|---|---|
| 3.1 | “What spreadsheets does your team maintain that feed into or correct system data?” | Shadow data, system gaps |
| 3.2 | “Where do you download data from one system to upload it into another?” | Integration gaps, manual bridges |
| 3.3 | “What reconciliations does your team perform outside the official close procedure?” | Undocumented reconciliation |
| 3.4 | “Which processes take significantly longer than they should because the system was not designed for your reality?” | Friction between standard and actual |
| 3.5 | “What tools has your team adopted that IT did not provide?” | Shadow IT, unmet needs |
| 3.6 | “Walk me through what happens when [standard process X] does not cover a real situation.” | Exception handling, workaround triggers |
| 3.7 | “If I followed one of your team for a full day, what would I see that is not in any procedure manual?” | Actual versus documented practice |
Method. Agent-guided conversation to identify categories, structured follow-up to capture specifics, spreadsheet and configuration audits to validate. Output. A workaround register: trigger, method, frequency, time cost, owner, dependencies, risk, each tagged.
Layer 2: Standard Operating Procedures
| # | Question | What it surfaces |
|---|---|---|
| 2.1 | “When were your procedures last reviewed against what people actually do?” | Documentation currency |
| 2.2 | “Which procedures do new joiners find most confusing or incomplete?” | Onboarding gaps |
| 2.3 | “Are there processes your team follows with no written procedure?” | Documentation gaps |
| 2.4 | “Which procedures do people routinely work around, and why?” | Procedure–reality gaps |
| 2.5 | “How are exceptions handled when the procedure does not cover the situation?” | Escalation paths, Layer 4 triggers |
| 2.6 | “If you had to hand over your operation next month, what would you need to write from scratch?” | Missing documentation |
Method. Document audit and gap analysis; process mining shows where behaviour departs from procedure. Output. A procedure coverage map; gaps feed the workaround register or the decision inventory.
Layer 1: Standard Software Process
| # | Question | What it surfaces |
|---|---|---|
| 1.1 | “Which system configurations do users complain about most?” | Pain points, workaround triggers |
| 1.2 | “What data do you not trust in the system, and what do you do instead?” | Data-quality gaps |
| 1.3 | “Which integrations need manual intervention to keep working?” | Integration gaps |
| 1.4 | “What system functionality do you pay for but not use?” | Implementation gaps |
| 1.5 | “What has changed in the business since implementation that the system does not reflect?” | Configuration drift |
| 1.6 | “Which system reports do people not trust, and what do they use instead?” | Reporting gaps (a Layer 3 signal) |
Method. System scan and configuration review. By the time discovery reaches Layer 1, the findings from Layers 4 and 3 give context: a configuration that looks correct in isolation may be the root cause of a Signature workaround found at Layer 3. Output. A system fitness assessment, cross-referenced against the workaround register.
Adapting to the starting point
| Entry condition | Emphasis | Opening question |
|---|---|---|
| Greenfield (buying new systems) | Layer 4 — capture judgement before it is buried | “What decisions drive your business?” |
| System unfit (heavy workarounds) | Layer 3 — the workarounds are the operating model | “Show me the spreadsheets.” |
| AI-first | Layers 4 and 3 — find automation candidates | “What decisions consume the most time?” |
| After fit-to-standard | Layers 3 and 4 — fit-to-standard created the problem | “What changed after go-live that nobody planned for?” |
This is not an exhaustive mapping exercise. Start with the two or three processes that embody competitive strategy, follow the constraint, and expand from findings rather than from a predetermined scope.
Read first, then confirm
Activity-based costing offers the lesson. Attempts in the 1990s to capture indirect activity through surveys and interviews largely failed: people could not accurately describe how they spent their time, and many resisted. Time-driven activity-based costing succeeded by reading the transaction data and deriving the activity through business rules and time equations.
Layer 3 and 4 discovery has the same problem. People cannot fully articulate tacit knowledge — that is why it is tacit — and they may resist articulating judgement that gives them standing. So read first, then confirm. Use system logs, exception reports, escalation patterns, spreadsheet analysis and process mining to infer what people actually do; then use conversation not to discover from scratch but to validate and enrich what the data shows. Process mining and spreadsheet audits find the workarounds; conversation finds the why. Decision logs show that decisions are made; conversation captures the reasoning. Where read data is not yet available, specific, evidence-based questions still let people articulate what a blank prompt would not.
Conversation, not questionnaire
Layer 3 and 4 knowledge resists static questionnaires. A finance director who overrides the forecast every quarter does not think of it as a “judgement call”. A questionnaire gets “sometimes”; a conversation gets the reasoning, the data sources, the criteria and the triggers.
| Aspect | Static questionnaire | Agent-guided conversation |
|---|---|---|
| Best for | Layers 1–2 (structured) | Layers 3–4 (judgement-laden) |
| Follow-up | None | Immediate, adaptive |
| Captures reasoning | Rarely | By design |
| Scales | Easily | Less easily |
Design for transition states, not end states
An end-state design assumes you can define the destination before you understand the starting point. Layers 3 and 4 are not understood at the start; each pass reveals more, so the target has to evolve.
| Version | Contents |
|---|---|
| v0.1 | First Layer 4 conversations — the first decision inventory |
| v0.5 | Layer 4 complete, Layer 3 under way — the workaround register forming |
| v1.0 | Layers 4 and 3 complete — the full picture below the line, Signature identified |
| v1.1 | Layer 2 audit complete — procedure gaps cross-referenced |
| v1.2 | Layer 1 review complete — system fitness read in the light of Layers 4 and 3 |
| v2.0 | First transformation cycle complete — agents deployed |
Like a product’s first release, it ships, it works, and every later version builds on it. There is no final version. Each snapshot of articulated knowledge is worth more than the last because it builds on everything before it.
9. The ambidextrous dimension
Ambidextrous leadership theory (O’Reilly and Tushman) holds that organisations must exploit what they have while exploring what they need. Read across the five layers, the balance shifts:
| Layer | Dominant mode | Operating logic |
|---|---|---|
| L1: Standard Software Process | Exploit | Standardise, optimise |
| L2: Standard Operating Procedures | Exploit | Follow the process, improve incrementally |
| — the Blind Spot Line — | — mode shift — | Below here requires both |
| L3: Contextual Workarounds | Explore, then exploit | You cannot optimise work you have not surfaced |
| L4: Managerial Judgment | Explore and exploit at once | Where ambidextrous leadership lives |
| L5: Agentic Potential | Mainly explore | The future operating model |
The simultaneity principle — that exploit and explore operate at every layer at once, in different ratios — is the core point. The frozen middle is Layer 4 stuck in exploit mode: managers default to exploitation because their judgement has never been articulated, so it cannot be governed, so it falls back to the lowest-risk mode.
Validating across layers
Any claim about a layer should be checkable from three points: the layer itself, the layer above it (what it serves) and the layer below it (what it depends on). Two traversals keep a design honest. Working upward asks: given what we have at each layer, what can we achieve? Working downward asks: given where we need to be, what must each layer provide? — what judgement Layer 4 must deliver, what Layer 3 must surface and disposition, what procedures Layer 2 must hold, what Layer 1 must be configured to enforce, and what orchestration and delegated authority Layer 5 requires.
Finding the constraint layer
At any point in the articulation work, one layer is the binding constraint, and the Five Focusing Steps of the Theory of Constraints apply:
- Identify the constraint layer — whose limitation governs transformation throughput?
- Exploit it — get the most from it without adding resources.
- Subordinate the other layers to it.
- Elevate it — invest to expand its capacity.
- Repeat when the constraint moves.
Early on, the constraint is usually at Layers 3 and 4: the organisation cannot see its current reality. As articulation deepens it may move to Layer 1 (system fitness) or back to Layer 4 (alignment among decision-makers). Where the constraint sits tells you what to work on next.
10. Where the model sits in the O2O method
The Five-Layer Model is the diagnostic; O2O is the method. Its first nine steps — the Strategy tile — are not a planning exercise so much as an articulation exercise: each step forces a different part of the organisation’s operating reality into explicit form.
The nine steps fall into three groups, each led by a different architecture and approaching the layers from a different direction:
| Steps | Architecture | Discovery direction | Layer focus |
|---|---|---|---|
| 1–3 (business) | Business architecture | Top-down: Layer 4 to Layer 3 | Starts where knowledge lives; surfaces the unarticulated |
| 4–6 (platform) | Enterprise architecture | Bottom-up: Layer 1 to Layer 3 | Starts at the system; maps upward to where workarounds form |
| 7–9 (initiative) | Change architecture | Full stack: Layers 1 to 5 | Plans the transition across all layers at once |
Business architecture discovers below the line; enterprise architecture designs above it; change architecture bridges both. The order matters. Steps 1 to 3 do not begin with “what system do you want?” (Layer 1) but with “what is actually happening in your business?” (Layer 4), so that by Step 4 the platform work has Layer 3 and 4 context. Starting with the platform means designing systems for a reality nobody has looked at.
Step by step
| Step | Primary layers | What gets articulated | Constraint check |
|---|---|---|---|
| Step 1 — Business Context | L3, L4 | The operating environment as it actually is | “Can we see our current reality clearly enough to act?” |
| Step 2 — Business Goals | L4, L5 | Strategic intent, with decision-makers aligned | “Is the constraint strategic clarity or absorption capacity?” |
| Step 3 — Business Change | L3, L4 | The change narrative and who is committed to it | “Is the binding constraint commitment or capability?” |
| Step 4 — Platform Change Strategy | L1, L2 | The platform response to the Layer 3–4 reality | “Is the constraint system fitness or organisational readiness?” |
| Step 5 — Platform Update Strategy | L1, L2, L3 | The platform estate, with workarounds in view | “Does the platform choice address the constraining layer?” |
| Step 6 — Platform Decision Strategy | L1, L4 | The commitment decision and how it is governed | “Is the constraint the platform choice or the ability to execute?” |
| Step 7 — Initiative Alignment | All | Alignment across the initiative portfolio | “Which layer is the portfolio bottleneck?” |
| Step 8 — Initiative Structure | L1, L2, L5 | Delivery architecture, including agent roles and their delegated authority | “Is the constraint the architecture or the team?” |
| Step 9 — Initiative Planning | All | An execution plan with layer-aware milestones | “Is the identified constraint reflected in the plan?” |
Discovery before response; below the line before above it.
The completeness check
After Step 9, check that all five layers were addressed:
| Layer | Steps 1–3 | Steps 4–6 | Steps 7–9 |
|---|---|---|---|
| L1: Standard Software Process | — | Primary | Secondary |
| L2: Standard Operating Procedures | — | Primary | Primary |
| L3: Contextual Workarounds | Primary | Primary | Primary |
| L4: Managerial Judgment | Primary | Primary | Primary |
| L5: Agentic Potential | Secondary | — | Primary |
Gap rules. If Layer 3 was not surfaced in Steps 1 to 3, it will not appear in Steps 4 to 9. If Layer 4 patterns were not mapped in Steps 1 to 3, they cannot be designed for in Steps 4 to 6. If Layer 5 — both the orchestration and the authority to delegate — was not scoped in Steps 7 to 9, execution defaults to human-only delivery.
11. Putting it to work
The human/AI share by layer
The articulation work changes how much of each layer’s cognitive load AI carries. The columns below are a ratio of AI to human share, not a maturity score: maturity is a different measure, of how well an organisation cycles through change. And at every ratio, the same rule holds at Layer 5 — agents orchestrate; the authority to let them act is delegated by people and answered for by people.
| Layer | 0/100 (all human) | 20/80 | 50/50 | 80/20 |
|---|---|---|---|---|
| L1 | System-assisted | Agents handle routine transactions | Agents handle all standard transactions | Fully delegated |
| L2 | People follow procedures | Agents follow documented procedures | Agents handle procedures and known exceptions | Agent-driven; people take novel exceptions |
| L3 | All workarounds manual | Key workarounds identified | Priority workarounds automated | Most workarounds resolved or agent-managed |
| L4 | All human judgement | Judgement patterns surfaced | Decision-support agents active | Agents advise; people decide, at least on Signature |
| L5 | Orchestration not built; delegation unwritten | Orchestration scoped; delegations named | First orchestration agents running under explicit delegation | Orchestration across layers, under authority people hold and answer for |
Full automation (100/0) is not on the table: Layer 4 judgement, and the Layer 5 authority to delegate, stay with people. At 80/20, the human share concentrates at Layer 4 (judgement, decisions, exceptions) and Layer 5 (delegating authority, setting the architecture, answering for what agents do).
Setting the order of work: the Cognitive P&L
The Cognitive P&L scores each activity on four dimensions to set the order of work:
| Dimension | What it measures | How it sets priority |
|---|---|---|
| Cost of current human effort | Time, salary, opportunity cost | Higher cost, higher priority |
| Value of the output | Revenue impact, decision quality, risk reduction | Higher value: protect and augment, don’t just automate |
| Risk if an agent gets it wrong | Financial, regulatory, reputational exposure | Higher risk: a person in the loop |
| Ease of articulation | How describable the work is today | Easier: faster to deploy; harder: higher long-term value |
Applied after discovery has produced the registers, it decides what is delegated (Layers 1–2), what is augmented (Layers 3–4), what stays human (Layer 4 judgement), and what is orchestrated under delegated authority (Layer 5).
12. Boundary conditions
The model does not apply uniformly. Four conditions reduce its usefulness or change its emphasis.
Digital-native organisations. Firms built in the cloud and agent era, with codified practice from the start, often have small Layer 3 and 4 surfaces by design. The diagnosis still applies but returns different proportions: less of the operation depends on unarticulated work, so the share of value below the line would be expected to be much smaller. Such firms tend to need more Layer 5 design and less Layer 3–4 articulation.
Highly codified industries. In commercial aviation, nuclear power, pharmaceutical manufacturing and clinical medicine, regulation and safety have already forced much of Layers 3 and 4 into articulated form. The model still diagnoses usefully, but the gains from articulation are smaller.
Very small organisations. The model describes organisational capability, where tacit knowledge is spread across people. In a firm of one, or of fewer than five, all layers are effectively held by the same person and the articulation work becomes personal. Simpler frameworks serve better at that scale.
Firms in active crisis. In a liquidity event, regulatory investigation or catastrophic system failure, the model’s horizon is too long to help. Crisis management comes first; the model is for organisations stable enough to plan deliberate change.
None of these invalidates the model; they calibrate it. The test is one question: does the organisation have significant unarticulated Layer 3–4 work whose value would be captured by making it explicit? If yes, the model applies.
Who benefits from articulation
The model is operationally neutral; its consequences for people are not. When Layer 3 and 4 work is articulated, knowledge held by experienced practitioners becomes organisational property — capturable, transferable and in principle automatable. That is a transfer of value, and who benefits is a governance question, not a technical one. In the classic re-engineering failure, articulation benefited the organisation and disadvantaged the people whose knowledge was extracted.
Core, Context and Signature help here too. Articulating Context has limited consequences for individuals; commodity work was never anyone’s competitive asset. Articulating Core usually leaves practitioners with augmented rather than replaced roles. Articulating Signature is where the question sharpens, because the judgement that is a practitioner’s competitive asset becomes the organisation’s once written down. Compensation, career path, participation in the articulation and recognition in any later use belong on the table at the start, not afterwards. So does the apprenticeship path: automating entry-level Layer 1 and 2 work removes the way juniors have historically acquired tacit knowledge, and a firm that articulates, automates and does not redesign that path is trading long-term capability for short-term value.
13. Academic grounding
The Five-Layer Model is not offered as a new theory. It is an operational synthesis that stands on a substantial academic and practitioner literature.
Tacit knowledge. Michael Polanyi’s The Tacit Dimension (1966) distinguished knowledge that can be articulated from knowledge that cannot — “we can know more than we can tell”. David Autor’s Polanyi’s Paradox and the Shape of Employment Growth (NBER, 2014) showed that work depending on tacit knowledge resisted automation because it resisted specification. The model applies Polanyi’s distinction across organisational work: Layers 1 and 2 are describable and therefore automatable; Layers 3 and 4 need articulation first. Nonaka and Takeuchi’s SECI model of knowledge conversion (The Knowledge-Creating Company, 1995) is the closest prior framework to the discovery protocol in Section 8. Zollo and Winter (2002) established knowledge articulation as a learning mechanism; this model treats its absence at organisational scale as a root cause of AI value failure. Argyris and Schön’s distinction between espoused theory and theory-in-use is a direct ancestor of the Layer 2 / Layer 3 distinction. Lippman and Rumelt’s Uncertain Imitability (1982) identified causal ambiguity — a form of unarticulated capability — as a reason competitive advantage persists.
Institutional theory. DiMaggio and Powell’s The Iron Cage Revisited (1983) explains why organisations adopt practices under pressure that is not strictly economic. Their coercive, mimetic and normative mechanisms predict adoption regardless of demonstrated value: boards adopt AI because other boards do, because analysts and regulators press for it, and because professional networks normalise it. Isomorphic pressure explains the 88%; the articulation gap explains the 6%. The two accounts are complementary.
Technology and productivity. Erik Brynjolfsson’s The Productivity Paradox of Information Technology (1993) established that IT investment yields productivity gains only with accompanying organisational change. Alfred Chandler’s The Visible Hand (1977) showed management structures emerging from technology revolutions. Carlota Perez’s Technological Revolutions and Financial Capital (2002) distinguished the installation phase of a technology revolution from the deployment phase of organisational absorption. On this reading the agentic moment is still in installation: AI is everywhere, but the organisational form that captures its value has not yet arrived — consistent with McKinsey’s AI Is Everywhere, the Agentic Organization Isn’t Yet (April 2026) and with the NBER working paper The Coasean Singularity (Shahidi, Rusak, Manning, Fradkin and Horton, 2025).
Re-engineering as a cautionary precedent. Hammer and Champy’s Reengineering the Corporation (1993) was a genuine attempt to redesign processes at enterprise scale, and many programmes run under it fell short in execution. It identified the right problem and the right vocabulary; its weakness was the assumption that the work could be specified top-down rather than articulated by the people doing it. The model takes the lesson structurally: articulation starts where the knowledge lives (Layer 4), not where the specifications live (Layers 1–2).
14. Attribution
The Five-Layer Activity Model — its five layers, the Blind Spot Line, the technology and agent mapping, and the Layer 4-to-Layer 1 articulation method — is BusinessGPS work, developed from business process outsourcing practice, the articulation-gap thesis and Moore’s Core/Context framework. Signature, as a third category beside Moore’s Core and Context, is BusinessGPS work. The articulation gap is Daniel Miessler’s framing; its application to enterprise transformation is ours. The ambidextrous dimension draws on O’Reilly and Tushman’s ambidextrous leadership theory. Delegation, augmentation and orchestration as AI patterns draw on Ignacio de Gregorio’s compression, extension and delegation framing. The five failure archetypes are diagnostic categories of our own.
References
Tacit knowledge and organisational learning
- Polanyi, Michael. (1966). The Tacit Dimension. University of Chicago Press.
- Autor, David H. (2014). Polanyi’s Paradox and the Shape of Employment Growth. NBER Working Paper 20485.
- Nonaka, Ikujiro and Takeuchi, Hirotaka. (1995). The Knowledge-Creating Company. Oxford University Press.
- Zollo, Maurizio and Winter, Sidney G. (2002). Deliberate Learning and the Evolution of Dynamic Capabilities. Organization Science, 13(3): 339–351.
- Argyris, Chris and Schön, Donald. (1974). Theory in Practice: Increasing Professional Effectiveness. Jossey-Bass.
- Lippman, Steven A. and Rumelt, Richard P. (1982). Uncertain Imitability: An Analysis of Interfirm Differences in Efficiency under Competition. Bell Journal of Economics, 13(2): 418–438.
Institutional theory
- DiMaggio, Paul J. and Powell, Walter W. (1983). The Iron Cage Revisited: Institutional Isomorphism and Collective Rationality in Organizational Fields. American Sociological Review, 48(2): 147–160.
Technology, productivity and capability classification
- Moore, Geoffrey A. (2005). Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution. Portfolio.
- Brynjolfsson, Erik. (1993). The Productivity Paradox of Information Technology. Communications of the ACM, 36(12): 66–77.
- Chandler, Alfred D. (1977). The Visible Hand: The Managerial Revolution in American Business. Harvard University Press.
- Perez, Carlota. (2002). Technological Revolutions and Financial Capital. Edward Elgar.
- Hammer, Michael and Champy, James. (1993). Reengineering the Corporation. HarperBusiness.
- Goldratt, Eliyahu M. (1990). What Is This Thing Called Theory of Constraints and How Should It Be Implemented? North River Press.
The AI era
- McKinsey. (November 2025). The state of AI in 2025: Agents, innovation, and transformation.
- McKinsey QuantumBlack. (April 2026). AI Is Everywhere, the Agentic Organization Isn’t Yet.
- Shahidi, K., Rusak, G., Manning, B., Fradkin, A. and Horton, J. (2025). The Coasean Singularity? Demand, Supply, and Market Design with AI Agents. NBER Working Paper.
Practitioner sources
- The Secret CFO. (March 2026). Tech Debt, four-part series.
- Miessler, Daniel. (2025–26). The Articulation Gap; Capability Stack. Unsupervised Learning.
- de Gregorio, Ignacio. (2025–26). Writing on compression, extension and delegation.
- Blundin, Dave, on Moonshots (Diamandis), episode 242, recorded 23 March 2026.
Cases
- Business Transformation World Summit. Failure First: Four Transformation Failures That Will Change How You Lead (content bundle; Process Excellence Network; accessed 2026). https://www.processexcellencenetwork.com/events-business-transformation-world-summit
Version index and changelog
- v3.2 (19 October 2026): Layer 5 named as published, with its authority face; the paper narrowed to the model, its method, its grounding and four public cases; before publication, the summary table’s Layer 3 and Layer 4 entries scoped to standard delivery, as the body states them, and the companion paper cited at the version being published (v0.4); the capabilities subsection set out as four views (value streams, capabilities, processes, activities), with capability and process related many-to-many and neither a decomposition of the other, and a process able to be Signature in its own right.
- v2.3 (21 May 2026) published.
From BusinessGPS source R&D.