Rig Agent Architecture — Dev-E, Review-E, iBuild-E¶

Overview¶

The rig is an automated development system. Three agent types work issues from backlog to production:

Agent	Platform	Responsibilities
Dev-E	k8s	Backend, infra, Node.js, .NET, docs
iBuild-E	Mac Mini	iOS/Swift, `requires-macos` issues
Review-E	k8s	Reviews all PRs independently

Conductor-E orchestrates all three agents: routing work, storing session IDs, and coordinating the event flow from issue assignment through to merge.

Session Persistence¶

Critical requirement: agents maintain Claude Code context from issue assignment through to merge.

claude --resume <session-id> continues an interrupted session with full context
Dev-E / Review-E: PVC per instance on k8s mounts ~/.claude/ — survives pod restarts
iBuild-E: local ~/.claude/ on Mac Mini persists naturally
Conductor-E event store keeps the session ID keyed to the active issue or PR
Sessions are cleared only after merge + smoke test (Phase 2+)

Agent Lifecycle¶

Dev-E / iBuild-E¶

ASSIGNED
  → WORK_STARTED        (save session-id to conductor-e)
  → implement
  → PR_CREATED          (suspend, watch for review events)

REVIEW_CHANGES_REQUESTED
  → resume session      (--resume <session-id>)
  → iterate
  → push                (suspend)

REVIEW_PASSED + CI_PASSED
  → human gate          (if required)
  → MERGED
  → DONE                (clear session)

Review-E¶

PR_READY
  → start session       (per PR, save session-id)
  → read diff + context
  → review
  → submit              (suspend)

Dev pushes changes
  → resume session      (--resume <session-id>)
  → re-review
  → approve             (suspend)

MERGED
  → clear session

Discord Integration¶

PR threads already exist in #tasks, created by request-review.yml
The thread ID is stored as a hidden PR comment so agents can look it up
Dev-E / iBuild-E post questions, progress updates, and blockers to the thread
Review-E posts review summaries to the thread
Humans respond in the thread — the agent resumes with the answer
Conductor-E coordination (routing decisions, health, cost) stays in #conductor-e

Routing¶

Conductor-E routes work based on GitHub labels:

Labels	Destination
`requires-macos` + `agent-ready`	iBuild-E queue
`agent-ready` (no `requires-macos`)	Dev-E queue
PR opened / updated	Review-E (via `request-review.yml`)

GitHub Apps¶

App	Agent	Permissions
dev-e-bot (new)	Dev-E	`contents:write`, `issues:write`, `pull_requests:write`, `workflows:write`
review-e-bot (existing)	Review-E	`contents:read`, `pull_requests:write`
ibuild-e-bot (existing)	iBuild-E	`contents:write`, `issues:write`, `pull_requests:write`, `workflows:write`

Event Flow¶

Conductor-E receives GitHub webhooks and emits internal events:

GitHub Webhook	Internal Event
PR opened	`PR_CREATED`
PR synchronized	`PR_UPDATED`
Review submitted (approved)	`REVIEW_PASSED`
Review submitted (changes requested)	`REVIEW_CHANGES_REQUESTED`
PR merged	`MERGED`
CI check completed (success)	`CI_PASSED`
CI check completed (failure)	`CI_FAILED`

Dev-E and iBuild-E executor loops poll the event store for events on their active issue. Review-E polls for events on its active PR.

Existing PR Pipeline Integration¶

The current GitHub Actions pipeline is unchanged:

request-review.yml — assigns Review-E, creates the Discord PR thread
forward-copilot-reviews.yml — posts Copilot inline comments to the thread
auto-merge.yml — merges when all checks pass
auto-resolve-copilot-conversations.yml — unblocks stale Copilot conversations

Agents integrate with this pipeline by:

Using the Discord thread created by request-review.yml (thread ID from hidden PR comment)
Monitoring PR status via gh CLI or GitHub API
Posting to threads via Discord webhook

Scaling¶

Agent	Instances	Where
Dev-E	1–3 (k8s replicas)	Dell k3s
iBuild-E	1	Mac Mini M4
Review-E	1	Dell k3s
Conductor-E	1	Dell k3s

Multiple Dev-E instances are safe: conductor-e API uses optimistic locking to prevent double-assignment of the same issue.

Runtime¶

All agents use automate-e as the base runtime:

Discord bot for conversation and thread posting
Claude Code CLI for implementation (--resume for context persistence, --dangerously-skip-permissions inside containers)
GitHub MCP tools for issue and PR operations
Heartbeats every 60s to the conductor-e API

iBuild-E uses agent-runner instead of automate-e but follows the same patterns for session persistence, Discord posting, and heartbeats.

Phases¶

Phase	Components	Status
1 — Current	Conductor-E running, coordination cron, cost tracking	Active
1b — Next	Dev-E on k8s, Review-E migrated to k8s, iBuild-E integrated	In design
2	Production deployment pipeline, smoke tests, session cleanup	Planned
3	Monitor-E 24/7, incident auto-response	Planned
4	Architect-E proposes features from production data	Future