Parallel AI coding, without parallel chaos.

Concurrency is not orchestration.

Several terminal windows can execute several agents concurrently. Orchestration adds the missing control plane: a shared plan, visible ownership, isolated execution, dependency order, review state, and a record of what each agent changed.

The objective is not the largest possible agent count. It is shorter delivery time without increasing integration risk faster than useful work.

What breaks first.

Ownership becomes invisible

When prompts live in separate terminals, it is difficult to see who owns authentication, who is editing shared types, and which task is waiting on another. Duplicate work is common; conflicting assumptions are worse.

Agents share a mutable folder

Two processes editing the same checkout can overwrite files, observe half-finished changes, or include another task’s edits in a commit. Separate branches do not help if both agents still work in the same directory.

Completion is mistaken for acceptance

An agent saying “done” only means execution stopped. Tests may not cover the change, the diff may include unrelated files, and a technically valid result may violate the product intent. Parallel output still needs a deliberate review and merge gate.

Choose work that can actually run in parallel.

Good parallel tasks have clear boundaries, observable acceptance criteria, and limited overlap with other active tasks.

• Good: add an API endpoint while another agent writes an unrelated settings screen against an agreed contract.
• Good: have one agent implement a change and another prepare independent test cases or review criteria.
• Risky: ask three agents to refactor the same shared module at once.
• Sequence instead: schema changes that downstream tasks must consume, broad dependency upgrades, or migrations that redefine shared interfaces.

A safe five-step workflow.

1. Decompose by outcome. Write cards with one result, relevant context, boundaries, and a verifiable definition of done.
2. Map dependencies. Run independent cards together; place interface-defining work before its consumers.
3. Isolate execution. Give every active card its own branch and git worktree—not only a different terminal.
4. Verify in context. Run focused tests inside the worktree, inspect the complete diff, and check for assumptions that conflict with other cards.
5. Merge intentionally. Land reviewed cards in dependency order and re-test after integration. Preserve the ability to undo a bad merge.

How PapAgent applies the workflow.

PapAgent places the plan on a Kanban board and assigns each card to an installed AI CLI. Active tasks receive isolated git worktrees. The board exposes progress and ownership; completed work exposes its diff before merge.

Different models can take different roles. Claude Code can implement while Codex reviews, Codex can build while Claude reviews, or both can own independent cards. PapAgent provides coordination and isolation; the CLIs continue to use their native provider behavior and the developer’s existing subscriptions where supported.

For the underlying isolation model, continue with Git worktrees for AI coding agents. For a concrete two-agent pattern, see the Claude Code and Codex workflow.