00 · ABSTRACT # The deterministic runtime that makes agent-authored code defensible in production. Declarative workflows compile to a durable execution graph. LLMs run as bounded operators inside workflow steps; the control loop is deterministic code. Cedar evaluates policy in the hot path. Entries produced by the current audit append path are hash-linked and carry per-workspace Ed25519 signatures; retained history can include legacy unsigned entries. Decision provenance binds every action. [Review the architecture with us](https://rensei.ai/#contact) [Read the evidence →](https://rensei.ai/evidence) `curl https://rensei.ai/.well-known/audit-keys.json` verification protocol and key-discovery endpoints, published · [the runtime is open source →](https://rensei.ai/open-source) > “Engineers should not have to --dangerously-skip-permissions their way to the next promotion or termination.” *[from the founder's principles →](https://rensei.ai/principles)* 01 · INBOX ## One inbox holds the whole fleet. Every session a person is entitled to see, across orgs and projects, sits in one list in creation order. What needs them stays full weight, working rows recede, and finished work turns green where it sits. Approvals collect in a tray with a batch verb, and each decision lands on the audit chain. The inbox ships with the unified session stream and is listed in the [claims ledger](https://rensei.ai/evidence) as roadmap. FIG 1.0 *FIG 1.0 - The user-scoped inbox: one static list in creation order. Urgency resolves by badge, an approval storm collapses into a single tray row, and finished work is filed to the shelf.* Figures are live component renders, not screenshots. Demo data. 02 · OPERATE ## The loop closes bounded and on the record. Behind every row in that inbox is a session, an issue, and a handoff. Acceptance fails. The issue is auto-rejected. Refinement dispatches in about five seconds, parked behind the active session, capped at eight dispatches per issue. Every transition lands on the audit chain. Governor-level hard caps and holds are on the roadmap and listed in the [claims ledger](https://rensei.ai/evidence) . FIG 2.0 Replay 2026-06-09 *FIG 2.0 - Fleet topology and sessions stream, looping over a captured demo run.* FIG 2.1 *FIG 2.1 - Acceptance fails, the issue auto-rejects, refinement dispatches. The cap holds at eight.* 03 · ROUTE ## Routing is a posterior, not a preference. Each dispatch in that topology began as a decision. A permission gate and a viability filter narrow every dispatch to the pools that may and can serve it; Thompson-sampling posteriors per provider and work type then rank the survivors, never widen the set. Exploration stays policy-bounded, and posteriors update from observed session outcomes. Per-line provenance and survival measurement are live: survival rewards join the routing posteriors by decision id, with propensity recorded for offline evaluation. Live ranking is org opt-in and kill-switched; unopted orgs run in shadow mode. FIG 3.0 *FIG 3.0 - Thompson posteriors per provider. Survival-to-posterior wiring: verified, decision-id joined.* ### EXAMPLE DECISION TRACE · ILLUSTRATIVE NUMBERS 14 pools considered: 9 excluded for missing `os=macos` , 3 forbidden by policy v37 data-residency, 2 unhealthy. Zero survive, and the dispatch fails loud, naming every excluded pool and its reason on the decision record. It does not silently downgrade to whichever pool is reachable. 04 · WORKFLOW ## One request path. Five layers. Every layer auditable. The inbox, the topology, and the routing decisions above all run one declared graph. One request path runs Compose to Verify: Compose declares the workflow, Compile turns it into a durable execution graph, Scale routes work across providers, Intelligence persists what the fleet learns, and Verify keeps every step on the record. FIG 4.0 *FIG 4.0 - SDLC v2 workflow definition, 46 nodes. One scripted run lights research through acceptance.* 05 · VERIFY ## Four primitives. Properties of the engine. Everything above lands on the record. Cedar policy enforcement, hash-chained audit, fail-closed egress, and decision provenance are properties of the deterministic execution graph. The security disclosure walks each one. - [Cedar policy enforcement→](https://rensei.ai/security#cedar) - [Hash-chained audit→](https://rensei.ai/security#audit) - [Fail-closed egress→](https://rensei.ai/security#egress) - [Decision provenance→](https://rensei.ai/security#provenance) FIG 5.0 *FIG 5.0 - Audit-chain verification with one expanded provenance row. Mock hashes.* 06 · REMEMBER ## The learning compounds. The data does not. The platform extracts a knowledge graph from agent activity. Reads are Cedar-authorized, every access lands on the hash-chained audit trail, and feedback weights decay on an exponential moving average. Cross-tenant aggregation covers anonymized model-performance priors only. FIG 6.0 *FIG 6.0 - Knowledge-graph explorer over a fictional codebase. Layout precomputed at build.* 07 · RUNTIME ## The execution layer is open source. Donmai ( どんまい ) is the MIT-licensed runtime under the platform: one Go binary, a persistent daemon, a dispatch loop. The same runtime powers Rensei in production. The star count is fetched on a daily schedule; the git history is the interesting part. ### donmai `brew install RenseiAI/homebrew-tap/donmai` [View on GitHub](https://github.com/RenseiAI/donmai) [Why open source →](https://rensei.ai/open-source) 08 · RECORD ## Published numbers. Declared status. [Full claims ledger on the evidence page →](https://rensei.ai/evidence) 09 · CONTACT ## Review the architecture with us. Every message reaches our team and gets a reply. Bring us the runtime thesis you came here for: the workflow whose git history would tell you whether an agent can be trusted with it. [Review the architecture with us](https://rensei.ai/#contact-form) [Read the principles](https://rensei.ai/principles) --- Canonical: https://rensei.ai/ Site index: https://rensei.ai/llms.txt Docs: https://rensei.ai/docs OpenAPI: https://rensei.ai/openapi.json