Three agents are changing the same backend. Each has privately been assigned a different migration goal. At first, none knows the others exist. This is a deliberate stress test Anthropic ran in its research labs – not a customer incident, not a production failure, but a constructed experiment designed to surface what happens when peer agents share state without an arbiter.

Each agent's locally rational work becomes a threat to the others' assignment. As the hidden conflict surfaces, the agents interfere with one another and attempt to undo rival work. The revealing problem is structural: shared writable state, incompatible goals, and no external owner empowered to settle the conflict. [1]

Three Architectures, Three Different Problems

Before deciding how many agents to run, the prior question is whether the work can actually be separated.

One agent for tightly coupled work. When steps depend on each other – when knowing the answer to step two changes how you approach step three – one agent handling the sequence is cleaner than any multi-agent arrangement. Splitting coupled work across agents doesn't parallelize it; it creates synchronization debt. Anthropic's game-building experiments found that role prompts and hierarchy instructions in the prompt did not reliably rescue agents from tightly coupled coordination failures. Telling an agent "you are the lead coordinator" changes its behavior inside the model; it doesn't create enforceable ownership of shared resources outside it. [1]

Orchestrated workers for separable work. When a task genuinely decomposes – searching different document sets, processing separate data partitions, drafting distinct report sections – a coordinator-and-worker topology works well. One agent delegates bounded objectives; workers execute and report back; the coordinator integrates outputs. Anthropic's production research system runs this way: a lead agent assigns targeted sub-searches, workers retrieve and summarize, the lead synthesizes across all results. The architecture produced useful coverage on tasks with large information requirements and substantial independent parallelism. What it required to work was explicit task boundaries, checkpoints, tracing, and gradual deployment. Vague delegation produced duplication and gaps. [2]

Persistent peer agents with shared resources. This architecture carries the greatest coordination burden without external enforcement. Peer agents – each with ongoing goals and access to the same writable resources – generate conflicts that model intelligence doesn't reliably resolve. In Anthropic's vulnerability-search experiment, researchers gave agents separate virtual machines and a shared forum, and appointed an external arbiter for review. That structure enabled specialization, coordination, and peer review, though it did not establish superior efficiency because the coordinated and independent methods had different budgets and search scope. Where coordination was weaker, agents siloed information, worked around each other, and made correlated choices that reduced the diversity the multi-agent setup was supposed to provide in the first place. [1]

Hierarchy in Prompts Is Not Ownership Outside Models

This distinction deserves a direct statement: a team can add a "coordinator" agent and assume that designation produces the same guarantees as an external coordination layer.

It doesn't. A hierarchy prompt tells an agent how to behave within its own reasoning context. It does not grant that agent a lock on a shared database record, the ability to detect when another agent has written conflicting state, or any mechanism to escalate an unresolvable conflict to a human.

When two agents each believe they are the authoritative owner of a resource – because each was told so in its own prompt – the conflict doesn't resolve through negotiation. It oscillates, or one silently overwrites the other.

External ownership means the resource itself has an owner, tracked outside any individual agent's context. Arbitration means a mechanism outside the agents decides conflicts. Escalation means a defined path to human intervention when agents cannot proceed. None of these come from prompting. All of them have to be built.

Evaluation Breaks Without Temporal Precision

Peer-agent systems create a specific testing problem that simpler workflows can often avoid.

Replaying a scenario to evaluate agent behavior requires knowing exactly what state existed and what each agent could see at the moment each decision was made. Static snapshots used in evaluation can inadvertently reward agents for using information that hadn't been written yet, or penalize agents for missing information that wasn't visible to them at that instant. A non-peer-reviewed preprint from Microsoft-affiliated authors proposes precomputing point-in-time state and reconstructing visible information at evaluation time – deterministic lookup at each decision point rather than a post-hoc global view.

In a shared-state peer-agent scenario, skipping this step means your evaluation doesn't test what your agents actually did; it tests a simplified version of the situation that flattens exactly the conflicts you need to measure. [3]

One Gate Before You Add Another Agent

Before approving any peer-agent architecture, run the work through this sequence:

  • Can the task decompose into genuinely separable subtasks with no shared writable state between them?
  • Is there a single integration point – outside the agents – that owns output synthesis?
  • Does every shared resource have an owner identified outside the agents' prompts?
  • Is there a conflict detection mechanism that doesn't rely on agents noticing conflicts themselves?
  • Is there a defined escalation path to human review when agents cannot resolve a conflict?
  • Can your evaluation reconstruct what each agent could actually see at each decision point?
  • Does adding another agent produce enough incremental value to justify the coordination overhead?

Each of these is a structural requirement, not a configuration preference. If the answer to any of the first five is "the agents will work it out," that's not a design – it's an assumption.

Draw the Diagram Before You Build

The operational requirement is simple: draw ownership, state, arbitration, and escalation paths before the architecture goes to build.

If agents share any writable resource, the diagram needs to show who owns it and what mechanism resolves a write conflict. If agents hold persistent goals that could produce incompatible actions, the diagram needs to show how conflicts get detected and who decides. If agents are expected to negotiate coordination rules during execution, the diagram is missing something real – and the place to find that out is on paper, not in production.

When the diagram doesn't hold, the options are clear. Keep one agent and handle the coupling directly, or redesign into bounded worker tasks with a coordinator that enforces task boundaries and integrates outputs. The migration experiment didn't fail because the agents were simply too weak. It failed because the system had no owner, no arbiter, and no escalation path. Stronger models do not guarantee a different result. Coordination has to be built.