Infrastructure — Not Applications, Models, Harnesses, or Loops — Is the Product

Your CEO vibe-coded a dashboard this morning. It's good, actually — pulls the revenue numbers, has the right chart. By Friday he has ten of them. His marketing manager made him an eleventh, as a gift.

Now answer the only question that matters: where do they go?

Not the git repo — where do they run? Behind whose login? Who sees the revenue feed they display? Which of the eleven is still getting dependency patches in six months? When the board asks whether the numbers on screen are governed data or a hallucinated join, who can answer? Every one of those dashboards took twenty minutes to create and would take a platform team a week to host responsibly — and the twenty minutes is falling to two.

Nobody asks "can we build it" anymore. Applications are exhaust. Models are rented by the token. Harnesses and agent loops are open source and multiplying. Every layer the industry keeps shipping as "the product" — the app, the model, the harness, the loop — has gone abundant. What's scarce is the thing every one of them needs the moment it exists: a safe, governed, instant place to run.

Infrastructure — not applications, models, harnesses, or loops — is the product. That's not a hosting company's cope; it's the same labor-collapse arithmetic read from the other side. This is the agentic revolution: not developer tools — infrastructure tools. The developer-tools wave made software free to create. The infrastructure wave decides whether any of it is safe to exist.

We keep re-learning this inversion at every scale. Here it is inside a single application first — a build — and then at the platform level, where it becomes Kilter's whole reason to be.

The same inversion, inside one application

ServiceNow is a multi-billion-dollar company selling what is, architecturally, a very large CRUD app with a workflow bolted on the side. The screens are the product. Every ticket type gets its own tables, its own forms, its own hand-wired business logic; SLAs run on schedulers; approvals are status columns nudged by jobs; the audit trail is whatever the application remembered to write. The bulk is not incidental. It's what happens when the UI is the thing you build and the lifecycle is an afterthought stapled to it.

Squall is an ITSM platform built on the opposite bet: the application's infrastructure layer — the workflow engine — is the product, and the UI is disposable. That single inversion — plus Kilter making it affordable — collapses the system to a fraction of the code and turns the parts you'd normally get wrong into things you structurally cannot get wrong.

The bet: Temporal is the product, not the schema

In Squall, every lifecycle is a Temporal workflow. Not "a workflow feature" — the product. An incident with its SLA timers, a change with its CAB approval and freeze windows, the approval process itself, the fulfillment step interpreter: each is a deterministic, versioned, replayable workflow.

// the approval process is a workflow anything can invoke as a child
export type ApprovalMode = 'single' | 'chain' | 'quorum';

There are no cron jobs. There are no state machines hand-rolled in application code. An SLA breach isn't a row a scheduler polls for — it's a durable timer inside a running workflow. A CAB quorum isn't a counter you increment in a handler — it's a child workflow in quorum mode with cabQuorum approvers. When the process is the workflow, the process can't drift from the code, because there is no second copy of it living in a status column somewhere.

This is the same move as putting compliance in Postgres RLS: take the thing everyone else scatters across application logic and make it a single, canonical, inspectable primitive. Here the primitive is a workflow history — which is also, for free, a perfect audit of exactly how every ticket reached its current state.

One record, one door

Underneath the workflows, the data model refuses to sprawl. Incident, request, change, problem, task — in a conventional ITSM these are five subsystems. In Squall they are one universal work_item record with a kind-specific JSONB payload, each bound to a Temporal workflow run. Approval isn't reimplemented per type; it's a generic child workflow that anything can invoke.

And there is exactly one way to mutate the world. Every domain change goes through a single function — withMutation — that makes the write, the audit event, and the outbox publish one atomic transaction:

/**
 * The one door for domain mutations: tx → work_item change → audit_event →
 * outbox. Call sites cannot write audit or outbox rows themselves, and a
 * failure anywhere rolls back all three.
 */
export async function withMutation<T>(pool: Pool, spec: MutationSpec<T>): Promise<T> {
  // ... BEGIN
  const out = await spec.run(client);            // the work_item change
  await client.query(
    `INSERT INTO audit_event (work_item_id, event_type, actor, agent_chain, payload)
     VALUES ($1, $2, $3, $4, $5) RETURNING id, occurred_at`, /* ... */);
  await client.query(
    `INSERT INTO outbox (topic, key, payload) VALUES ($1, $2, $3)`, /* ... */);
  // ... COMMIT  (any failure ROLLBACKs all three)
}

Notice the agent_chain column in that insert. Agents are first-class principals in Squall — they carry Ory identities, and every action they take lands in audit_event with the full human→agent provenance chain intact. When a machine transitions a ticket, the record says which human it was acting for. Same governance as the humans, no backdoor — the exact property the regulated blog engine enforced for PHI, applied here to every mutation.

Event-driven — and not event-sourced

Here's the beat that separates "right architecture" from "fashionable architecture." The convenient-lazy choice is a status column. The convenient-trendy choice, in a system this event-heavy, is full event sourcing — rebuild every aggregate by replaying its events. Squall declines both.

Postgres rows are the source of truth. The append-only audit_event table feeds an outbox, the outbox feeds Kafka, and Kafka consumers build projections — search, embeddings into pgvector, notifications. Events drive everything downstream, but nothing upstream is reconstructed from them.

That's a deliberate, load-bearing "no." Event sourcing would have bought replayable aggregates at the cost of every schema migration becoming an event-versioning archaeology project. Squall wanted the event backbone's benefits — decoupled projections, a real audit stream, async enrichment — without paying the event-sourcing tax. Picking the right architecture sometimes means turning down the impressive one.

The UI is disposable — and that's the safety story

If the engine is the product, the UI is exhaust — the same status your CEO's dashboards have. Squall treats it that way, with a three-tier server-driven UI (SDUI) model:

• Tier 0 — a design-system component library, shipped as an npm package.
• Tier 1 — disposable UI specs, generated as JSON by Claude (through Kilter's bifrost LLM gateway) with a validate-and-retry loop.
• Tier 2 — the specs a human reviewed and signed, promoted to durable ui_surface rows.

The renderer that paints these specs is deliberately, aggressively dumb. It validates every spec against a JSON schema, draws only from a component allowlist, and — the keystone — it will only wire an action to a declared workflow signal:

/** Signals each workflow type declares — the only signals SDUI actions may
 *  reference. */
export const declaredSignals: Record<string, string[]> = {
  incident: ['transition', 'assign', 'escalate'],
  request:  ['transition', 'assign'],
  change:   ['transition', 'assign'],
  // ...
};

A generated spec cannot smuggle in behavior. It can't reference a signal a workflow didn't declare, can't invoke an undeclared mutation, can't execute arbitrary code — the renderer collects form values and hands them to a dispatcher that invokes exactly these and nothing else. This is what makes it safe to let a model generate your interface in a governed system: the blast radius of a bad generation is "a spec that fails validation," never "an action nobody authorized."

Look at what carried the weight in that build. Not the application code — the engine, the event backbone, the identity system, the allowlisted renderer. The infrastructure was the product; everything above it was generated, validated, or disposable. Now zoom out one level, because the same thing is true of your company.

Development against the deployment and runtime infrastructure

Every one of Squall's "right" choices depends on infrastructure that is normally expensive to stand up: a Temporal cluster, a Kafka backbone, Postgres with pgvector, a full Ory stack, object storage, traces, an LLM gateway. Reach for all of that from scratch and the right architecture dies in the backlog — you ship the status column instead, because that's what you can afford this quarter.

Kilter is what changes the math, and how it changes it is the point. One command composes the whole stack:

That is not a dev-tools trick. It's a different relationship between writing software and running it: you develop against the deployment and runtime infrastructure itself. The cluster on your laptop is the same primitives, the same charts, the same auth, the same policies as production — so the thing you build is born deployed, governed from its first line. There is no "works locally, now begins the hosting project" seam, because development happened on the hosting substrate all along.

And that's exactly what the CEO's eleven dashboards need. Not a better generator — they had one. A landing zone: a namespace with Ory in front of it, secrets that were never in the prompt, resource limits, an audit trail, scale-to-zero for the nine dashboards nobody opens twice, and a 48-hour reaper for the experiments. That's what the free-tier and ephemeral allocations in our pricing are — infrastructure shaped like the actual output of the agentic era: many small, transient, vibe-coded things that still must be run like software.

The revolution, correctly aimed

Two scales, one lesson. Inside an application, the durable asset was the engine and its governance — the UI became AI-generated exhaust. Across a company, the durable asset is the substrate — the applications become exhaust. The industry is still aiming its energy at the exhaust: better generators, better models, better harnesses, better loops. All genuinely useful, all abundant, all upstream of the real bottleneck.

The agentic revolution is an infrastructure revolution. The winners of the generation wave will be whoever gives the generated things a safe place to live — instantly, governably, at the price of the resources they consume and not a markup more. Pick the architecture that's right, not the one that's convenient — and let Kilter be the reason those are finally the same choice.

Where to go next

1. Read the companion build — an agentic blog engine for regulated environments — the same inversion told through compliance.
2. See The IaaS/PaaS/SaaS Singularity — the pricing consequence of infrastructure being the product.
3. See what makes a platform agent-native — the capability-bounded surface that makes the allowlisted renderer safe.
4. Start your free trial — give your dashboards somewhere to live.