What Is Multi-Agent Coding? Architecture, Workflows, and Examples with Codex, Claude Code, and GitHub Copilot

The first generation of AI coding workflows centered on one conversation: one developer, one agent, one growing context window. That model still works well for a focused bug or a small component. It becomes a bottleneck when the task spans architecture, implementation, tests, documentation, and review.

A single agent can perform those steps sequentially. But every repository scan, test log, failed hypothesis, and implementation detail competes for the same context. The agent must repeatedly switch roles, and work that could be independent still happens one step at a time.

Multi-agent coding changes the unit of work. Instead of asking one agent to be researcher, implementer, test engineer, and reviewer in sequence, a coordinating agent delegates bounded tasks to specialized agents, runs independent work in parallel, and combines their results.

Multi-agent coding is becoming the default approach for complex software work—not because more agents are always better, but because decomposition, context isolation, and parallel execution solve limitations that a larger single context window does not.

The important word is *complex*. A typo does not need an agent team. A repository-wide migration might. The advantage appears only when the work can be divided cleanly and the cost of coordination is lower than the time or context saved.

What is multi-agent coding?

Multi-agent coding is a software-development workflow in which multiple AI agents work toward one engineering outcome. Each agent receives a bounded responsibility, its own working context, and an expected result. An orchestrator—or sometimes a human—coordinates dependencies, resolves conflicts, and verifies the combined output.

A useful multi-agent system has five properties:

1. A shared objective. The agents are not answering unrelated prompts; their outputs contribute to the same definition of done.
2. Explicit decomposition. Work is separated by role, module, question, or verification concern.
3. Isolated context. Each worker can inspect logs, files, or documentation without filling the main conversation with every intermediate detail.
4. Coordination. Someone owns task assignment, dependencies, decisions, and integration.
5. A verification boundary. The combined work is tested as one system rather than trusted as several individually plausible answers.

Opening three terminal windows and asking each agent to “improve the app” is parallel prompting, not a reliable multi-agent workflow. Without ownership boundaries, the agents may edit the same files, make incompatible assumptions, or duplicate work.

The goal is not to maximize agent count. It is to create the smallest useful team for the shape of the problem.

How a multi-agent coding system works

Most implementations can be understood as a simple control loop:

Human objective
      ↓
Orchestrator → task graph → specialized workers
      ↑                         ↓
      └──── summaries, diffs, evidence
      ↓
Integration → tests → review → final result

The orchestrator

The orchestrator translates an outcome into bounded tasks. It decides what can run in parallel, what must wait, what context each worker needs, and what evidence must come back. It should retain the product requirements and architectural decisions while workers handle noisy local details.

The orchestrator does not need to write most of the code. Its highest-value responsibilities are maintaining the task graph, detecting incompatible assumptions, and refusing to declare success until the integrated result passes verification.

Specialized workers

Workers should have narrow ownership. Useful roles include:

• repository explorer;
• API or documentation researcher;
• backend implementer;
• frontend implementer;
• migration author;
• test engineer;
• security reviewer;
• performance reviewer.

Specialization is valuable because the prompt, tools, model, and permissions can match the task. A read-only reviewer should not need write access. A fast model may be sufficient for repository mapping, while a difficult concurrency analysis may justify more reasoning.

The task graph

A checklist becomes a task graph when dependencies are explicit. “Add API, UI, tests, and docs” is not enough. The orchestrator should know that the API contract must be decided before generated client types, that UI work can begin against an agreed schema, and that end-to-end tests require both sides to be integrated.

Good parallel tasks have independent inputs and non-overlapping outputs. If two agents need to change the same central file, the work is probably sequential—or one agent should own integration.

Context and handoffs

Each worker needs a compact context packet:

• objective and acceptance criteria;
• owned files or questions;
• constraints and decisions already made;
• relevant commands;
• required return format.

The return should be equally deliberate: findings with file references, a patch or commit, assumptions, commands run, and remaining risks. Raw transcripts are rarely useful to the orchestrator.

Isolation and integration

Read-only agents can usually share a checkout. Parallel writers need stronger boundaries: separate modules, branches, worktrees, or hosted environments. Isolation prevents accidental overwrites, but it does not remove semantic conflicts. Two correct patches can still encode contradictory API assumptions.

Integration is therefore a first-class task. One owner must combine the work, run repository-level checks, and review the final diff as a coherent change.

Single agent vs. multi-agent coding

Multi-agent execution optimizes wall-clock time and context quality, not necessarily total compute. Four agents completing a task in fifteen minutes may consume more tokens than one agent completing it in forty-five. That can still be the right trade when developer attention, delivery time, or independent review is more valuable than model cost.

Five core multi-agent patterns

1. Orchestrator and workers

One lead agent decomposes the request, delegates independent tasks, waits for results, and synthesizes the outcome. This is the most general pattern and the one exposed directly by current coding-agent products.

Use it for a feature that spans several well-separated modules. Avoid it when every task depends on the previous agent's unfinished implementation.

2. Parallel specialists

Several read-heavy agents investigate the same system from different angles: architecture, security, test coverage, and performance. They return evidence rather than edits, and the main agent decides what to change.

This is often the safest first multi-agent workflow because read-only work creates few merge conflicts and keeps verbose exploration outside the main context.

3. Pipeline

Agents work sequentially with structured handoffs: researcher → planner → implementer → tester → reviewer. The advantage is specialization and context isolation rather than parallel speed.

Pipelines work well when each stage produces a stable artifact, such as an API contract, implementation patch, or test report. They fail when every handoff loses essential nuance that would have remained available in one conversation.

4. Implementer and reviewer

One agent writes the change; another independently reviews the diff against requirements and likely failure modes. The reviewer should receive the original acceptance criteria, not only the implementer's summary.

This pattern adds genuine independence. Asking the same agent to immediately validate its own assumptions often produces confirmation rather than review.

5. Competing hypotheses

Multiple agents investigate different explanations for a difficult bug or propose alternative designs. The orchestrator compares evidence and selects a direction.

This is especially useful when early commitment is dangerous. It is wasteful when the solution is already obvious from a failing test and a narrow stack trace.

Multi-agent coding in Codex, Claude Code, and GitHub Copilot

The three products now support more than “open several sessions,” but their abstractions are not identical.

Codex: parallel subagents with inspectable threads

Current Codex releases enable subagent workflows by default. You can ask Codex directly to spawn agents for independent parts of a task, and the main thread collects their results. In the app, CLI, and supported IDE surfaces, subagent activity is visible as separate agent threads. In the CLI, /agent lets you inspect and switch between them.

The practical prompt shape is explicit:

Review this branch with three parallel subagents:
- one for security risks,
- one for missing tests,
- one for maintainability.

Keep all agents read-only. Wait for all three, then return one deduplicated
report with severity, file references, and recommended fixes.

Codex can also define custom agents with different instructions, models, and reasoning settings. OpenAI's guidance recommends starting with read-heavy parallel work such as exploration, tests, triage, and summaries, while treating concurrent code editing more carefully because coordination and conflicts increase.

Git worktrees add another useful layer. Separate Codex chats can operate in independent checkouts of the same repository, allowing parallel feature work without modifying the local checkout. This is session-level parallelism rather than the same thing as an orchestrated subagent workflow, but both approaches can be combined deliberately.

See the official OpenAI documentation for Codex subagents and Git worktrees .

Claude Code: subagents versus agent teams

Claude Code has two related architectures. A subagent runs in its own context, handles a focused task, and returns its result to the main conversation. Custom definitions can live in .claude/agents/ for a repository or ~/.claude/agents/ for the user. Subagents can run in the foreground or concurrently in the background, subject to their permissions.

Agent teams go further. A team lead spawns independent Claude Code sessions, teammates share a task list, and agents can message one another directly. This suits sustained work where workers need to exchange discoveries or coordinate dependencies rather than simply return one summary to the parent.

That distinction matters:

• use a subagent for bounded research, review, or a self-contained implementation;
• use an agent team when teammates must coordinate, challenge one another, or own separate parts of a larger feature;
• use one conversation when the phases share extensive context and require frequent back-and-forth.

A practical team prompt might be:

Create an agent team for this feature. Assign one teammate to the API contract,
one to the React client, and one to integration tests. The API owner must publish
the agreed request and response schema before the client task begins. Keep file
ownership separate and have the lead run the final test suite.

See Anthropic's official documentation for Claude Code subagents and agent teams .

GitHub Copilot CLI: custom agents and /fleet

Copilot CLI includes built-in agents for exploration, command execution, general-purpose work, code review, research, and critical review. The main agent can run appropriate agents as subagents in separate context windows. Repository-specific agent profiles can be stored in .github/agents/.

The clearest multi-agent control is /fleet. Copilot analyzes a complex request or implementation plan, breaks it into independent tasks, manages dependencies, and runs suitable subagents in parallel. Each subagent has a separate context window, and custom agents can be selected for particular subtasks.

/fleet Implement the approved account export plan. Use @api-specialist for the
export endpoint, @frontend-specialist for the download UI, and @test-writer for
independent coverage. Do not edit the same files concurrently. Run the full test
suite after integration and report any assumptions that changed.

/fleet and Autopilot solve different problems. Autopilot controls how long Copilot continues without user intervention. /fleet controls parallel decomposition and orchestration. They can be used together, but autonomy is not the same thing as multiple agents.

See GitHub's documentation for custom agents in Copilot CLI and parallel execution with `/fleet` .

Practical workflow 1: build a cross-stack feature

Suppose the product needs saved searches with a new database table, API endpoints, a React interface, and end-to-end coverage.

Success criterion: users can create, rename, apply, and delete saved searches; authorization is enforced; migrations are reversible; all tests pass.

Use an orchestrator with four bounded roles:

• architect: inspect existing patterns and define the data/API contract;
• backend owner: migration, persistence, authorization, and endpoints;
• frontend owner: state, UI, and API integration against the agreed contract;
• test reviewer: identify missing cases and add integration coverage after the contract stabilizes.

Implement saved searches using a multi-agent workflow. First, have a read-only
architect map the existing search, persistence, and authorization patterns and
propose an API contract. After the contract is approved, run backend and frontend
work in parallel with non-overlapping file ownership. Then assign an independent
test agent to verify permissions, validation, migration rollback, and the main
user journey. The lead owns integration and the final build.

The architecture step is a dependency. Backend and frontend implementation can then overlap. The final end-to-end verification cannot be delegated away from the integration owner.

Use one agent instead if the feature is a small local form backed by an existing generic endpoint. Coordination would add more overhead than the implementation.

Practical workflow 2: debug an intermittent failure

Intermittent failures benefit from competing hypotheses because a single agent may anchor on the first plausible cause.

Success criterion: reproduce the failure, identify evidence for the root cause, add a regression test, and show that the fix survives repeated runs.

Assign three read-only investigators:

• one traces concurrency and shared mutable state;
• one analyzes test isolation, timing, and fixtures;
• one reviews recent changes and environment differences.

Investigate this intermittent test failure with three parallel read-only agents.
Give each agent a different hypothesis: application race condition, test isolation
problem, and environment or dependency drift. Require reproduction steps and file
references. Wait for all results, compare the evidence, then let one implementer
make the smallest fix and one reviewer validate the regression test independently.

The key is not voting. Three agents repeating the same guess do not create confidence. The orchestrator must compare evidence, reject unsupported explanations, and select one minimal experiment.

Use one agent when the failure is deterministic and the stack trace points directly to a narrow defect.

Practical workflow 3: perform a repository-wide migration

Consider migrating a monorepo from one logging API to another across services, packages, tests, and documentation.

Success criterion: no deprecated imports remain, behavior and structured fields are preserved, tests pass, and the migration can be reviewed in bounded changes.

Start with a read-only inventory agent. Divide implementation by package boundary, not arbitrary file counts. Give one agent ownership of shared adapters and types before leaf packages begin. Reserve another agent for repository-wide verification.

Migrate the repository to the new logging API. First build an inventory of every
usage and classify it by package and call pattern. Create a dependency-aware task
graph: one owner for shared logging types and adapters, then one worker per
independent package. Give each worker exclusive file ownership and require a
commit plus tests. After integration, run a separate verification agent to search
for deprecated imports, changed structured fields, and missing documentation.

This workflow should use branches or worktrees when several agents write concurrently. Merge the shared foundation first, rebase or refresh worker contexts, and integrate packages incrementally rather than combining every branch at the end.

Use one agent if the migration is a safe mechanical replacement that a codemod and test suite can complete deterministically.

What usually goes wrong

Tasks overlap

“Agent A handles backend” and “Agent B handles API” may describe the same files. Define ownership using modules, paths, exported contracts, or explicit questions. If overlap is unavoidable, serialize the work.

Workers receive incomplete context

An isolated context is useful only when the delegation message includes the relevant decisions. Provide acceptance criteria and constraints, not the entire parent transcript. Ask workers to surface assumptions instead of silently filling gaps.

Parallel work is only cosmetically parallel

If every task waits on an unresolved architecture decision, launching five agents creates five blocked investigations. Build the dependency graph first and parallelize only ready tasks.

The orchestrator becomes a summarizer

Collecting five reports is not orchestration. The lead must reconcile contradictions, update task state, route follow-up questions, and protect the definition of done.

Integration is postponed

Long-lived parallel branches drift. Integrate stable contracts early, keep patches bounded, and run shared checks after each meaningful merge.

Cost is ignored

Every worker performs its own model and tool calls. Codex documentation explicitly notes higher token use for subagent workflows, and GitHub warns that /fleet can consume more AI credits. Measure elapsed time, total model usage, review effort, and defect rate—not just how many agents were busy.

Agents review their own assumptions

A reviewer adds the most value when it receives the original requirement and independently inspects the result. If it sees only the implementer's confident summary, it may inherit the same blind spots.

When not to use multiple agents

Stay with one agent when:

• the change is small and reversible;
• most work happens in one file or tightly coupled module;
• the next step depends on the exact output of the previous step;
• requirements are still changing through frequent human discussion;
• a deterministic script is better than model-driven delegation;
• integration would cost more than the work itself.

A practical rule is to add an agent only when it creates at least one of three benefits: independent evidence, isolated context, or real parallelism. If it provides none of them, it is probably ceremony.

A practical adoption framework

Do not begin by designing an autonomous virtual engineering department. Adopt multi-agent coding in four stages.

Stage 1: delegate noisy reading

Use one main agent and one read-only worker for repository exploration, logs, documentation, or test output. Require a concise evidence-based summary.

Stage 2: add independent review

After implementation, give another agent the original requirements and the diff. Ask it to find correctness, security, and test gaps without changing files.

Stage 3: parallelize separated modules

When the contract is stable, let workers own independent packages or layers. Use explicit paths, branches, or worktrees and define the integration order.

Stage 4: introduce an orchestrated task graph

For recurring large workflows, encode reusable agent roles, dependency rules, return formats, and verification gates. Track whether parallelism actually reduces delivery time without increasing rework.

At every stage, preserve one human-readable objective and one final verification owner. Autonomy can increase; accountability should not disappear.

The trend: from pair programming to agent teams

AI coding tools are moving from a single assistant surface toward orchestration primitives. Codex exposes subagent threads across its local clients. Claude Code distinguishes focused subagents from communicating agent teams. Copilot CLI exposes parallel execution directly through /fleet. The products differ, but the direction is consistent: delegation and coordination are becoming normal parts of the coding interface.

That does not mean every developer becomes a manager of dozens of bots. The durable skill is decomposition: expressing a clear outcome, separating independent work, preserving contracts, and demanding evidence at integration boundaries.

The best multi-agent workflow feels less like prompting a crowd and more like designing a reliable build system. Work enters through explicit inputs, runs in appropriate isolated stages, and leaves only after shared checks pass.

Frequently asked questions

Is multi-agent coding the same as running multiple AI coding tools?

No. Multiple tools become a multi-agent workflow only when they share an objective, have defined responsibilities, exchange structured results, and feed into one integration and verification process.

Are subagents always faster than one agent?

No. They reduce wall-clock time only when tasks can run independently. Startup, context gathering, coordination, and integration can make a multi-agent workflow slower for small or sequential work.

Do coding agents share the same context?

Usually not. Subagents typically have separate context windows and receive a delegation prompt plus selected project context. This isolation is a benefit, but important requirements and decisions must be passed explicitly.

Should multiple agents edit the same repository at once?

Prefer non-overlapping ownership. For parallel writes, use separate branches, worktrees, or environments and appoint one integration owner. Shared-file editing creates both Git conflicts and semantic conflicts.

How many coding agents should I use?

Use the smallest number that matches independent workstreams. Two focused investigators and one orchestrator are often more useful than a large team with vague responsibilities.

What is the best first multi-agent coding workflow?

Start with parallel read-only review: security, test gaps, and maintainability. It provides independent evidence and context isolation with minimal merge risk. Add parallel implementation only after you can define stable contracts and file ownership.