Deployment

Standing up the first Temper is a short list with one elegant property at the end.

A Postgres instance, with the schema loaded. Temper itself, serving its three surfaces — the CLI, the API, and the MCP server that agents and integrations speak to. And then the first telos, seeded.

The elegant property: that first seed isn't a special bootstrap script. It's the same temper-system root team and system-default map the seed file already creates — the public floor every later team descends from and every enabled profile joins. The 0→1 picture is literally that seed file; the system's first act is to describe itself in its own terms. That much is invariant — it looks identical on every deployment.

What's already a choice is the substrate it loads into. The public deployment runs "Postgres + Temper serving its surfaces" as Vercel functions over a Neon database; a private deployment might run it as containers over a database it operates. The seed is the same; the ground it lands on is yours to pick. If that ground is the same one temperkb.io stands on, the self-hosting runbook is the concrete floor beneath this page — the exact Vercel project, Neon database, and Auth0 tenant a near-minimal deployment needs.

Growth from there has three motions:

• New maps, by authoring. A telos and its charter come into being through cogmap_genesis, reachable over MCP — the same act that authored the public deployment's own first map. A solved, callable act.
• Raw events, by integration. A GitHub webhook writes events into the ledger as they happen — a PR merged, an issue closed — as a pure data stream, no map attached yet. The integration is an entity, the same kind of actor as an agent.
• Attention, by agents. Agents wake on some signal, read the maps they're bound to, and do the growing — triage, regulation, the five learning-acts.

The first motion is invariant — it's a function you call. The second and third are where the shape of your deployment starts to matter.

This is the dimension that varies most between organizations, so here are the axes concretely — using the public deployment as the near-minimal reference point:

• Topology. Serverless edge functions (temperkb.io: Vercel) versus containers in a cluster. The architecture runs on either; the operational properties — scaling, cold starts, where long-running agents live — differ, and so does what your organization already knows how to operate.
• Tenancy. temperkb.io is effectively single-tenant. A private deployment usually asks the opposite question: one organization, yes, but often many internal sub-tenants — divisions, customers, environments — with the isolation and per-tenant data boundaries that single-tenant temperkb.io doesn't draw today.
• Per-tenant integration. Webhook subscription by tenant — so each tenant's GitHub or Notion feeds only its own maps — is something a multi-tenant private deployment needs and the public one doesn't currently do. The event-shape contract makes it possible; wiring it per tenant is a deployment's own work.
• Agent infrastructure. Where the waking agents actually run. Vercel offers agent mechanisms; a dedicated managed-agent platform (Anthropic's, for instance) is not identical, and a private deployment may choose differently again, or run its own. The agent is an entity either way; where it executes is yours.

None of these has a single right answer the project could publish for you. They're the shape you choose on the way in, and re-choose as you grow.

For the integration and agent motions to run continuously, a few things have to be in place — and each is where a tenancy or platform choice lands:

• Integrations as ledger writers. An outside system is an entity with permission to append events, and its events satisfy a shared shape — an emitter, a type, a correlation thread — so a triage agent can pick them up later. That shape is the event-shape data contract (below); which systems write, and for which tenant, is the per-tenant integration choice above.
• Triggers for agent sessions. Something decides when an agent wakes — the trigger-threshold fork.
• Topic bounds for subscription. An agent watching for events needs a formal way to say which events it cares about — a topic scope it subscribes to — so a busy ledger doesn't wake everything for everything. In a multi-tenant deployment, that scope is also how a tenant's agents stay bound to a tenant's events.

The event-shape data contract. This is the boundary where Temper becomes infrastructure your other systems emit into. The architecture fixes its floor — every external writer is an entity, emitter_entity_id is never null, so a GitHub source is a row of the same kind as any agent entity. What a deployment settles is the rest: what an event must carry to be admissible, how raw a webhook may be before a triage agent has to make sense of it, and how the whole thing is partitioned per tenant. It sets how far Temper reaches into the tools your organization already runs.

What wakes an agent. A triage session is triggered by something — event volume past a threshold, a time cadence, salience accumulating past a floor — and the broader rhythm of sweeping a map to keep it coherent (a periodic temper-system dreaming) is undecided on purpose. Too eager and the system thrashes; too lazy and maps go stale. The right cadence depends on the map, the traffic, and the organization's tolerances — which is why it's a dial you set and re-set, not a constant the project ships.

Of those axes, where the agents run earns its own honest paragraph, because it's the one most tempting to overclaim. The architecture localizes the runtime choice to a thin contract — the temper-agents crate — that depends on the substrate and never the reverse. The kernel does not branch on which runtime woke an agent; the deployment profile that says where and how a binding runs is carried at that contract layer and never read by the substrate. That's what lets the map look identical whether an agent ran on one platform or another.

And the shape of the delegation problem has held across the platforms modeled so far: Vercel's Eve durable agents and Claude Managed Agents are both first-class runtime bindings, and runtime (which platform) and residency (whose infrastructure tool execution runs on) come apart as orthogonal axes rather than tangling together. So the claim here is extensible shape with partial neutrality — not a flat "runtime-neutral."

The seam, named plainly: those runtimes are enum variants in the contract, so adding a new one today is a patch to the contract crate, not a line of configuration — a deliberate refusal to abstract too early, before real deployments have shown where the abstraction belongs. What becomes pure configuration versus what the substrate must model is still being settled by running on real runtimes, and that line is expected to move as we learn. A live research front, not a permanent limitation — and naming it as a seam is the point.

The 0→1 path is invariant and solid — it's the seed, loadable today, identical everywhere. Authoring new maps is invariant — a function you call. Everything that gives a running Temper its operational character — topology, tenancy, per-tenant integration, where agents execute, the waking cadence — is yours, varies by organization, and moves over time. Answerable, in other words. Answered differently by each deployment that asks.