The four-layer model for an accountable system of work

Most platform problems are misdiagnosed because they are described at the layer where they surfaced rather than the layer where they started. A migration that stalls on user mapping is called a migration problem. An audit finding about permissions is called a governance problem. An agent that reads something it should not is called an agent problem.

They are usually the same problem, and it usually lives one or two layers down. The four-layer model is a way of naming the layer so the fix lands in the right place.

The model

Four layers, load bearing from the bottom up.

The Stack, load bearing bottom to top. L1 carries L2, L2 carries L3, L3 carries L4.

L1, identity and access. Who and what can reach the estate. Human accounts, service accounts, keys, and now agents. SSO, provisioning, least privilege, access reviews.

L2, platform and migration. What the work runs on. Instances, schemes, licensing, consolidation, and the decisions about what the system of work is supposed to be.

L3, governance and change. What makes change safe and evidence automatic. Permission architecture, change control, audit, and the reporting above it.

L4, agents and automation. What acts on your behalf. Rovo, Agents in Jira, Forge apps, connections through the Model Context Protocol, and the lifecycle and cost governance around them.

Why the order matters

The layers are not a maturity ladder. You do not finish one and move up. They are a dependency order, which means a defect at a lower layer expresses itself as a symptom at a higher one, and treating the symptom does not remove the defect.

An example that recurs across sectors. A regulated organization cannot pass its quarterly access review. The review is an L3 artifact, so the work goes to the governance team, who build a better report. The report is accurate and the review still fails, because the underlying problem is that nobody can say who owns half the service accounts. That is L1. The L3 work made the failure legible without making it go away.

The same shape appears going the other way. A migration is scoped as an L2 project, the identity mapping is treated as a task inside it, and the project discovers at cutover that the mapping cannot be done cleanly because the directory has never been authoritative. The L2 timeline absorbs an L1 problem, badly, under time pressure.

The diagnostic question is therefore always the same. Not what broke, but what the thing that broke was standing on. A team that asks it early spends a fortnight on the layer below and saves a quarter on the layer above. A team that does not ends up with a very good report about a problem it cannot fix.

L1 is the layer everyone wants to skip

Identity is unglamorous, it has no launch date, and its success condition is that nothing happens. It is also the layer the other three rest on, which is why it is the one most likely to be deferred and most expensive to defer.

The numbers describe an estate that has moved faster than its identity model. There are now 109 machine identities per human in the enterprise, up from 45 to 1 two years earlier, and seventy-nine of the 109 are agents (Palo Alto Networks, 2026 Identity Security Landscape, 2,930 respondents). Ninety-two percent of security leaders say they lack full visibility into the machine identities already running in their environment (2026 CISO AI Risk Report, 235 large-enterprise leaders).

Nine in ten organizations had a successful identity-related breach in the last twelve months (Palo Alto Networks, 2026 Identity Security Landscape). Identity is the attack surface now, and it is also the layer that decides whether the other three can be governed at all.

L2 is where accumulation becomes visible

Most estates were not designed. A team picked a tool, another team picked a different one, an acquisition brought a third, and joining them fell to whoever noticed first. Data Center instances that were meant to be temporary became load bearing. Projects came to share a name and nothing else.

A migration or a consolidation is the moment that becomes legible, which is why it is treated as risk rather than opportunity. The instinct is to lift everything across and sort it out later, and later never arrives with a budget attached.

The L2 decision that matters is not which tool. It is whether you are willing to decide what the system of work should be before you move it. Consolidating instances into one is a different project from moving each of them on its own.

L3 is where policy becomes mechanism

Governance fails in two directions. Too little, and permissions drift, audit evidence is reconstructed by hand every cycle, and change lands in production because the person who knew the rule was on leave. Too much, and every request queues behind an approval nobody has time to give, so teams route around the system and the record stops matching what happened.

Both failures have the same root: the controls were written as policy rather than built into the platform. Only 16 percent of security leaders say they govern access to their core platforms effectively, and the rest are managing it by exception (2026 CISO AI Risk Report, 235 large-enterprise leaders).

Governance that lives in a document depends on people remembering it. Governance that lives in permission architecture, change control, and reporting depends on nothing, and it produces its own evidence as a side effect of ordinary work. That is the difference between passing an audit and being able to pass one at any time.

L4 is new, and its failure mode is not

Rovo passed five million monthly active users (Atlassian Q2 FY26 shareholder letter), which means agent capability is table stakes and governance is what differentiates. The Model Context Protocol passed 97 million monthly SDK downloads and was donated to the Linux Foundation in December 2025 (Anthropic and the Linux Foundation, December 2025), so the connective tissue is standard rather than proprietary.

What is not standard is ownership. Only 23 percent of organizations report having an identity strategy that covers agents at all, and only 18 percent of security leaders are confident their identity management can handle agent identities (Cloud Security Alliance and Strata, 2026). Eighty-one percent worry about excessive access held by non-human identities (Okta Global CISO Insights, 2026).

That is the same shape as unmanaged integrations and unmanaged accounts, arriving faster and with more autonomy. What makes it tractable is that the three layers underneath already answer most of it. An agent needs an identity, a platform to act in, and a change record. Where those exist, an agent is a governed participant. Where they do not, it is another account nobody owns.

How to use the model

When something is not working, name the layer where the symptom appeared, then ask what it rests on. If the answer is unowned, that is the real work, and doing it at the symptom layer will produce a better report about the same problem.

The corollary is more useful. Because the layers are load bearing, work at a lower layer pays at every layer above it. An identity model built properly for humans and service accounts is most of what agents need. A platform standardized once is what makes governance expressible as configuration rather than as policy. Every layer is a front door, and whichever one you come through, the other three are still holding it up.