Operating Model

    The Musubi operating model

    One human lead, two AI agents, a relay orchestrator, and a shared codebase. Build, then audit, then harden, then adapt — every cycle.

    Section 01

    The technical stack

    Who made what, and how the pieces connect.

    OpusClaude · AnthropicShared commsAppend-only file<OVER> = turn signalOrchestrator relaysCodaCodex · OpenAIHuman lead · approves

    Hover to watch the relay flow

    Asymmetric agents

    Opus brings product framing, design critique, and broad codebase reasoning. Coda is the ‘suspicious adult in the room’ — integration sceptic, surgical patches. The friction between them is the value.

    How the relay works

    1. Opus writes to the comms file, ends with <OVER>
    2. Orchestrator detects <OVER> and relays to Coda
    3. Coda reads the full file, acts, replies with <OVER>
    4. Cycle repeats; human watches and approves merges

    Section 02

    The daily cadence

    A sprint is a day. The sequence never breaks: build, then audit, then harden, then adapt.

    Dev sprint

    Build one thing. Green CI before merge. No "while I'm here" refactors.

    Audit sprint

    Fresh context window. Read-only. Severity-ordered findings. Independent eyes.

    Harden sprint

    Close critical + high audit findings. Add the tests dev sprints skipped.

    Adapt sprint

    What did agents get wrong? What rule prevents it next time? Update CLAUDE.md.

    A representative week

    1. Mon

      Dev

      Build feature X

    2. Tue

      Dev

      Continue feature X

    3. Wed

      Audit

      Independent review — 3 findings

    4. Thu

      Harden

      Close findings, add tests

    5. Fri

      Adapt

      Update CLAUDE.md, plan next cycle

    Signs it's working

    • Each audit finds fewer critical items
    • Adapt changes get smaller over time
    • Same finding never appears twice
    • You can describe last week in five sentences

    Signs it's drifting

    • Audits get longer each cycle
    • Adapt sprints become defensive
    • Dev sprints stretch to 3+ days regularly
    • Cadence-log goes silent for weeks

    Section 03

    Communication protocol

    Every message has shape. Evidence-first format makes lying about progress structurally awkward.

    Action

    Exact command run, edit made, or NOT STARTED

    Evidence

    File paths, diffs, command output, PID — or "none"

    Result

    claimed · started · blocked · spawned · completed

    Next

    Next concrete action only

    Forbidden without evidence

    “about to” · “prepping” · “gearing up” · “working on” · “handling” · “on disk”

    Execution state vocabulary

    claimed

    Slice assigned. No execution implied.

    started

    Concrete action occurred — file edited, command run, test executed.

    blocked

    Cannot proceed — named constraint required.

    spawned

    Real child execution context exists. Proof block required.

    confirmed_running

    Previously spawned context freshly verified.

    completed

    Artifact exists and validation threshold met.

    Section 04

    The improvement loop

    The meta-process is itself a deliverable. Every cycle, the system revises its own rules.

    A rule without a mechanism is a wish

    Run:<exact command>
    Expect:<exact output>
    Fail if:<observable condition>

    Evidence-shaped comms

    You cannot fill the Evidence line with vibes.

    Durable state before messages

    Capsule first, comms second. The message reports reality, not promises it.

    Asymmetric peer review

    When the reviewer's job is to find bugs in the other agent's optimism, ‘looks fine’ stops being a viable answer.

    Continue the read

    See how Musubi compares to the parallel, pipeline, and routing patterns everyone else is using.