Multi-delegating, the build play run in parallel

The play is the retreat. Every block you build runs the same four moves: plan well, build small, build all, review. Run it once and you have a feature. Run it five times and you have a system. Run it without thinking and you have the muscle that makes the next project take a day instead of a month.

The second half is where the leverage compounds. One founder, one laptop, one afternoon: the dashboard building in one session, the nurture campaign in another, the agent in a third. Not because the AI is faster, but because you stopped waiting on one build to start the next.

The play: four moves, every time

Every build at the retreat runs the same play. The CRM. The dashboard. The nurture campaign. The agent. By the fourth time you do not need the handout.

• Plan well
  The interview writes the product plan and the Definition of Done. The PM agent writes the build plan for the AI: ordered steps, a visible check each, under two pages. Nothing is built until both exist.
• Build small
  The smallest thing that proves the whole loop. A form that writes one row and sends one email, live on a real URL. Not a prototype: a thin slice of the real system. If the thin slice does not work, the full build will not either.
• Build all
  The full system from the same plan, on a branch, with the developer agent working the steps top to bottom and stopping only when a check fails. You read the report, not the code.
• Review
  QA tests every line of the Definition of Done against the live site. PASS or FAIL with evidence. FAILs get fixed and re-tested. Nothing is marked passing that nobody observed. Then merge.

Multi-delegating: running the play in parallel

Once the play is a habit, the bottleneck is you waiting. A full build takes forty minutes of agent time and two minutes of your attention. Multi-delegating is spending those forty minutes starting the next build instead of watching this one.

It works because of worktrees (Protocol 05). Each Claude Code session gets its own copy of the repo on its own branch. The dashboard session and the nurture session never see each other's half-finished files. They each run the play. They each stop when a check fails or the Definition of Done passes. You check them in one at a time.

• One plan per build
  Each worktree runs from its own docs/plans file with its own Definition of Done. A build without a plan is not delegated, it is abandoned.
• Builds that do not share files
  The dashboard and the nurture campaign touch different tables and different pages. Run them together. Two builds that both edit the login page will collide; run those in sequence.
• Check in, do not hover
  Your job is the check-in: read the session's report, answer the question it stopped on, approve the merge. Ten minutes per build. Then the next one.
• Merge one at a time
  The first build to pass QA merges first. The second pulls main, re-runs its checks on the merged code, then merges. Never two merges at once; that is how you lose work.

Spawning new projects

The same move works one level up. A new project is a new folder with the canonical layout (Protocol 08), a new repo, a new Vercel project, and the play run from the start. Because every project has the same shape, the agents do not need to learn it; they already know where the plan lives and where the QA review goes.

Founders who run this well have three or four projects in flight at once and spend their day checking in, not building. That is the leverage curve. The agents hold the volume; you hold the judgment.

The play run twice at once, two branches merged in turn, no lost work. You have felt the moment the bottleneck moves from the agent to your own check-in cadence, which is the moment leverage becomes real.