To run coding agents in parallel, give each agent its own git worktree and branch, feed the agents from a queue of plans a human has already reviewed, run tests and lint inside each worktree before anyone reads the diff, and record what every plan cost. Most teams reach this setup by passing through three earlier patterns: a single agent in a chat window, one agent per branch started by hand, and a queue with worker agents. Each pattern fixes one problem and exposes the next one. This guide covers the four patterns, what breaks at each step, and the six things an orchestrator has to own.
The four patterns
Steve Yegge's "8 Levels of AI-Assisted Development" (2025) is a useful frame. Most teams at the time of writing sit at levels 2 to 3: a developer prompts an agent, reads the result, and commits. Orchestration with parallel agents, persistent memory, and review gates is level 8.
Pattern 1: one agent in a chat window
A developer opens a terminal or an IDE panel, describes a task, and watches the agent edit files in the working directory. Throughput is one task per developer at a time, because agent and developer share one checkout. A second task started before the first is finished puts both sets of edits in the same tree, and the diff stops meaning anything.
Pattern 2: one agent per branch, started by hand
The next step is to give each task its own branch and its own checkout. Git worktrees make this cheap: one object store, several working directories.
# from the main checkout
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "Add a search button to the sidebar. Run the tests when done."
A developer can now run two or three agents at once, each in its own directory. What breaks is bookkeeping. Nobody records which worktree belongs to which task, and prompts live in terminal scrollback. Two agents pointed at the same files produce merge conflicts that appear only at merge time.
Pattern 3: a queue with worker agents in isolated worktrees
Once the team runs more than a handful of agents, the manual start step becomes the slowest step. The fix is a queue: tasks go in, worker processes pick them up, create a worktree, run the agent, push a branch, and open a pull request.
Removing the human from the start of every task is where the next failure appears. Nothing checks the task before the agent begins, so badly specified tasks spend tokens on pull requests nobody wants. Nothing checks the output before the pull request, so reviewers become the slowest step. And because the queue runs unattended, cost accumulates unwatched.
Pattern 4: a plan lifecycle with review checkpoints
The last pattern adds two human checkpoints and a verification step. A task becomes a written plan. A human reads the plan before any code is written. Agents execute in isolated worktrees. Tests, lint, and a diff summary run inside the worktree. A human reads the diff. Only then does a pull request open.
Ivy calls this pattern a software factory: a repeatable workflow in which every change passes through the same stages and the same two sign-offs. See What is a software factory for the full definition.
What breaks at each step
| Pattern | What it fixes | What breaks next |
|---|---|---|
| One agent in a chat | Nothing yet; this is the baseline | One task per developer; shared working directory |
| One agent per branch, by hand | Concurrent tasks without directory collisions | Lost context, unrecorded prompts, conflicts found at merge |
| Queue with workers | Manual start step removed | Unreviewed input and output, cost blindness |
| Plan lifecycle with checkpoints | Wasted execution, unreviewed changes | Requires tooling to own queue, isolation, verification, cost, memory |
What an orchestrator has to own
An orchestrator is the software that runs pattern 4. It has six responsibilities; any one that is missing gets done by hand and becomes the slowest step again.
- Queue. Plans wait in a defined order with a defined state: draft, approved, executing, verifying, in review, merged. The state must be visible without opening a terminal.
- Isolation. Each executing plan gets its own worktree and branch. The main branch never receives an agent edit directly. Git worktrees for parallel AI agents explains why worktrees beat shared checkouts and containers.
- Verification. Tests, lint, type checks, and a diff summary run inside the worktree after execution and before a human sees anything. Failures go back to the agent with the failing output attached.
- Review. Two checkpoints, the plan and the diff, each with an explicit approve or reject action. Rejection at the plan stage costs nothing in tokens. Rejection at the diff stage costs one execution.
- Cost accounting. Tokens and dollars recorded per plan and per job, so the team can see what a merged change cost and which plans were abandoned after spending.
- Memory. What the agent learned in one plan must be available in the next; otherwise every plan starts from zero and repeats the same mistakes.
How Ivy Tendril implements this
Ivy Tendril is a local-first desktop application (macOS, Windows, Linux) that runs pattern 4 for any CLI coding agent. It also runs headless with tendril --web.
- Queue: the Plans surface holds every plan with its lifecycle state. Drafts, Icebox, and Recommendations hold work that is not yet approved. Plans can be created from GitHub issues and jam.dev bug reports through webhooks, or through the MCP server, REST API, and CLI.
- Isolation: when execution starts, Tendril creates a git worktree and branch for that plan. Many plans execute at once, each in its own worktree. After merge, Tendril removes the worktree. See git worktrees for parallel AI agents.
- Verification: the Review app shows tests, lint, and diff as tabs for each plan. Pro plans can import verification results from CI.
- Review: the plan checkpoint lets a reviewer Expand, Split, or Update a draft, or comment inline and have the plan rewritten. The diff checkpoint comes after verification. Nothing opens a pull request without both.
- Cost accounting: tokens and cost are tracked per plan and per job, and the Dashboard shows cost KPIs and a trend chart.
- Memory: each lifecycle stage is run by a promptware unit with a Program.md of instructions that evolve, a Memory/ directory of persistent learnings, scoped Tools/, and Logs/. Built-in units include CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr, and CreateIssue. See promptware.
Tendril is agent-agnostic. It runs Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode, and any other CLI agent, and the agent or model can be switched per plan. Code stays on the machine; the only external calls are to the LLM API you configure and to GitHub.
Ivy reports that its own team went from roughly 10 to more than 100 pull requests per day after adopting this workflow.
How to start
- Install Tendril:
curl -sSf https://cdn.ivy.app/install-tendril.sh | shon macOS or Linux,irm https://cdn.ivy.app/install-tendril.ps1 | iexon Windows. Details at installation. - Open a repository in it and add an API key for the model provider you already use.
- Create one plan from an existing ticket, review the draft, execute it, and read the diff in the Review app.
- Once the first plan merges, create three plans at once and watch them execute in parallel.
Tendril is free and source-available under the Functional Source License; team features, SSO, on-prem hosting, and CI verification imports are on the Pro ($59 per user per month) and Enterprise plans.
Frequently asked questions
Do I need containers to run agents in parallel?
No. Git worktrees give each agent its own working directory and branch while sharing one object store. Containers add runtime isolation, which matters if agents install system packages or bind ports; most coding tasks do not need it.
How many agents can run at once?
The limit is usually the model provider's rate limit and the machine's capacity for running tests, not the orchestrator. Start with three to five parallel plans and raise the number while verification still finishes promptly.
What happens when two plans touch the same file?
The second plan to merge will produce a conflict on its branch. The fix is at the plan stage: split or sequence plans that touch the same modules before execution, which is what the Split action in Tendril is for.