What comes after applications.

We are about to drown in software.

The problem is not build speed. The industry is reading the AI coding boom as a productivity story: more apps, faster, everywhere. But every AI-generated application encodes operating-model assumptions true at the moment it shipped, and every business keeps moving. What operations-heavy companies are about to drown in is not software itself. It is software that cannot keep up with them.

AI coding has collapsed the cost of building bespoke internal software. For simple cases, the marginal cost is already below the cost of configuring an existing SaaS tool. For harder cases, it crosses that threshold in the next twelve months. When it does, every operations-heavy company produces internal apps and agents at a rate nobody is staffed for. Most mid-market enterprises already run a hundred to two hundred overlapping SaaS applications. AI-generated application entropy turns that into thousands of brittle, redundant, partially-overlapping internal apps and agents, none of them coherently updatable when the business changes.

This is the door-opening problem. Every operations-heavy company will feel a version of it in the next twelve months. Most will reach for agent frameworks or AI-powered internal tooling platforms to manage it. Those are the same architectural mistake in a new form, and they will age into the same sprawl.

Organizations are thinning.

This is the less-discussed half of the AI story, and it is the one that changes everything. A finance function that used to run with thirty people now runs with eight. The ops team that had three specialists per subdomain has one generalist. Procurement is one person. This is observable, not predictive. Since 2023, major public companies have openly tied workforce reductions to AI productivity gains in their earnings calls. Labor-market data shows recovering unemployment alongside declining job openings, a combination that historically signals structural displacement, not cyclical contraction.

Thin organizations cannot function with the current software operating model. They do not have the humans to run a hundred heterogeneous applications, and they do not have the humans to absorb the coordination overhead that disappeared when the org shed its middle layer. Each remaining domain has to operate at three to five times the effective capacity of its headcount.

The old org structure absorbed that math implicitly through sheer redundancy. Thin organizations do not have the slack. This is not a market to win. It is the condition on which the 2026-2030 enterprise operates. It is the we have to solve this version of the pain, one the sprawl problem only opens the door to.

Two independent forces converge on the same architecture. One is organizational. The other is technical. The convergence is what makes the shift inevitable, and not merely possible.

The organizational force.

For twenty-five years, enterprise architects have tried to align organizations around unified operating models. TOGAF, Zachman, master-data management, canonical ontologies. All failed. Not for lack of technology, but for lack of political economy.

Every domain had its own team, its own budget, its own power center, its own reasons to resist a model imposed from above. The CFO's finance model and the CMO's customer model would never reconcile because reconciling them required one of them to concede. Enterprise-wide alignment required negotiations across stakeholders that inevitably died in committee.

Thinning changes the political economy. When a finance function goes from thirty people to eight to three to one, that single remaining person has unilateral authority to define how finance operates. The committee is gone. The politics are gone. The competing stakeholders are gone. What used to require enterprise-wide alignment now requires one person's decision. And that person, already overwhelmed by carrying a function that used to have thirty people, is desperate for leverage. They adopt a living runtime because it is the only way they can do their job at all.

What follows is emergent, not designed. Each domain leader adopts the runtime for their own function because their own function is drowning. Domain-level specifications compose into a cross-domain model because the substrate makes them composable. The enterprise-level unified operating model is an emergent property of thin organizations each adopting the runtime for local reasons. Not a top-down architecture decision that requires CEO buy-in. Not a migration anyone has to schedule.

The technical force.

For sixty years, computing has relied on a clean separation. Data was inert, code was executable, and the runtime kept them apart. Every abstraction downstream (databases, APIs, object models, service architectures) is a variation on that split. It is what made enterprise software tractable at all. It is also the assumption under which every platform, framework, and tool of the past four decades has been built.

LLMs broke it. A language model treats every prompt as executable instructions, not data; the prompt is a program the system is assembling one turn at a time. This is not a quirk of one product category. It is the architectural fact that every attempt to bolt AI onto a static runtime is working around. The consequences are still being counted. The planning requirement is the first one that matters at the scale of operating a business.

Everyone agrees we need AI that can plan. Planning is what separates a useful assistant from a system that can actually operate a business. But planning has one hard precondition: the AI must be able to execute the plan. Not approximate it. Not intend it. Execute it.

Execution requires a machine-readable language. A machine-readable language requires machine-readable state, machine-readable logic, and machine-readable actions. Applied to an entire business, that means the whole operating model has to be represented as a machine-readable, monolithic codebase. Not a collection of documents. Not a set of integrations. Code.

A codebase the size of an organization cannot be loaded in full, and most of it is irrelevant to any given task. The runtime is provisioned per workload, not per server. We call each provisioned instance a context: a dedicated environment the resident AI terraforms from the global operating source code, activating only the logic it needs to function.

The AI does the terraforming. It explores your world. It traverses the ontology, reads the live graph, and activates the logic it needs as it reaches for each new decision. As the task evolves, the terraforming continues: more of the operating model comes into scope when new questions surface, programs the AI composes just-in-time execute against it, and when the plan needs something that does not yet exist, the AI extends the context with it. Enough to reason. Not so much that the reasoning collapses under its own weight.

The context is much larger than the AI's attention. The AI holds only the part of it that it is currently reasoning about: a small working window, measured in tokens. The context itself is a symbolic graph that can run to gigabytes: state, declared actions, the policies and constraints that govern them, and the provenance trace of everything the runtime has ever executed. The AI pulls what it needs into attention as the work demands. The rest is material the AI reaches for when the work requires it: the policy that denied a plan so it can read the condition and revise, the contract of an unfamiliar action so it can invoke it correctly, the trace of an incident so it can reconstruct what went wrong. The context is a tool the AI uses selectively, not a corpus it has to hold in full.

This is the second half of the architecture. When the AI composes a program, the symbolic runtime reacts to what the program invokes. It evaluates the policies declared on each action, enforces constraints without pulling the AI into the loop, substitutes approvers when an approval fails a condition, records provenance for every step. The runtime layers determinism on top of the AI's reasoning, in places the AI does not have to track. The AI reasons about what it needs. The runtime does the rest.

Planning and execution have to be separate modes. While the AI is inside a context and still reading (traversing the ontology, building up what it needs to decide), it loops: reasoning, observing, reasoning again. That nondeterminism is appropriate. The AI is reading, not yet acting, and everything it sees is already typed and structured by the runtime. When the AI decides to act, the architecture shifts. It composes a complete program of interdependent stages and hands it to the engine to execute. No inference per step. No drift. The failure mode of most current agent systems is using one loop for both modes, so a wrong turn during exploration becomes a wrong action in the world. Separating them is the point.

# Plan: process work order WO-2026-04-0471.# Authored by the resident AI managing a facilities engagement.
CONSTRUCT {  ?workOrder  wo:status       ?finalStatus ;              wo:riskLevel    ?riskLevel ;              wo:approvedBy   ?approver ;              wo:dispatchRef  ?dispatchRef .}WHERE {  BIND(wo:WO-2026-04-0471 AS ?workOrder)
  # Step 1: external API. Fetch current details from the backend.  ?details wo:GetWorkOrder (?workOrder) .
  # Step 2: AI reasoning. Assess risk from details + site history.  ?assessment wo:AssessRisk (?workOrder) .  ?assessment wo:riskLevel ?riskLevel .
  # Step 3: human in the loop. Manager reviews and approves.  ?approval wo:RequestApproval (    ?workOrder    wo:assessment ?assessment  ) .  ?approval wo:approvedBy ?approver .
  # Step 4: external API. Dispatch the approved work order.  ?dispatch wo:DispatchWorkOrder (    ?workOrder    wo:approval ?approval    wo:priority ?riskLevel  ) .  ?dispatch wo:dispatchRef ?dispatchRef .
  BIND(wo:Dispatched AS ?finalStatus)}
# One plan. Four action types, one execution.# ▶ external system call        (wo:GetWorkOrder)# ▶ AI reasoning                (wo:AssessRisk)# ▶ human approval gate         (wo:RequestApproval)# ▶ external system call        (wo:DispatchWorkOrder)## Notice what the plan does not do. It does not coordinate# the human step. It does not branch on the risk level. It# does not retry the dispatch when a constraint fails. The# runtime dispatches each invocation to the correct handler# and enforces whatever policies are declared on the action.# The plan runs as written. Planning and execution are# separate. The plan is a script; the enforcement is# structural.

There is a cost argument here as well. Agent loops scale inference linearly with task steps: every step is a fresh call. A runtime that plans once and executes deterministically pays for inference only when the plan is composed or revised. In our own workloads, we have observed inference iterations grow logarithmically with task complexity, not linearly. We are preparing public benchmarks on token usage during normal operations.

Every other architecture (bolting an AI on top of static applications, wiring stateless LLM calls into an agent mesh, asking a chatbot to operate a business through its integrations) sidesteps the planning requirement by making the AI react instead of plan. Those architectures can automate a task. They cannot operate a business.

The organizational argument says the paradigm will land. The technical argument says this is what the architecture has to be. Both meet at operating model as code, executed inside a living runtime that AI inhabits. Everything that follows in this essay is a consequence of those two forces meeting.

Self-extension is what makes the adoption economics work.

Codification is what killed prior unified-model attempts, even when the political economy was favorable. Writing down how an organization actually works, in a form a machine can execute, used to be a multi-year consulting engagement with armies of analysts and domain experts. It cost more than the value it unlocked and drifted out of alignment with the business faster than it could be updated.

AI changes that. In a living runtime, the person running the function describes how their function operates, in their own language. The runtime writes a versioned, composable specification of the domain: its concepts, its rules, and its actions. They review it in human-readable form and govern it through conversation. Codification stops being a human-hours problem.

This is the connection between thinning and self-extension. Thinning creates the political opening; self-extension makes the opening affordable to pass through. Neither half is optional. Agent frameworks and AI-powered internal tooling platforms address the sprawl problem without a substrate that can evolve. Their output ages the same way hand-written code ages. Manual ontology projects have the substrate but not the authoring economics. Both choices fail in the paradigm that is arriving. A living runtime is the only architecture that makes both bets at once.

Underneath, a runtime of this kind needs three structural guarantees the prior failures did not have. Typed values, so bad state cannot exist. Situational access control, so unauthorized actions cannot execute. And full provenance, so every step is auditable. These are not features bolted on; they fall out of the substrate.

# Role + identity policy.
ps:ExpenseApproverRole  a  iam:Role ;  iam:hasPolicy  ps:ApproveExpensePolicy .
ps:ApproveExpensePolicy  a  iam:IdentityPolicy ;  iam:action     act:InvokeAction ;  iam:resource   ps:ApproveExpense ;  iam:effect     iam:Allow ;  iam:condition  ps:WithinAuthorityAndIndependent .
# Action + resource policy. Both sides must allow.
ps:ApproveExpense  a  act:Action ;  iam:hasPolicy  ps:ApproveExpenseResourcePolicy .
ps:ApproveExpenseResourcePolicy  a  iam:ResourcePolicy ;  iam:action  act:InvokeAction ;  iam:role    ps:ExpenseApproverRole ;  iam:effect  iam:Allow .
# The condition. Two checks, evaluated at request time# against the live graph:#   1. The approver's authority limit covers the amount.#   2. The approver is not anywhere in the requester's#      reporting chain.
ps:WithinAuthorityAndIndependent  a  iam:Condition ;  iam:scope   iam:Resource ;  iam:sparql  [ os:ask """    ASK {      ?scope      exp:amount         ?amount ;                  exp:submittedBy    ?requester .      ?principal  hr:authorityLimit  ?limit .      FILTER (?amount <= ?limit)
      FILTER NOT EXISTS {        ?requester  ( hr:reportsTo )*  ?principal .      }    }""" ] .
# Plan attempts: approve(exp:2026-04-Q2-047, hr:m-okonkwo)## ▶ resource policy  allows ps:ExpenseApproverRole.# ▶ identity policy  denied. m-okonkwo sits two levels#                    up the requester's reporting chain;#                    approval within one's own management#                    line is not permitted.## ▶ escalated. runtime finds an approver whose authority#              limit covers ?amount and who is not anywhere#              in the requester's reporting chain.#              → hr:s-marquez  ✓

What you are looking at is the kind of rule static role-based access control cannot express. Whether a principal may approve an expense depends on the live amount, the approver's current authority limit, and the relationship between principal and requester at the moment of the request. The condition is a query. The query runs against the state of the business at request time. The situation changed; the permission changed. The graph is the authority.

No plan the AI writes (the work-order script in §03, a batch of expense approvals, anything else) has to check any of this. The plan binds work and invokes actions. The runtime evaluates the policies declared on each action, substitutes eligible principals when a condition fails, records what happened, and returns. Planning is upstream. Enforcement is underneath. The script never has to know.

Every state change the runtime produces (the substituted approver, the matched amount, the invocation itself) is recorded as a typed observation with full provenance. Who did what, under which authority, at what moment, and why. Audit is not a log to grep. It is a query against the same graph the runtime executes against.

Domain-level capacity. Enterprise-level outcome.

A living runtime does not arrive as an enterprise transformation. It arrives as the system running one domain in a thin organization. Finance. Procurement. Compliance. Support. The person running that domain adopts it because they are being asked to do the work of ten without the coordination overhead the old org absorbed implicitly. They do not buy a unified enterprise model. They buy a way to operate their function with one-tenth the headcount.

Six months later, a second domain adopts the runtime for the same reason. The specifications compose because they share a substrate. At the graph level, a customer named in finance is literally the same customer named in procurement; SHACL shapes keep structural contracts honest between them. The data flows without integration projects. The handoffs work because they are not handoffs. They are traversals in a single graph.

Eighteen months later, the enterprise has effectively adopted a unified operating model. Nobody held an architecture meeting. Nobody wrote a canonical data model. The enterprise-level outcome is an emergent property of domain-level pain being solved domain by domain, each adoption strengthening the next.

This is what the next decade of enterprise software looks like. Not a better application. Not another agent framework. Not a top-down transformation project. One runtime, adopted one domain at a time, producing the unified model that twenty-five years of enterprise architecture could not produce top-down.

The semantic web did not fail. It was waiting for this.

RDF, OWL, SPARQL, and the surrounding stack have been production-grade since the mid-2000s. The standards exist. The tooling exists. Twenty-five years of a technically solved capability sitting commercially stuck is not a cautionary tale. It is what a waiting technology looks like when the implementation has not caught up and the use case has not arrived.

What it was waiting for was an implementation that could execute, not just describe, and an AI that could operate against it. Both are here. The twenty-five-year backlog of standards and tools stops being a graveyard and starts being a runway.