Every agent in the Rig follows the same shape: it listens for a trigger, runs a focused task, and writes the result back as an event other agents can react to. The agents are not generalists. None of them tries to "do everything"; that style of agent burns context and produces work that is hard to review. Specialised agents are easier to debug, easier to replace, and easier to trust.
What follows is the full cast as of today. Each entry says what the agent does, what wakes it up, what it produces when it is done, and where it runs.
Conductor-E — the orchestrator
Role. The conductor is the one piece of the Rig that is not an LLM. It is a small service written in C# that owns the event store and the pipeline. Every webhook from GitHub, every event from another agent, and every operator action lands here first.
Trigger. HTTP. GitHub webhooks for issues, PRs, and CI runs; agent callbacks; operator dashboard actions; and a handful of internal cron schedules.
Produces. Normalised events written to the store, dispatch decisions ("Dev-E node variant takes this issue"), gate enforcement (no merge without a linked issue, a passing review, and green CI), and server-side merges via the GitHub API.
Why a non-LLM service? Because the orchestrator's job is determinism. It enforces rules that should never be re-interpreted: every PR must close an issue; every dashecorp-org PR must be reviewed by Review-E; nothing merges with red CI. Putting that logic in code, not in a prompt, is the difference between a pipeline that always works and one that mostly does.
Dev-E — implements issues
Role. The implementer. Given an issue and a target repo, Dev-E clones the repo, creates a feature branch, writes the code (plus tests and docs), runs the test suite, commits, pushes, and opens a pull request. It is the agent that does most of the actual coding.
Trigger. An "issue assigned" event from Conductor-E.
Produces. A feature branch, a pull request linked to the source issue, and a memory write summarising any non-obvious decisions for the next agent that touches the same area.
Dev-E ships in three flavours that share the same runtime image but mount different toolchains: a node variant for TypeScript and JavaScript work, a dotnet variant for the C# orchestrator and other .NET services, and a python variant for data and scripting work. Conductor-E picks the right variant based on the repo's primary language. The variants are otherwise identical; the same agent character sees the same memories regardless of which toolchain is loaded.
Review-E — the independent reviewer
Role. Reviews every pull request the implementer agents open. Review-E reads the diff, the linked issue, the relevant docs, and any memory entries that match the touched code, then either approves the PR or requests specific changes. By design, Review-E is a different agent from Dev-E: an implementer cannot approve its own work.
Trigger. A cron tick every few minutes that polls Conductor-E for unreviewed PRs in the org.
Produces. A GitHub review with verdict and inline comments, plus a review-result event back to Conductor-E. If changes are requested, Dev-E picks the PR back up. If approved and CI is green, Conductor-E merges.
The independence matters. Reviewing your own pull requests is the kind of thing humans are bad at and LLMs are even worse at — the model has already convinced itself the code is correct once. A separate agent with a separate memory and a different prompt brings genuinely different attention.
iBuild-E — iOS builds
Role. Same job as Dev-E, but for iOS apps. Building and testing iOS code requires Xcode, which requires macOS, which means iBuild-E cannot live in the same Linux Kubernetes cluster as the other agents. It runs on a Mac in our office instead.
Trigger. An "issue assigned" event from Conductor-E targeting an iOS repository.
Produces. Feature branches, pull requests, and (when needed) signed builds uploaded to App Store Connect.
iBuild-E is the agent that exposes how much the rest of the Rig benefits from running in a homogeneous Linux cluster. Everything iBuild-E does is harder: fewer images to choose from, slower scaling, OAuth tokens that need refreshing every few minutes via a cron job. The trade-off is unavoidable as long as iOS development is gated to macOS, but it is a useful counter-example whenever someone proposes adding another platform-specific agent.
Pi-E — the home-assistant agent
Role. An always-on conversational agent that lives on a Raspberry Pi, talks to the team via the shared chat channel, and runs small ambient tasks on a heartbeat. It is the agent most likely to start a conversation rather than wait to be summoned.
Trigger. Two sources. Direct messages and mentions in the chat channel; and a heartbeat that fires every thirty minutes asking "is there anything I should be doing right now?"
Produces. Replies in chat, status notes when long-running tasks change state, and the occasional question for the operator when something looks off.
Pi-E proves that an agent does not need a powerful host to be useful. The Pi has 8 GB of RAM and runs on solar-friendly idle power. The model itself runs in the cloud; the Pi is just the body that holds the personality and the heartbeat.
Volt-E — security research and always-on tasks
Role. The agent that handles long-horizon research tasks — security advisories, dependency audits, vulnerability triage, and anything else that benefits from running continuously rather than reactively. Where Dev-E is event-driven, Volt-E is patient.
Trigger. A scheduled cron and standing search filters. New CVEs in dependencies, new advisories from upstream maintainers, and periodic sweeps of the codebase.
Produces. Issues filed in the right repo, with a clear description of the risk, the affected versions, and a suggested fix path. Critical findings are escalated to the operator chat channel; routine ones queue for a normal Dev-E pickup.
Codi-E — the writer
Role. The agent behind the Codi-E blog. When something interesting happens in the Rig — a new pattern, a postmortem worth sharing, a build-log story — Codi-E turns it into a long-form post and opens a PR against this site.
Trigger. Operator request, or a scheduled review of recent activity that surfaces story candidates.
Produces. Blog posts in the same repository as this page, complete with table of contents, structured data, and the same style you are reading now.
Codi-E is also the test bed for the rest of the Rig. Long-form writing exercises the same memory, planning, and review loops that the implementer agents use, but the artifact is easier for humans to evaluate. If the writing reads well and the facts are right, the underlying machinery is probably healthy.
The human operator — the part of the loop the agents do not replace
Role. The person who sets direction, files the initial issues, watches the dashboard for things that look wrong, intervenes when an agent gets stuck, and approves anything that touches money, identity, or production data. The operator is not a fallback; the operator is the part of the loop the Rig is explicitly designed to keep.
Trigger. Whatever the operator decides. New product ideas. Bug reports from real users. Heartbeat questions from Pi-E. Pull request notifications. A weekly review of cost and queue depth. The operator is the only participant who chooses their own triggers.
Produces. Issues, decisions, and the occasional override. Most of the operator's day is review and direction-setting, not code. The agents handle the implementation; the operator handles taste, accountability, and the things that should never be automated — deciding what to build, deciding when something is good enough to ship to users, and deciding when to apologise to a user when it is not.
Planned: Architect-E and Ops-E
Two personas in development — portraits ready, runtime not yet. Architect-E takes long-horizon design work that does not fit a single issue: drafting the next major refactor, evaluating whether a new dependency belongs in the stack, writing the proposal that becomes a quarter of work for Dev-E. Ops-E watches the cluster and the agent fleet itself: scaling decisions, cost anomalies, certificate renewals, the boring maintenance that keeps the rest of the cast online.
How the cast works together
Reading the agents one by one makes them sound independent. They are not. Almost every interesting outcome in the Rig involves two or three of them in sequence. The next page in this section — one issue's life — walks a single ticket from operator filing to live deploy, naming every agent that touches it.
Deeper engineering reference for the cast — the runtime image, the configuration schema, the deployment manifests — is being prepared for public release. Check back soon.