Every action has an approver
Not a person watching a dashboard, but a plan that was checked and a decision that was recorded. When someone asks who authorised this, there is an answer that does not depend on anybody's memory.
Product
What K3rnel actually does.
A plain description of the shape of the thing: where it sits, what it produces, and what changes about the day you put an agent in front of something that matters.
01The shift
Decide once, in the open. Then run.
Most agent systems make the decision and take the action in the same instant. The model is asked what to do, and whatever comes back is carried out. That is fast, and it is why the demos are good, but it leaves nothing behind that anyone can check. There is no moment where a person could have looked at the plan, because there was never a plan — only a sequence of choices made under time pressure.
K3rnel separates the two. The model's work happens once, ahead of time, and produces something concrete: a plan written down, versioned, and readable by a person who was not in the room. That plan is then checked against the rules you actually care about. Only after it passes does anything execute.
The result is an ordinary engineering artefact. You can diff it against last week's version, put it through code review, hand it to a compliance team, and point at it during an incident. None of that is possible when the decision only ever existed inside a single inference call.
02The three steps
Compile, verify, execute.
- 01
Compile
Your intent — the workflow you want an agent to handle — is compiled into a fixed plan. This happens offline, once, and can take as long as it needs to. The plan enumerates what may happen rather than describing it loosely, and it carries a version hash so you always know exactly which plan you are talking about.
You get an artefact you can read, review and version.
- 02
Verify
The compiled plan is checked against your policies and constraints before it is allowed anywhere near production. Because the plan is fixed, this check is meaningful: it is a statement about what will happen, not a guess about what might. A plan that does not pass does not run at all.
You get a decision made before the risk is taken, not after.
- 03
Execute
The verified plan is carried out by deterministic software. Anything unexpected — an error, a timeout, an ambiguous result — ends the run rather than improvising past it. When execution finishes, a signed certificate is written recording the plan, the decision and the outcome.
You get a run that is reproducible and a record that is signed.
03Deterministic replay
Re-run last month's execution and get last month's answer.
This is the part that turns a log into evidence. A record you can only read is a description of what happened. A record you can re-execute is proof.
Original run
- Plan
- process_refund@3
- Version hash
- sha256:9f3c…a17b
- Input digest
- sha256:61ba…04c7
- Decision
- Certified
- Recorded
- 2026-06-10 14:22:07 UTC
Replay
- Plan
- process_refund@3
- Version hash
- sha256:9f3c…a17b
- Input digest
- sha256:61ba…04c7
- Decision
- Certified
- Recorded
- 2026-08-01 09:05:41 UTC
Outputs match
The replay runs months after the original and reaches the same decision from the same plan and the same inputs.
04What changes
What you can say afterwards.
A bad day is a refusal
The failure mode of an unproven plan is that it does not run. That is a support ticket rather than an incident, and it is the same outcome whether the cause was a policy violation, a bug or an outage.
Audits stop being archaeology
Instead of reconstructing what an agent probably did from scattered logs, you hand over signed certificates and let the auditor re-run them.
Scope grows without the risk compounding
Adding a workflow means compiling and verifying another plan. It does not mean widening a blast radius and hoping the monitoring catches it.
See it against your workflow.
The fastest way to understand K3rnel is to walk one of your ownworkflows through it. Tell us which one.