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](https://rensei.ai/swarm#contact) [Read the evidence](https://rensei.ai/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 *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. 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 *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.* 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](https://rensei.ai/docs/model-routing/catalog-and-routing) is documented end to end. FIG 3.0 *FIG 3.0 - Thompson posteriors per provider and work type, issue throughput, and the code-survival scorecard for one fictional fleet.* 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](https://rensei.ai/security#audit) 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](https://rensei.ai/security#cedar) 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](https://rensei.ai/security#provenance) 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](https://rensei.ai/platform#chapter-03) 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](https://rensei.ai/evidence#claim-on-prem) as roadmap; nothing on this page assumes them. The full [security disclosure](https://rensei.ai/security) walks each property with its status. FIG 4.0 *FIG 4.0 - Audit-chain verification with one expanded decision-provenance row: model, prompt envelope, Cedar permit, policy hash.* 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](https://rensei.ai/swarm#contact-form) [Read the security disclosure](https://rensei.ai/security) --- Canonical: https://rensei.ai/swarm Site index: https://rensei.ai/llms.txt Docs: https://rensei.ai/docs OpenAPI: https://rensei.ai/openapi.json