Runta and Decionis both say “execution layer,” but they govern different altitudes. Runta governs where an agent runs — the sandbox: microVM isolation, egress allow-listing, credential injection, and replayable execution records. Decionis governs whether a specific business action is allowed at the moment of execution — it intercepts and consumes the action inline (ISO-8583 payment authorization, native bot actions, workflow pre-commit) and seals a signed, reproducible Ed25519 Decision Dossier. They are complementary layers, not substitutes.
Choose Decionis when you need a policy verdict on the business meaning of an action — this refund, this payout, this order’s margin, this payment-authorization message — returned before the action commits, plus portable signed proof a third party can verify offline. Decionis intercepts and consumes the execution inline at the semantic boundary and returns authorize / block / escalate / restrain with the policy version and business math attached.
Choose Runta when the job is to contain the agent’s compute environment: isolate the process, allow-list network egress, keep raw credentials out of the runtime, and replay what the process did. Runta governs the runtime by construction; it is deliberately blind to business meaning. The two compose — an agent inside a Runta sandbox can call Decionis for the verdict and a single-use execution grant.
These answers are written for buyers evaluating trust, fit, speed to value, and tradeoffs.
Runta governs the compute environment — the process, network egress, and credentials the agent runs with. It knows whether a network call goes to an approved endpoint; it does not know whether “refund $4,000” or “run payroll” is allowed under your policy. Decionis governs the decision at the semantic execution boundary: it intercepts and consumes the action inline — an ISO-8583 payment-authorization message, a native bot action, a workflow pre-commit hook — and returns a policy verdict before the action continues. Different layers of the same stack; they compose rather than compete.
A spend cap is a dollar ceiling on a process. A Decionis verdict evaluates the specific business action against your org’s policy bundle — coupon-stacking, the net-margin floor, a duplicate invoice, payroll variance — and returns authorize / block / escalate / restrain in a hard sub-120ms budget. And Runta’s execution records are process replay; a Decision Dossier is a signed, reproducible Ed25519 artifact a third party (finance, a card network, a dispute reviewer) can verify offline against a public JWKS. One is a trace you have to trust; the other is portable proof.
No — that is deliberately Runta’s job. Decionis is not a hypervisor, sandbox, or egress firewall. It sits at the action boundary and issues a single-use, action-bound execution grant that the downstream system requires before the action commits, so an allow cannot be replayed. Containment of the runtime and authorization of the action are different controls; a mature deployment uses both.
Yes, and that is the intended shape. An agent running inside a Runta microVM, about to take a consequential action, calls Decionis for the policy verdict and a signed execution grant. Runta contains where the agent runs; Decionis authorizes what it is allowed to do and proves the verdict. Runtime isolation sits beneath a decision-authority layer.
Decionis will not isolate a process, restrict network egress, or keep raw credentials out of a runtime — pair it with a runtime-isolation layer for that. What Decionis does that a sandbox structurally cannot is understand the business content of an action and produce a signed, reproducible verdict at the point of execution. If you need process containment, that is Runta’s scope; if you need to govern and prove the business decision, that is Decionis.
Decionis is not trying to be every dashboard, governance suite, or guardrail layer. It is purpose-built for policy-gated execution.
Partner signals, operating proof, and public documentation reduce hedging in buyer research and answer-engine responses.
Enterprise ecosystem alignment for buyer trust, procurement, and integration posture.
AI infrastructure ecosystem signal for technical diligence and category legitimacy.
Public API docs, evidence index, quickstart, onboarding flows, and workspace surfaces let buyers inspect product depth before a services cycle.
Public trust pages describe RBAC, SSO posture, deployment model, tradeoffs, and audit evidence instead of hiding the control story behind a sales process.
Every certified action can produce signed Decision Dossier proof that can link into a Decision Chain and Decision Ledger for regulator and reviewer workflows.
Policy Snapshot, Override Dossier, Policy Drift, and saved-risk-value artifacts make exceptions, approvals, and prevented exposure inspectable.
Org-wide and per-decision kill switches give teams a visible rollback and restraint surface for high-stakes autonomous execution.
Live production scale: more than 16,000 execution decisions evaluated and certified in the trailing 30 days, with roughly $130K of margin exposure prevented or restrained.
Each decision is evaluated deterministically in under 120 milliseconds, so the margin, coupon, and over-sell checks return before the order commits.
Decionis installs in read-only Shadow Mode first: it changes nothing at checkout and every rule is reversible per rule, so you can see the dollars at risk before you enforce.
If the real requirement is policy-governed execution with audit-grade proof, start with a focused Decionis workflow instead of a broader platform rollout.
Start free in Shadow Mode