How Rensei Works

Rensei is a platform for orchestrating fleets of AI agents across your software development lifecycle. At its core is the open-source donmai runtime - an execution layer that knows how to spawn agents, wire tools, manage workareas, and interact with providers. Rensei extends donmai with a control plane: multi-tenant governance, a visual workflow editor, persistent memory, analytics, and deep integrations with the tools engineers already use.

The six-layer stack

The execution architecture has six layers. The rensei.ai home page traces the same architecture as a five-stage request path (Compose, Compile, Scale, Intelligence, Verify): those five stages are the path a request travels, and they run on the six layers below. The sixth layer is the provider-contract foundation (Layer 1), the typed interface surface the request rides on rather than a stage it passes through. Same architecture, two views: the request path is what a workflow does; the layer stack is what it runs on.

Layer 1 - Provider contracts

The foundation is a set of typed interfaces - SandboxProvider, WorkareaProvider, VCSProvider, IssueTrackerProvider, RuntimeProvider, IntelligenceServicesProvider, DeploymentProvider, AgentRegistryProvider. Each describes what a provider must expose; implementations can be swapped without changing the layers above.

These contracts are OSS-canonical. If you are building a custom sandbox provider or integrating an external agent registry, the interface surface you implement is documented at donmai.dev/docs/provider-base-contract.

Layer 2 - Integrations

Concrete implementations of the provider contracts for real services. Rensei ships first-party integrations for Linear (21+ native workflow nodes), GitHub, Vercel, Jira, Asana, Slack, and Incident.io.

A key design principle here is native richness: Rensei never collapses a provider's capabilities into a generic abstraction. Linear gets the full Linear API surface as native workflow nodes; GitHub Issues gets its own distinct node set. The workflow editor's palette filters to only the integrations you have connected, so you only see the nodes that are available to your project.

Layer 3 - Execution

The execution layer manages the lifecycle of agent sessions - spawning processes, managing workareas (the checked-out git tree each agent works against), satisfying toolchain demands (the right version of Node, Python, or Rust), and coordinating with Intelligence Services.

Execution substrates:

The local daemon and its installation paths (launchd, systemd, Docker) are documented at donmai.dev/docs/local-daemon.

Layer 4 - Composition (the Orchestrator)

The Orchestrator is the runtime that compiles a workflow YAML definition into an execution plan, manages the dispatch loop, and coordinates with the Governor.

The Governor is a background scan loop that monitors all running workflow instances. It advances gates when their signals arrive, re-dispatches crashed sessions, and enforces timeout policies. The Orchestrator handles hot dispatch; the Governor handles the long tail.

Worker daemons register with the Orchestrator via a dial-in protocol: the daemon polls the platform for work, receives a signed session spec, and spawns the agent. The platform never needs to open an inbound connection to your machine.

For the platform-extended orchestrator internals (Topology view, multi-machine fleet aggregation, live capacity reporting), see Orchestrator and the Topology view.

Layer 5 - Intelligence Services

Intelligence Services is the layer that makes quality compound over time rather than decay.

Three components:

Memory. Every session produces observations - structured facts about the codebase, decisions made, patterns observed. At the start of each new session, the memory layer retrieves the most relevant observations via BM25 + vector hybrid search and injects them into the agent's context. The agent starts with knowledge, not a blank slate.

Code Intelligence. Six MCP tools (@donmai/code-intelligence) provide semantic code search, symbol lookup, repo map generation, and file embedding. These run as an MCP server against your workarea and are available to every agent regardless of model or substrate.

Architectural Intelligence. A knowledge graph built from AST extraction, PR-merge ingest, and session-terminal extraction. The graph surfaces tech-stack fingerprints, dependency maps, and architectural patterns that agents use during research and planning phases.

The OSS contracts for memory query/write and code-intelligence tools are at donmai.dev/docs/intelligence-services. The platform extends these with multi-tenant pgvector storage, Cedar-gated row-level memory access, and a memory analytics dashboard.

Layer 6 - Policy, Security, and Observability

The top layer is invisible when everything works and essential when something goes wrong.

Cedar policies enforce fine-grained access control: who can read a project, who can dispatch an agent, which memory is accessible cross-project. Cedar is evaluated at the API layer, not in application code.

Audit chain. Every session event is appended to a hash-chain with Ed25519 signatures and optional TSA anchoring. The chain is tamper-evident and can be verified offline without trusting any authenticated Rensei endpoint.

Cost tracking. Every agent dispatch is attributed to a project, a session, and a work type. The cost dashboard shows cost-per-issue, cost-per-phase, and provider benchmark comparisons.

The cross-provider value promise

The layered model is not just an architectural diagram - it enables a concrete promise: using multiple providers together produces strictly better results than using any single provider alone.

Three cross-provider seams drive this:

The Intelligence Services layer is what makes this true. An agent running on Vercel Sandbox and an agent running on your local machine share the same memory store, the same code-intelligence index, and the same routing posteriors. The platform aggregates their contributions; each benefits from the other.

How the OSS and platform layers relate

The donmai runtime works standalone - no Rensei account required. When workers register with the Rensei platform, the platform adds:

• Multi-tenant credential management (workers never carry raw API keys)
• Workflow orchestration and governor (the dispatch loop lives in the platform, not the runner)
• Persistent memory with RLS and Cedar access control
• The visual workflow editor and template marketplace
• Analytics, audit chain, and compliance tooling

The interface between the runner and the platform is the worker protocol: a REST API for worker registration, session polling, heartbeat, and credential snapshot. The runner's OSS contract is not coupled to the platform - a donmai worker can register with any orchestrator that speaks the protocol.

The five-point boundary discipline (001-donmai-rensei-platform-contract) governs what belongs in each layer:

For the full OSS internals and canonical contract language, see donmai.dev/docs/layered-execution-model.

Next steps

• Key concepts - terms and glossary
• Quickstart - first agent running in under 10 minutes
• Sandbox providers - choose and configure your execution substrate
• Memory and intelligence - how observations compound
• Worker protocol - register your own compute