How to Build Your Enabling Agentic Substrate

The last post made a claim: you scale agents not by making them smarter, but by standing them on infrastructure that makes their actions durable, isolated, and traceable — so each new agent inherits those properties instead of rebuilding them badly.

That shared layer has a name: the substrate. This post is the build guide. Not the app, not the agent — the thing underneath both that turns "an LLM wired to an API" into a system you'd trust to act on your business.

What a substrate is (and isn't)

An agent is vertical — it does one job. A substrate is horizontal: it's the set of capabilities every agent needs and none should own privately. Durability. Events. Memory. Isolation. An audit trail. A surface agents can actually drive.

The test is simple. When you build your second agent, how much of the first one do you copy? If the answer is "the retry logic, the event plumbing, the audit writes, the auth" — those were never agent code. They're substrate, and they belong below the waterline where both agents share one hardened copy.

Start where you'll finish: a real cluster

The substrate has to be the same locally and in production, or every guarantee you build into it has a parity hole. So step zero isn't a framework — it's a real (small) Kubernetes cluster on your laptop that mirrors prod.

Everything below is a service you compose onto that cluster, not glue you write. The order matters: each layer assumes the one before it.

Layer 1 — The durable spine

The first thing an agent needs is somewhere durable to run. Not the LLM call — the orchestration around it. This is Temporal: a workflow engine where every step is recorded, retried, and resumable. The agent's reasoning stays ephemeral and quarantined to a single step; the workflow that sequences those steps survives crashes, restarts, and the 40-minute job that a serverless function would have killed at minute 15.

If you build nothing else, build this first. A crash at step 9 of 14 that resumes at step 9 — never step 1, never re-applying step 8 — is the difference between an agent you can leave running and one you have to babysit.

Layer 2 — The event backbone

Durable runs need a way to start without polling. The backbone is two pieces: a log to carry events (Redpanda or NATS), and change data capture (Debezium) that turns every row change in an app's Postgres into an event — without modifying the app.

This is what lets an agent be a reaction instead of a cron job. A doc changes in Outline, a deal moves in Twenty, a file lands in Nextcloud — CDC emits it, the backbone carries it, and a durable workflow wakes up. The agent never reaches behind the app; it listens to the same truth the app already writes.

Layer 3 — Memory and retrieval

Reasoning is stateless, but the agent needs context to reason over. Two stores cover most of it: Postgres for structured state and durable application data, and a vector store for retrieval over unstructured content — the wiki, the docs, the past decisions.

The rule from the last post still holds: this is where state lives, not in the model's context window. The agent reads from here at the start of a step and writes back at the end. Nothing important survives only in the prompt.

Layer 4 — The safety envelope

Now make it safe to let the thing act autonomously. On Kubernetes this is mostly configuration, not code: namespaces for tenant isolation, RBAC so an agent's service account can touch exactly the resources it's scoped to, quotas so a runaway loop can't starve the cluster, and network policy so one agent can't see another's traffic.

The point of putting this in the substrate is that every agent gets it by being deployed, not by remembering to ask. Safety you opt into is safety you'll forget.

Layer 5 — The audit substrate

The last layer is the one that earns trust: an append-only, immutable log of what every agent did. Not mutable application state you can overwrite — a tape you can replay. The trigger, the model's intended change, the actual write, the result.

The rule is the one from the previous post, and it belongs in the substrate so no agent can violate it: no write to a system of record without an audit entry first. If the log write fails, the business write doesn't happen. Combined with Temporal's own execution history, you get two independent traces — the workflow (every durable step and retry) and the intent log (every decision and why). When something goes wrong months later, you don't guess. You read the tape.

Layer 6 — The agent-facing contract

A substrate humans can use but agents can't drive is half a substrate. The last layer is a contract: a structured, low-token surface — typed APIs, JSON output, discoverable capabilities — that an agent can explore and operate the same way a human would, but without scraping a UI.

This is why the Kilter CLI returns machine-readable output by default:

The same property your operators want — clear, composable, inspectable — is exactly what makes an agent able to build with the substrate, not just run on it.

Compose it, don't wire it

The payoff of doing this on a platform is that the whole substrate is a file, not a quarter of plumbing work. Each layer above is one line:

# kilter.yaml — the substrate as a composition
name: agentic-substrate
services:
  - postgres        # structured state
  - qdrant          # retrieval
  - temporal        # the durable spine
  - redpanda        # the event backbone
  - debezium        # CDC: apps emit events
  - ory             # identity for the safety envelope

kilter up applies it locally; kilter deploy applies the same composition to prod. No parity gap, so the guarantees you tested locally are the guarantees you ship.

A sane order to build in

You don't need all six layers on day one. Add them as the agents earn them:

1. Spine first (temporal) — make runs durable before anything else.
2. Memory (postgres, qdrant) — give reasoning something to stand on.
3. Backbone (redpanda, debezium) — when you want agents to react, not poll.
4. Audit — the moment an agent can write to anything that matters.
5. Safety envelope — before more than one agent, or any real tenant.
6. Agent contract — when you want agents building on the substrate, not just running.

Most teams discover they need each of these at Series B and bolt it on under duress. Building on a substrate means they were always there, composed, waiting.

The whole point

The substrate is what you build once. The agents are what you build many. Get the layer underneath right — durable, event-driven, remembered, isolated, audited, drivable — and every agent you add inherits a system that holds up under autonomy. Get it wrong, and each new agent is a fresh copy of the same half-solved problems.

That's the prerequisite the last post pointed at. This is how you lay it.

Where to go next

1. Re-read Building Agents on Open-Source Apps for the why behind these layers.
2. See why Kubernetes is the right foundation for the durable spine.
3. Browse the Kilter Platform catalog — every service above is one kilter add away.
4. Start your free trial — the full platform, 7 days, no card.