Three layers, one asset

Three layers, one asset

The story about agents replacing SaaS is mostly wrong. The more accurate story is quieter, more structural, and more useful to anyone shipping production systems right now.
SaaS, as a contract and a deployment shape, persists. What changes is the stack sitting underneath the workflows users actually care about. The diagram looks like this:
Agent-Layer -> Business Graph -> Systems of Record

Three concrete examples, each running a real domain end-to-end:
1. Revenue Agent -> CRM Database

2. Finance Agent -> Accounting Database

3. Operations Agent -> Projekt Database

The database survives. The interface evolves. The question worth investing in is the middle layer.

What each layer actually does

Systems of Record

are the durable surfaces. Customer rows, invoice lines, ticket histories, project state. They have gravity, audit history, and schema relationships that other tools depend on. They do not disappear because a new interface paradigm arrives. They become more important, not less, because the layer above them treats their structure as truth.

The Business Graph

is the harder piece. It encodes the semantic interpretation that says: the customer in the CRM, the customer on the invoice, and the customer in the support ticket are the same entity at three different lifecycle stages. Without this interpretation, agents reasoning over raw databases produce shallow results. They can answer "what is in this system?". They cannot answer "what should we do about this account?". The Business Graph is where domain knowledge lives — entity resolution, process maps, organizational vocabulary, the accumulated context of how this specific business operates.

The Agent Layer

is the surface customers and operators touch. Narrow agents, each with one deliverable shape, each reading and writing through the Business Graph rather than directly against raw schemas. The interface becomes conversational + generative where it helps, structured where it must, and stays out of the way where neither serves the user.

What this means for what you build

Three structural consequences that change near-term engineering priorities.

1. Frontend investment shifts from form construction to agent-readable schema discipline

A hand-crafted CRM screen for a niche workflow ages fast when an agent can render the same workflow conversationally over the underlying data. The durable asset is no longer the UI component library. It is the schema clarity, naming consistency, and entity-relationship documentation that let the Business Graph map raw tables into normalized concepts an agent can reason about. Engineering effort relocates accordingly.

2. Write-back infrastructure becomes a first-class concern

Reading systems of record is the easy half. Writing to them — updating pipeline stage, advancing contract status, logging a customer outcome — requires real discipline: per-write audit trails, schema validation at the boundary, operator approval for high-stakes changes, undo and rollback semantics. The three-layer diagram makes this look like a passing arrow. In code it is its own infrastructure tier, comparable in weight to the agents above it.

3. The middle layer is where competitive advantage compounds

Two organizations using the same agent framework and the same systems of record will diverge based on the quality of their Business Graphs. The graph captures how this specific business defines a customer, what its actual sales process looks like versus what its documented process claims, which signals predict churn here, which integrations matter. That accumulated context cannot be bought off the shelf. It is the asset that grows with use.

A note on positioning

Vendors selling "AI for X" with no view on the middle layer are selling a thin top. The interesting questions are downstream: how does the agent know what your business knows? How does the write-back survive an incorrect inference? How does the graph stay consistent across the systems it spans?
These are not exotic questions. They are the same data-modeling, integrity, and audit questions that defined good systems engineering before agents existed. They show up in new form, sitting between two layers most diagrams treat as edges.
The database survives. The interface changes. The graph in between is what you build.