Skip to content
Rig Docs

Brain and Memory — architecture for autonomous engineering

For engineering leadership across the orgs using the rig. The rig is a shared autonomous-engineering platform. Two orgs build on it today — more to follow. Each project in each org gets the same agents, the same dispatcher, the same memory — and its own project brain.

TL;DR: a human labels a GitHub issue agent-ready; minutes later a reviewed, CI-green PR is merged. Measured today: 20 min issue→merge, $0.62/task, 0 human interventions.

The claim in one picture

Section titled “The claim in one picture”
flowchart LR
    H["🧑 Human<br/>any product team"] -->|"issue + label<br/>agent-ready"| GH[GitHub]
    GH --> R{Rig}
    R -->|"minutes later"| M[["✅ Merged PR<br/>CI green"]]
    R -.->|event stream| OBS[("Audit log<br/>cost, turns<br/>quality")]

    style R fill:#f9f,stroke:#333,stroke-width:2px
    style M fill:#dfd,stroke:#333,stroke-width:2px
View Mermaid source
flowchart LR
    H["🧑 Human<br/>any product team"] -->|"issue + label<br/>agent-ready"| GH[GitHub]
    GH --> R{Rig}
    R -->|"minutes later"| M[["✅ Merged PR<br/>CI green"]]
    R -.->|event stream| OBS[("Audit log<br/>cost, turns<br/>quality")]

    style R fill:#f9f,stroke:#333,stroke-width:2px
    style M fill:#dfd,stroke:#333,stroke-width:2px

One labeled issue in. One merged, reviewed, audited change out. Between them: agents read the brain, consult memory, emit events.

1 · Two modes of use

Section titled “1 · Two modes of use”

The rig serves two audiences at once — and the same agents do both.

flowchart LR
    subgraph M1["🔧 Mode 1 · Building the rig"]
        direction TB
        M1a[Issues on rig repos]
        M1b[rig brain = canonical]
        M1c[PRs to rig-agent-runtime,<br/>rig-conductor, etc.]
    end
    subgraph M2["📦 Mode 2 · Building products"]
        direction TB
        M2a[Issues on product repos]
        M2b[project brain = canonical]
        M2c[PRs to product code<br/>across any org]
    end
    M1 -.->|"same agents<br/>same dispatcher<br/>same memory"| M2

    style M1 fill:#e3f2fd,stroke:#1976d2
    style M2 fill:#fce4ec,stroke:#c2185b
View Mermaid source
flowchart LR
    subgraph M1["🔧 Mode 1 · Building the rig"]
        direction TB
        M1a[Issues on rig repos]
        M1b[rig brain = canonical]
        M1c[PRs to rig-agent-runtime,<br/>rig-conductor, etc.]
    end
    subgraph M2["📦 Mode 2 · Building products"]
        direction TB
        M2a[Issues on product repos]
        M2b[project brain = canonical]
        M2c[PRs to product code<br/>across any org]
    end
    M1 -.->|"same agents<br/>same dispatcher<br/>same memory"| M2

    style M1 fill:#e3f2fd,stroke:#1976d2
    style M2 fill:#fce4ec,stroke:#c2185b

Mode 1 — the rig improves itself. Every feature of the rig today was shipped by the rig. Self-hosting is a test, not a slogan — if an agent can’t land a PR on its own codebase, it can’t land one on yours.

Mode 2 — product teams ship faster. Each project has its own brain (repos, stack, conventions). Agents read the rig brain first, then the project brain. Product teams never touch rig internals.

2 · Why two stores — brain and memory

Section titled “2 · Why two stores — brain and memory”

The rig separates knowledge into two deliberately different stores.

flowchart TB
    subgraph BR["🧠 BRAIN — canonical"]
        B1[How the rig works]
        B2[Repos, stacks, deploy paths]
        B3[Event types, conventions]
        B4[Known gaps + prior art]
    end
    subgraph MM["💾 MEMORY — operational"]
        M1[Agent learnings]
        M2[Errors and gotchas]
        M3[Patterns observed]
        M4[Decisions, with why]
    end
    BR -->|"teaches<br/>rules"| A["🤖 Agent"]
    MM -->|"recalls<br/>experience"| A
    A -->|"write after work"| MM
    A -.->|"never writes to"| BR
    PL["📋 Weekly lint"]
    MM -->|"importance ≥ 4<br/>hit_count ≥ 5"| PL
    PL -->|"promote via PR"| BR

    style BR fill:#e3f2fd,stroke:#1976d2
    style MM fill:#fff3e0,stroke:#f57c00
    style A fill:#f3e5f5,stroke:#7b1fa2
    style PL fill:#e8f5e9,stroke:#388e3c
View Mermaid source
flowchart TB
    subgraph BR["🧠 BRAIN — canonical"]
        B1[How the rig works]
        B2[Repos, stacks, deploy paths]
        B3[Event types, conventions]
        B4[Known gaps + prior art]
    end
    subgraph MM["💾 MEMORY — operational"]
        M1[Agent learnings]
        M2[Errors and gotchas]
        M3[Patterns observed]
        M4[Decisions, with why]
    end
    BR -->|"teaches<br/>rules"| A["🤖 Agent"]
    MM -->|"recalls<br/>experience"| A
    A -->|"write after work"| MM
    A -.->|"never writes to"| BR
    PL["📋 Weekly lint"]
    MM -->|"importance ≥ 4<br/>hit_count ≥ 5"| PL
    PL -->|"promote via PR"| BR

    style BR fill:#e3f2fd,stroke:#1976d2
    style MM fill:#fff3e0,stroke:#f57c00
    style A fill:#f3e5f5,stroke:#7b1fa2
    style PL fill:#e8f5e9,stroke:#388e3c
BrainMemory
Who writesHumans via PR reviewAgents, inline, ungated
AuthorityWins on conflictSubordinate
RetrievalDeterministic (path)Semantic (vector)
Age-outNever (versioned)30 days if unused
Typical content”User stories live in GitHub issues with agent-ready label""Editing astro.config.mjs — run npm run build locally first, JS-in-MD quirk breaks deploy”

Why not one? Brain-only: every task starts fresh, mistakes repeat. Memory-only: noise accumulates, no authority when stores disagree. Together: brain teaches, memory learns, the weekly promotion pipeline makes the brain smarter without letting it go stale.

3 · System anatomy

Section titled “3 · System anatomy”
flowchart TB
    H["🧑 Human"] -->|issue + label| GH[GitHub]
    GH -->|webhook| CE["rig-conductor<br/>event store"]
    CE -->|XADD| VK["Valkey streams<br/>per-agent queues"]
    VK -->|KEDA<br/>scale 0→1| DE["rig-dev pod<br/>node / python / dotnet"]
    VK -->|KEDA| RE["rig-reviewer pod"]
    VK -->|KEDA| IE["rig-macos<br/>on a Mac node"]
    DE -->|cold start| BR["/BRAIN.md"]
    RE -->|cold start| BR
    DE -->|MCP| MEM[("Memory MCP<br/>pgvector")]
    RE -->|MCP| MEM
    DE -->|PR created| GH
    RE -->|review posted| GH
    GH -->|PR_CREATED<br/>REVIEW_PASSED| CE
    GH -.->|merge| MAIN[["main branch"]]
    CE --> PG[(Postgres<br/>event store)]
    CE --> DASH["📊 Dashboard<br/>built-in SPA"]

    style BR fill:#e3f2fd,stroke:#1976d2
    style MEM fill:#fff3e0,stroke:#f57c00
    style CE fill:#f3e5f5,stroke:#7b1fa2
    style MAIN fill:#c8e6c9,stroke:#388e3c
View Mermaid source
flowchart TB
    H["🧑 Human"] -->|issue + label| GH[GitHub]
    GH -->|webhook| CE["rig-conductor<br/>event store"]
    CE -->|XADD| VK["Valkey streams<br/>per-agent queues"]
    VK -->|KEDA<br/>scale 0→1| DE["rig-dev pod<br/>node / python / dotnet"]
    VK -->|KEDA| RE["rig-reviewer pod"]
    VK -->|KEDA| IE["rig-macos<br/>on a Mac node"]
    DE -->|cold start| BR["/BRAIN.md"]
    RE -->|cold start| BR
    DE -->|MCP| MEM[("Memory MCP<br/>pgvector")]
    RE -->|MCP| MEM
    DE -->|PR created| GH
    RE -->|review posted| GH
    GH -->|PR_CREATED<br/>REVIEW_PASSED| CE
    GH -.->|merge| MAIN[["main branch"]]
    CE --> PG[(Postgres<br/>event store)]
    CE --> DASH["📊 Dashboard<br/>built-in SPA"]

    style BR fill:#e3f2fd,stroke:#1976d2
    style MEM fill:#fff3e0,stroke:#f57c00
    style CE fill:#f3e5f5,stroke:#7b1fa2
    style MAIN fill:#c8e6c9,stroke:#388e3c

Each component owns one concern.

ComponentRoleTech
rig-conductorEvent store + dispatchC# / Marten / Postgres
Valkey streamsPer-agent queuesRedis-compatible streams
Agent podsDo the workNode runtime + Claude Code CLI
Memory MCPVector-searchable learningsPostgres + pgvector + MCP
BrainCanonical truth, compiledYAML → markdown → Cloudflare Pages
DashboardHuman observabilitySingle-page HTML, /dashboard

4 · The execution loop

Section titled “4 · The execution loop”

Every issue follows the same deterministic path.

sequenceDiagram
    actor H as Human
    participant GH as GitHub
    participant CE as rig-conductor
    participant DE as rig-dev
    participant BR as Brain
    participant MEM as Memory
    participant RE as rig-reviewer

    H->>GH: issue + label agent-ready
    GH->>CE: webhook
    CE->>CE: emit ISSUE_APPROVED
    CE->>DE: assignment (Valkey stream)
    DE->>BR: WebFetch BRAIN.md (session start)
    DE->>MEM: read_memories(repo, topic)
    DE->>DE: code, branch, push
    DE->>GH: open PR
    GH->>CE: PR_CREATED
    CE->>RE: assignment (Valkey stream)
    RE->>BR: WebFetch BRAIN.md
    RE->>MEM: read_memories
    RE->>GH: post review
    alt APPROVED
        GH->>GH: auto-merge
        GH->>CE: MERGED
        RE->>MEM: write_memory(learning)
    else CHANGES_REQUESTED
        GH->>CE: REVIEW_DISPUTED
        CE->>DE: follow-up assignment
        DE->>GH: push fix
        Note over DE,RE: iterate until approved
    end
View Mermaid source
sequenceDiagram
    actor H as Human
    participant GH as GitHub
    participant CE as rig-conductor
    participant DE as rig-dev
    participant BR as Brain
    participant MEM as Memory
    participant RE as rig-reviewer

    H->>GH: issue + label agent-ready
    GH->>CE: webhook
    CE->>CE: emit ISSUE_APPROVED
    CE->>DE: assignment (Valkey stream)
    DE->>BR: WebFetch BRAIN.md (session start)
    DE->>MEM: read_memories(repo, topic)
    DE->>DE: code, branch, push
    DE->>GH: open PR
    GH->>CE: PR_CREATED
    CE->>RE: assignment (Valkey stream)
    RE->>BR: WebFetch BRAIN.md
    RE->>MEM: read_memories
    RE->>GH: post review
    alt APPROVED
        GH->>GH: auto-merge
        GH->>CE: MERGED
        RE->>MEM: write_memory(learning)
    else CHANGES_REQUESTED
        GH->>CE: REVIEW_DISPUTED
        CE->>DE: follow-up assignment
        DE->>GH: push fix
        Note over DE,RE: iterate until approved
    end

Verified today: full loop, issue → merged, 20 min, 0 human interventions. rig-dev auto-response to CHANGES_REQUESTED: 87 seconds.

5 · Scaling to many projects

Section titled “5 · Scaling to many projects”

Same agents, same dispatcher, same memory — but a project brain per portfolio.

flowchart TB
    subgraph RIG["🧠 RIG BRAIN · invariant across orgs"]
        RG["Agents, dispatch, events, conventions<br/>research.rig.dashecorp.com/BRAIN.md"]
    end
    subgraph PROJ["📦 PROJECT BRAINS · one per portfolio"]
        PA["Org A · product 1<br/>a1-docs.pages.dev/BRAIN.md"]
        PB["Org A · product 2<br/>a2-docs.pages.dev/BRAIN.md"]
        PC["Org B · product 1<br/>b1-docs.pages.dev/BRAIN.md"]
        PD["Future<br/>xyz-docs.pages.dev/BRAIN.md"]
    end
    subgraph AGENTS["🤖 Shared agents"]
        A1[rig-dev]
        A2[rig-reviewer]
        A3[rig-macos]
    end
    RG --> A1 & A2 & A3
    PA -.-> A1 & A2 & A3
    PB -.-> A1 & A2 & A3
    PC -.-> A1 & A2 & A3
    PD -.-> A1 & A2 & A3

    style RIG fill:#e3f2fd,stroke:#1976d2
    style PROJ fill:#fce4ec,stroke:#c2185b
    style AGENTS fill:#f3e5f5,stroke:#7b1fa2
View Mermaid source
flowchart TB
    subgraph RIG["🧠 RIG BRAIN · invariant across orgs"]
        RG["Agents, dispatch, events, conventions<br/>research.rig.dashecorp.com/BRAIN.md"]
    end
    subgraph PROJ["📦 PROJECT BRAINS · one per portfolio"]
        PA["Org A · product 1<br/>a1-docs.pages.dev/BRAIN.md"]
        PB["Org A · product 2<br/>a2-docs.pages.dev/BRAIN.md"]
        PC["Org B · product 1<br/>b1-docs.pages.dev/BRAIN.md"]
        PD["Future<br/>xyz-docs.pages.dev/BRAIN.md"]
    end
    subgraph AGENTS["🤖 Shared agents"]
        A1[rig-dev]
        A2[rig-reviewer]
        A3[rig-macos]
    end
    RG --> A1 & A2 & A3
    PA -.-> A1 & A2 & A3
    PB -.-> A1 & A2 & A3
    PC -.-> A1 & A2 & A3
    PD -.-> A1 & A2 & A3

    style RIG fill:#e3f2fd,stroke:#1976d2
    style PROJ fill:#fce4ec,stroke:#c2185b
    style AGENTS fill:#f3e5f5,stroke:#7b1fa2

At session start, an agent picks up an assignment, reads its repo’s org, and fetches both brains (rig + matching project). Zero agent duplication; each project owns its own truth.

Responsibility split

Section titled “Responsibility split”
flowchart LR
    subgraph RM["🛠 Rig maintainer team"]
        r1[Agent runtime]
        r2[Event store + dispatch]
        r3[Rig-wide conventions]
        r4[Security + audit]
    end
    subgraph PO["🎯 Project owner team"]
        p1[Own repos + stack]
        p2[Project brain content]
        p3[Product roadmap]
        p4[Release decisions]
    end
    RM -.->|"service<br/>infrastructure"| SHARED((Rig))
    PO -.->|"what to build"| SHARED

    style RM fill:#e3f2fd,stroke:#1976d2
    style PO fill:#fce4ec,stroke:#c2185b
View Mermaid source
flowchart LR
    subgraph RM["🛠 Rig maintainer team"]
        r1[Agent runtime]
        r2[Event store + dispatch]
        r3[Rig-wide conventions]
        r4[Security + audit]
    end
    subgraph PO["🎯 Project owner team"]
        p1[Own repos + stack]
        p2[Project brain content]
        p3[Product roadmap]
        p4[Release decisions]
    end
    RM -.->|"service<br/>infrastructure"| SHARED((Rig))
    PO -.->|"what to build"| SHARED

    style RM fill:#e3f2fd,stroke:#1976d2
    style PO fill:#fce4ec,stroke:#c2185b

Today both roles sit in the same org as the rig matures. The architecture is already shaped for one rig per org once each tenant is ready to stand on its own.

6 · Onboarding a new project — five steps

Section titled “6 · Onboarding a new project — five steps”
flowchart LR
    S1["1 · Create<br/>&lt;project&gt;-docs<br/>from template"] --> S2["2 · Populate<br/>facts/*.yaml<br/>(repos, stack, team)"]
    S2 --> S3["3 · Deploy brain<br/>to Cloudflare Pages<br/>/BRAIN.md"]
    S3 --> S4["4 · Register<br/>in rig-conductor<br/>dispatcher config"]
    S4 --> S5["5 · Label issues<br/>agent-ready<br/>on project repos"]
    S5 -->|"rig operates<br/>autonomously"| LIVE((Live))

    style S1 fill:#fff9c4
    style S2 fill:#fff9c4
    style S3 fill:#fff9c4
    style S4 fill:#fff9c4
    style S5 fill:#fff9c4
    style LIVE fill:#c8e6c9,stroke:#388e3c,stroke-width:2px
View Mermaid source
flowchart LR
    S1["1 · Create<br/>&lt;project&gt;-docs<br/>from template"] --> S2["2 · Populate<br/>facts/*.yaml<br/>(repos, stack, team)"]
    S2 --> S3["3 · Deploy brain<br/>to Cloudflare Pages<br/>/BRAIN.md"]
    S3 --> S4["4 · Register<br/>in rig-conductor<br/>dispatcher config"]
    S4 --> S5["5 · Label issues<br/>agent-ready<br/>on project repos"]
    S5 -->|"rig operates<br/>autonomously"| LIVE((Live))

    style S1 fill:#fff9c4
    style S2 fill:#fff9c4
    style S3 fill:#fff9c4
    style S4 fill:#fff9c4
    style S5 fill:#fff9c4
    style LIVE fill:#c8e6c9,stroke:#388e3c,stroke-width:2px

Time to first autonomous merge on a new project: a few hours — mostly populating project brain content. The infrastructure already exists.

7 · Trust model

Section titled “7 · Trust model”

Three concentric defenses before a change reaches production.

flowchart TB
    subgraph L3["3 · Branch protection"]
        B1[rig-reviewer approval required]
        B2[CI green required]
        B3[rig-conductor server-side gate]
    end
    subgraph L2["2 · rig-reviewer in-band"]
        R1[Reads PR diff]
        R2[Applies brain conventions]
        R3[Closes issue required]
        R4[Test coverage check]
    end
    subgraph L1["1 · Agent scope"]
        A1[Short-lived GitHub token]
        A2[Scoped repo access]
        A3[No prod deploy creds]
        A4[Every tool call audited]
    end
    WORK((Agent work)) --> L1 --> L2 --> L3 --> MERGED["✅ Merged"]

    style L1 fill:#fff3e0
    style L2 fill:#ffe0b2
    style L3 fill:#ffccbc
    style MERGED fill:#c8e6c9
View Mermaid source
flowchart TB
    subgraph L3["3 · Branch protection"]
        B1[rig-reviewer approval required]
        B2[CI green required]
        B3[rig-conductor server-side gate]
    end
    subgraph L2["2 · rig-reviewer in-band"]
        R1[Reads PR diff]
        R2[Applies brain conventions]
        R3[Closes issue required]
        R4[Test coverage check]
    end
    subgraph L1["1 · Agent scope"]
        A1[Short-lived GitHub token]
        A2[Scoped repo access]
        A3[No prod deploy creds]
        A4[Every tool call audited]
    end
    WORK((Agent work)) --> L1 --> L2 --> L3 --> MERGED["✅ Merged"]

    style L1 fill:#fff3e0
    style L2 fill:#ffe0b2
    style L3 fill:#ffccbc
    style MERGED fill:#c8e6c9

The human gate is the agent-ready label. Nothing without it gets dispatched. That label is the human’s explicit “yes, work on this.”

8 · Live evidence — 2026-04-19

Section titled “8 · Live evidence — 2026-04-19”

Three autonomous merges in a 70-minute window, all observable in Postgres events.

timeline
    title Three autonomous merges in a 70-minute window
    0753 UTC : rig-docs PR 26 merged — manual XADD, rig-reviewer CHANGES, rig-dev fix 87s, auto-merge
    0819 UTC : rig-docs PR 30 merged — full agent-ready flow, 20-minute cycle
    0846 UTC : rig-agent-runtime PR 92 merged — checksum annotation, self-healing landed
View Mermaid source
timeline
    title Three autonomous merges in a 70-minute window
    0753 UTC : rig-docs PR 26 merged — manual XADD, rig-reviewer CHANGES, rig-dev fix 87s, auto-merge
    0819 UTC : rig-docs PR 30 merged — full agent-ready flow, 20-minute cycle
    0846 UTC : rig-agent-runtime PR 92 merged — checksum annotation, self-healing landed

Quoting rig-reviewer’s review on the first PR:

Delivery-chain test: ✅ CONFIRMED. Fetched https://research.rig.dashecorp.com/BRAIN.md at session start and got v5 content — TokenUsageProjection deployed, 40+ rig-conductor event types, Dashboard at /dashboard (42 KB SPA). Chain is live.

She then caught two real bugs in that PR, applying the fresh brain content. rig-dev-node fixed both in 87 seconds. Auto-merge after re-approval.

Cost attribution

Section titled “Cost attribution”

Every LLM call emits TOKEN_USAGE. Per-task cost is queryable.

flowchart LR
    A[Agent call] -->|TOKEN_USAGE event| CE[rig-conductor]
    CE -->|Marten projection| P[(daily_agent_costs)]
    P -->|GET /api/costs/*| D[Dashboard]
    P -->|future| AL[Alerts]

    style P fill:#fff3e0
    style D fill:#e3f2fd
View Mermaid source
flowchart LR
    A[Agent call] -->|TOKEN_USAGE event| CE[rig-conductor]
    CE -->|Marten projection| P[(daily_agent_costs)]
    P -->|GET /api/costs/*| D[Dashboard]
    P -->|future| AL[Alerts]

    style P fill:#fff3e0
    style D fill:#e3f2fd

Typical: ~$0.62/task (mixed reviews + fixes). Scales with task complexity, not linearly.

9 · What’s built vs what’s next

Section titled “9 · What’s built vs what’s next”
flowchart TB
    subgraph D["✅ Deployed · live today"]
        D1[Event store + dispatcher]
        D2[Valkey streams + KEDA]
        D3[rig-dev / rig-reviewer / rig-macos runtimes]
        D4[Memory MCP]
        D5[Brain compiled + served]
        D6[Cost tracking + Dashboard]
        D7[Self-healing ConfigMap rollout]
    end
    subgraph P["🟡 Partial · works with gaps"]
        P1[OTel Collector · rig-conductor only]
        P2[rig-reviewer auto-dispatch · agent PRs only]
        P3[Memory promotion · design done, cron pending]
    end
    subgraph X["📋 Planned · next quarter"]
        X1[Multi-project brain · two-layer]
        X2[LiteLLM proxy · per-project budgets]
        X3[Docs → memory embedding]
        X4[Langfuse traces]
        X5[External dashboard access]
    end
    subgraph A["🔭 Aspirational · further out"]
        A1[Weekly quality evaluator]
        A2[Complex refactor capability]
        A3[Multi-runtime · Codex + Gemini]
    end

    style D fill:#e8f5e9,stroke:#388e3c
    style P fill:#fff8e1,stroke:#f9a825
    style X fill:#e3f2fd,stroke:#1976d2
    style A fill:#f3e5f5,stroke:#7b1fa2
View Mermaid source
flowchart TB
    subgraph D["✅ Deployed · live today"]
        D1[Event store + dispatcher]
        D2[Valkey streams + KEDA]
        D3[rig-dev / rig-reviewer / rig-macos runtimes]
        D4[Memory MCP]
        D5[Brain compiled + served]
        D6[Cost tracking + Dashboard]
        D7[Self-healing ConfigMap rollout]
    end
    subgraph P["🟡 Partial · works with gaps"]
        P1[OTel Collector · rig-conductor only]
        P2[rig-reviewer auto-dispatch · agent PRs only]
        P3[Memory promotion · design done, cron pending]
    end
    subgraph X["📋 Planned · next quarter"]
        X1[Multi-project brain · two-layer]
        X2[LiteLLM proxy · per-project budgets]
        X3[Docs → memory embedding]
        X4[Langfuse traces]
        X5[External dashboard access]
    end
    subgraph A["🔭 Aspirational · further out"]
        A1[Weekly quality evaluator]
        A2[Complex refactor capability]
        A3[Multi-runtime · Codex + Gemini]
    end

    style D fill:#e8f5e9,stroke:#388e3c
    style P fill:#fff8e1,stroke:#f9a825
    style X fill:#e3f2fd,stroke:#1976d2
    style A fill:#f3e5f5,stroke:#7b1fa2

Status ships with every merge — see rig-gitops/docs/whitepaper/implementation-status.md.

10 · What an onboarded team gets

Section titled “10 · What an onboarded team gets”

In → Out

Section titled “In → Out”
flowchart LR
    subgraph IN["Input"]
        I1[Well-scoped issue]
        I2[agent-ready label]
    end
    subgraph RIG["Rig (shared infrastructure)"]
        R1[Dispatch]
        R2[Code]
        R3[Review]
        R4[Merge]
    end
    subgraph OUT["Output"]
        O1[Merged PR on your repo]
        O2[Cost event for billing]
        O3[Memory written for next time]
    end
    IN --> RIG --> OUT

    style IN fill:#e3f2fd
    style OUT fill:#c8e6c9
    style RIG fill:#f3e5f5
View Mermaid source
flowchart LR
    subgraph IN["Input"]
        I1[Well-scoped issue]
        I2[agent-ready label]
    end
    subgraph RIG["Rig (shared infrastructure)"]
        R1[Dispatch]
        R2[Code]
        R3[Review]
        R4[Merge]
    end
    subgraph OUT["Output"]
        O1[Merged PR on your repo]
        O2[Cost event for billing]
        O3[Memory written for next time]
    end
    IN --> RIG --> OUT

    style IN fill:#e3f2fd
    style OUT fill:#c8e6c9
    style RIG fill:#f3e5f5

What changes in engineering practice

Section titled “What changes in engineering practice”
BeforeAfter
Engineer triages, implements, tests, opens PR, iterates on reviewEngineer writes issue; rig does the rest
PR review = mechanical + productPR review = product only (rig-reviewer handles mechanical)
Tribal knowledge in headsLearnings accumulate in Memory MCP

What stays with the product team

Section titled “What stays with the product team”
flowchart LR
    T["🎯 Product team"] --> P1[Product direction]
    T --> P2[Architecture decisions]
    T --> P3[Release judgment]
    T --> P4[Customer communication]
    T --> P5[Issue quality]

    style T fill:#fce4ec,stroke:#c2185b
View Mermaid source
flowchart LR
    T["🎯 Product team"] --> P1[Product direction]
    T --> P2[Architecture decisions]
    T --> P3[Release judgment]
    T --> P4[Customer communication]
    T --> P5[Issue quality]

    style T fill:#fce4ec,stroke:#c2185b

The rig is executional, not strategic. Keep what a product team should always keep.

Example 90-day adoption timeline

Section titled “Example 90-day adoption timeline”
gantt
    title First-tenant onboarding shape
    dateFormat YYYY-MM-DD
    section Phase 1 · Setup
    Project brain template + populate   :a1, 2026-04-20, 7d
    First dry-run on low-risk issue     :a2, after a1, 2d
    section Phase 2 · Graduated
    Small well-scoped issues            :b1, after a2, 21d
    Calibrate agent-ready discipline    :b2, after a2, 21d
    section Phase 3 · Scaled
    Feature development issues          :c1, 2026-05-20, 60d
    Cost dashboards + memory review     :c2, 2026-05-20, 60d
View Mermaid source
gantt
    title First-tenant onboarding shape
    dateFormat YYYY-MM-DD
    section Phase 1 · Setup
    Project brain template + populate   :a1, 2026-04-20, 7d
    First dry-run on low-risk issue     :a2, after a1, 2d
    section Phase 2 · Graduated
    Small well-scoped issues            :b1, after a2, 21d
    Calibrate agent-ready discipline    :b2, after a2, 21d
    section Phase 3 · Scaled
    Feature development issues          :c1, 2026-05-20, 60d
    Cost dashboards + memory review     :c2, 2026-05-20, 60d

Expected state at day 90: rig absorbing 50-80% of mechanical engineering on onboarded repos. The residual 20-50% is work that intentionally requires human judgment.

11 · Honest limits

Section titled “11 · Honest limits”
flowchart TB
    subgraph K["✅ Works well"]
        K1[Bug fixes]
        K2[Small features]
        K3[Documentation]
        K4[Bounded refactors]
        K5[Test additions]
    end
    subgraph S["⚠️ Works with caveats"]
        S1[Multi-file changes]
        S2[Non-obvious fixes]
        S3[Workflow yml changes]
    end
    subgraph N["❌ Does not fit today"]
        N1[Large architectural refactors]
        N2[Production incidents]
        N3[Non-GitHub trackers]
        N4[Non-code work]
        N5[Long-horizon work >1 day]
    end

    style K fill:#e8f5e9,stroke:#388e3c
    style S fill:#fff8e1,stroke:#f9a825
    style N fill:#ffebee,stroke:#c62828
View Mermaid source
flowchart TB
    subgraph K["✅ Works well"]
        K1[Bug fixes]
        K2[Small features]
        K3[Documentation]
        K4[Bounded refactors]
        K5[Test additions]
    end
    subgraph S["⚠️ Works with caveats"]
        S1[Multi-file changes]
        S2[Non-obvious fixes]
        S3[Workflow yml changes]
    end
    subgraph N["❌ Does not fit today"]
        N1[Large architectural refactors]
        N2[Production incidents]
        N3[Non-GitHub trackers]
        N4[Non-code work]
        N5[Long-horizon work >1 day]
    end

    style K fill:#e8f5e9,stroke:#388e3c
    style S fill:#fff8e1,stroke:#f9a825
    style N fill:#ffebee,stroke:#c62828

Limits are known, measured, documented in the rig’s own backlog (facts/backlog.yaml). They shrink each quarter.

12 · Decisions before onboarding

Section titled “12 · Decisions before onboarding”

Three questions every onboarding team answers up front:

flowchart LR
    Q1["❓ What's the first repo?"] -.->|suggest| A1["A backend or internal tool<br/>with green CI. Avoid<br/>customer-facing for first month."]
    Q2["❓ Who owns the project brain?"] -.->|suggest| A2["One engineer primary;<br/>eng lead as reviewer;<br/>weekly review first month."]
    Q3["❓ Budget ceilings?"] -.->|suggest| A3["$50/day soft cap,<br/>$200/day hard cap,<br/>Discord alert at 80%."]

    style Q1 fill:#fff9c4
    style Q2 fill:#fff9c4
    style Q3 fill:#fff9c4
    style A1 fill:#e8f5e9
    style A2 fill:#e8f5e9
    style A3 fill:#e8f5e9
View Mermaid source
flowchart LR
    Q1["❓ What's the first repo?"] -.->|suggest| A1["A backend or internal tool<br/>with green CI. Avoid<br/>customer-facing for first month."]
    Q2["❓ Who owns the project brain?"] -.->|suggest| A2["One engineer primary;<br/>eng lead as reviewer;<br/>weekly review first month."]
    Q3["❓ Budget ceilings?"] -.->|suggest| A3["$50/day soft cap,<br/>$200/day hard cap,<br/>Discord alert at 80%."]

    style Q1 fill:#fff9c4
    style Q2 fill:#fff9c4
    style Q3 fill:#fff9c4
    style A1 fill:#e8f5e9
    style A2 fill:#e8f5e9
    style A3 fill:#e8f5e9

13 · Further reading

Section titled “13 · Further reading”

All authoritative; updates with every merge.

Naming note

Section titled “Naming note”

This document uses the target agent names: rig-conductor, rig-dev, rig-reviewer, rig-macos. The running deployment today still uses the original -E suffixes — rig-conductor, Dev-E, Review-E, iBuild-E — and the live brain at /BRAIN.md reflects that. A rename is tracked as follow-up work. Readers may see both forms in infrastructure code, Discord channels, and event payloads during the transition.