Run AI Coding Agents in Parallel

Synara lets you run multiple AI coding agents in parallel on the same project. Give each editing task its own Git worktree, choose its provider, and define which files it owns. One person or task then reviews and integrates the results.

Before starting, install Synara, connect your providers, and identify a known base commit. Separate conversations alone do not isolate file changes.

Example: build a search feature with two agents

Suppose a repository has an API in apps/server and a client in apps/web. Agree on the search response fields and empty-query behavior first, then record that contract in a commit both tasks will start from.

1. Create a server task in its own worktree. Ask it to implement the search endpoint and verify its response against the contract. Limit edits to apps/server.
2. Create a web task in a different worktree from the same commit. Ask it to implement the search form, results, loading state, and empty state in apps/web.
3. Assign shared schemas and dependency files to one owner. If either task needs to change them, settle that change before allowing the other to depend on it.
4. Review each task's diff and checks, then commit its intended changes. Integrate both branches into one integration branch.
5. Run the combined app. Submit a real search, an empty query, and a query with no results. Confirm the client and API agree, then run the repository's relevant checks.

The two implementation tasks can proceed independently after agreeing on the contract. The final browser check must use the combined code; a passing test in either worktree does not verify the integration.

For a sequential implementation-and-review example, follow Use Claude Code and Codex on the same project.

Choose the right level

Use the smallest level that creates a real boundary. More agents are not a substitute for decomposition.

Design parallel work before creating tasks

A useful task plan makes ownership explicit:

Integration owner:
Owns shared contracts, final conflict resolution, broad verification, and delivery.

Task A — server:
Implement the endpoint and focused server tests.
May edit apps/server/** only.

Task B — web:
Implement the client and focused UI tests against the agreed contract.
May edit apps/web/** only.

Task C — review:
Read both diffs after A and B finish.
Do not edit until findings are reported.

Avoid plans such as “three agents finish the feature.” They do not define file ownership, interfaces, or integration responsibility.

Separate top-level tasks

Create separate Synara tasks when work needs its own:

• Objective and transcript
• Provider and model
• Working environment
• Terminal state
• Diff and commit history
• Review and delivery lifecycle

Use separate worktrees whenever two top-level tasks can edit the same repository. Separate conversations do not prevent filesystem collisions.

Provider-native subagents

Some providers can create child agents or tasks inside one provider session. Synara can project supported child activity into the task UI, including identity, status, and tool activity.

Use provider-native subagents for:

• Independent codebase research
• Comparing several implementation approaches
• Focused test design
• Small delegated changes that the parent will integrate immediately

The parent task remains the owner. Provider-native children are not automatically separate Synara tasks, branches, or worktrees.

A /subagents prompt can encourage a capable provider to delegate, but the exact child behavior remains provider-specific.

Agent Gateway orchestration

The Agent Gateway lets supported Synara provider sessions create, read, wait for, steer, interrupt, title, and archive ordinary Synara tasks through app-owned MCP tools.

Use it when the coordinating task can:

1. Describe exact child objectives.
2. Choose appropriate projects, providers, models, environments, and runtime modes.
3. Track stable request IDs and created task IDs.
4. Wait for terminal results without busy polling.
5. Inspect each result and integrate it deliberately.

The gateway can create an exact batch of up to 20 threads in one operation. That is a limit, not a recommended default. Start with the smallest batch that has independent value.

Worktree strategy

For concurrent repository edits:

• Give each top-level task its own managed worktree.
• Start all tasks from a known base ref.
• Record interface decisions before implementation diverges.
• Do not manually copy files between worktrees.
• Integrate through commits, rebases, merges, or cherry-picks you can review.

Read Worktrees before running concurrent writers.

Integration ownership

One task or person must own the final combined result.

The integration owner should:

• Resolve shared-contract questions
• Detect overlapping files early
• Review child diffs rather than only summaries
• Re-run broad checks after combining changes
• Remove duplicated or contradictory implementations
• Confirm the final branch contains only intended work

Child tasks can verify their own scope. They cannot prove that the integrated system is correct.

Monitoring without micromanagement

Use task state and targeted reads rather than repeatedly sending “status?” messages.

A good monitoring loop is:

1. Create the tasks with stable objectives.
2. Wait for meaningful state changes.
3. Read the result, latest turn, and changed files.
4. Steer only when a concrete correction is needed.
5. Interrupt work that is unsafe, stuck, or no longer useful.

Repeated follow-ups can consume context and distract a provider without improving the result.

Failure handling

Two tasks need the same file

Pause one task. Decide which owner controls the shared file, or redefine the interface so the work becomes independent.

A child task changes shared architecture

Stop integration. Review the decision with the integration owner before allowing other tasks to build on it.

A task finishes with unrelated changes

Do not merge the branch wholesale. Separate, revert, or recreate the intended change in a clean ownership boundary.

One task depends on another

Do not pretend they are parallel. Sequence them, or have the upstream task publish a stable contract or commit before the dependent task begins.

A child is stuck

Read its current state and diagnostics. Steer with a specific hypothesis, change provider through a deliberate handoff, or stop it. Do not create several replacement tasks against the same worktree.

Parallel completion checklist

• Every task has a distinct, verifiable objective
• Concurrent writers use separate worktrees
• Shared files and interfaces have an identified owner
• Provider-native subagents remain under one parent owner
• One integration owner reviews all child results
• Each child branch passes focused verification
• The combined result passes broad verification
• No task summary is accepted without inspecting its actual diff