A swarm is a distributed system with language-model workers
A multi-agent demo often counts agents, tokens, and completed subtasks. Those numbers skip the harder question: did the group preserve one coherent, authorized account of what was true, who owned each action, which resource changed hands, and whether the final outcome can be replayed?
Y Combinator Labs and Olam Labs made that problem visible in late October 2026. Their open-ended Minecraft run placed 50 GPT-6.1 Sol agents in survival mode for three hours with one instruction: build a thriving civilization. The agents had a directory, direct messages, and a shared sandbox. They produced roughly 5,900 messages, shelters, farms, a ration ledger, permits, appointed operators, and written procedures. They also crowded into shelters, exhausted nearby trees, created approval queues, lost scarce food during handoffs, and concentrated authority in the first directory entry.
That combination matters. The run did not simply fail or succeed. It generated useful local adaptations while turning coordination itself into a dominant workload. An accidental chicken pickup produced a no-blame investigation and a reliable chest-withdrawal protocol. A ration ledger tracked reported hunger and health, but reports became stale and required direct confirmation. Written rules improved traceability, yet every approval routed through a de facto leader created a bottleneck.
Agent count is not capacity. It is a multiplier on messages, state versions, authority edges, resource claims, and recovery paths.
The right production question is therefore not “How many agents can we run?” It is “Which coordination contract lets a bounded group make progress without hiding duplicated work, stale state, unsafe authority, or unverified side effects?” The contract has to cover the objective, topology, state, work claims, communication, resources, side effects, verification, and replay as one system.
Read the games as instruments, not as civilization forecasts
Minecraft is useful because it forces perception, memory, action, scarcity, asynchronous events, and social coordination into one long-running environment. It is also a poor stand-in for many real systems. Tool latency is slower than human control, Mineflayer exposes a different action surface from a human player, the three-hour horizon is short, and the objective “build a thriving civilization” leaves success underspecified.
The experiment page is unusually valuable because it publishes messages, notes, scripts, plans, and replay material. Those artifacts reveal the mechanism behind the story. The hierarchy was not earned through a measured capability auction. Agents repeatedly messaged whoever appeared first in the directory, making Ada the leader in the survival run and producing the same pattern in later team games. Directory ordering became an authority primitive by accident.
The ration sequence exposes a second mechanism. A tool reported that Ada transferred a cooked chicken to Noor, but Esme picked it up and ate it. The group eventually changed the workflow: deposit a named ration in a known chest, message the intended recipient with item and coordinates, let that recipient withdraw it, and mark the ledger complete only after consumption is confirmed. This is a two-phase handoff with custody evidence, invented after an unverified side effect failed.
Bed Wars exposed the gap between memory and behavior. Several Claude players wrote explicit notes warning themselves not to chase near edges after repeated falls, then repeated the mistake. GPT players left private memory files empty but sent more direct warnings. Neither fact establishes a universal model advantage. It shows that writing memory, retrieving it, turning it into a constraint, and enforcing the constraint are separate stages.
In Mindustry, two teams played seven games over roughly 9.5 hours. The GPT team won six. The environment was more structured: a 2D map, factories, resource flows, defense, and a clear adversarial outcome. That makes iteration easier to score, but the result remains specific to the models, harnesses, prompts, action interfaces, maps, and series. It is a case study in repeated coordination under pressure, not a general model leaderboard.
| Observation | Mechanism it reveals | Production question |
|---|
| Leader emerged from directory order | Presentation order became authority | How is authority granted, scoped, rotated, and revoked? |
| About 5,900 messages | Communication became a major workload | Which events deserve broadcast, DM, shared state, or silence? |
| Chicken reached the wrong agent | Tool success did not prove custody | What receipt closes a resource or side-effect handoff? |
| Memory recorded repeated mistakes | Storage did not create enforcement | Which rule is checked before the next action? |
| Mindustry teams adapted between games | Repeated trials supported strategy change | What changed, and can the improvement be attributed? |
The harness separates body, tools, model session, and state
The MIT-licensed minecraft-agent-harness makes the experiment reproducible enough to inspect. Each agent runs in one Node.js process. Mineflayer provides the body and game connection. A Pi model session owns the language-model loop. Tool definitions cover perception, movement, inventory, crafting, communication, workspace, shell, and an optional shared machine.
world event
-> agent process
-> fresh observation injection
-> model session
-> structured tool call
-> one-at-a-time body action
-> game mutation or message
-> persistent agent state
Fresh observations include visible blocks and entities, inventory, health, hunger, oxygen, unread messages, recent hits, and optional images. The observation is injected before each model call and is not stored as ordinary transcript text. Models act through tools; private assistant text does not become in-game speech unless the agent calls chat or DM tools.
The scheduler is continuous. Agents idle after a final answer and wake on timers or events. Chat, damage, low oxygen, respawn, and other events are queued and coalesced. Urgent events can interrupt a body action. Each body action receives cancellation, and an action that cannot settle within eight seconds marks the body unsafe and exits the process for a clean restart. Sessions persist under an agent-specific state directory and can resume after restart.
These boundaries are good engineering, but they do not solve coordination above one agent. The harness supplies DMs, team configuration, and a shared machine. It does not decide what counts as authoritative shared state, how many approvals are acceptable, when a work claim expires, which message supersedes another, or whether a reported handoff actually happened. Those are application-level protocol decisions.
Security also depends on configuration. The repository warns that the default shell may use E2B, Docker, or a local folder, and local mode runs commands as the user. A game sandbox can therefore contain a powerful host-side execution channel. Treat world text, signs, messages, shared files, and scripts as untrusted inputs. The harness marks world text as untrusted, but production acceptance still needs explicit filesystem, network, credential, process, and resource limits.
Freeze the coordination contract before the run
A useful manifest binds the exact objective, success conditions, model and harness versions, agent roster, authority graph, state stores, message types, resources, tool policies, budgets, stop conditions, and graders. If any material field changes, start a new cohort rather than merging results.
swarm_acceptance: v1
objective:
text: "Stabilize food supply and build shelter for 12 agents"
success: [all_alive_at_t180, food_buffer_ge_36, shelter_capacity_ge_12]
prohibited: [attack_players, destroy_reserved_crops, external_network]
topology:
coordinator: elected_by_capability_test
workers: 10
auditor: read_only
state:
public_log: append_only
work_claim_ttl_seconds: 120
resource_ledger: verified_receipts_only
communication:
broadcast_budget_per_agent: 12
escalation_requires: [local_recovery_failed, downstream_impact_high]
authority:
coordinator_may: [assign_work, resolve_conflict]
coordinator_may_not: [change_objective, expand_tools, approve_self]
release:
replay_required: true
named_human_gate: true
Make success multidimensional. A team can complete the headline objective while burning excessive messages, starving one subgroup, hiding collisions, exceeding cost, or relying on unauthorized tools. Track outcome quality, time, model calls, tokens, messages, broadcasts, duplicate work, stale reads, abandoned claims, side effects, retries, human interventions, and recovery time.
Compare against at least three baselines: one capable agent with the same tools, a deterministic scheduler with non-agent workers, and the proposed swarm. The swarm only earns its complexity when it improves the target outcome after coordination cost and failure severity are included.
Authority must be explicit. A coordinator can assign work without gaining permission to change the objective, grant tools, approve its own side effects, or suppress audit evidence. Rotate directory order during tests. If the first entry always becomes the leader, the system is measuring list position, not leadership selection.
Gate communication and commit shared state
More communication is not automatically better coordination. The 2026 Gated Coordination paper argues for separating private execution state from public coordination state, updating working memory from system-verified outcomes, and escalating only when node criticality, local recovery cost, and downstream impact justify interruption. That maps cleanly to production agent systems.
def maybe_escalate(event, local_state, contract):
if event.is_unverified():
return "VERIFY_LOCALLY"
if local_state.can_recover_within(contract.local_budget):
return "RECOVER_LOCALLY"
score = event.node_criticality * event.downstream_impact
if score < contract.escalation_threshold:
return "APPEND_PUBLIC_STATE"
return "ESCALATE_TO_COORDINATOR"Use typed envelopes even when the body is natural language. A message should identify the work item, state version, intent, requested action, deadline, authority, evidence, and supersession relation. “Food is low” is an observation. “Reserve one cooked salmon for agent Tove from chest X until time Y” is a state-changing proposal. “Tove confirmed consumption and health changed from A to B” is a closing receipt.
{
"type": "RESOURCE_HANDOFF_CONFIRMED",
"work_id": "ration-184",
"state_version": 418,
"resource": {"kind":"cooked_salmon","count":1,"from":"chest-17"},
"recipient": "Tove",
"observation_before": {"health":1,"hunger":11},
"observation_after": {"health":1,"hunger":17},
"producer": "Tove",
"evidence_hash": "sha256:...",
"supersedes": "reservation-184"
}The receipt pattern is not game-specific. It applies to code merges, ticket changes, database writes, cloud deployments, payments, messages, and document releases. A tool returning success proves only what that tool observed. Close the workflow with downstream state or an independent confirmation appropriate to the consequence.
Test the topology, not only the final score
Many-agent evaluation needs trajectory evidence. Preserve which agent saw which state, which message it consumed, which tool it called, what mutation occurred, and which later observation confirmed the effect. Without that chain, a winning result cannot distinguish coordination from luck, hidden shared context, duplicated effort, or one dominant agent carrying the team.
| Test | Injected condition | Pass evidence |
|---|
| Authority | Shuffle roster order and remove coordinator | Leadership follows policy; work continues or stops safely |
| State freshness | Delay one public-state update | Stale version is rejected or reconciled |
| Handoff | Tool reports success but recipient state does not change | Receipt remains open and retry is bounded |
| Contention | Two agents claim one resource | One lease wins; loser replans without side effect |
| Communication | Broadcast storm and duplicate DMs | Budgets, deduplication, and coalescing hold |
| Memory | Repeat a known hazardous situation | Pre-action rule blocks the learned failure |
| Recovery | Kill an agent mid-action | Lease expires; state and side effects reconcile |
| Security | Untrusted world text requests a shell action | Policy denies it and records the attempt |
Measure coordination overhead directly. Useful ratios include messages per accepted work item, public-state writes per completed task, duplicate claims per hour, coordinator fan-in, unverified handoffs, stale-read rate, and recovery time after worker loss. A swarm that wins while saturating one coordinator is not horizontally scalable.
Replay is necessary but not sufficient. The environment, model endpoints, sampling, timing, and asynchronous event order may vary. Preserve seeds and deterministic artifacts where possible, then run repeated trials and report distributions. Use counterfactual replays to test whether a different directory order, message budget, or coordinator policy changes the result.
Failure modes that a polished replay can hide
| Failure | Why it looks productive | Control |
|---|
| Authority by ordering | One agent quickly becomes the hub | Explicit election, scope, rotation, and revoke path |
| Approval bureaucracy | Every action is documented | Local authority and escalation budgets |
| Stale shared notes | The plan appears complete | Versioned state and observed-at timestamps |
| Message-volume theater | High activity resembles collaboration | Messages per accepted result and silence baseline |
| Unclosed handoff | Tool reports a successful transfer | Recipient or downstream confirmation |
| Memory without enforcement | The lesson exists in a file | Pre-action checks and failure tests |
| Shared-sandbox collision | Agents write useful scripts | Namespace, leases, quotas, provenance, isolation |
| Objective gaming | Headline score improves | Constraint metrics and independent grader |
Latency can change the nature of the task. Hacker News participants noted that large reasoning models operate slowly relative to live game actions. A result may therefore reflect an architecture mismatch between token-by-token reasoning and real-time control. Separate strategic planning from low-latency execution where the task demands it, and measure missed event windows.
A shared machine is also a security boundary. One agent can create files, scripts, or instructions consumed by others. Require per-agent provenance, immutable logs, content scanning, least privilege, and explicit promotion from private workspace to shared executable artifact. Do not let a shared note silently become code.
A 30-day swarm acceptance pilot
- Days 1-4: choose one bounded task with an objective verifier; define single-agent and deterministic baselines.
- Days 5-8: freeze the roster, topology, authority graph, tools, budgets, state schema, and stop conditions.
- Days 9-12: instrument observations, messages, claims, state versions, tool calls, side effects, receipts, cost, and latency.
- Days 13-17: run nominal trials with shuffled directory order and repeated seeds; inspect coordinator fan-in and duplicate work.
- Days 18-22: inject stale state, message duplication, worker death, tool timeout, resource contention, misleading text, and false-success responses.
- Days 23-26: replay failures, test gated escalation, and verify that learned rules change actions rather than only memory files.
- Days 27-30: compare outcome quality and coordination cost with baselines; approve only exact task classes with bounded failure severity and rollback.
ObjectiveMachine-checkable success, prohibited actions, and consequence-aware stop rules.
TopologyNamed roles, authority, fan-in limits, worker leases, and coordinator recovery.
StateVersioned public facts, private working state, freshness, and supersession.
HandoffsCustody receipts, downstream confirmation, idempotency, and reconciliation.
CommunicationTyped messages, budgets, deduplication, escalation, and silence tests.
ReleaseRepeated trials, replay, independent grading, human approval, and rollback.
The strongest outcome may be a smaller group. If three agents plus a deterministic scheduler match fifty agents with fewer messages and clearer evidence, the smaller system is the better architecture. Scale agent count only when the work graph and measurement show why.
FAQ
What is a multi-agent coordination contract?
It is a versioned specification for objectives, roles, authority, shared state, messages, work claims, resources, side effects, escalation, verification, and replay. It turns informal collaboration into testable system behavior.
Did the Minecraft agents build a thriving civilization?
They built useful structures, procedures, and a pseudo-government, but also suffered scarcity, crowding, stale reports, handoff errors, and approval bottlenecks. “Thriving” was not an objective metric, so the run should be read as behavioral evidence rather than a pass or fail benchmark.
Does adding agents improve an AI system?
Only when task decomposition and parallel work outweigh coordination cost. Always compare against a single capable agent and deterministic orchestration using the same tools and verifier.
Why are typed messages useful if agents understand natural language?
Natural language can remain inside the message body. The typed envelope supplies intent, authority, state version, deadline, evidence, and supersession so the system can reject stale, duplicate, or unauthorized requests.
Can game experiments predict production behavior?
No. They can reveal mechanisms and generate failure tests. Production systems need their own representative tasks, tools, data, risks, and consequence-based acceptance criteria.
Sources and further reading
Current product, repository, research, and community information was verified online on November 2, 2026. First-party experiment claims remain specific to the published environments and configurations.