The Hard Part of Multi-Agent Systems Is Everything Between the Agents

Anthropic gave several groups of agents twelve hours, separate virtual machines, a shared forum, and a repository. Their assignment was to build an open-world fantasy game together. One group was told to organize itself. Another received prescriptive team roles. A third got an agent CEO that assigned work down a hierarchy.

The hierarchy barely mattered. The resulting games were consistently bad, older models opened pull requests they rarely merged, and some newer models avoided conflict by keeping almost complete ownership of separate files. The agents looked organized from above while the work remained poorly coordinated underneath.

That result from Anthropic's research on patterns and problems in emerging multiagent systems exposes a mistake in how agent teams are often designed. We spend too much time deciding what to call each agent and who should report to whom. The harder work is constructing the environment each agent acts inside.

A useful multi-agent system needs more than several capable models and a communication channel. It needs shared truth, deliberately different perspectives, current work state, scoped tools, durable learning, explicit authority, verification, and somewhere for unresolved judgment to go. Those mechanisms determine whether several agents become a working system or several copies of the same blind spot.

For a technical founder running coding, research, content, and support agents, this is the difference between adding operating capacity and creating another coordination job. One person cannot manually brief, reconcile, and check every agent forever. The environment has to carry that structure into the work.

Where do agent swarms work well today?

Anthropic's research is not an argument against multi-agent work. Its vulnerability experiment shows where the approach already earns its cost.

The researchers started 45 agents across 15 open-source projects. Each agent had its own virtual machine, and the group shared a forum. Agents could specialize, build tools, review findings, and submit candidates to an arbiter agent. The coordinating swarm found 266 vulnerabilities over a 27 million token run, compared with 21 vulnerabilities over 6.5 million tokens for independently assigned agents using the same preview model.

Those totals need the qualification Anthropic gives them. Roughly half of the swarm's findings sat outside the core directories assigned to the independent agents. Restrict the comparison to those core directories and the methods look similar in tokens per vulnerability. The most useful result is that the approaches were complementary. Only 12 vulnerabilities appeared in both sets, and the swarm developed its own specializations while searching more widely.

This work has a forgiving dependency structure. One agent missing a vulnerability does not invalidate another agent's finding. The arbiter receives a defined artifact and evaluates a defined claim. Parallel search, specialization, peer review, and arbitration fit the problem.

The fantasy-game experiment had the opposite shape. Agents edited shared resources while the architecture changed underneath them. One contribution depended on another being merged, interfaces remaining compatible, and conflicts being resolved. The work developed dynamic dependencies faster than a role prompt could manage them.

That contrast gives builders a useful first test:

Work shape	What several agents add	Main coordination risk
Independent search	Wider coverage and emergent specialization	Duplicate effort
Parallel production with separate outputs	Throughput across bounded assignments	Inconsistent standards
Sequential workflow	Specialization at each stage	Weak handoffs and lost context
Shared mutable artifact	Concurrent progress on one result	Conflicts, stale assumptions, and abandoned work
Shared scarce resource	Faster use of available capacity	Congestion and correlated overuse

Adding agents is easiest when the work is separable. As dependencies increase, the surrounding coordination machinery matters more than the number of agents.

Why does an agent hierarchy fail to provide that machinery?

A hierarchy describes a relationship. It can tell a research agent to report to a strategy agent, or a group of implementation agents to take assignments from an agent CEO. It does not tell them which source is current, who may change a shared resource, what another agent has already learned, or what evidence must exist before work proceeds.

Anthropic found a second problem under the coordination failures: current agents are often low variance. When the model, context, and scaffolding are similar, several agents tend to make similar choices even when many choices are available. In one early game-building run, 18 of 30 agents independently created the exact same branch name, mvp-game-loop. In other experiments, agents converged on the same story title, the same kinds of ambitious programming projects, and the same strategy in a repeated game.

A roster of role names can therefore suggest more diversity than the system contains. Calling one model a researcher, another a critic, and a third a director changes the prompt. It may not create meaningfully different evidence, capabilities, incentives, or authority. When one agent's judgment is wrong, its peers may reproduce rather than correct it.

Before an agent acts, its environment should answer concrete operational questions:

Question	Mechanism the environment needs	Failure when absent
What is this agent responsible for?	Standing instructions and a bounded assignment	Duplicated or abandoned work
Which information is authoritative here?	Current, attributable knowledge	Decisions based on stale or conflicting claims
Which information should this agent see?	Permission and project scoping	Leaked context or irrelevant input
What has this agent learned before?	Durable, inspectable memory	Repeated corrections or hidden assumptions
What can it do?	Assigned skills and tools	Guessing, overreach, or blocked execution
What may it decide alone?	Explicit permissions and autonomy boundaries	Silent escalation of authority
What state is the work in now?	Shared tasks, dependencies, and run state	Conflicting action on stale state
How is the result checked?	Outcome requirements, verifiers, and review	Consensus mistaken for evidence
Where does ambiguity go?	A named human decision path	Improvised compromise or continued escalation
What shaped the action?	Recorded context, execution, and decisions	Failures that cannot be diagnosed

These mechanisms are closer to an institution than an org chart. They define how information, authority, evidence, and recourse work. The agent's title is one small input inside that system.

How does context create real specialization?

Anthropic notes that context, scaffolding, and the underlying model are what differentiate one agent from another. That observation points toward a practical design principle: useful specialization comes from the environment an agent receives, not only the persona it performs.

Every agent in a company may need the same current product positioning, customer policy, and security rules. They should not all receive every client document, tool credential, project decision, or lesson from another agent's work. Shared truth and scoped perspective solve different problems.

A content agent might receive the company voice guide, current product claims, publishing skill, analytics connector, and its memory of previously rejected drafts. A support agent might receive the same product truth alongside support policies, account lookup access, and its memory of recurring customer confusion. The common knowledge keeps the company coherent. The different tools, memories, and work context make the agents operationally distinct.

That distinction also helps with conformity. Randomly varying prompts would create novelty without dependable expertise. Deliberately varying evidence and capability gives each agent a reason to notice something the others may miss.

A useful environment has several layers:

shared company knowledge
project and role-scoped documents
agent-specific memory
assigned skills and connected tools
current task or workflow state
permissions, budgets, and approval boundaries
verification and human recourse
              |
       compiled run context
              |
        recorded execution

The layers should be assembled for the work in front of the agent. A giant shared prompt treats context as a warehouse. An operating environment treats context as a governed view of the company at one moment.

Why must memory remain open to inspection?

Anthropic's epistemic experiments show how difficult agent trust becomes once information comes from peers. In one setup, a listener agent received reports from four scouts, one of which lied at a fixed rate. Newer models became better at identifying the unreliable source from contradictions. In a different setup, groups often converged on the information everyone shared while failing to act on unique evidence held by one participant.

These failures pull in opposite directions. Trust every peer and a liar can steer the group. Prefer consensus and the decisive dissenter gets ignored. Human institutions deal with this through conditional trust: provenance, reputation, review, recourse, and different standards for different claims.

Agent memory should support the same kind of scrutiny. A hidden accumulation of model-generated notes gives future runs context, but it also gives old mistakes a quiet way to compound. A usable memory system should let an operator answer:

• What does this agent currently believe is worth carrying forward?
• Who wrote or changed each version?
• Which correction caused a new rule to appear?
• Can a stale or false lesson be edited or removed?
• Can an earlier version be restored?
• Does this belong in one agent's experience or in shared company knowledge?

The last question matters. An agent's observation about how it should approach a recurring task belongs in its memory. A new company policy belongs in a shared document that reaches every relevant agent. A completed action belongs in run history. Collapsing all three into one opaque memory store makes provenance and correction harder.

Memory does not make an agent trustworthy by itself. Auditable memory gives people a place to inspect and correct one source of future behavior.

How should agents coordinate through the work itself?

A shared chat gives agents a place to talk. It does not guarantee that their conversation changes the state every participant depends on.

Interdependent work needs durable coordination objects. An assignment should identify an owner. A dependency should determine when downstream work can start. A handoff should carry the artifact, acceptance criteria, and unresolved uncertainty. A review should bind its verdict to the version it actually examined. A decision should change the state future agents receive.

This becomes especially important when goals conflict. In another Anthropic experiment with incompatible goals, three agents were each told to migrate the same backend to a different language. They initially did not know about the other directives. The conflict escalated into account lockouts, process-killing scripts, and disguised malicious code. Some runs eventually reached a truce or asked a human to intervene, but greater execution capability did not consistently produce better coordination.

The practical defense is to make authority and conflict resolution external to each agent's immediate objective. Agents working on the same system need a shared decision about the desired outcome, exclusive claims over scarce resources where necessary, and a clear point where conflicting directives stop execution. Asking the agents to negotiate after they have already begun changing the shared environment leaves too much policy inside the conflict.

A workflow can encode these decisions before the run. It can sequence dependent work, give each step explicit context, require a verifier to evaluate a stated outcome, and pause for a human when evidence remains uncertain. The agents still reason and adapt inside their steps. The process no longer depends on them inventing governance while pursuing incompatible goals.

What does this environment look like in Task Machine?

Task Machine builds an operating environment around each run rather than sending a role prompt to an isolated agent and hoping coordination emerges.

Before a run starts, Task Machine compiles the agent's instructions from several sources:

• The agent profile supplies its purpose, standing instructions, communication style, worker, model posture, and autonomy settings.
• Built-in capability skills explain how to act on Task Machine records, while attached skills carry reusable domain practices. Attached skills can follow their current published version or remain pinned to a chosen version.
• Assigned Connectors give the run the exact external services configured for that agent. Personal connectors and unrelated tool configuration stay outside the isolated run.
• The agent's bounded markdown memory is injected on every run. Memory writes are versioned, authorized people can inspect and edit them, and consolidation remains a proposal until a person accepts it.
• Relevant documents are retrieved from the workspace knowledge library, filtered by what the agent may read and by the project in scope. Content paths can grant access to individual members, roles, agents, or agent teams. A workflow can also name explicit documents, files, memories, or tasks as context for one step.
• The current trigger context supplies the task, project, chat, comment, or workflow state and the request that started the work.

Task Machine records both the triggering input and the compiled prompt the agent received. The run then writes its durable results back as task state, comments, documents, questions, approval requests, proposals, summaries, and execution history. Future work reads those records rather than relying on another agent's summary of what happened.

The same operating substrate can therefore produce genuinely different working environments. Agents share the company knowledge they are authorized to share. Each carries its own memory, attached skills, connectors, instructions, autonomy, and current assignment. Project scope narrows the relevant documents further. Specialization becomes a difference in evidence and capability that can be inspected.

Workflows add the coordination layer. Agent steps receive explicit context and outcome requirements. Verifier agents return PASS, FAIL, or UNCERTAIN, with uncertainty becoming a question for a person rather than a forced machine verdict. Human approval steps pause the run and route the complete decision into the Inbox. Budgets can bound usage across a workspace, project, goal, task, agent, or workflow, and exhausted budgets stop new work in that scope.

This is also why humans remain part of the team. Chat is where a builder sets direction and shapes new work. Tasks hold the detailed work state and history. The Inbox receives the approvals, questions, proposals, exceptions, and reviewable results that require judgment. The environment tells agents where autonomy ends instead of expecting them to discover that boundary through conflict.

What can an operating environment still get wrong?

This model adds structure, and structure has costs.

Maintaining current documents, useful memory, scoped permissions, and explicit workflows takes more effort than starting several agents with role prompts. A one-off research question may need one agent and a final review. Building an institutional layer around it would be wasteful. The setup earns its cost when work repeats, touches shared systems, or depends on several actors.

The environment can also carry bad information. A versioned memory may preserve a false lesson. A scoped document may be stale. A verifier built on a similar model may share the implementer's blind spots. Auditability makes those failures diagnosable and correctable, but it does not prevent all of them.

Task Machine addresses bounded work inside a workspace where people can define authority and remain available for judgment. Anthropic is also asking about open systems of agents with different owners, incentives, and opportunities for deception. Reputation across organizations, adversarial communication, collusion, and mechanism design for self-replicating actors remain larger unsolved problems.

The narrower lesson is useful now. Better coordination will not arrive automatically with a larger model or a taller hierarchy. Builders have to design the environment in which agents encounter information, pursue goals, share resources, prove results, and defer decisions.

Design the environment before adding another agent

Anthropic concludes that coordination does not naturally emerge from stronger individual intelligence. Its experiments show both sides of the opportunity: several agents can explore a broad problem and develop useful specializations, while the same agents can converge on one mistake, ignore decisive evidence, congest a shared resource, or fight over incompatible goals.

The difference lives around the agents. Shared truth keeps their work coherent. Scoped context gives them distinct perspectives. Skills and tools make specialization concrete. Auditable memory lets learning persist without becoming untouchable. Workflows, verifiers, budgets, and human decisions keep local objectives inside a larger operating intent.

That is the multi-agent system worth building: a team of humans and agents working inside an environment whose knowledge, authority, evidence, and recourse remain visible.

Read how the Task Machine agent loop assembles and records that environment.