00 · ABSTRACT

The ticket goes in. The swarm brings back the pull request.

Agents coordinate with each other over the A2A protocol, across Claude Code, Codex, Pi, Antigravity and OpenCode, on whichever model earns the work, from a Linear issue to a merged pull request with one human sign-off. Your engineers keep the judgment and lose the copy and paste.

Talk to us about a design partnership Read the evidence

01 · THE SWARM

Sessions that talk to each other.

A multiplexer flips a person between agent sessions. Here the sessions coordinate among themselves: a planner hands scope to an implementer, the implementer hands a green branch to a reviewer, and the messages cross harness and model boundaries on their way.

Each agent runs in its own harness on its own model and reaches the others over the A2A protocol, so a swarm is not five copies of one tool but whatever combination the work calls for. A person can attach to any session from the web, an iPad or an iPhone, watch the agent-to-agent rail, and take the pen when they want it. Coordination is tested across Claude Code, Codex, Pi, Antigravity and OpenCode, on Anthropic, OpenAI, Google, the Vercel AI Gateway, Z.ai, xAI and local models, and carried on the claims ledger as verified, with a walkthrough on request.

FIG 1.0

Tue 12 May 9:41

Interactive session

AViPhoneTMweb2 watching

mer-142-ramp-clampRelease control

Pi 0.14.2 harness · meridian-coder-32b

torque-fw · firecracker · us-west-2

workarea torque-fw · branch mer-142-ramp-clamp

harness ready · 12 tools registered

Attached. Nothing queued yet.

AVfrom web

what changed in the ramp path last week?

·gitlog --oneline src/torque6 commits

add cold-start bias to ramp_step

widen the calibration table schema

drop the legacy ramp limiter

refresh the torque smoke fixtures

split ramp_step from the integrator

move cal loading to boot

The legacy limiter went out with that drop and

nothing replaced it. That is where the ceiling

used to be enforced.

·readsrc/torque/limiter.cdeleted

·readtests/torque/ramp_test.c144 lines

ramp_test covers zero, ramp-up and hold. No

bounds case, so a regression would not fail.

AVfrom web

put the plan on MER-142 before you touch it.

·a2ato @plan.torque-fw

ramp ceiling unenforced since the limiter drop.

asking for scope before editing ramp_step.

delivered · seq 34

·runctest -R torque

Test project /srv/work/torque-fw/build

14 of 14 tests passed · 6.0s

Baseline is green. Waiting on scope.

AVfrom web

scope is in. read the calibration notes.

·readdocs/calibration.md96 lines

·readsrc/torque/ramp.c218 lines

·grep"ramp_step"7 hits

The integrator is shared by the cold-start and

the warm path. Table lookups live in the cal

file and are only read at boot.

AVfrom web

does anything else read the table at runtime?

·grep"cal_table"11 hits

src/torque/boot.c:88 cal_table_load()

src/torque/state.c:14 cal_table_ref()

sim/harness.c:203 cal_table_ref()

Only boot loads it. The ramp path holds a ref

but never reads the ceiling field.

·runctest -R cal

12 of 12 tests passed · 2.3s

AVfrom web

what does the table cap the ceiling at?

·readcal/table.json48 entries

·grep"ceiling_nm"3 hits

cal/table.json:12 "ceiling_nm": 240.0

cal/table.json:31 "ceiling_nm": 240.0

Every profile caps at 240.0 Nm. The ramp never

reads it, so nothing enforces the cap.

AVfrom iPhone

the ramp still overshoots on a cold start.

clamp it to the calibration table, add a test.

·readsrc/torque/ramp.c218 lines

·readcal/table.json48 entries

ramp_step() scales the raw setpoint and never

reads the table. Clamping at the ceiling.

·editsrc/torque/ramp.c+14 -3

·runctest -R ramp

Test project /srv/work/torque-fw/build

1/7 ramp_zero ............ Passed 0.02s

2/7 ramp_bounds .......... ***Failed 0.03s

FAILED ramp_bounds: limit 240.0 Nm, got 268.4

6 of 7 tests passed · 0.8s

The clamp runs after the integrator, so a cold

start overshoots first. Moving it ahead of it.

·editsrc/torque/ramp.c+6 -5

·runctest -R ramp

7 of 7 tests passed · 0.9s

·runctest -R calibration

12 of 12 tests passed · 2.4s

·gitcommit -m "clamp ramp to cal ceiling"2 files

branch mer-142-ramp-clamp · +20 -8

·a2ato @review.cal-harness

clamp landed ahead of the integrator.

ramp_bounds and calibration are green.

delivered · seq 41

Handed off. Holding for review.

›

Pi 0.14.2 · meridian-coder-32b19:41 elapsed · $0.43

Statusrunning

Sessionis_7f3a2c91

Workareatorque-fw / mer-142

HarnessPi 0.14.2

Modelmeridian-coder-32b

Sandboxfirecracker

Elapsed

19:41 / 45:00

Spend$0.43

Hostonline

sbx-mrd-04

hst_9c21bd · us-west-2

CPU38% · 8 cores

Memory52% of 32 GB

Slots4 / 6

A2Achecked just now

@impl.torque-fw

Implementer · torque-fw

@review.cal-harnessjust now

Holding review until ramp-bounds lands. Ping me when the suite is green.

delivered

@smoke.fleet-sim1m ago

Smoke suite green on fleet-sim after the last push. 10 of 10 steps, 3m 12s.

read

Open activity inspectorStop session

9:41

impl.torque-fwMeridian Robotics / MER-142

Pi 0.14.2 harness · meridian-coder-32b

torque-fw · firecracker · us-west-2

workarea torque-fw · branch mer-142-ramp-clamp

harness ready · 12 tools registered

Attached. Nothing queued yet.

AVfrom web

what changed in the ramp path last week?

·gitlog --oneline src/torque6 commits

add cold-start bias to ramp_step

widen the calibration table schema

drop the legacy ramp limiter

refresh the torque smoke fixtures

split ramp_step from the integrator

move cal loading to boot

The legacy limiter went out with that drop and

nothing replaced it. That is where the ceiling

used to be enforced.

·readsrc/torque/limiter.cdeleted

·readtests/torque/ramp_test.c144 lines

ramp_test covers zero, ramp-up and hold. No

bounds case, so a regression would not fail.

AVfrom web

put the plan on MER-142 before you touch it.

·a2ato @plan.torque-fw

ramp ceiling unenforced since the limiter drop.

asking for scope before editing ramp_step.

delivered · seq 34

·runctest -R torque

Test project /srv/work/torque-fw/build

14 of 14 tests passed · 6.0s

Baseline is green. Waiting on scope.

AVfrom web

scope is in. read the calibration notes.

·readdocs/calibration.md96 lines

·readsrc/torque/ramp.c218 lines

·grep"ramp_step"7 hits

The integrator is shared by the cold-start and

the warm path. Table lookups live in the cal

file and are only read at boot.

AVfrom web

does anything else read the table at runtime?

·grep"cal_table"11 hits

src/torque/boot.c:88 cal_table_load()

src/torque/state.c:14 cal_table_ref()

sim/harness.c:203 cal_table_ref()

Only boot loads it. The ramp path holds a ref

but never reads the ceiling field.

·runctest -R cal

12 of 12 tests passed · 2.3s

AVfrom web

what does the table cap the ceiling at?

·readcal/table.json48 entries

·grep"ceiling_nm"3 hits

cal/table.json:12 "ceiling_nm": 240.0

cal/table.json:31 "ceiling_nm": 240.0

Every profile caps at 240.0 Nm. The ramp never

reads it, so nothing enforces the cap.

AVfrom iPhone

the ramp still overshoots on a cold start.

clamp it to the calibration table, add a test.

·readsrc/torque/ramp.c218 lines

·readcal/table.json48 entries

ramp_step() scales the raw setpoint and never

reads the table. Clamping at the ceiling.

·editsrc/torque/ramp.c+14 -3

·runctest -R ramp

Test project /srv/work/torque-fw/build

1/7 ramp_zero ............ Passed 0.02s

2/7 ramp_bounds .......... ***Failed 0.03s

FAILED ramp_bounds: limit 240.0 Nm, got 268.4

6 of 7 tests passed · 0.8s

The clamp runs after the integrator, so a cold

start overshoots first. Moving it ahead of it.

·editsrc/torque/ramp.c+6 -5

·runctest -R ramp

7 of 7 tests passed · 0.9s

·runctest -R calibration

12 of 12 tests passed · 2.4s

·gitcommit -m "clamp ramp to cal ceiling"2 files

branch mer-142-ramp-clamp · +20 -8

·a2ato @review.cal-harness

clamp landed ahead of the integrator.

ramp_bounds and calibration are green.

delivered · seq 41

Handed off. Holding for review.

›

Pi 0.14.2 · meridian-coder-32bAV holds the pen

StatusPi · meridian-coder-32b

Elapsed19:41

CPU38%

Spend$0.43

@review.cal-harnessjust now

Holding review until ramp-bounds lands. Ping me when the suite is green.

FIG 1.0 - One session of a five-agent swarm followed from an iPad and an iPhone: the swarm sidebar, the terminal, and the agent-to-agent rail where the planner, implementer and reviewer hand work across.

Figures are live component renders, not screenshots. Demo data.

REC 01 ▸ sha256:cf56…cfcd ▸ prev f38e…2572 ▸ build 2026-09-03T21:23Z

02 · THE TICKET

One sign-off. No relay.

A Linear issue enters a declarative workflow: plan, implement, test gate, review, human sign-off, merge. Each stage is dispatched to an agent on the routed provider. The one place a person acts is the sign-off gate, and that ruling lands on the audit chain with everything else.

The workflow is stated as data and reviewed like code, so the path from intake to merge is the same on the hundredth ticket as on the first. A failed test gate sends the work back through implement on its own; an exhausted retry budget escalates to a person rather than looping. The Linear path is live and carried on the ledger as verified. GitHub Issues, Jira and Asana are in integration as sources for the same workflow, GitHub partial and the other two early, and the ledger says so.

FIG 2.0

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 2.0 - One issue replaying through the workflow: the test gate fails, refinement re-enters implement, the second pass clears review and the human sign-off gate, and merges.

REC 02 ▸ sha256:6e8f…bbb0 ▸ prev cf56…cfcd ▸ build 2026-09-03T21:23Z

03 · THE MODELS

Whichever model earns the work.

Three providers run in production at Rensei today: Anthropic, OpenAI and Google. The routing layer also reaches Anthropic, OpenAI, Google, the Vercel AI Gateway, Z.ai, xAI and local models, so a fleet registers a newer arm the week it ships and lets the posteriors decide how much of the work it earns.

Routing is a posterior per provider and work type, and code survival feeds it: a change that is still in the tree thirty days on counts for the arm that wrote it. Survival joins the posterior by decision id, with propensity recorded at decision time for offline evaluation; live ranking is org opt-in and kill-switched, and unopted orgs route in shadow mode. The execution layer underneath, Donmai, is open source under the MIT license, so the runtime that runs your swarm can be read before it is trusted, and the model catalog and routing layer is documented end to end.

FIG 3.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

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 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

CI < 0.15CI < 0.35wide CI

Provider posteriors

gpt-5.6-luna

triage

0.898

90.0%

106

$0.02

claude-fable-5-1

implement

0.898

89.0%

$4.10

gemini-3.1-pro

review

0.871

87.0%

$0.47

claude-opus-5

implement

0.853

85.0%

$2.05

claude-opus-5

review

0.849

84.0%

$0.98

claude-haiku-4-5

triage

0.835

85.0%

$0.09

claude-sonnet-5

triage

0.800

74.0%

$0.18

gpt-5.6-sol

implement

0.797

81.0%

$2.40

gpt-5.6-terra

review

0.764

77.0%

$0.44

gemini-3.8-flash

triage

0.727

29.0%

$0.07

grok-4.6

review

0.722

44.0%

$0.25

muse-spark-1.2

implement

0.700

46.0%

$0.42

glm-5.3

implement

0.625

38.0%

$0.44

Recent decisions

When

Model

Work type

Reward

Strategy

2m ago

gpt-5.6-luna

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

review

0.861

Exploitation

38m ago

claude-haiku-4-5

triage

0.803

Exploitation

52m ago

grok-4.6

review

0.788

Exploration

1h ago

gemini-3.8-flash

triage

0.702

Exploration

Real product UI · demo data from a fictional fleet (Meridian Robotics), 30-day window · arms beyond the three production providers reach the fleet through OpenAI-compatible endpoints

FIG 3.0 - Thompson posteriors per provider and work type, issue throughput, and the code-survival scorecard for one fictional fleet.

REC 03 ▸ sha256:6c02…6a3f ▸ prev 6e8f…bbb0 ▸ build 2026-09-03T21:23Z

04 · THE PROOF

What procurement asks. Already answered.

The same runtime that runs the swarm is the one that survives a security review: the four properties below are how it executes, not modules bolted on for the audit.

Hash-linked, signed audit records, checked offline: Entries on the current append path are hash-linked and Ed25519-signed; retained history may include legacy unsigned entries. The verification protocol and per-workspace key discovery are published, so a reviewer checks a supplied segment offline without an account.
Policy that fails closed: Every outbound tool call passes a Cedar ruling in the execution path. When the policy engine cannot answer, the call does not go; observation-only reads proceed and land on the chain.
A typed record for every routing decision: The candidates considered, a named reason for each exclusion, the chosen target, and the ruleset revision it was evaluated against. Reconstructable after the fact, which is what nondeterministic models require.
Every session recorded and replayable: The terminal stream is kept as a cast under the org’s recording policy, and anyone entitled to the session replays it in the platform player: seek, speed, the session record beside it.

Rensei operates the platform today. VPC and on-prem deployment are on the roadmap and carried on the claims ledger as roadmap; nothing on this page assumes them. The full security disclosure walks each property with its status.

FIG 4.0

Audit log

meridian-robotics/assembly-toolingdemo data · Jun 9, 2026 · UTC

d3c0de…1b44cc

UTC

Event

Actor · detail

Prev hash

Entry hash

genesis000000…000000
13:58:07
Issue accepted
intake-serviceMER-2841 · Gripper calibration drifts after firmware flash · P2
000000…000000
d3c0de…b8656b
14:02:31
Plan approved
m.alvarez3-step plan · scope: services/calibration · est. small
d3c0de…b8656b
d3c0de…22eacd
Decision dec_d3c0de24dd1c binds the model, prompt envelope, retrieved context, and policy ruling to one signed audit entry.
Model
claude-sonnet-5
version: claude-sonnet-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
14:19:12
Implementation complete
implementer/mr-fleet-02+214 −38 across 6 files · tests green · branch agent/mer-2841
d3c0de…ebca0f
d3c0de…e52bab
14:31:58
Review approved
k.tanaka2 comments resolved · approved for merge
d3c0de…e52bab
d3c0de…5945d7
14:32:20
Change merged
merge-botmerge d3c0de1 → main · checks green
d3c0de…5945d7
d3c0de…3c339d
14:35:00
Merkle checkpoint
audit-serviceroot sealed · tree size 4,187 · signed
d3c0de…3c339d
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. All hashes shown are seeded demo values; this specimen is not externally anchored.

FIG 4.0 - Audit-chain verification with one expanded decision-provenance row: model, prompt envelope, Cedar permit, policy hash.

REC 04 ▸ sha256:42dc…a8b4 ▸ prev 6c02…6a3f ▸ build 2026-09-03T21:23Z

05 · CONTACT

Bring us a ticket.

A design partnership starts with one real issue from your backlog, run end to end on your harnesses and your models, with the audit trail to show for it. Every message reaches our team and gets a reply.

Talk to us about a design partnership Read the security disclosure

REC 05 ▸ sha256:1c06…5f4a ▸ prev 42dc…a8b4 ▸ build 2026-09-03T21:23Z