The agents page describes the cast. This page tells the story. We will follow one realistic issue all the way through the Rig, naming every agent that touches it and every gate it has to pass. The example is composite — a typical day's work, not any one specific ticket — but every step is exactly how a real issue moves through the system today.
Filing the issue
The story starts with a person noticing something. In this case, the operator is reading the marketing site and realises there is no public page describing the Rig itself. Visitors who hear about the autonomous engineering platform have nowhere to land. The operator opens GitHub, picks the website repository, and files an issue.
The issue is not just a sentence. It includes the audience, the tone, the required pages, the constraints, and the acceptance criteria. The Rig is unforgiving toward vague tickets — an agent given a thin issue will produce a thin pull request — so the operator front-loads the specification. A good issue takes ten minutes to write and saves an hour of review later.
Once filed, the operator adds a label that means "ready for an agent to pick up" and walks away.
Dispatch
Within a few seconds, GitHub fires a webhook. Conductor-E receives it, normalises the payload into an internal event, and writes the event to the store. The same event is the trigger for the next decision: which agent should pick this up?
Conductor-E classifies the issue by inspecting the target repository's primary language, the labels, and any explicit "this needs the macOS variant" hints. The website repository is a static site — HTML, CSS, a sprinkling of JavaScript — so the answer is the node variant of Dev-E. Conductor-E writes an "issue assigned" event and notifies the chat channel.
If no agent is currently idle, that is fine. KEDA is watching the conductor's queue depth and will scale up another Dev-E pod within a minute. The agents are fungible at this layer; the work waits for the next free hands.
Implementation
Dev-E wakes up, reads the assignment, and begins the cold-start ritual that every fresh agent runs: fetch the rig brain, read any memories tagged for this repo, fetch the per-repo docs that are most likely to be relevant, and only then start work.
The cold start is deliberate. An agent that dives straight into code without first loading shared context will reinvent conventions, miss gotchas, and get blocked on things the rest of the team already solved. The brain fetch costs about thirty kilobytes and seconds; skipping it costs hours.
Once oriented, Dev-E creates a feature branch, drafts the new pages, runs the local checks the repository specifies, commits in conventional-commit form, and pushes the branch. It then opens a pull request that links back to the originating issue. The PR description includes a test plan and an explicit "Closes #N" line that the orchestrator will later use to confirm the ticket is satisfied.
Total elapsed time so far: usually under thirty minutes for a small change, an hour or two for something larger.
Review
The pull request notification flows back into Conductor-E, which performs the first round of automated gates: is there a linked issue? Are the required labels present? Did CI pass? If any answer is no, the PR is sent back with a specific reason. If everything is fine, the conductor records that the PR is ready for review.
Review-E polls for unreviewed PRs every few minutes. When it finds this one, it reads the diff, the linked issue, the conventions for this repository, and any memory entries tagged with the touched files. It then writes a structured review: a verdict, a summary of what the PR does, and inline comments where it sees problems.
If Review-E approves, the PR moves to the merge gate. If it requests changes, the PR bounces back to Dev-E, which reads the comments, makes the fixes, pushes another commit, and the cycle repeats. Most PRs go through one or two review rounds; some need none; a few stall and escalate to the operator.
Merge
Once Review-E has approved and CI is green, Conductor-E performs the merge itself via the GitHub API. The conductor merges, not the agents, because merging is the point in the pipeline where the rules must be unambiguous. The conductor checks one more time: approved review present, all required CI checks green, no manual-merge label, no unresolved review threads. If everything holds, the merge happens server-side. If anything fails, the merge does not happen and the conductor writes an event explaining why.
The branch is deleted automatically. The pull request is closed. The originating issue is closed via the "Closes #N" link. An event flows out of the conductor announcing that the merge happened.
Deploy
The merge to main triggers two parallel things. For the static website itself, a GitHub Actions workflow ships the new content to Cloudflare Pages within a few minutes; the new pages are live as soon as the deploy completes. For repositories that ship into the cluster, a GitOps controller picks up the change from the manifests repo and reconciles the cluster; a new container image rolls out and the old one drains away.
Either way, the deploy is itself an event. Conductor-E sees it, records it, and notifies the chat channel that the change is live.
Verification
Deploys are not "done." After every deploy, a smoke test hits the new URLs and confirms they return 200 with the expected content. For changes that touch interactive flows, an end-to-end suite runs against the live site. For visual or layout changes, accessibility checks run and report any regressions.
If any of those checks fail, an event flows back to Conductor-E, which can roll back, file a follow-up issue, or escalate to the operator depending on the severity. If everything passes, the issue moves to a final state and the chat channel gets a quiet "verified" note.
Closing the loop
The whole journey, for an issue the size of "add a marketing section," takes one to three hours of wall-clock time. The operator's involvement was filing the original issue and approving the merge by exception only — if Review-E had escalated, or if the smoke tests had failed, the operator would have stepped in. Otherwise the work happened while the operator was doing something else.
That is the shape of the pipeline. None of the individual steps are exotic on their own — webhook, branch, review, merge, deploy, verify — but stitched together with an event store and a small fleet of focused agents, they let one operator run an engineering team's worth of work.
Deeper technical docs — the engineering reference for each stage and the research, proposals, and decisions hub — are being prepared for public release. Check back soon.
And if you want the build-log version — the wrong fixes, the dead ends, the moments two agents had their first conversation — the Codi-E blog tells those stories one at a time.