Blog #ai #ai-agents #software-engineering
Rhumbatron: Many AI Agents on One Codebase
How we built a multi-agent Git platform on Cloudflare Workers, Artifacts, and Durable Objects that detects semantic conflicts, verifies candidate builds in sandboxes, and promotes only passing releases.
- Published
- Reading
- 5 min
- Author
- Sudhanva Narayana
Rhumbatron is a coordination and release platform for running multiple humans and AI coding agents against the same repository at the same time. You describe a product change in plain English, and Rhumbatron decomposes it into a dependency graph, wakes agents in isolated Git forks, catches semantic conflicts before merge, runs full build/test/browser verification in Linux containers, and promotes only the candidate that passes every check.
Maanasa Narayan and I built it for the Cloudflare challenge Build the Next-Gen Git Platform on Cloudflare. As an end-to-end stress test, Rhumbatron built Loom, an interactive handweaving draft studio, starting from an empty Git repository.
The source is open on GitHub, with full architecture docs at docs.rhumbatron.com.
How it works
flowchart TD
goal[Request in plain language] --> intake[Intake check<br/>clear? duplicate?]
intake --> plan[Work Graph<br/>Tasks and dependencies]
plan --> wake[Wake only ready Tasks]
wake --> agents[Agents in parallel<br/>one Git fork each]
agents --> intents[Typed Intents and Claims<br/>on product areas]
intents --> conflict{Conflict<br/>between plans?}
conflict -->|no| compose[Compose one Candidate]
conflict -->|yes| fork[Fork Candidates<br/>A and B]
compose --> verify[Verify with evidence<br/>build, tests, contract, browser, p95]
fork --> verify
verify --> select[Select by evidence]
select --> promote[Compare-and-swap promotion<br/>S41 to S42]
promote --> live[Live app on<br/>Dynamic Workers]
Key features
- Parallel agents with zero idle spin. Each ready task wakes an agent with its own forked Git workspace and Linux Sandbox. Blocked tasks stay hibernated until their upstream dependencies land.
- Semantic conflict detection. Clean
git mergeoutput doesn’t mean two agents agreed on the architecture. Agents publish typedClaimsandIntentsover product surfaces so Rhumbatron can spot incompatible designs (like two competing schemas for the same feature) and fork separate Candidate builds to race them. - Evidence-driven promotion. Candidate builds must pass TypeScript and bundle builds, unit and contract suites, headless browser screenshots, and p95 latency checks. A skipped check never counts as green.
- Atomic compare-and-swap releases. A per-project Durable Object serializes pointer promotions (
S41 → S42) so concurrent merges can never clobber production. - Multi-user governance. Role-based access (owner, admin, member, viewer) and a live Kanban board tracking every change from intake to release.
- Per-task token budgets and model routing. Routine classification and routing run on small models (
clef-flash/ Haiku) so frontier calls are reserved for complex planning and code generation, with hard spend caps enforced at the gateway.
Built on Cloudflare
| Cloudflare primitive | Role in the Rhumbatron architecture |
|---|---|
| Workers | Ten specialized Workers handling the web UI, API, planner/coordinator, agent loops, event router, integration engine, code indexer, Sandbox host, live preview apps, and documentation. |
| Artifacts | Backing Git storage for every project; each agent task, Candidate composition, and interactive edit session operates on an isolated fork. |
| Durable Objects | Single-writer coordination. One root object per project owns the live version pointer and compare-and-swap promotion, while companion objects track Claims/Intents and WebSocket feeds. |
| Sandbox | Ephemeral Linux containers where agents run shell commands, bun install, builds, and integration test suites. |
| Dynamic Workers | Instant hosting for every Candidate preview and promoted production bundle at <project>.rhumbatron.com. |
| Workflows | Durable multi-step orchestration for Change planning, Candidate verification pipelines, and live app rollouts. |
| Queues | Asynchronous command bus decoupling agent wake-ups, integration runs, verification jobs, indexing, releases, and dead-letter handling. |
| K2 | Ordered event log partitioned across eight streams, fed via a transactional Durable Object outbox. |
| D1 | Relational store for Projects, Changes, Tasks, Candidates, verification summaries, team memberships, and token usage ledgers. |
| R2 | Object storage for large artifacts including test logs, context packets, Git patches, compiled app bundles, and archived event segments. |
| Workers KV | Low-latency edge cache for project policies and routing rules. |
| Vectorize | Vector index over repository symbols and historical Changes, queried after exact AST/dependency lookups. |
| Workers AI | Runs bge-small-en-v1.5 for code/change embeddings and bge-reranker-base to deduplicate incoming requests at intake. |
| Clef-flash | Fast, confidence-gated classifier that chooses model tiers, filters noisy wake events, and checks whether a new request is well-scoped. |
| AI Gateway | Proxies Anthropic calls, logs token telemetry, and enforces hard monthly spend ceilings. |
| Browser Run | Drives a headless browser against Candidate preview URLs to capture visual evidence and catch runtime rendering errors. |
The entire Cloudflare footprint is provisioned declaratively with Terraform, with Claude Sonnet 5.5 and Claude Haiku 5.5 powering the coding and planning loops.
flowchart TD
user[Browser] --> web[Web app]
web --> api[API]
api --> plan[Change workflow<br/>planner]
plan --> router[Event router<br/>wakes ready Tasks]
router -->|ready Tasks| agent[Agent<br/>model and tool loop]
agent -->|fork, commit| art[(Artifacts)]
agent -->|shell| sbx[Sandbox]
agent -->|ChangeSet| integ[Integration<br/>compose and verify]
integ --> ev[(Evidence<br/>D1 and R2)]
integ -->|compare-and-swap| root[Project owner<br/>Durable Object]
root -->|outbox| k2[(K2 events)]
k2 --> router
integ -->|release| apps[Dynamic Workers<br/>live apps]
See the architecture guide for a deeper look at the state machines and wire protocols.
Documentation
| Topic | Page |
|---|---|
| How a request becomes a release | Change lifecycle |
| Agents, models, and model routing | Agents and models |
| Git workspaces, Candidates, and checks | Source and verification |
| Events, Queues, and the outbox | Events and commands |
| Roles, request review, and the Board | Shared Projects |
| Live apps on Dynamic Workers | Live apps |
| API routes and schemas | Protocols |
| Deployment and cost limits | Deploy, Costs |
| Design decisions | Architecture decision records |
Try it
- Sign in with Google at rhumbatron.com.
- Create a Project and describe a feature or app under New change.
- Watch the work graph decompose and agents spin up on the Change page; once a Candidate passes verification and promotes, click through to the live deployed app.
Run it yourself
Prerequisites: Bun 1.3.14+ and Terraform 1.16+.
git clone https://github.com/nsudhanva/rhumbatron.git
cd rhumbatron
bun install
cp apps/web/.env.example apps/web/.env.local
bun run dev
Drop your Clerk dev keys into apps/web/.env.local. bun run dev brings up the web UI on localhost:5173 and the API Worker on localhost:8787 using local Wrangler state (.wrangler) for D1, R2, and Queues. Note that full end-to-end agent execution requires Artifacts, K2, Sandbox, and Workers AI on a live Cloudflare account; follow the deployment runbook to stand up your own environment.
Team
| Name | Website | GitHub | X | |
|---|---|---|---|---|
| Sudhanva Narayana | sudhanva.me | @nsudhanva | nsudhanva | @SudhanvaN |
| Maanasa Narayan | maanasa.dev | @maanasanarayan | maanasa-narayan | @maanasa_narayan |
Rhumbatron is open source under the MIT license.
Header photo: A Jacquard loom showing information punchcards, National Museum of Scotland by Stephencdickson, CC BY-SA 4.0, cropped.
Related work
Production ML context
See how this topic connects to production ML systems, infrastructure, and inference.