Fastest to start
Managed cloud
We run it. The fastest way to get a workflow into production, with isolation between workspaces and encryption in transit and at rest.
Product
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.
Monitor
Govern
Workspace
Northwind Bank · Production
Assurance posture across every automated workflow.
Runs certified
+12.4% · vs last week
Certified rate
+0.6 pts · vs last week
Actions refused
+38 · none reached production
Median run time
−7.2% · vs last week
Every certified run is replayable for 7 years.
| Workflow | Business unit | Outcome | Started | Time |
|---|---|---|---|---|
| process_refund@3 | Northwind Bank | Certified | 14:22:07 | 1.9s |
| claims_intake@7 | Meridian Health | Running | 14:21:54 | — |
| reply_router@2 | Acme Retail | Refused | 14:20:31 | 0.4s |
| update_address@2 | Northwind Bank | Certified | 14:19:02 | 0.4s |
| issue_credit@1 | Acme Retail | Needs approval | 14:18:12 | 0.3s |
| disburse_payout@4 | Northwind Bank | Certified | 14:16:47 | 2.4s |
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.
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.
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.
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.
Monitor
Govern
Workspace
Runs / process_refund@3
Certified run · Northwind Bank · Production
A refund request arrived from the customer support inbox for order #18223.
The request matched process_refund, version 3 — the version currently approved for production.
Amount of $240.00 is within the $500 auto-approval limit for this account tier. Payee matched the account on file.
$240.00 returned to the original payment method. No other account field was written.
Confirmation sent to the address on the account. Run sealed and certificate written.
The assurance argument is worth less if meeting it means moving regulated data somewhere new. All three options run the same software.
Fastest to start
We run it. The fastest way to get a workflow into production, with isolation between workspaces and encryption in transit and at rest.
Your network, your keys
Runs inside your own cloud account, so records and traffic stay within your network boundary and your existing controls apply.
Air-gap capable
Fully self-hosted, including air-gapped environments with no outbound connectivity, for workloads that cannot leave the building.
No exceptions, no fast path, no mode where the checks are skipped because the workload looked routine.
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.
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.
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.
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.
A policy is written once, reviewed like code, and checked on every run. There is no configuration in which an unchecked run proceeds.
Monitor
Govern
Workspace
Govern / Policies
Rules every run is checked against before it is allowed to act.
| Policy | Applies to | Approver | Limit | Status |
|---|---|---|---|---|
| Refund ceiling | process_refund | Auto | $500.00 | Active |
| Named approver above ceiling | process_refund | Risk & Controls | $500.00+ | Active |
| Payee must match account | All payment workflows | Auto | — | Active |
| No writes outside the request | All workflows | Auto | — | Active |
| Business hours only | disburse_payout | Auto | 09:00–17:00 | Active |
| Bulk credit review | issue_credit | Finance | 25 / day | Draft |
WHEN a refund is requested AND amount is over $500.00 THEN hold for a named approver ELSE refuse, and record why
A policy that cannot be evaluated is treated as a failure. There is no configuration in which an unchecked run proceeds.
This is the part that turns a log into evidence. A record you can only read describes what happened. A record you can re-execute proves it.
Monitor
Govern
Workspace
Certificates / cert_8f31…
Re-run a past execution and compare it against the original.
| Field | Result |
|---|---|
| Workflow version | Identical |
| Inputs | Identical |
| Policy decisions | Identical |
| Actions taken | Identical |
| Timestamp | Differs — expected |
An execution you cannot reproduce is a description of what happened. One you can re-run is evidence.
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.
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.
Instead of reconstructing what an agent probably did from scattered logs, you hand over signed certificates and let the auditor re-run them.
Adding a workflow means compiling and verifying another plan. It does not mean widening a blast radius and hoping the monitoring catches it.
The fastest way to understand K3rnel is to walk one of your ownworkflows through it. Tell us which one.