We’ve been experimenting with how to run larger builds across multiple Claude Code chats without letting scope, context, and decisions turn into a mess. The model we’ve settled on is one coordinator, many executors . One Claude chat owns the entire phase as the coordinator. It does not write code . It holds the plan, breaks the work into bounded units, writes the brief for each worker, handles anything workers kick back, and keeps the project status current in the repo. Each unit of work gets its own fresh chat and branch. The brief defines: the goal what is in scope what is explicitly out of scope the exit gate The worker builds to that gate and stops. If it finds something outside its scope, it doesn’t “helpfully” fix it. It hands it back to the coordinator with the file/function and what it found. The chats don’t talk to each other This is probably the part that runs against the current multi-agent trend. I am the communication channel. A worker reports back to me. I give that report to the coordinator. The coordinator decides what happens next, and I relay the instruction. It sounds slower than letting agents communicate directly, but in practice it gives me a very useful control point. No worker can widen its own scope, and I see every significant decision in plain language before it happens. Reviews happen in fresh context When the worker finishes, it stops. A different Claude chat that has never seen the implementation reviews the branch and returns findings by severity. The coordinator turns those findings into an amendment, the original worker fixes them, and the reviewer checks again. Once the normal review is clean, we do one capped multi-agent review . Fixed number of agents, one round. No recursive army of reviewers reviewing reviewers. Then I deploy and check production. We also never amend a reviewed commit. Anything changed after review gets another commit, which makes it very easy to see what changed between gates. Model cost follows the task We’ve also stopped treating every task as deserving the strongest model. The coordinator gets the strongest model because planning, architecture and scope decisions have the highest leverage. Implementation can run a tier below that. Mechanical checks can run cheaper still. The important rule is that quality stays fixed; model cost is the variable . If a cheaper model repeatedly misses a particular class of work, that work gets promoted to a stronger model and we document why. I also use Codex as another set of eyes on Claude’s work rather than treating Claude vs. Codex as an either/or decision. The repo is the memory The other big change has been moving anything important out of chat history. Rulings, status, hand-backs, review results and the operating procedure itself all land in the repo. The goal is that a completely fresh chat should be able to show up next month, read the current state, and continue the project without needing the previous conversation. That has probably been the biggest shift for me personally: I’m spending less time reading generated code and more time reading plans, resolving decisions, and checking what actually reached production. For larger AI-assisted builds, that seems like a much better place for the human to sit. I wrote up the full version of the workflow, including the review ladder and how we’re handling hand-backs, here: https://www.reddit.com/r/Ordovee/comments/1wmprdu/how_were_running_multichat_ai_development_at/ submitted by /u/PartHaven
Originally posted by u/PartHaven on r/ClaudeCode