Four Git Worktrees, One Shared Agent Budget

For a team running coding agents throughout the day, parallelism is a scheduling problem before it is a prompting problem. Three agents can finish three patches quickly and still leave a maintainer with conflicting migrations, incompatible interfaces, and an expensive integration queue. A stronger operating model uses four git worktrees: three bounded implementation lanes and one controlled integration lane.

01 · Allocate Three Implementation Lanes and One Integrator

Start from a freshly fetched, known-good commit. Record its hash in the task manifest, then create a separate branch and worktree for each assignment. For example, git worktree add -b agent/auth ../wt-auth BASE_COMMIT creates an authentication lane. Repeat for the other two assignments and create an integration branch from the same commit.

Launch each agent with its working directory explicitly set to its assigned worktree. Do not rely on a prompt to keep an agent out of another directory. Worktrees separate checked-out files, indexes, and branch state, but share repository objects and some metadata. They are not security boundaries; untrusted execution still needs containers or equivalent sandboxing.

02 · Partition by Change Ownership, Not Ticket Count

Give each lane a contract containing its objective, writable paths, interface assumptions, acceptance commands, and stop conditions. Assigning one agent the API, another its client, and a third the same shared schema invites coordination overhead unless the interface is frozen first.

• › Prefer independent boundaries: separate modules, distinct test suites, or unrelated fixes with minimal shared dependencies.
• › Reserve shared files: designate one owner for lockfiles, generated clients, migration numbering, and public type definitions.
• › Require escalation: an agent that needs changes outside its writable paths should propose them rather than silently expanding its task.

Have each agent report its base commit, changed files, tests executed, unresolved assumptions, and final commit hashes. This turns handoff into an inspectable artifact rather than a conversational summary.

03 · Isolate Runtime Resources Beyond the Checkout

Separate directories do not prevent two test processes from claiming the same port or deleting the same database. Allocate a unique port range, database namespace, temporary directory, and output directory to each lane. Scope environment files and credentials narrowly, and keep secrets outside tracked files.

Treat caches according to their actual concurrency guarantees. Share immutable downloads where supported, but avoid sharing mutable build outputs or tool state that assumes a single writer. If worktrees run in containers, mount only the resources each task needs and verify that test cleanup cannot reach another lane.

04 · Route Models Against Explicit Token Ceilings

Use model selection as a workload decision. A bounded fixture update might be a candidate for Claude Haiku 4.5, while a difficult cross-module change could justify evaluating Claude Opus 5.5. Validate those choices against your repository's acceptance tests rather than assuming that a model label predicts patch quality.

Quanta fits this setup when several agents need sustained access through one pay-as-you-go balance. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK integrations, letting the team centralize API spending while retaining its preferred tools. Open a Quanta account to put a measured pilot behind that shared balance.

Set per-lane token allowances, wall-clock deadlines, and retry limits in your orchestration layer. Every call is metered on real tokens, with cache writes and cache reads priced separately. Track those categories independently; repeated context is not automatically free, and cache reuse depends on the provider's rules and request structure. Keep stable instructions consistent where practical, but do not assume different agents share a cache.

05 · Merge Through a Single Tested Integration Queue

Require clean, committed handoffs. The integrator should inspect each diff, cherry-pick accepted commits in dependency order, and run both targeted tests and the combined acceptance suite after each addition. Avoid simultaneous cherry-picks or branch rewrites in the integration worktree.

If integration changes an assumption another lane relies on, pause that lane and explicitly rebase or restart it against the updated baseline. Do not let agents chase a moving target without recording the new base.

Measure accepted changes per unit of spend, integration waiting time, and repair work—not merely simultaneous sessions. Add another lane only when useful throughput improves. After acceptance, remove worktrees with git worktree remove and retain the task manifests for the next scheduling decision.