Fail closed, always
Uncertainty is not a reason to proceed carefully. It is a reason to stop. Errors, timeouts and ambiguous results all resolve to the action not being taken — there is no configuration that makes the risky outcome the default.
The assurance layer for AI execution
Stop debugging your agent.
Compile it.
Autonomous systems are being handed real authority — money, records, infrastructure — faster than anyone can prove what they will actually do. K3rnel closes that gap: intent becomes a fixed, inspectable plan, the plan is checked before anything runs, and only what passed is allowed to execute.
Private beta · Apache-2.0 open core
01How it works
Three steps, and a receipt.
The creative, risky work happens once — before anything touches your systems. What runs afterwards is ordinary, reviewable software.
- 01
Compile
A model reads your intent once, offline, and produces a fixed plan you can open and read. It is a document, not a conversation — the same input yields the same plan, and the plan is what ships.
- 02
Verify
Before a single action is taken, the plan is checked against your policies and constraints. Anything that cannot be shown to hold is refused outright rather than attempted and rolled back.
- 03
Execute
Only the plan that passed runs, and it runs deterministically. Every execution ends by writing a signed certificate recording exactly what was approved and what happened.
Certificate
- Plan
- process_refund@3
- Version hash
- sha256:9f3c…a17b
- Issued
- 2026-06-10 14:22:07 UTC
- Signature
- Ed25519
- Certificate
- cert_8f31…
CertifiedVerification complete
02The problem
Capability outran assurance.
Prompt an agent, watch it work, and the demo is genuinely impressive. Put it in front of a customer's money and the question changes shape entirely. Not can it do this, but what exactly will it do, who approved that, and what happens the day it is wrong.
The industry's answer so far has been to watch more closely. Log every step, score every output, add a guardrail model to check the first model, and escalate when confidence drops. All of it is inspection after the fact — a way of noticing that something went wrong slightly faster than a customer would have.
Inspection cannot produce a guarantee. If the decision about what an agent may do is made in the same breath as the doing, there is no earlier moment to point at and no artefact to review. Nothing can be signed, because there was never a fixed thing to sign.
So move the decision. Let the model do its thinking once, up front, and commit the result to something concrete enough to be read, checked and approved. Then let ordinary software carry it out. The creativity stays; the uncertainty leaves the runtime.
03Where it sits
Between your agents and everything they can touch.
K3rnel is not a framework you rebuild on top of, and not a model you swap in. It is a layer your existing agents call through — so the systems on the far side only ever see verified, attributable actions.
Your agents and applications
Whatever you already build with. K3rnel does not ask you to change how your agents are written.
K3rnel — compile, verify, execute
Intent is fixed into a plan, the plan is checked, and only what passed is carried out.
Signed certificate and replay log
Every run produces a durable record: what was approved, what ran, and the result.
Your systems of record
Databases, payment rails, ticketing, internal APIs — reached only through actions that were verified first.
04What you get
A record you can hand to someone else.
Not a transcript to scroll through. A ledger of runs, each one tied to the exact plan that was approved and the outcome it produced.
Runs
| Plan | Version hash | Status | Duration |
|---|---|---|---|
| process_refund@3 | sha256:9f3c…a17b | Certified | 1.24s |
| close_ticket@7 | sha256:4b81…c052 | Certified | 0.61s |
| process_refund@3Refund exceeds the approved limit for this account. | sha256:9f3c…a17b | Rejected | 0.08s |
| update_address@2 | sha256:7ea2…31d9 | Certified | 0.44s |
| issue_credit@1Held for a human approver before any action is taken. | sha256:c19f…8b40 | Needs review | 0.19s |
| sync_inventory@5 | sha256:2d77…f6ae | Running | — |
05The lifecycle
Every run takes the same four steps.
No exceptions, no fast path, no mode where the checks are skipped because the workload looked routine.
- 01
Compile
Intent becomes a fixed, inspectable plan. It is produced once, offline, and it does not change while it runs. You can read it, diff it against the last version, and put it through review like any other artefact.
- 02
Verify
The plan is checked against your policies and constraints before anything is attempted. This happens ahead of execution, not alongside it, so a failure costs nothing and leaves nothing to undo.
- 03
Execute
Only the plan that passed is carried out. Anything uncertain is refused rather than attempted — the safe outcome is the automatic one, including when something breaks mid-flight.
- 04
Attest
The run ends with a signed certificate: the plan, its version, the decision, and the result. Replay it later and you get the same answer, which is what makes an audit possible at all.
06Questions
The things people ask first.
No. K3rnel sits between what you already built and the systems it acts on. Your agents keep their framework, their prompts and their tools.
What changes is the boundary: instead of an agent reaching your database directly, it reaches it through a plan that was verified first.
Not on the path that decides whether something is allowed to happen. The model does its work up front, when the plan is compiled.
That is the whole point. A run that depends on a model responding correctly under load, in the moment, is a run you cannot make promises about.
It is refused. K3rnel fails closed: an error, a timeout, an unclear result and a genuine policy violation all end the same way, with the action not taken.
Refusals are recorded as first-class outcomes with a reason attached, so a rejected run is something you can investigate rather than something you have to reconstruct.
The plan that ran, its version, when it ran, the decision that was reached, and a signature over all of it.
It is designed to be useful to somebody who was not there and does not trust you — an auditor, a regulator, a customer's security team.
The ability to re-run a past execution and get the same result, rather than an approximation of it.
In practice that is the difference between explaining an incident and arguing about it. You can show what happened instead of describing what probably happened.
Private beta. We are working with a small number of design partners running real workloads rather than opening a self-serve signup.
If your agents are close to touching something that matters, we would like to hear what you are trying to put into production.
07Principles
What we refuse to compromise on.
Nothing executes unproven
There is no path where a plan runs because it looked fine, or because the check was slow, or because someone needed it shipped today. The verification step is not advisory and cannot be turned off for convenience.
Every run is replayable
An execution you cannot reproduce is a story, not a record. Runs are deterministic and signed so that months later, to someone who was not there, the evidence still holds up.
Put an agent into production you can defend.
We are working with a small number of teams whose agents are about totouch something that matters. If that is you, get in touch.