A small lab for making bigger things.
01 / Our CMUX build
My CMUX build is a multi-agent orchestration harness: bounded Worker attempts produce immutable candidates, one canonical Engineer integrates them, and independent UI and Backend QA tie their verdicts to the same candidate hash. Agent self-certification is not acceptance.
Nine roles. Explicit boundaries.
Scope & acceptance
Turns the objective into bounded feature contracts and defines what counts as done.
Coordinates dependencies and delivery through Fleet PMs and Engineering PM, keeping final acceptance tied to Engineer and QA evidence.
Controls scope and acceptance; does not implement or direct Workers itself.
Candidate selection
Runs parallel Worker attempts and promotes one tested, compatible result.
Assigns bounded work, compares complete attempts and merges compatible, validated Worker results into a fleet-local candidate before promotion.
Consolidates its own fleet’s candidate—not the cumulative build. Worker self-certification is not proof.
Readiness & repair
Decides what is ready to integrate and what needs another repair pass.
Maintains the Engineering queue, identifies blockers, routes promoted candidates to the sole Engineer and coordinates both QA lanes.
Owns technical readiness and routing, not the canonical integration itself.
One integration writer
Combines promoted work into the single candidate that independent QA will judge.
Alone writes the cumulative integration candidate from promoted fleet-local results, preserving provenance and running deterministic checks before QA.
Accepts routed, immutable candidates; cannot approve its own result or issue QA verdicts.
Independent interface review
Tests what a person can see and use, without changing the implementation.
Checks live interactions, responsive layout, accessibility and visual requirements against the exact immutable Engineer candidate.
Issues a verdict tied to that candidate’s hash. Never edits or integrates it.
Independent systems review
Checks behaviour and contracts beneath the interface with reproducible evidence.
Evaluates deterministic tests, security, reliability and regressions against the exact immutable Engineer candidate.
Issues a verdict tied to that candidate’s hash. Never edits or integrates it.
Architecture & state
Builds an isolated candidate around clear architecture and a reliable source of truth.
Works on state, APIs, data flow, configuration and runtime boundaries, making the result straightforward for Fleet PM to verify and merge.
Produces a Worker candidate; does not claim final acceptance.
Interfaces & handoffs
Proves that separate parts exchange data correctly before canonical integration.
Builds an isolated candidate addressing schemas, paths, field names, adapters and compatibility failures at system seams.
Fixes the connections; only the canonical Engineer integrates final Fleet output.
Interaction & accessibility
Turns a candidate’s interface into a flow that is clear and safe for people to use.
Makes concrete changes to UI, copy, layout, interaction and code, with accessibility and product feel as implementation concerns.
Fleet PM and deterministic gates judge the candidate. This role is not independent UI QA.
Each Worker fleet has three Workers and a Worker PM. Engineering has its own PM, one Engineer, and paired UI and Backend QA.
Swipe or scroll sideways to see Engineering and QA →
02 / The hardware
The physical side of my lab.
03 / The workflows
Planning, parallel work, testing and review—one handoff at a time.
Follow the forward path, then the checks that send work back.
Scroll across to follow the full diagram.
Support, Product and Engineer feed Kanban Ticket. The ticket enters planning through Engineer Prompt or the advanced teams bypass, then proceeds through Status: Planning, Scout Agent, Plan Agent and Status: Building.
Scroll across to follow the full diagram.
Build Worktree Code sends an engineer prompt into three parallel planner, build, test and review lanes. Failed tests return to Build Agent; failed reviews return to Planner Agent. Passed reviews converge at Merge and continue to Ship.
Scroll across to follow the full diagram.
Engineer Prompt sends to Planner Agent, which returns review to Engineer Prompt and sends to Build Agent. Build Agent sends to Test Agent; test failure returns to Build Agent. Test pass proceeds to Engineer Review; review failure returns to Planner Agent, while review pass proceeds to Ship.
Scroll across to follow the full diagram.
Engineer Prompt feeds Build Agent, then Lint Code, Format Code, Test Code and Engineer Review. Each code check passes forward or fails back to Build Agent.
Scroll across to follow the full diagram.
Engineer Prompt feeds Build Agent, then Lint Code, Format Code and Engineer Review. Lint and format failures each return to Build Agent; passes proceed forward.
Scroll across to follow the full diagram.
Engineer Prompt feeds Build Agent and Lint Code. Lint failure returns to Build Agent, while pass proceeds to Engineer Review.
Scroll across to follow the full diagram.
Your actors of value creation branches to Engineers, Agents and Code.
Scroll across to follow the full diagram.
Five compounding investments for senior engineers: Agent Harness, Software Factory, Extensible Software, Always On Agents and Agentic Access. The source groups five numbered pillars without directional relationships.
Scroll across to follow the full diagram.
A Kanban ticket enters the Sandbox through Engineer Prompt or the advanced teams bypass, then moves through planning, scouting, building, testing and CI/CD. Test and CI/CD failures return to Build Agent; Engineer Review either returns work to the Sandbox or passes it to Ship.