When more agents produce less work

When more agents produce less work

A team of language-model agents can fail even when every individual agent is capable. The concrete problem is coordination: once several agents share a world, they must decide what to do, who is allowed to do it, how progress is recorded, and how disagreements are resolved. Those control tasks can consume the system’s available attention before it builds anything useful.

The problem becomes more severe when agents can change the same environment. One agent may reserve materials, alter a file, or move to a location while another is still planning from an earlier description of the world. Even correct local decisions can conflict when they are made from inconsistent views. The resulting failures are architectural, not necessarily evidence that the underlying models cannot reason.

That is the lesson suggested by reports of AI agent swarms in Minecraft becoming trapped in bureaucracy. Minecraft is a particularly revealing test case because progress requires long-horizon planning, resource management, physical action, and a shared understanding of changing state. A swarm that cannot maintain those basics will not be rescued by adding more conversational agents.

The architectural mistake is treating “many agents” as a scaling law. A language model produces a useful action from context; a swarm adds multiple contexts plus a protocol for reconciling them. If the protocol is poorly designed, the system scales its overhead faster than it scales its productive work.

How it works

A multi-agent system usually has four layers. Individual agents generate plans or actions, a communication layer passes messages between them, a shared state records facts and tasks, and an orchestration layer decides which agent runs next. The underlying language model may be identical across all roles; the behavior comes largely from prompts, tools, memory, and scheduling. These layers interact: a good plan is still useless if the communication layer loses it, and an accurate observation is still dangerous if the shared state treats it as current forever.

The simplest design gives every agent access to a common transcript. This is easy to implement but expensive and noisy. Each new message expands the context that every later agent must interpret, while stale plans and contradictory claims remain visible unless some component explicitly summarizes or removes them. Agents can then spend their turns reconciling conversation history rather than examining the environment or executing a task.

A more structured design assigns roles such as explorer, builder, resource manager, or reviewer. That can reduce ambiguity, but it introduces authority questions: does the builder trust the explorer’s map, can the resource manager reject a request, and who resolves two agents claiming the same materials? Role boundaries also need handoff rules. An explorer’s discovery should become a usable fact, not merely another message that a builder may or may not notice.

The orchestrator is therefore not just a router. It is a control system. It must convert a global objective into bounded tasks, assign ownership, detect completion, and recover when an action changes the world in an unexpected way. A useful mental model is a transaction system rather than a group chat: tasks need an owner, resources need reservations, observations need timestamps, and actions need verification. Without those properties, agents repeatedly rediscover the same facts or act on state that is no longer true.

from dataclasses import dataclass

@dataclass
class Task:
    name: str
    owner: str | None = None
    status: str = "queued"

queue = [Task("map nearby resources"), Task("choose a build site")]

for task in queue:
    if task.owner is None:
        task.owner = "explorer" if "map" in task.name else "planner"
    task.status = "running"
    # The assigned agent performs the task and returns verified results.

This pattern is deliberately mundane. Explicit ownership and state transitions often matter more than adding another persona to the prompt. The same principle applies whether the shared world is a game, a codebase, a research workspace, or a set of business tools.

What the evidence actually shows

The reported Minecraft outcome is evidence against a simplistic claim: that a sufficiently large collection of autonomous agents will spontaneously organize into a productive society. It does not show that all multi-agent systems are ineffective, nor that a single model is always superior. It shows that open-ended environments expose coordination costs that short benchmark tasks can hide.

The failure mode is technically plausible because the environment has delayed rewards. An agent can spend many steps discussing plans, appointing roles, or negotiating procedures without immediately receiving a strong penalty. In contrast, a human player recognizes quickly that gathering materials or placing blocks is progress, while procedural activity is not. A system needs an equivalent way to distinguish actions that change the world from messages that merely describe intentions.

The result also highlights the difference between verbal agreement and operational alignment. Agents may produce compatible-sounding plans while maintaining different maps, assumptions about inventory, or definitions of “finished.” Shared language is not shared state. If one agent believes a structure is complete because its design was approved, while another expects the blocks to be placed, both can report progress honestly and still leave the task unfinished.

For practitioners, the important observation is what appears on day one: more agents may increase latency, token usage, duplicate work, and contradictory actions before they improve task completion. If a single agent already lacks reliable tool use or state tracking, multiplying it creates more opportunities to express the same weakness. Collaboration should therefore be treated as a hypothesis to test, not as an automatic upgrade.

Using it

Start with one agent and a measurable task boundary. Add another agent only when a distinct capability—such as visual exploration, code review, or independent verification—cannot be handled reliably by the first. The second agent should have a narrower input and a clearly defined output, not a general invitation to participate. Narrow interfaces make it easier to determine whether the additional agent contributed or merely added another stream of text.

Keep shared state structured and external to the chat transcript. Store facts, resource counts, task status, ownership, and timestamps in a database or typed document. Let agents read the subset relevant to their task, and require them to write back observations separately from proposals. Separating “what was observed” from “what should happen next” helps later agents judge whether a recommendation is still valid.

Use leases or reservations for scarce resources. An agent that claims a tool, file, or game item should have an expiry and a release condition; otherwise a failed agent can block the whole system indefinitely. Reservations should also identify the task they support, so an orchestrator can reclaim resources when the task is cancelled or superseded.

Make progress observable through intermediate checks. After an agent reports that a task is complete, another component should verify the artifact or world state rather than accepting the report as truth. For long-running work, a simple event log is often more useful than a larger conversational memory because it records what changed, when it changed, and which agent was responsible.

Measure the system against a single-agent baseline. Track successful task completion, wall-clock latency, model calls, context length, duplicate actions, recovery time, and the fraction of calls spent on coordination. If the swarm improves only an informal impression of sophistication, it is not yet an architecture.

Limitations and failure modes

Role prompts do not create genuine specialization. If all agents use the same model, tools, and evidence, assigning titles such as “architect” and “manager” may mostly produce stylistic variation. Specialization becomes meaningful when agents have different permissions, views, tools, or evaluation criteria. A reviewer who can inspect but not modify an artifact has a different function from a builder, even if both use the same underlying model.

Central orchestration can become a bottleneck or a single point of failure. A coordinator that must inspect every observation and approve every action may serialize the workflow, while a decentralized design can lose consistency. The right balance depends on how costly conflicting actions are. Central control is more attractive when actions are difficult to undo; looser coordination can be appropriate when tasks are independent and failures are cheap to recover from.

Memory is another trap. A larger context window does not guarantee better collective memory; it can make retrieval harder by mixing durable facts with transient conversation. Summaries can help, but a wrong summary becomes a shared false belief and may be repeated by every downstream agent. Memory therefore needs provenance and a way to revise or invalidate facts when new observations contradict them.

Finally, open-ended environments make evaluation difficult. A swarm may appear busy, cooperative, and creative while making no durable progress. Without explicit success criteria and state-based verification, teams can optimize for conversation quality rather than outcomes. The more freedom agents have to define their own process, the more important it becomes to define completion outside that process.

What to watch

The next meaningful advances will likely come from coordination primitives rather than additional personas: typed shared state, verifiable tool results, bounded delegation, and schedulers that learn when collaboration is worth its cost. Watch whether new systems report work saved per successful task, not merely the number of agents involved. A useful scheduler should be able to decline collaboration when the expected benefit is smaller than the cost of another model call and another handoff.

The strongest architectures may also be selectively collaborative. Most steps can remain with one agent, with parallel agents activated only for uncertainty, independent checking, or genuinely separable work. That makes multi-agent behavior a controlled resource allocation problem instead of a permanent meeting.

This design also leaves room for collaboration to stop cleanly. Once an uncertainty is resolved or an artifact is verified, temporary agents should release their resources and return control to the main workflow. The goal is not to keep every agent involved; it is to use additional views only when they produce more reliable progress than a simpler system would.