Ask HN: Rethinking SaaS architecture for AI-native systems
I’ve been experimenting with an architecture for long-lived AI-generated applications (CRUD systems, dashboards, workflows). One pattern keeps appearing: the traditional frontend / backend / database model starts to struggle once an LLM can modify the structure of the application.
The issue isn’t first generation.
The issue is evolution of application state and schema over time.
The first version of an AI-generated app usually works. Problems appear during the second or third iteration:
* schema changes silently breaking dashboards * metrics changing meaning across versions * UI components querying incompatible datasets * the model fixing a local issue while violating global invariants
In short: the system drifts.
Most SaaS systems today look like this:
User ↓ Frontend ↓ Backend API ↓ Database
The real semantics of the system end up scattered across API handlers, migrations, background jobs, RBAC logic, UI assumptions and reporting queries. Nothing explicitly defines the meaning of the system or guarantees invariants when the schema evolves.
When an LLM can propose structural changes (entities, workflows, dashboards), a naive architecture looks like:
User ↓ LLM ↓ JSON change ↓ Apply to system
This works for demos but breaks for long-lived systems. “Valid JSON” doesn’t guarantee reference integrity, workflow invariants, permission boundaries, metric semantics or UI binding compatibility.
One approach that seems to stabilize things is separating AI reasoning from deterministic execution.
Instead of mutating the system directly, the LLM proposes an intent plan:
User ↓ LLM ↓ Intent / Plan (IR) ↓ Runtime validation ↓ Deterministic execution
The runtime decides whether the change is valid before anything is applied.
This leads to a deterministic execution layer exposing primitives such as:
Entity Relation State Transition Event Handler Query Mutation Permission
These primitives define the semantic model of the application. The runtime enforces invariants like reference resolution, schema evolution safety, RBAC boundaries and deterministic state transitions.
At that point the application stops looking like APIs and starts looking like an executable semantic graph.
Entities become nodes, relations connect them, events trigger handlers and transitions define allowed state changes. Interfaces (UI, API, LLM, agents) interact with this runtime.
An interesting consequence is that the runtime itself can remain general-purpose infrastructure while the application becomes declarative.
For example a simple CRM could be described as a semantic model:
entities: Contact, Company, Deal relations: Contact→Company, Deal→Company workflows: Deal pipeline (Lead → Qualified → Won/Lost) metrics: pipeline_value, conversion_rate permissions: role policies
The runtime interprets this model and exposes queries, dashboards and workflows.
Runtime (constant)
* semantic model (JSON / DSL) = application
This effectively turns the runtime into a programmable application platform where different SaaS products are just different semantic models running on the same execution layer.
Conceptually this behaves less like a typical backend and more like a domain-specific runtime or application kernel.
In this architecture the LLM doesn’t execute the system directly. It proposes changes to the semantic model, and the runtime validates them before execution.
Curious if others building AI-native infrastructure, agent runtimes or programmable SaaS platforms have explored similar patterns.