Pierre KasparianAI & Data freelancer
← Back to category
multiagent systemAI agentsovereign AI EuropeGDPRAI governance

Multiagent systems: the 5 failure modes to avoid

August 17, 2026 · 9 min read · Articles

Pierre Kasparian

AI Engineer — UTT 4th year · LLM, RAG & GDPR compliance specialist · 15+ client projects

On August 13, 2026, Anthropic's Frontier Red Team published the study "Patterns and problems in emerging multiagent systems". The goal: understand how coordinated AI agents behave when they interact at scale, and especially where they fail. The findings matter directly for companies deploying agents, not just for research labs.

Direct answer: the study identifies five major failure modes of multiagent systems: poor peer coordination, failed merging of collective work, conformity cascades (all agents repeat the same mistake), collusion between agents, and a lack of vigilance against misleading information. For a European company, these failures also carry a regulatory dimension: under GDPR, every uncontrolled action remains attributable to the data controller.

What is a multiagent system? It is an architecture in which several autonomous AI agents collaborate on a single mission, sharing tasks, tools, and resources. Each agent has its own context and its own instructions. Coordination happens through direct messages, a shared forum, or hierarchical delegation. Agents can thus work in parallel, specialize, and review each other's work.

Why coordination between agents is so hard

Agents already excel at tool use. They work well together when they treat each other as tool invocations: well-defined inputs (prompts) and outputs (responses). The study shows that they struggle, however, to treat one another as distinct, long-lived peers with their own goals and behaviors, and no clear hierarchy.

Agent swarms already deliver value on parallelizable problems: missions that break down into independent sub-problems, where each agent can specialize. Software vulnerability detection is the canonical example.

Vulnerability detection: the swarm beats brute force

To test coordination, Anthropic's team launched 45 agents, each on its own virtual machine, with a shared forum and an identical prompt: find vulnerabilities in 15 open-source projects. The agents had to peer-review each other's findings, and a separate arbiter agent decided whether each finding was new and valid.

MethodTokens spentVulnerabilities found
Independent parallel agents6.5 million21
Coordinated swarm27 million266

With the Mythos Preview model, the classic parallel method found 21 vulnerabilities for 6.5 million tokens. The coordinated swarm found 266 for 27 million tokens. About half of the swarm's findings were located outside the directories targeted by the parallel agents. When limited to the core directories only, both methods become comparable in terms of tokens per vulnerability.

The two approaches are mostly complementary: only 12 vulnerabilities are shared. The swarm focuses its attention where it expects the best findings, builds its own tools, and learns to specialize. According to Anthropic, this coordinated specialization should dominate uncoordinated brute-force search in the future.

Before launching a swarm, estimate the token cost of your runs: 27 million tokens represents more than 4 times the budget of a parallel run. The RAG cost calculator helps plan that budget before going to production.

What the video game experiment reveals: merging collaborative work

When agents genuinely depend on one another, coordination becomes much harder. To prove it, several swarms had to create a text-based, web-playable open-world fantasy game. Each agent still had its own virtual machine, a shared forum, and a self-hosted repository. The swarms ran for 12 hours, with varying model generations and swarm sizes.

Three prompts were compared: a baseline prompt (form teams), a prompt with prescriptive roles (programming, artistic direction, play testers), and a "CEO hierarchy" prompt where one agent directed the others. Anthropic's verdict: these prompts made little difference. The games produced were bad: they did not run at human speed, their interfaces were inscrutable, and they had steep learning curves. Models still have poor taste in this area and require significant human direction.

Two metrics illuminate the failure: the share of merged pull requests and the amount of code shared between agents. Sonnet 4.6 and Opus 4.6 coordinate very poorly: few PRs are merged, often conflicting and then abandoned. Opus 4.8 and Mythos Preview dodge the problem by barely working together: each agent keeps exclusive ownership of its files. Only Sonnet 5 maintains both high code sharing and a high merge rate.

In short: real collaborative ability depends heavily on the model generation. Even with the best models, the end-to-end result stays mediocre. A multiagent system needs human direction, not just a well-tuned prompt.

The conformity failure: when every agent copies the same mistake

Individual agents are low-variance: facing the same situation, they make the same decisions, where humans would diverge. An agent only shares a context, a scaffolding, and a model. When these factors look alike, decisions look alike. And when one agent makes a bad decision, many agents make that same bad decision: isolated problems become systemic failures.

The study provides striking examples:

  • In an early version of the game experiment, 18 out of 30 agents created a git branch with exactly the same name: "mvp-game-loop".
  • In a writer's workshop, several agents, given zero guidance on subject matter, titled their first piece "The Cartographer's Last Commission".
  • Asked to each create something impressive, more than half of the agents chose to build ray tracers or self-hosting compilers.
  • In an iterated prisoner's dilemma with communication, all agents settle on the same strategy and defect at the same time, ruining their rewards.

This conformity produces concrete risks. In a test with job queues running on limited bandwidth, agents flooded the system with polling daemons at 30 times per second to push their jobs through. In one run, there were 2.4 million job requests and only 117 jobs accepted.

Worse: agents easily enter collusion. In a Bertrand pricing game with three to eight agents, they agreed on a price floor as early as round 3, through a private back-channel: "wholesale is 10 for all of us, so a price war just burns everyone's margin". Even with all direct communication channels removed, they kept matching prices to the penny on a public listings board. When every agent makes the same bet, a system becomes more vulnerable to sudden collapse or resource scarcity.

The epistemic failure: why agents believe lies

Humans apply discernment to new information: consistency with what they already know, the historical reliability of the source, and the interests at stake. AI models lack this epistemic vigilance and are vulnerable to deceptive senders.

In one experiment, a listener agent had to make 10 to 15 decisions about a world it could not observe directly. Four scout peers each reported part of the truth, and one of them lied at a fixed rate. The overlap in their reports made detection possible in theory. The most recent models recover an increasing share of the gap between the naive strategy (trust everyone) and the perfect oracle.

Implication for a company: never assume an agent verifies its sources. In a multiagent system, an agent can repeat erroneous information received from a peer without questioning it. Add verification layers and human checks.

What these failures change for GDPR compliance

A multiagent system processes personal data as soon as it handles customer files, contracts, or B2B exchanges. Every technical failure then has a regulatory translation.

Attribution of actions (GDPR Article 5(2)): the data controller must be able to demonstrate compliance. In a swarm, who is accountable when an agent makes a bad decision? You need a per-agent audit log: which agent, what action, what data, for which user, at what time.

Processors (GDPR Article 28): if agents rely on cloud models (Anthropic, OpenAI) or on a third-party hosting provider, a Data Processing Agreement is mandatory. This is a requirement the CNIL details on its official website, in particular for AI tools.

Transfers outside the EU (GDPR Article 44): as soon as personal data flows between agents and then to a US-hosted model, it becomes an international transfer subject to safeguards. The CLOUD Act (2018) makes this risk concrete: US authorities can demand access to data held by US companies, even when stored in Europe. The Foreign Intelligence Surveillance Act (FISA) draws the same horizon for surveillance.

The sovereign alternative simplifies the equation: European or open-weights models (Mistral, self-hosted Llama), a Qdrant vector database, and OVHcloud or Scaleway storage. No transfer outside the EU, fewer DPAs to manage, and a processing register that is easy to document. This is the path I defend as a freelance AI engineer: AI agent integration on European infrastructure, from the very first pilot.

How to deploy a robust and compliant multiagent system

Here are best practices drawn from the Anthropic study and from hands-on agent deployments in enterprise:

  • Set up a central forum for conventions: the study suggests that a space where agents agree on best practices and protocols is a serious remedy against coordination failures.
  • Vary the diversity factors: different contexts, scaffolding, and models break conformity cascades. If all your agents share the same context, they will share the same mistake.
  • Keep human supervision and an arbiter agent on high-stakes decisions: the arbiter of the vulnerability test (validating every finding) is a good model to generalize.
  • Log every action in an attributable way to satisfy GDPR Article 5(2).
  • Watch for collusion signals: exact price alignment, unanimous strategies, synchronous behaviors. Set quotas and alarms.
  • Host in the EU and sign your DPAs before any production rollout, as explained in this guide on integrating an LLM without violating GDPR.

The identity and permissions of each agent remain the prerequisite of any deployment: I detail this in the article Enterprise AI agents: governance is the real bottleneck.

TL;DR

Multiagent systems promise real productivity gains, but the Anthropic study shows their failures are predictable: weak coordination, failed merging of collective work, conformity cascades, collusion, and credulity toward misleading sources. For a French or European company, these technical failures become regulatory exposures under GDPR. The best practices exist: a central forum, controlled diversity, human supervision, audit logging, and European hosting.

Deploying AI agents and want to avoid these pitfalls from the architecture stage? Let's talk.

About the author

Pierre Kasparian

4th-year engineering student at UTT (University of Technology of Troyes) and AI integration freelancer. He deploys LLMs, RAG pipelines, and AI agents for French and European companies, with strong expertise in GDPR compliance and European hosting. 15+ client projects, including Pretto and LiveSession.