Your AI Agents Are Not a Team Yet: 7 Orchestration Lessons from Multi-Agent Failures

Giving five AI agents access to the same repository does not create a team. It creates five fast, confident developers who may open conflicting pull requests, repeat the same mistake, and tell each other that everything looks good.

That sounds harsh, but it matches what developers are starting to see in real systems. Multi-agent demos are easy to make impressive. One agent plans, another codes, a third reviews, and a final agent announces success. The diagram looks clean. The execution is usually messier.

Anthropic tested agent swarms on vulnerability research and collaborative software projects. The results were promising and uncomfortable: agents covered a huge search space, but coordination became fragile once their work depended on one another.[1]

The lesson is not to avoid multi-agent systems. It is to stop treating "more agents" as an architecture.

What counts as a multi-agent system?

A multi-agent system has several AI workers with separate contexts, responsibilities, or tools. They may run in parallel, pass work to one another, review outputs, or report to an orchestrator.

Two common designs have emerged:

• A manager keeps control and calls specialist agents for bounded tasks.
• A router hands the task to a specialist, which then owns the rest of the interaction.

OpenAI's Agents SDK documents both patterns and makes an important distinction: you can let an LLM decide the workflow, or you can control the workflow in code. LLM-led orchestration is flexible. Code-led orchestration is more predictable in cost, speed, and behavior.[2]

That distinction matters more than the number of agents. A system with ten agents and no deterministic control is often less dependable than one agent running inside a strict loop with tests.

Lesson 1: parallel work is the easy part

Multi-agent systems are strongest when a task breaks into independent pieces.

Security research is a good example. Anthropic gave 45 agents their own virtual machines and asked them to search 15 open-source projects for vulnerabilities. The agents could coordinate through a shared forum, peer-review findings, and submit results to an arbiter agent.[1]

The swarm found 266 vulnerabilities while consuming 27 million tokens. A simpler parallel setup found 21 vulnerabilities using 6.5 million tokens. Those numbers do not prove the swarm was automatically more efficient. About half of the swarm's findings were outside the core directories assigned to the simpler setup, and only 12 vulnerabilities appeared in both result sets.[1]

The useful part is the coverage. Independent agents explored different areas, built tools, and specialized. One missed finding did not invalidate another agent's work.

This pattern maps well to development tasks such as:

• inspecting separate modules for security issues;
• researching competing libraries;
• generating tests for unrelated components;
• checking accessibility across independent pages;
• reviewing a change from performance, security, and product perspectives.

If the workers can fail independently, parallel agents can give you more coverage. If every worker depends on another worker's half-finished output, the system becomes much harder to trust.

Lesson 2: dependency turns speed into coordination debt

Anthropic also asked agent swarms to build a web-playable fantasy game over 12 hours. The agents had virtual machines, a shared repository, and a forum. Researchers tried loose collaboration, prescribed roles, and a CEO-style hierarchy.[1]

None of those prompts rescued the final product. The games were poor, interfaces were confusing, and older models frequently opened pull requests that conflicted and were abandoned. Some newer models avoided conflicts mostly by working in separate files rather than collaborating deeply.[1]

This is coordination debt. Every new worker adds possible handoffs, stale assumptions, merge conflicts, and decisions that nobody clearly owns.

Human teams have tools for this: tickets, code ownership, API contracts, design reviews, CI, and someone who can say no. Agent teams need the same constraints, often in a stricter form.

Do not ask four agents to "work together on the feature." Split the work along boundaries you can verify:

• Agent A defines the API contract and acceptance tests.
• Agent B implements the server against that contract.
• Agent C implements the client against the same contract.
• Agent D runs integration tests and reports failures without editing production code.

The contract gives every worker something concrete to build and test against. A long agent conversation does not.

Lesson 3: identical agents do not provide independent judgment

A reviewer agent sounds reassuring until you realize it may think exactly like the author agent.

Anthropic observed unusually similar behavior among agents using the same model and setup. In one experiment, 18 of 30 agents independently chose the exact branch name mvp-game-loop. In a writing task, multiple agents produced the same title without being given a shared subject. In another task, more than half chose to build either a ray tracer or a self-hosting compiler.[1]

This low variance creates correlated failure. If the implementation agent misunderstands a requirement, a reviewer with the same model, prompt style, and context may approve the same misunderstanding.

A second agent only gives you a useful second opinion when it checks different evidence or uses a different method.

You can create more useful disagreement by changing the evidence and incentives:

• Give the reviewer the acceptance criteria and diff, not the author's reasoning.
• Ask the reviewer to find a counterexample rather than rate quality.
• Use deterministic tools such as tests, linters, and schema validators.
• Separate security review from feature review.
• For consequential work, use a different model or a human reviewer.

The goal is not artificial debate. It is to prevent one plausible mistake from becoming a unanimous team decision.

Lesson 4: the orchestrator should own the answer

One agent should be responsible for the final result. That does not mean it performs every task. It means it owns scope, merges evidence, resolves conflicts, and decides whether the work is complete.

The manager pattern in OpenAI's Agents SDK keeps one agent in control while specialists operate as tools. Handoffs are better when a specialist should take over the interaction entirely.[2] For engineering work, the manager pattern is usually safer because the final response, patch, or release still has one owner.

A practical orchestration loop can be simple:

type Finding = {
    agent: string;
    claim: string;
    evidence: string[];
    status: "unverified" | "verified" | "rejected";
};

const tasks = splitByIndependentBoundary(request);
const reports = await Promise.all(tasks.map(runSpecialist));

const findings: Finding[] = normalize(reports);
const verified = await runDeterministicChecks(findings);
const conflicts = detectConflicts(verified);

if (conflicts.length > 0) {
    await requestTargetedRechecks(conflicts);
}

return orchestratorBuildsFinalArtifact(verified);

The loop does not rely on a free-form group chat where agents keep talking until they feel aligned.

The orchestrator should consume structured reports. Each report should name the task, artifact, evidence, commands run, unresolved risks, and confidence. That makes failures inspectable instead of burying them in a transcript.

Lesson 5: verification must live outside the agent's confidence

Agents are good at producing completion language. "Implemented successfully" is not evidence.

Anthropic's Claude Code guidance recommends giving an agent a check it can run: a test suite, build command, linter, output comparison, or screenshot. Without that check, the agent stops when the work looks finished. With a readable pass-or-fail signal, it can iterate against reality.[3]

For multi-agent systems, verification should happen at two levels.

Each worker verifies its own artifact:

• the code compiles;
• focused tests pass;
• generated data matches a schema;
• cited evidence contains the claimed fact.

The orchestrator then verifies the combined system:

• integration tests pass;
• no worker changed files outside its scope;
• two outputs do not contradict each other;
• the final artifact satisfies the original acceptance criteria;
• reported commands and results are attached as evidence.

A reviewer agent can help find gaps. It should not replace the test runner.

Lesson 6: control the expensive parts in code

LLMs are useful when the next step requires judgment. They are a costly choice for workflow rules that could be an if statement.

Use code to control:

• which tasks may run in parallel;
• maximum retries and token budgets;
• required output schemas;
• permission boundaries;
• which checks must pass;
• when the workflow stops;
• when a human must approve an action.

Use an agent to handle:

• ambiguous decomposition;
• investigation across unfamiliar code;
• comparison of competing explanations;
• drafting a patch from evidence;
• summarizing trade-offs for a human.

OpenAI's orchestration guide recommends code-based flows when you need deterministic speed, cost, and performance. It also describes evaluator loops, structured outputs, agent chains, and parallel execution as core patterns.[2]

Most dependable agent systems still look like ordinary software: explicit branches, budgets, schemas, tests, and a few carefully placed reasoning steps.

Lesson 7: communication protocols do not solve organizational design

Google's Agent2Agent protocol gives agents a standard way to advertise capabilities, exchange tasks and artifacts, report status, and work across vendors. It builds on familiar technologies such as HTTP, Server-Sent Events, and JSON-RPC.[4]

That is useful infrastructure. It does not tell you whether the task should have been delegated, whether two agents are duplicating work, or whether the final output is correct.

Developers made a similar mistake with microservices. Network communication made independent services possible, but it did not remove the need for ownership, contracts, observability, and sensible boundaries. Multi-agent systems are heading toward the same lesson, only faster and with participants that can confidently invent missing information.

Treat agent communication as an API design problem:

• publish clear capabilities;
• pass explicit task IDs and deadlines;
• define artifact schemas;
• make retries idempotent;
• preserve provenance;
• log every tool call with side effects;
• never pass secrets or broad permissions by default.

An agent message should be inspectable like an API request, not trusted like a conversation between coworkers.

A small architecture that works

For a repository change, start with four roles:

1. The orchestrator reads the request, repository instructions, and acceptance criteria. It divides work only when the boundaries are clear.
2. Investigators inspect independent parts of the codebase. They return findings with file paths and evidence but do not edit files.
3. One implementer owns the patch. This avoids several agents fighting over the same code.
4. A verifier runs tests, reviews the diff against the requirements, and tries to disprove completion.

The orchestrator then returns the artifact only after deterministic checks pass. If a check cannot run, it reports the blocker instead of converting uncertainty into a success message.

This is less exciting than a swarm of autonomous developers, but it is much easier to debug when something goes wrong.

A quick check before you add another agent

Before you split a workflow across more workers, answer these questions:

• Can the new task fail without corrupting another worker's output?
• Does the worker have a clear input, output, and permission boundary?
• Can a test, schema, command, or human decision verify the result?
• Who owns conflicts and the final artifact?
• What stops retries, token use, and tool calls from growing without limit?

If those answers are vague, another agent will probably add coordination work rather than remove it.

When one agent is enough

Use one agent when the task is small, sequential, or tightly coupled. A typo fix does not need a planner, implementer, reviewer, and philosopher.

Use several agents when independent exploration has real value, specialists need different tools or context, or you want separate adversarial review. Even then, compare the expected gain against extra tokens, latency, and integration work.

Instead of asking how many agents you can add, ask which parts can fail independently and how you will verify the combined result.

If you cannot answer that, you do not have an agent team yet. You have concurrency with better marketing.

References

[1] Anthropic, Patterns and problems in emerging multiagent systems

[2] OpenAI Agents SDK, Agent orchestration

[3] Anthropic, Best practices for Claude Code

[4] Google Developers Blog, Announcing the Agent2Agent Protocol (A2A)