The Enterprise Stack for the Next 100 Years
May 26, 2026
What runs underneath when AI agents transact across the economy
Robert Koller, Founder and CEO
May 2026
Every previous wave of enterprise software ended up with a stack diagram. Networking had OSI. Data had Snowflake at the bottom and Looker on top. Cloud had IaaS, PaaS, SaaS. The diagram comes after the technology has matured enough that practitioners need to agree on what sits where.
AI is approaching that point now. Enough has happened in the past eighteen months that the industry has more or less agreed on the foundation model layer. The application layer has begun to reprice. What sits between them is still contested.
This is the version of the stack we have been building against for five years in regulated production. Six layers. None of them is the model. The model is what runs on top of the stack, the way Postgres runs on top of Linux. It matters, and it commoditizes.
Layer 1 – The substrate (what governs)
The bottom layer is the operome. Every company already has rules. They sit in contracts, policies, regulations, procedures, SOPs. The substrate is those rules, extracted from the source documents, compiled into machine-executable form, and made queryable, auditable, updatable. Nothing above this layer can run reliably without it.
In our production deployment through fDesk, the substrate consists of approximately seven thousand variables, thirty-five thousand business rules, and fifty micro-classes spanning ten functional domains: parties, instruments, interest, redemption, derivatives, commercials, operations, legal, listing, and miscellaneous. Each rule traces back to a clause in a source document. Each clause is hashable.
This is the only layer that is hard to commoditize. The rules in any given industry took decades or centuries to develop. The compilation effort is non-trivial. The maintenance is permanent. Once an operome exists for a vertical, the cost to a competitor of building a parallel one is structurally high.
Layer 2 – The runtime (what executes)
The substrate is not enough on its own. You need a runtime that can take a proposed action, evaluate it against the relevant rules, return a deterministic permit-or-deny, and emit an audit trace. This is the runtime layer.
Functionally, the runtime is what makes the substrate operable. It is the interpreter for the rule language. It handles rule conflicts, deadlocks, escalations, and human-in-the-loop checkpoints where the substrate is intentionally underdetermined. It is also where the auditor's questions get answered. Every rule trace at runtime is what "why did the system decide that" actually means in production.
We built our own runtime because nothing existing handled the substrate-rule semantics correctly. Decision tables, BPMN engines, and rule-engine products all try to be general-purpose. The substrate runtime has to be specific to the operome's structure.
A worked example. A bond redemption instruction arrives. The runtime takes it, pulls the clauses the substrate says are relevant (the redemption schedule, the notice-period rule, the jurisdiction carve-out, the counterparty's permitted-action set), evaluates the proposed action against each one, and returns a single deterministic answer: permitted, blocked, or routed to a human. Then it emits the trace. The trace names every clause that was checked and the source document each clause came from. When the auditor asks why the system allowed that redemption, the answer is not a model's explanation of its own reasoning. It is the trace. The substrate is the fuel. The runtime is the engine that burns it and leaves a record of every combustion.
Layer 3 – The notary (how counterparties prove agreement)
Two operomes meeting need a way to register that they agreed on the same state at a specific time. This is what blockchain anchoring does well, and is the layer where current debate is most active.
The case for using blockchain at this layer is structural rather than ideological. Cross-counterparty regulated transactions need timestamped, immutable, jurisdictionally-neutral proof that two parties saw the same rule state at the moment of decision. No central authority works at the cross-jurisdictional scale where this matters. Capital markets infrastructure has been searching for a real use case for blockchain settlement since 2015. Operome handshake notarization is a better one than anything that has shipped so far, because the underlying transaction is real, the value is real, and the participants are already regulated.
In practice the notary layer can be implemented in several ways. Public-chain anchoring is one. Permissioned-chain consortium notarization (similar to TradeFi's existing model) is another. Pure cryptographic timestamping with signatures and a Merkle log is a third. The choice depends on the regulator's posture and the counterparty trust assumptions in the specific vertical. The shape of the layer matters more than the technical implementation.
A worked example. A bank in Frankfurt and a counterparty in Singapore execute a cross-border transaction. Each side runs its own operome. At the moment of agreement, both substrates resolve the transaction against their own compiled rules, and the notary layer records a timestamped, hash-anchored proof that both parties saw the same rule state at the same instant. Eighteen months later a dispute arises. There is no argument about what each side knew, because the handshake was notarized at the time and neither party can revise it after the fact. The notary is the handshake that nobody can later deny. It is the layer that lets two operomes that have never met transact without a central authority sitting between them.
Layer 4 – The agents (who runs operations)
Above the substrate, runtime, and notary sits the agent layer. This is where AI does the actual work. Foundation models propose actions. The substrate-runtime evaluates them. The notary records the result. The agent moves to the next step.
In our production deployment, agents are not autonomous in the romantic sense. They are tightly bounded. Every proposed action is validated against the substrate before execution. The agent has no discretion over whether a clause applies. It has discretion only over the order in which it processes work, the human-in-the-loop escalations it triggers, and the natural-language interface it presents to its operator.
This is also where the foundation model layer plugs in. The agent layer is model-agnostic. Whichever LLM is most capable and cheapest at any given moment is what the agent uses. The substrate beneath does not care which model proposed the action, as long as the action is validated.
A worked example. An agent is processing a queue of forty securities transactions. For each one it reads the instruction, asks the runtime whether the proposed action is permitted, and either executes it, escalates it, or moves on. The agent decides the order it works the queue, when to batch, when to pull a human in. What the agent never decides is whether a clause applies. That is not its job and it has no authority over it. The agent is the operator on the floor. The substrate is the rulebook bolted to the wall. A good operator works fast and knows when to call the supervisor. A good operator does not get to rewrite the rulebook because the queue is long. That distinction, operator versus rulebook, is the whole reason a regulated institution can let an agent touch the work at all.
Layer 5 – The interfaces (how humans and systems plug in)
The interface layer is where humans encounter the substrate. Dashboards, chat interfaces, mobile apps, APIs, MCP servers, custom integrations into existing enterprise software (SAP, Workday, Salesforce, Bloomberg). Most users never touch the substrate directly. They touch the interface layer.
This layer is where the application-layer companies – Harvey, Manifest, Legora, AUI, Lio, FurtherAI – operate. They build verticalized interfaces over the substrate. Once the substrate exists openly, this layer fragments into many competitors, each optimizing for a specific user, vertical, workflow, or geographic market. The interface layer competes on UX, integration depth, and customer relationships, the same way the BI layer competes on top of Snowflake.
A worked example. The same compiled substrate, on the same day, serves four different surfaces. A relationship manager sees a chat interface and asks a question in plain language. A board sees a three-dimensional visualization of the rule graph in a presentation. A regulator receives an audit export through an API. A counterparty's own agent calls the substrate's MCP server directly, machine to machine, with no human in the loop at all. Four interfaces, one substrate underneath, each rendering the same compiled rules for a different audience. The substrate is the building. The interfaces are the windows. Cut as many windows as you like; the structural work was done once, below.
Layer 6 – The horizon (why this stack outlives technology generations)
The bottom five layers are operational. The sixth is structural.
Foundation models will change many times in the next ten years. Each generation will be more capable, cheaper, faster, and more energy-efficient than the last. The agents on top of them will inherit those improvements. The interfaces over the agents will evolve too – what feels like good UX today will feel quaint in five years.
The rules underneath will not change at the same speed. Civil law in France has been in force since 1804. The Indian Contract Act has been in force since 1872. Securities regulations evolve over decades. Healthcare compliance frameworks evolve over decades. The substrate of any regulated industry has a half-life measured in human generations, not technology cycles.
That is why the substrate is the durable layer. It outlives every model, every agent, every interface that runs on top of it. The economics of capturing the substrate are the economics of capturing infrastructure that earns rent for centuries.
One way to hold the whole stack in mind. The model is weather. It changes constantly, it is what everyone watches, and a forecast more than a few days out is worthless. The substrate is climate. It moves slowly, it is what you actually build a city around, and it is still recognizably itself a century later. Confusing the two is the central mistake of the current AI conversation. Everyone is trading the weather. The infrastructure that compounds is built on the climate.
Eventually that infrastructure has to scale beyond Earth. When commerce extends to the Moon, to Mars, to asteroid mining and lunar resource extraction, the same problem reappears in a sharper form: how do you run an orderly economy where there is no central authority to enforce the rules? The answer is the same answer that works on Earth, with one addition: the notary layer becomes the only authority. A not too distant Moon colony's insurance contracts must trace back to compiled, auditable, hash-anchored rule sets that earthside parties can verify without asking anyone for permission. The substrate plus the notary is the foundation for off-Earth commerce.
This is not a near-term claim. It is the long-term implication of building infrastructure correctly. The same pattern that makes the substrate the right answer for fDesk's bond issuance work today is what makes it the right answer for orderly commerce on the Moon in 2035. Build the substrate properly now and the system extends naturally to wherever humans take commerce next.
Why this is the right shape of the stack
Two structural arguments anchor the six-layer view.
First, layer separation matters. Most current AI infrastructure conflates layers. Foundation model labs treat the model as the product. Vertical-AI companies treat the application as the product. Both miss the substrate. When the substrate is missing or rebuilt manually inside each product, the system cannot scale across counterparties, cannot be audited consistently, and cannot survive technology generations. Separating the substrate as its own layer is what makes the architecture durable.
Second, governance follows architecture. In rule-based industries, i.e. basically any business, the auditor enforces the documents. If the substrate is the compiled documents, the auditor enforces the substrate directly, and every layer above inherits rules compliance by construction. In this context the auditor can be the regulator, the legislator, a court, even an arbitration court, a Big 4 firm or any other authority in the specific circumstances. If the substrate is empirical (a context graph that learned what people did), the auditor cannot use it. Architectural choices at the substrate layer determine what compliance with rules looks like at every layer above.
What this means for the people building above the substrate
If you are building a vertical-AI company, the practical implication is this: every month you spend rebuilding the substrate inside your own product is a month you are paying off your own future commoditization. The substrate is hard to build but harder to defend. As soon as a horizontal substrate exists, your customers will plug into it directly with their own UX, or they will pick whichever interface partner offers the best relationship and pricing.
The right play for application-layer companies is to compete on integration, customer relationship, and vertical depth – knowing that the substrate beneath them will eventually be shared infrastructure. The wrong play is to keep building substrate as if it were product, it is the future infrastructure that rule-governed enterprise work will run on for generations. Foundation Capital, Sequoia, and a16z are funding the right play. The substrate is what we are building.
LLMs will change many times in the next ten years. The business rules they need to follow will not. We encode the part that stays.
Robert Koller, Founder and CEO, SynapseLayer
rk@synapselayer.ai · synapselayer.ai