Building Muxon has a serial plan that estimates six to nine weeks to the MVP. I want that shorter. Not by working more hours — by running more agents.

The bet is simple. Most of the implementation work is independent if the seams are decided first. A seam is anywhere two components meet: a trait signature, a proto envelope, an event type, a store schema. Once a seam is fixed, the two sides of it can be built in parallel without talking to each other.

Standard project plans do not work this way. They are ordered by release: ship a daemon, then a store, then directory binding, then a multiplexer trait, then a backend. Each release builds on the last. A single operator moves through them linearly. The ordering is habit — most of the dependencies are at the seam level, not the release level, and the seams can be decided in an afternoon.

The seam gate

The only work that must happen serially is the work that decides what the seams are. For Muxon that is one focused day:

• every ULID newtype in resurreccion-core
• every event type as a struct, because rt-events keys subscriptions on TypeId
• the proto envelope and the verb-name constants
• the Mux trait, including a sketch of how a second backend would implement it — if a hypothetical tmux implementation would be awkward, fix the trait now, not after it is shipped
• the Store signatures
• the Plan types

No business logic. Just shape.

This is the leverage gate. One hour spent sketching the second backend against the Mux trait saves weeks of trait churn when the second backend actually lands. The same logic applies to every other seam — the proto envelope, the event taxonomy, the fidelity lattice. Get the shape right once, compound it forever.

Ten lanes

With the seams locked, the work splits into ten lanes. Each one owns a crate or a slice of one. Each has crisp inputs from the seam sprint and crisp outputs — a compiled module with tests.

• A — store implementation
• B1 — daemon runtime
• B2 — workspace verbs
• B3 — snapshot verbs + event streaming
• C — CLI
• D — Zellij backend
• E — directory binding
• F — planner
• G — event bus and subscribers
• I — integration tests, smoke script, docs, release

The lanes do not talk to each other. They all talk to the seams. That is the whole trick.

No human in the middle

If ten agents write code in parallel, ten PRs land per day. I am not reviewing ten PRs per day by hand.

The workflow is four stages:

1. Implementation agent. Works in an isolated worktree; pushes a branch; opens a PR; enables auto-merge at creation.
2. Review agent. Fresh context, same model, independent conversation. Reads the diff against the lane spec. Flags seam violations, missing tests, scope creep, obvious bugs, rt-events callback discipline. Emits approve or request-changes via gh pr review.
3. CI. Format, clippy, tests, build. All required by branch protection.
4. Merge. GitHub merges the moment both gates are green.

The reviewer does not share memory with the implementer. Same model, new conversation. That is the cheapest practical substitute for human judgment against a spec. It is not perfect. It catches what a careful spec catches — which is why the specs live in TASKS.md with explicit Done when and Out of scope bullets per lane. A vague spec produces a vague review.

If a lane loops three times without green gates, it escalates to a human. The escalation usually does not mean the implementation is wrong. It means the seam was wrong for this lane’s problem — which is a Sprint 0 cost surfacing late, not a Sprint 1 cost.

What scales and what does not

The seam sprint does not scale with agent count. Neither does the integration pass at the end. Everything in between does.

For Phase 0 — roughly fourteen agent-days of focused work — the longest lane is about three days. Run all ten in parallel and the wall-clock shrinks to the slowest lane plus the seam sprint plus integration. Best case, four to five days. With one seam revision and a couple of integration bugs, seven to ten.

That is the design. Six weeks collapses to one. Maybe.

What I do not yet know

This is a design. It has not run. I am writing this before Sprint 0 starts. The next post will say what went wrong.

The failures I expect:

• A seam I thought was locked turns out not to be, and three lanes block on one core change.
• The reviewer agent approves something that CI was too weak to catch, and it merges anyway.
• Zellij’s CLI output format drifts underneath Lane D, and I find out via flaky tests.

Those are the ones I see. The interesting ones are the ones I do not.

The whole plan is an ante. The bet is that seams done well are worth ten lanes of parallel work, and the hour spent on each seam in Sprint 0 pays itself back many times in Sprint 1.

We will see.