Running Claude Code in 4 Parallel Sessions Led to 'Team Development' — 7 Recipes to Prevent Collisions

An engineer at forge.workstyle.tech reports that running Claude Code in four parallel sessions led to autonomous 'team development' among AI agents, which both caused and prevented incidents similar to those in human teams. The post details seven recipes for preventing collisions, including declaring scope, using session-to-session messages, and maintaining a declarative deployment ledger, illustrated by a near-disaster where an agent almost deployed from the wrong branch.

📝 Originally published in Japanese at forge.workstyle.tech . In a previous article , we introduced an environment for parallel execution of coding agents using Git worktrees. This article is a follow-up. As we progressed with parallelization, we ended up with 3-5 Claude Code sessions simultaneously developing the same microservices . What happened was no longer just "parallel execution of tools" but actual "team development" . All the issues that arise in human teams—miscommunication, deployment conflicts, and territorial overlaps—occur here as well. And the practices that work for human teams work almost identically here. We’ll share seven recipes that emerged from actual operations, along with real-life close calls. One day, while Session A responsible for voice functionality was in the middle of a major refactor, Session B responsible for streaming functionality sent this message: "We’re about to build the frontend as version 1.0.399 based on main ." At first glance, this seemed fine. However, in this repository, the authoritative branch for the production environment was not main but a dedicated deployment branch . The latest features from the past few dozen versions were only in the deployment branch, while main was outdated. If Session B had deployed an image based on main, weeks’ worth of features would have been rolled back in production . Session A immediately sent a warning, and Session B halted the build before pushing. Session B then cherry-picked their changes into the deployment branch and rebuilt the image, avoiding the disaster entirely. All this communication was handled autonomously between the agents via session-to-session messages . I the human only learned about it later from the logs. This incident highlights two things: parallel agents can cause the same accidents as human teams , and with proper communication channels and rules, they can prevent accidents just like human teams . talk -related components, the streaming session handles broadcast -related components, and the phone session handles only the callgw directory. git status before committing."This is equivalent to a human team’s daily stand-up. Agents exchange session-to-session messages or use a shared notes file if messaging isn’t available to communicate: expressive voice.py and env . I won’t touch the prompt section in talk service.py ."The key is declaring the scope . By stating not only "what will be done" but also "what won’t be touched," other sessions can safely continue parallel work. In practice, this alone nearly eliminated file conflicts. Container image tags are shared namespace. If two sessions build different content with the same tag, say 1.0.399 , it leads to tag overwrite , a hard-to-detect issue we once experienced a nightmare where a chained command error overwrote an old tag with new content, causing behavior to persist even after a rollback . The root cause of the incident mentioned earlier was the assumption that main is the authoritative branch, which didn’t hold true for this repository. deploy/xxx in the operational notes or memory accessible to the agents. main and the authoritative branch diverge, main Consolidate "what’s running in which environment" into a declarative repository like Kubernetes manifests, and commit tag updates with each deployment. This ensures the ledger stays up-to-date regardless of which session deploys, allowing other sessions to check the current state without querying kubectl . If you directly modify environment variables e.g., kubectl set env , always update the ledger —drift can become a time bomb we once had to sync the ledger after encountering this issue . A unique risk in multi-session operations is permission circumvention . If one session is denied an operation, they might ask another session to do it instead, bypassing user permissions. In multi-day development, the session that created feature X and the session modifying it are often different. While code and commit logs provide information, asking the original session or its transcripts is the fastest way . For example, when we sent a question list to the session that authored the old implementation—asking about testing practices, pitfalls, and billing blind spots—we received operational knowledge not evident from the code e.g., "This timeout was increased from 600 to 1500 due to a past incident," "This external monitoring URL is useful" . This saved a full day of investigation. If transcripts and memory persist, treat past sessions as "colleagues at the next desk," not "retired colleagues." | Recipe | Equivalent in Human Teams | |---|---| | 1. Separate worktrees and responsibilities | Team division, code ownership | | 2. Pre-start notification, scope declaration | Daily stand-ups, task declarations | | 3. Tag reservation | Release number management | | 4. Document authoritative branch | Shared branching strategy | | 5. Version ledger | Release ledger, CMDB | | 6. Permission boundaries | Role definitions | | 7. Consult previous sessions | Handovers, pair programming | We’re moving from an era of optimizing single-session productivity to an era of designing multi-session coordination for overall productivity . And the blueprint for this design is remarkably similar to what software engineering has refined for human teams over decades. Before assigning roles or personalities to agents, focus on territories, communication, and ledgers . It’s mundane, but it dramatically reduces parallel operation accidents.