Rensei
DOC R-002 · PLATFORM REFERENCE · REV 2026-10-27sha256:df2c…51b2

00 · ABSTRACT

A workflow is a graph. The graph is the contract.

Deterministic workflow engine. Vendor-neutral provider routing. Four verification primitives derived from the architecture, not configured onto it.

REC 00 ▸ sha256:95e3…61d7 ▸ prev 1549…b73e ▸ build 2026-10-27T18:47Z

01 · COMPOSE

State what should happen. Review it like code.

Workflows are declarative, typed YAML living in the repo, so pull requests, CODEOWNERS, and reviewers apply unchanged. The file and the canvas are the same graph.

FIG 1.0
# sdlc-default · atlas-firmware (Meridian Robotics, demo)
# Excerpt. FIG 1.1 renders the compiled graph.
kind: WorkflowDefinition
metadata:
  name: sdlc-default

nodes:
  - id: intake
    type: trigger
    config: { nodeId: linear.issue-assigned }

  - id: triage
    type: action
    config: { nodeId: agent.dispatch_stage, stage: triage }

  - id: plan
    type: action
    config: { nodeId: agent.dispatch_stage, stage: plan }

  - id: implement
    type: group
    stages: [branch, code, self-review, commit]

  - id: tests
    type: action
    config: { nodeId: ci.run_checks, stage: qa }

  - id: test-gate
    type: gate
    config:
      gateKind: signal
      onFail: { dispatch: refinement, cap: 8 }

  - id: review
    type: action
    config: { nodeId: agent.dispatch_stage, stage: review }

  - id: sign-off
    type: gate
    config: { gateKind: approval }

  - id: merge
    type: action
    config: { nodeId: repo.merge }

# edges omitted in this excerpt

FIG 1.0 - SDLC workflow definition, YAML excerpt. FIG 1.1 renders the compiled graph.
FIG 1.1
sdlc-defaultMeridian Robotics / atlas-firmware
Run queueddemo replay
Issue assigned
Triage & scope
agent.dispatch_stage · triage
Write implementation plan
agent.dispatch_stage · plan
Implement4

branch · code · self-review · commit

Run test suite
ci.run_checks · qa
Tests green?Signal
passed
failed
Retry budget left?attempt < 3
YesNo
Refinement loopLoop ×3
group: grp_implementdelay: 30son max: escalate
Escalate to operator
fleet.escalate · human
Agent code review
agent.dispatch_stage · review
Reviewer sign-offHuman query
approved
rejected
Merge to main
scm.merge_pr
FIG 1.1 - The compiled execution graph replaying one run: the test gate fails, refinement re-enters implement, the second pass merges.

Every saved change snapshots as an immutable version under workflow versioning, so a running instance is immune to edits made on the canvas beside it and a publish that goes wrong rolls back to the version that worked.

REC 01 ▸ sha256:95ab…8deb ▸ prev 95e3…61d7 ▸ build 2026-10-27T18:47Z

02 · COMPILE

Durable state. Replayable. Bounded.

Many platforms run the LLM as the control loop. Rensei takes the opposite stance: the compiler turns the graph into a durable execution plan whose control flow is deterministic code.

State persists at every step boundary, so a run survives crashes and redeploys and replays from the record for audit or selective re-run. LLMs run as bounded operators inside workflow steps: each call captures model version, prompt, and retrieved context, and every transition lands on the hash-chained audit trail.

FIG 2.0Replay 2026-06-09
Fleet topologyMeridian Robotics · autonomy-fleet
5 sessions · 1 issue · $5.25 today
MER-128awaiting sign-off
Torque telemetry drops samples
sessions
5
tools
309
cost
$5.25
planner-01Codex
plannercompletedgpt-6-astra
5m 52s41$0.67
impl-01Claude Code
implementercompletedfable-5-1
21m 24s131$2.50
impl-02OpenCode
implementercompletedglm-5.3
14m 6s74$0.91
review-01Antigravity
reviewercompletedgemini-3.1-pro
9m 2s
44
$0.86
OK
PR #214approved - awaiting 1 human sign-off
cost to date$0.86
smoke-01Pi
smoke-runnerrunninghaiku-5-5
3m 8s19$0.31
session streamreplaycaptured run · loops
  • 00:19impl-01Bashmake test - PASS (96/96)
  • 00:13impl-01Editfirmware/torque_sampler.c - guard ISR buffer flush
  • 00:09impl-02Editfirmware/isr_guard.c - bounded retry on flush
  • 00:04plan-01plan drafted - 2 slices, handoff to impl-01 and impl-02
  • 00:00plan-01Readfirmware/torque_sampler.c - ISR buffer path
FIG 2.0 - Fleet topology with the sessions stream: agents, issues, and dispatch updates replayed on a scripted loop.

REC 02 ▸ sha256:d0ee…9161 ▸ prev 95ab…8deb ▸ build 2026-10-27T18:47Z

03 · OPERATE

Every session reports to one inbox.

A user-scoped inbox lists every session the user is entitled to see across their orgs and projects: one active list in creation order, with urgency carried by badge and never by position. Approvals, interview questions, and requests for input collect in a tray above the list, so thirty parallel approvals are one row with a batch verb, and every decision lands on the audit chain.

The inbox is where the rest of this reference meets. The approval a gate holds for a person is the Cedar ruling the security disclosure walks. The row that finishes in place is the run the throughput panel counts. The filed shelf is the audit chain's view of finished work. The design was ruled in August 2026 and ships with the unified session stream; the claims ledger carries it as roadmap.

FIG 3.0
FIG 3.0 - Fifteen minutes of a two-org fleet replayed in the user-scoped inbox. Rows hold their positions, badges carry urgency, and finished sessions move to the filed shelf.

Interactive sessions put a running harness on whatever screen is at hand. The web view, an iPhone, and an iPad attach to the same session and see the same thing: the swarm sidebar, the terminal, host stats, and the agent-to-agent rail, with one operator holding the pen at a time. The figure runs the open-source Pi harness on a fictional model, which keeps the mechanism in view without favoring a provider. Interactive sessions are live today and carried on the claims ledger as verified, with a walkthrough available on request.

FIG 3.1
FIG 3.1 - One session followed from an iPad and an iPhone: Pi harness, fictional model, swarm sidebar, host stats, agent-to-agent rail.

A session is also kept. With recording on for the org, the terminal stream is written as a cast while the session runs, and once it ends anyone entitled to the session can replay it in the platform player: scrub to a moment, change the speed, and read the session record beside it, or tail the same recording as text from the CLI. That is the answer to the question compliance, risk, and security teams ask first, what did the agent actually do, and it holds without a screen recording anyone had to remember to start. Session replay has shipped with interactive sessions since their launch and is carried on the claims ledger as verified. A durable evidence store that checks replays in for the long term, and learning over them, is roadmap.

FIG 3.2
FIG 3.2 - The recording of the same session, replayed at 2x in the platform player: transport, seek bar, speed, and the session record with its recording policy.

REC 03 ▸ sha256:5bb4…859c ▸ prev d0ee…9161 ▸ build 2026-10-27T18:47Z

04 · SCALE

Three providers in production. The route is earned.

Three model providers run in production at Rensei today: Anthropic, OpenAI, and Google, each running host-session through the local daemon.

Additional endpoint configurations (Bedrock, Vertex AI, Azure OpenAI, OpenAI-compatible, local) extend the same model catalog and routing layer beyond the three providers running in production today. That is how a fleet registers a newer arm the week it ships, Muse Spark 1.2, GLM-5.3, or Grok 4.6 beside the current Claude, GPT-5.6, and Gemini tiers in the demo below, and lets the posteriors decide how much of the work it earns. 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 4.0

Routing Intelligence

Hot-path weighting activeThompson sampling · 30-day window

Every task type is a bandit. The fleet keeps a Beta posterior per model arm and routes work to whichever model is actually winning, while still spending a small exploration budget to keep the estimates honest.

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.

Exploration rate
13.8%
of routed decisions
Avg confidence
69.9%
across all arms
Decisions
720
30-day window
Active arms
13
12 models in rotation
Next decision

Next implement task routes to claude-fable-5-1: highest expected reward, 0.898 with a 95% CI of 0.83–0.96 across 86 observations. claude-opus-5-5 stays close at half the cost per task. Four arms registered in August (muse-spark-1.2, glm-5.3, grok-4.6, gemini-3.8-flash) share a 13.8% exploration budget until their intervals close.

Posterior distributions, Beta(α, β) per model arm

0.000.250.500.751.00IMPLEMENT · 253 OBSroutes → claude-fable-5-1claude-fable-5-1n=86claude-opus-5-5n=73gpt-5.6-soln=62muse-spark-1.2n=18glm-5.3n=14REVIEW · 231 OBSroutes → gemini-3.1-progemini-3.1-pron=91claude-opus-5-5n=71gpt-5.6-terran=53grok-4.6n=16TRIAGE · 236 OBSroutes → gpt-6-astragpt-6-astran=106claude-haiku-5-5n=83claude-sonnet-5-5n=38gemini-3.8-flashn=9

Provider posteriors

gpt-6-astra
triage
0.898
90.0%
106
$0.02
claude-fable-5-1
implement
0.898
89.0%
86
$4.10
gemini-3.1-pro
review
0.871
87.0%
91
$0.47
claude-opus-5-5
implement
0.853
85.0%
73
$2.05
claude-opus-5-5
review
0.849
84.0%
71
$0.98
claude-haiku-5-5
triage
0.835
85.0%
83
$0.09
claude-sonnet-5-5
triage
0.800
74.0%
38
$0.18
gpt-5.6-sol
implement
0.797
81.0%
62
$2.40
gpt-5.6-terra
review
0.764
77.0%
53
$0.44
gemini-3.8-flash
triage
0.727
29.0%
9
$0.07
grok-4.6
review
0.722
44.0%
16
$0.25
muse-spark-1.2
implement
0.700
46.0%
18
$0.42
glm-5.3
implement
0.625
38.0%
14
$0.44

Recent decisions

When
Model
Work type
Reward
Strategy
2m ago
gpt-6-astra
triage
0.924
Exploitation
6m ago
claude-fable-5-1
implement
0.917
Exploitation
11m ago
gemini-3.1-pro
review
0.889
Exploitation
19m ago
glm-5.3
implement
0.512
Exploration
27m ago
claude-opus-5-5
review
0.861
Exploitation
38m ago
claude-haiku-5-5
triage
0.803
Exploitation
52m ago
grok-4.6
review
0.788
Exploration
1h ago
gemini-3.8-flash
triage
0.702
Exploration
FIG 4.0 - Thompson posteriors per provider, issue throughput, and code survival. Survival-to-posterior wiring: verified, decision-id joined.

REC 04 ▸ sha256:a026…e7f9 ▸ prev 5bb4…859c ▸ build 2026-10-27T18:47Z

05 · INTELLIGENCE

Memory that survives the run.

Each run leaves a knowledge graph behind: code nodes and decision nodes joined by typed, confidence-labeled edges.

AST extraction covers TypeScript and JavaScript; extraction elsewhere is model-assisted. Reads are Cedar-authorized and land on the hash-chained audit trail, feedback weights update by exponential moving average, and the graph is tenant-scoped. Cross-tenant aggregation covers anonymized model-performance priors only.

FIG 5.0

Knowledge graph

Meridian Robotics · fleet-core · 49 entities · 66 relationships

service

fleet-gateway

service

telemetry-ingest

service

path-planner

service

order-orchestrator

service

firmware-ota

service

auth-service

service

notification-hub

module

kinematics-core

module

occupancy-grid

module

task-scheduler

module

retry-queue

module

feature-flags

api

POST /v2/missions

api

POST /v2/telemetry/batch

api

GET /v1/robots/:id/firmware

api

webhooks/order-events

api

RobotControl (gRPC)

database

telemetry-tsdb

database

fleet-postgres

database

missions-redis

library

meridian-proto

library

px-motion-sdk

library

grid-codec

library

retryx

repository

meridian/fleet-core

repository

meridian/edge-firmware

repository

meridian/web-console

repository

meridian/infra

person

Priya Nair

person

Marcus Webb

person

Elena Vasquez

person

Tom Okafor

person

Sara Lindqvist

person

Dev Patel

team

Fleet Platform

team

Autonomy

team

Reliability

decision

ADR-014: Event-sourced missions

decision

ADR-019: gRPC for robot control

decision

ADR-022: TimescaleDB for telemetry

decision

ADR-027: Canary firmware rollouts

decision

ADR-031: Idempotent order webhooks

incident

INC-2041: Telemetry ingest backlog

incident

INC-2087: OTA rollback storm

incident

INC-2113: Duplicate mission dispatch

convention

Error-wrapping convention

convention

Idempotent migrations rule

convention

Proto compatibility policy

convention

Retry budget convention

Mini Map

Entity types

Node size reflects importance · click an entity for provenance

FIG 5.0 - Knowledge-graph explorer over a fictional codebase: search, legend filters, detail panel.

REC 05 ▸ sha256:bc59…71d4 ▸ prev a026…e7f9 ▸ build 2026-10-27T18:47Z

06 · VERIFY

Four verification primitives run in the execution path.

Cedar policy enforcement, hash-chained audit, fail-closed egress, and decision provenance are properties of the execution graph. The security disclosure walks each one.

FIG 6.0

Audit log

meridian-robotics/assembly-toolingJun 9, 2026 · UTC
Event
Entry hash
  1. genesis000000…000000
  2. Issue accepted
    d3c0de…b8656b
  3. Plan approved
    d3c0de…22eacd
  4. Decision dec_d3c0de24dd1c binds the model, prompt envelope, retrieved context, and policy ruling to one signed audit entry.
    Model
    claude-sonnet-5-5
    version: claude-sonnet-5-5 · provider snapshot 2026-06-30
    Prompt envelope
    template: implementer.dispatch@v12
    sha256: d3c0dee3c9…b067e2f5d9
    tokens: 2,113 system · 18,402 input
    tools granted: git, fs.write (services/calibration/**), test-runner
    Retrieved context
    memobs_mem_a41f2c - “Calibration offsets are written by flash.ts, not the EEPROM map” · w 0.82
    fileservices/calibration/flash.ts · w 0.74
    filedocs/runbooks/gripper-calibration.md · w 0.61
    issueMER-2841 · intake thread (4 messages)
    Policy ruling · Cedar
    ALLOWfleet.dispatch.scoped-write@v7
    matched rules: allow-implementer-scoped-write, require-branch-isolation
    policy hash: d3c0deebfd…e103274083
    Cryptographic proof
    entry hash: d3c0deede1f3360c9c77bee1e4bfbe8cb2eb073fd81df5d241c11d8573ebca0f
    sequence: 4183
    signature:ed25519 · DEMOSIGqNdHF/pEQtKdTnhST…(key meridian-audit-2026a)
    Merkle inclusion: leaf 4183 / tree size 4,187
  5. Implementation complete
    d3c0de…e52bab
  6. Review approved
    d3c0de…5945d7
  7. Change merged
    d3c0de…3c339d
  8. Merkle checkpoint
    d3c0de…845dc2
Within the contiguous demo segment shown, hash chaining exposes an edit, interior deletion, or reorder at the break. It does not establish capture or full-history completeness. Whether what was written is true is the job of decision provenance; this specimen is not externally anchored.
FIG 6.0 - Audit-chain verification with one expanded decision-provenance row: model, prompt envelope, Cedar permit, policy hash.

REC 06 ▸ sha256:8884…f638 ▸ prev bc59…71d4 ▸ build 2026-10-27T18:47Z

07 · INTEGRATIONS

Rensei meets the systems auditors already credit, on their own ground.

No logo wall: each category states what crosses the seam today.

  • Source control

    Agent-authored changes arrive as pull requests in your repositories. Reviews, branch protection, and CODEOWNERS apply unchanged.

  • Issue tracking

    The dispatch loop works the backlog through 17 Linear MCP tools, shipped MIT across the donmai binary and its plugin packages.

  • Model providers

    Anthropic, OpenAI, and Google run in production today. Additional endpoint configurations (Bedrock, Vertex AI, Azure OpenAI, OpenAI-compatible, local) extend the same routing layer beyond the three.

  • Identity

    Workspace sign-in runs through single sign-on, and sessions, policy decisions, and audit rows are tenant-scoped by construction.

  • Audit and SIEM

    Audit-chain segments export as signed JSON and verify against the published Ed25519 keys, inside whatever log store the audit team already runs.

  • MCP tooling

    17 Linear and 6 code-intelligence tools, shipped MIT across the donmai binary and its plugin packages; the plugin contract is published in the open-source runtime.

REC 07 ▸ sha256:5fc1…feee ▸ prev 8884…f638 ▸ build 2026-10-27T18:47Z

08 · PATTERNS REJECTED

Three patterns this architecture rejects.

  • The LLM as the control loop

    When the model decides what runs next, the loop can rewrite its own record, and the audit trail becomes another model output. Rensei keeps the control loop in deterministic code; models run inside bounded steps, and every transition lands on the hash-chained audit trail.

  • The walled garden

    A runtime that cannot be inspected asks the buyer to take the execution layer on faith. The execution layer here is MIT-licensed, and the boundary between open source and the commercial control plane is published where anyone can read it.

  • Framework-only open source

    A framework without a runtime ships the hard parts back to the adopter: the daemon, the retries, the operational floor. Donmai is one Go binary with a persistent daemon and a dispatch loop, and the same runtime powers Rensei in production.

REC 08 ▸ sha256:0a11…7b70 ▸ prev 5fc1…feee ▸ build 2026-10-27T18:47Z

09 · CONTACT

Walk this reference against a real workflow.

Bring the workflow you would not hand an agent today. We will trace how approvals surface to the operator inbox, how policy evaluates before action, and how the entire run replays from the record.

Confirm your email and our team replies directly.

REC 09 ▸ sha256:f204…61e9 ▸ prev 0a11…7b70 ▸ build 2026-10-27T18:47Z