Ask HN: Rethinking SaaS architecture for AI-native systems

[RobertSerber]

Hello HN,

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.

[Gnobu]

Interesting framing around separating AI reasoning from deterministic execution. The “intent → runtime validation → execution” pattern makes a lot of sense once systems become mutable through LLMs.

One thing I’ve been thinking about while experimenting with Gnobu is how identity might fit into that runtime layer — not just for authentication but as a trust boundary for system actions. If AI systems are proposing structural changes or triggering workflows, identity and permission models might need to be deeply embedded in the execution runtime rather than scattered across services.

Curious whether you see identity and access control as primitives inside the semantic model itself, or as something the runtime enforces externally.

[RobertSerber]

Good point. In the model I'm experimenting with, identity and permissions end up being part of the runtime primitives rather than external services.

In traditional SaaS architectures identity is usually handled by separate layers (auth providers, middleware, RBAC checks in APIs). The problem is that when the system structure itself becomes mutable — entities, workflows, dashboards — those checks are no longer enough.

If an AI proposes structural changes, the runtime needs to reason about who is allowed to modify which parts of the semantic model.

So identity becomes part of the execution semantics of the system rather than just authentication.

Conceptually it looks closer to something like:

identity → permissions → allowed state transitions

instead of just:

identity → API access

This is also why the runtime primitives include things like entities, relations, transitions and permissions.

The runtime can then enforce invariants such as:

- which roles can evolve parts of the model - which workflows can trigger actions - which datasets a component can bind to

So the trust boundary ends up inside the runtime rather than in the surrounding services.

Still exploring the design space here, but it seems necessary once AI can propose structural mutations to the system.

[Gnobu]

That makes sense. Once AI can mutate structure, permissions probably need to govern model evolution itself, not just API access or workflow execution. It seems like auditability and approval for schema-level changes become runtime concerns too. Have you explored that layer yet?

[RobertSerber]

Yes — that layer is part of the runtime design. The AI never mutates structure directly. It only proposes a DSL change, which goes through a deterministic compile pipeline before it becomes canonical.

Schema evolution is treated as a runtime operation with versioning, migration logs, and a deterministic state hash (dslHash). Every compile produces a new schema version and writes a structured change plan to dsl_change_log, so structural mutations are fully auditable.

There’s also a cryptographic validation attestation step: the compiled DSL is hashed and attested so the runtime can verify that the schema being executed is exactly the one that passed the pipeline. That prevents unauthorized structural drift outside the compiler path.

Breaking changes, data compatibility, and migrations are evaluated before commit, so structural mutations are gated much like data mutations.

The stack to support this is admittedly quite complex, but most of that complexity lives in the runtime so the AI-facing interface can remain simple and safe. The big shift was treating AI as proposing structure, but never owning execution.

One thing I'm still unsure about is where the long-term governance layer should live once models can mutate system structure — inside the runtime itself, or higher up at the application/policy level. Curious how others are thinking about that boundary.

[RobertSerber]

For context, I'm experimenting with applying this architecture to a CRM system where the entire application is defined as a semantic JSON model executed by a runtime.

The LLM proposes structural changes (entities, workflows, metrics), while the runtime enforces invariants and deterministic execution.