Skip to content
sec/atlas
back to the map
practice
stage: drive
3 min read

Orchestration and parallel agents

One agent is a pair programmer. Several agents are a small team, and a team needs isolation, a way to see who is doing what, and a human who reviews the merges.

git worktreeherdrtmuxOh My OpenAgent (OMO)Claude Code subagentsGitHub pull requests

Why run agents in parallel

Many tasks are independent: a bug fix, a test backfill, a documentation pass, a dependency upgrade. Running them at the same time turns waiting into throughput. The limits are not compute but attention and conflicts: you must review every result, and two agents editing the same files will collide.

Isolation with git worktrees

A gives each agent its own working directory and branch from the same repository, so they cannot overwrite each other's files and each result arrives as a branch you can review and merge.

one worktree per taskbash
# from the main checkout
git worktree add ../app-fix-login   -b agent/fix-login
git worktree add ../app-add-tests   -b agent/add-tests
git worktree add ../app-upgrade-dep -b agent/upgrade-dep

# start one agent in each directory (any harness), then review each branch
git -C ../app-fix-login diff main --stat

# clean up after merging
git worktree remove ../app-fix-login

Seeing and managing many sessions

  • A terminal multiplexer such as tmux keeps sessions alive and lets you switch between them.
  • herdr is a multiplexer built for agents: real terminal panes for each agent in one persistent workspace, a sidebar that shows which agents are working, blocked on you, or done, detach and reattach, and use over SSH. It organizes agents; it does not replace them.
  • Some harnesses have built-in subagents: the main agent delegates a focused job to a helper with its own context and gets back a summary.
  • Orchestration plugins such as (OMO) on OpenCode add predefined roles (a coordinator, a planner, executors, researchers) and a mode where the team works through a task with little supervision.

Patterns that work

  • Planner, implementer, reviewer: one agent plans, another implements, a third reviews, ideally on a different model for an independent view.
  • Fan-out: split a large mechanical change by directory or module and run one agent per slice.
  • Research in parallel: several read-only agents investigate different questions and report back; none of them edits.
  • Always finish with a human merge: agents open pull requests, CI runs, a person decides.

Risks and limits

  • Review debt: ten agents make ten diffs. If you cannot review them, you are only creating unread code.
  • Cost: parallel and autonomous modes burn tokens quickly. Set budgets and watch usage.
  • Shared resources: databases, ports and external APIs are not isolated by a worktree.
  • : an agent with broad permissions running unattended can do broad damage. Use a sandbox or container, scoped credentials and no production access.
  • More layers, more trust: every plugin and orchestration tool runs with your permissions. Pin versions and read what you install.
Git worktreeAn extra working directory with its own branch for the same repository. Gives each agent an isolated place to work.see in glossary →OMOOh My OpenAgent · oh-my-opencodeA plugin for OpenCode that adds a team of specialized agents and an autonomous multi-agent mode. It extends a harness; it is not one.see in glossary →Blast radiusblast radiusThe size of the damage when something breaks: one account, an entire region, a tenant. Good cloud design limits the radius through isolation (separate accounts, separate VPCs, narrow roles) so that a failure or an attack does not become a full-blown disaster.see in glossary →

connections on the map

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

  • CI/CD hardeningsecengautonomous agents demand the same discipline as runners and credentials

Study before

test what you learned

Loading questions…