Software systems split state, execution, and policy across many services.
A frontend repository. A backend repository. A database. An auth service. A deployment pipeline. A logging system. A separate world for each agent that needs to act.
Each layer has its own model of reality. They drift. They fight. Every integration is a new source of failure and security surface.
The reader of data is also no longer only a human with a dashboard. It increasingly includes agents that need scoped context, execution limits, and an audit trail.
The thesis centers on two primitives.
A disposable, observable, killable computer that an agent can safely inhabit.
Docker made code portable. Sandboxes make code safer to run when the author is a model generating faster than any human can review.
One living database that holds data, UI, logic, policy, and history.
Not “the database for the app”. In this model, the database is the app. Schema, components, agent contracts, sandbox blueprints, permissions, and full causal history are all first-class queryable facts.
Under this thesis, frontend and backend repositories would collapse into one governed definition. The “app” would be three things:
1. A schema + policy definition in the substrate.
2. A set of sandbox templates and agent contracts attached to that schema.
3. Projections (views) that agents or humans can safely render and mutate.
New behavior would not ship as a new binary. You would evolve the schema, adjust the sandbox scopes, and let agents operating inside governed execution environments materialize the change.
“Deploy” could give way to instantiation: spawning a sandbox with a view over a slice of the living layer.
Design rules the thesis proposes, not properties of any existing system.
Speculative scenarios, not forecasts. Each sketches what the thesis could enable if its technical and governance assumptions hold.
A knowledge worker could have a personal substrate: notes, email, agents, tools, and history in one queryable, sandboxed store. “Apps” would be projections granted different execution scopes.
An organization could run a few governed living layers instead of hundreds of SaaS products. New “software” would arrive as a schema patch plus a sandbox policy bundle. Integration would be a permission grant, not an API-key dance.
Much software work could become forking, merging, and governing shared layers. The advantage would go to the best schemas and the tightest, safest sandbox contracts, not the prettiest UIs.
Three different kinds of material support this essay: my writing, a scoped data-movement prototype, and existing upstream software. None is a released implementation of the complete Living Layer.
This is a thesis to test. Can a shared substrate reduce integration cost without creating an unacceptable failure domain? Can sandbox lineage make agent actions easier to inspect and reproduce? Those questions need measured implementations.
The useful next step is a small implementation with clear boundaries,
repeatable workloads, and evidence of where the design helps or fails.