Skip to main content
For engineers

How it is actually built.

The rest of this site is about what the product does. This page is the other thing — for the engineer who wants to know whether the design holds up, and where the edges are.

01

Why a kernel first.

Most agent platforms started with an agent and added governance later. That ordering is hard to recover from: the durable spine has to be underneath, and retrofitting it means rewriting everything that assumed it was not there.

NovaCore was built in the opposite order. Three claims drove it:

  • Mission lifetime must be independent of any model conversation. Work spans hours or weeks, crosses context windows, survives model swaps and platform restarts. If the unit of work is a session, none of that is possible.
  • Policy must be enforceable even when the agent tries otherwise. Which means it cannot live in the prompt, and it cannot live in a log written after the fact.
  • Every consequential action must be attributable and reversible. Not describable afterwards — attributable at the time, with the evidence and the authority attached.

Each is a property of the substrate rather than of the model.

02

Everything durable is an event.

The event store is the system of record. Mission state is a fold over an append-only log, and read models are projections of it. If a projection is wrong it is rebuilt from events rather than patched.

Every envelope carries tenant, product, mission, correlation and causation identifiers, the acting principal and a schema version — which is what makes a trace reconstructable from mission down to individual tool calls.

All of it in Postgres: one piece of stateful infrastructure, with envelopes shaped so that introducing a broker later is a transport change rather than a redesign.

Why not a workflow engine

Mission lifecycle is durable-execution-shaped, and off-the-shelf engines solve genuinely hard distributed-systems problems. We did not use one, because it would have coupled the platform's core abstraction to a vendor's model of what a workflow is.

The mission model — its states, its transitions, its evidence and its verification — is the product. Owning it means owning timer wheels, lease reaping and replay correctness. That cost was accepted knowingly, and the walking-skeleton milestone existed to prove it before anything was built on top.

03

Pull, lease, heartbeat, reap.

Nothing is pushed at an executor. The kernel enqueues a step; workers and machines pull leases and heartbeat while holding them. An expired lease is re-queued and resumes from a checkpoint the server holds, not one the dead process was keeping.

That makes executor failure boring and backpressure natural. Machines on your network claim through the same contract rendered remotely — outbound long-poll, identical lease semantics, placement by label.

04

Decision and enforcement, split.

Authorisation splits into a decision point in the control plane and enforcement points where actions happen. The decision answers allow, prepare-only, queue-for-approval or deny, and can attach obligations. Denial at either enforcement point is fail-closed.

Enforcement is graded, and the grade is recorded. What the platform dispatches is governed per call; a third-party agent running its own loop is governed at dispatch and at the workspace boundary. We state this rather than claiming uniform per-call coverage, because that claim would not survive being checked.

Credentials follow scope rather than custody — three classes by blast radius, with restricted credentials never reaching a machine at all.

05

A typed boundary around every model call.

Conventional layering has no home for what crosses the boundary to a language model — a lossy, token-budgeted, two-representation wire to an untrusted system that is also the prompt-injection surface and the largest cost centre.

Left implicit, four things go wrong, quietly:

  • Entities get serialised into prompts by accident, carrying fields nobody meant to send.
  • Redaction becomes prompt discipline instead of a property of the code.
  • Tool schemas drift away from the parsers that read their results.
  • Prompt changes become untraceable string edits scattered across a codebase.

So there is a fourth type layer that is the only gate across that boundary. Classification checks, tenant scoping and redaction are enforced when a view is built — a view for confidential work cannot be constructed from records above its clearance, it fails at construction.

External content renders inside data-marked sections; instructions never come from data sections, and the renderer enforces that rather than the prompt.

Model output carries zero authority. A parsed tool call is a proposal, and it still passes enforcement before anything happens.

Why this matters commercially

Three things people usually promise become properties of the code instead:

  • Injection defence

    Structural. The renderer frames external content; the prompt author cannot forget to.

  • Token spend

    Measurable per view, per version — so cost optimisation is engineering rather than folklore.

  • Behavioural drift

    Traceable. Contract versions are stamped on every invocation, so a change in behaviour points at a version.

06

Agent-proposed, kernel-executed.

A pre-planned graph is wrong by step two on judgment work. A pure agent loop has the opposite problem: no durable spine, no waiting without a session, no enforceable budgets, no audit. NovaCore runs both modes on one kernel.

Orchestrated missions have one logical orchestrator on a durable session, acting only through kernel tools — host code that passes enforcement and calls the kernel's API. Emitting a plan creates real step rows. The step graph is emergent: the audit record of what happened, not a diagram revised five times.

Scripted missions keep a full graph upfront with no model in the control flow — synchronisation, change verification, scheduled operations.

In both, the kernel enforces dependencies, retries, budgets, escalation and verification before completion. Skills are versioned playbooks: the definition is the persona, the skill is the procedure, and a skill narrows behaviour without ever widening authority.

07

Isolation below the application.

Tenant is the isolation boundary; product is a scope beneath it. Tenant identity is a mandatory column on every table and a mandatory field on every event envelope, and row-level security enforces it below the application — an unscoped query is structurally impossible rather than something code review is supposed to catch.

On top of isolation sits confidentiality. One key per environment wraps one key per tenant, stored only in wrapped form. Content-bearing columns — transcripts, message bodies, memory and knowledge payloads, SSO configuration, personal data — are encrypted with binding that ties each value to its tenant, entity and field, so ciphertext cannot be moved between tenants even by direct database manipulation.

Offboarding is cryptographic. Deleting a tenant's wrapped keys is deleting the data — provable, auditable, and run as an ordinary mission so it has the same audit trail as any other consequential act.

One code path serves both deployment modes. A dedicated instance is the same image with a single tenant provisioned — a deployment-time choice, not a build variant, so the dedicated path is never the less-tested one.

Nothing crosses a tenant boundary, ever — including agent memory and learned patterns. That forecloses cross-customer learning deliberately.

08

What we deliberately did not build.

Every one of these was considered and rejected for a stated reason. Knowing what a system refuses to do tells you more about it than another feature list.

not built

A message broker

One piece of stateful infrastructure beats two sources of truth at this scale. Envelopes are broker-shaped, so adding one later changes the dispatcher rather than the contracts.

not built

Container-per-workspace isolation

It broke the toolchain it existed to run — nested containers, compose, test containers. The dedicated machine is the boundary instead, and the real perimeter was always credential scope.

not built

Two-way sync with your tracker

Two systems with equal authority produce conflicts nobody is entitled to resolve. Mission state is the record; the tracker is a projection kept in sync by an agent that proposes and acts but never decides what is true.

not built

Cross-tenant learning

It cannot be defended in a security review, and a capability withdrawn under scrutiny was never an asset. Nothing crosses the boundary, including learned patterns.

not built

Being the coding agent

That is the fastest-moving part of the market and the worst thing to couple a platform to. Adapters instead — and a second adapter is a proof obligation rather than a roadmap item.

not built

Reopening completed missions

Verification verdicts, cost attribution and change traceability all depend on completed being a fact. Continuity happens above the mission, as follow-up lineage on the same conversation.

Going deeper

This page is the summary.

Behind it sits the full design record — the data model, the wire contracts, the decision log with the alternatives that were rejected and why, and the milestone plan. We share the relevant parts under NDA during an evaluation, because that is usually the conversation where an architecture review actually gets settled.

Send us your hardest question.

The ones we get most: what happens when the model is wrong, what happens when the machine dies mid-merge, and what exactly can that token do. All three have specific answers.