KrewOS Runtime
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.
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
[email protected] agent-set@sha256:9f1c… prompts@v18 [email protected] [email protected] model-profile@balanced-v3 eval-suite@lawcrew-217
In-flight behaviour
GuaranteedLong-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