# Built for work that takes three days and cannot be run twice.

**Built for work that takes three days and cannot be run twice.**

Professional work is not a request-response cycle. It waits for people, it touches systems that charge money, and it must be reconstructable months later. The Runtime is designed around those three facts.

KrewOS Runtime

[Read the Runtime docs](/docs) [Replay a real run](/demo)

**Durable by default**

Committed run state survives worker restarts, deployments and zone failures. A run waiting four days for a partner’s approval is a normal state, not a timeout.

**Idempotent Actions**

Checkpoints before and after every externally visible effect, idempotency keys on every Action, and declared compensation behaviour. The same invoice is not sent twice.

**Budgets that bind**

Soft limits degrade the model tier or concurrency first; hard limits fail closed before spending. Enforced per run, per project and per tenant.

## Human wait states are first-class workflow nodes.

Approval, missing input, exception decision and escalation are states in the graph with owners, SLAs and reassignment — not an email and a hope.

| Wait state | Raised when | Resolves by | If the SLA expires |
| - | - | - | - |
| **Approval** | A gate precedes a declared external effect, or the autonomy stage samples this run. | A named approver accepts, rejects or edits. | Escalates to the backup approver; the run stays parked, it does not proceed. |
| **Missing input** | A required typed input was not supplied or failed validation. | Requester or operator supplies it. | Reminder, then the case is returned to the requester. |
| **Exception decision** | A deterministic policy check failed and the policy allows a human override. | An authorised role decides, with a mandatory reason. | Escalates. Overrides are always recorded with the reason. |
| **Specialist escalation** | Evidence fell below the floor and the crew abstained. | A domain specialist supplies the missing source or answers directly. | Routed to the knowledge-gap queue for the Pack owner. |

## Releases, rollback and in-flight cases.

Releases are immutable, checksummed and dependency-locked. The hard part is not rolling back — it is what happens to the six matters that were mid-review when you did.

**What a Release pins**

crew\@4.2.0 agent-set\@sha256:9f1c… prompts\@v18 policies\@2026.02 knowledge\@sg-statutes-2026.01 model-profile\@balanced-v3 eval-suite\@lawcrew-217

**In-flight behaviour**

Long-running cases continue on the release they started on, even after you deploy a new one or roll back. A matter opened under 4.1.3 finishes under 4.1.3, and its audit record says so. New cases start on the current release.

Rollback is a promotion of an earlier immutable release, not a code revert. Because dependencies are locked, the earlier release behaves exactly as it did when it was current.

## Every node run records what it actually used.

Not what the configuration said at some point. What this node, on this run, at this timestamp, resolved to.

**Component version**

Exact Agent or Pod version and its checksum.

**Model profile**

Provider, model, routing decision and fallback, if any fired.

**Prompt version**

The rendered prompt version, with variable bindings recorded.

**Knowledge and tools**

Knowledge Packs queried, chunks retrieved, tools called, policies evaluated.

### Four deployment shapes

The same governed crew, invoked four ways. Governance is enforced by the runtime, never by the calling interface.

Authenticated API Webhook or event handler Schedule Operator-started case workflow

---

Canonical page: https://dev.krewos.ai/runtime