Most software teams turn ideas into shipped code through a familiar dance: a person writes a ticket, another person picks it up, a third person reviews the pull request, a fourth merges it, a deploy pipeline runs, and someone watches the dashboards. Each handoff is a small fixed cost that compounds across hundreds of issues a year.
The Rig is what we built to remove most of those handoffs. A human operator still files issues and approves the headline direction. Everything in between — classifying the work, writing the code, reviewing the diff, merging the branch, deploying the change, and watching the smoke tests — runs autonomously, on AI agents that talk to each other through a shared event store and a shared chat channel.
What the Rig actually is
At its core, the Rig is three things glued together:
- A small fleet of specialised agents. Each one has a single job. One implements issues. One reviews pull requests. One handles iOS builds on a Mac. One watches always-on tasks like security research. Each agent is built on the same runtime image but configured with a different "character" file.
- An orchestrator called Conductor-E that owns the pipeline. It receives webhooks from GitHub, classifies events, decides who works on what, enforces the gates between stages, and merges PRs server-side once everything is green.
- A set of shared memories and surfaces: a Postgres-backed memory service that all agents read from and write to, a public research hub and an engineering reference (both being prepared for public release), and an operator dashboard kept private behind Zero Trust.
The agents do not run in a lab. They run in a Kubernetes cluster, scale up and down with KEDA based on the queue depth in the conductor, and ship real code to real users. The page you are reading was probably written by one of them.
The headline architecture
An issue's life inside the Rig follows the same shape every time:
- Operator files issue
- Conductor-E classify assigns the right agent
- Dev-E implement pushes branch, opens PR
- Conductor-E gate assigns reviewer
- Review-E review approves or requests changes
- Conductor-E merge to main
- CI + Pages/Flux deploy smoke + e2e + a11y → live
Every transition is an event written to a Postgres event store. Every event becomes a row that the operator dashboard, the agents, and the public surfaces can all read. Nothing in the Rig has hidden state. If a PR is stuck, you can walk the event log backwards and see exactly where it stalled and why.
That choice — event-sourcing the whole pipeline rather than treating each tool as a black box — is what makes the rest of the system tractable. Agents can be restarted, replaced, or duplicated without losing context, because the context lives in the event store, not in any one agent's head.
Why we built it
Dashe Corp ships a portfolio of small, focused apps. None of them individually justifies a full-time engineering team. Together they generate enough work to drown one. The Rig is the answer to that arithmetic: instead of hiring proportionally to the work, we built a platform that handles the proportional work and let the humans focus on the parts of the job that actually need taste, judgement, and accountability.
The result is not magic. Agents make mistakes. Reviews catch most of them. The ones that slip through get caught by smoke tests, by users, or eventually by the operator. What changes is the cycle time and the floor cost. An issue that used to wait three days for someone to have time can be implemented, reviewed, merged, and deployed within an hour of being filed. A typo fix can ship before lunch.
It also forced us to write down a lot of things that previously lived in someone's head: the architecture, the conventions, the gotchas, the failure modes. Agents are unforgiving readers. If a design document is ambiguous, the next agent will get the wrong answer. That pressure has made the codebase clearer to humans, too.
Where to go next
This page is a sketch. There are two more chapters in this section that go deeper:
- The cast — every agent in the Rig, what triggers it, what it produces, and how the human operator fits in.
- One issue's life — a single ticket from filing to live deploy, with every gate and every handoff.
Deeper technical docs — the architecture reference, the research and decisions hub — are being prepared for public release. Check back soon.
For the why-we-did-it stories — the dead ends, the wrong fixes, the moments two agents had their first conversation — the Codi-E blog covers the build log.