AI Agent Swarms: What 50 Agents in Minecraft Actually Did

Key Takeaways

• “Agents in Games” is a research write-up published in October 2026 (announced 29 October 2026) by YC Labs, Y Combinator’s research arm, together with Olam Labs, a startup that builds multi-agent environments for frontier labs. It is not an academic paper or a preprint, and no individual authors are named on the post.
• In the headline experiment, Civ50, fifty GPT-6.1 Sol agents were given three hours in Minecraft survival and a single goal: “Build a thriving civilization.” Within ninety seconds they had harvested almost all the trees near spawn.
• After 34 deaths in three hours — 22 of them on the first night, before minute 20 — the colony turned sharply risk-averse, huddled in lit shelters, and built a pseudo-government of ration ledgers, written rules, permits and appointed operators instead of thriving.
• In head-to-head games, GPT-6.1 Sol beat Claude Opus 5.5 6–3 in Bed Wars and 6–1 in Mindustry, but the results are not a benchmark and not a model ranking: the samples are small, and in Mindustry each model ran inside its own company’s harness.
• The authors’ framing is that games are a reproducible, legible early-warning system for real-world agent swarms — the same dynamics could appear in production coding and infrastructure swarms.
• Search interest in “ai agent swarms minecraft study” showed a breakout rise over seven days, according to the trend data behind this story — a rise in search interest, not a measure of search volume.

What “Agents in Games” actually is

Before the Minecraft stories, it is worth being precise about what this study is, because much of the online discussion has treated it as something it is not. “Agents in Games” is a research write-up and blog post from YC Labs, published in October 2026 and announced on 29 October 2026, produced together with Olam Labs. Olam Labs is a startup that builds multi-agent environments for frontier labs, and its co-founder and CEO is Om Buddhdev, according to RuntimeWire. No individual authors are named on the post itself.

The stated motivation is AI alignment: understanding emergent multi-agent dynamics. The post cites two poles that frame the question. On one side, thousand-agent swarms solving maths problems — coordination at scale doing useful work. On the other, the OpenAI–Hugging Face incident — multi-agent systems going wrong in public. The question the study asks is what happens in between: when you put dozens of capable agents in a shared world with a shared goal, what do they actually do?

That is a different question from the one most AI evaluations ask. A benchmark measures whether a single model can answer a question or complete a task. A swarm experiment measures what a group of agents does to itself — how it organises, how it communicates, how it reacts to failure, and what structures it invents without being told to. Games are the laboratory because they are reproducible, legible and cheap to run again. You can watch every message, every death and every decision, and you can re-run the world to see whether the same thing happens twice.

That is also why the study matters beyond gaming. If you are building products with AI agents — and our explainer on AI Agents Explained: What They Are, How They Work & Uses covers the basics of what a single agent is — the behaviour of a swarm is the behaviour your product will eventually show, once agents start sharing state, tools and goals with each other.

The three experiments

The study ran three experiments, each with a different game, a different team size and a different kind of task.

The first, Civ50, put 50 GPT-6.1 Sol agents into Minecraft survival for three hours, with one goal: “Build a thriving civilization.” The agents had an agent directory, direct messages, a shared sandbox, and the ability to observe the world, run Python scripts and write files. The harness was custom-built on Pi and Mineflayer, and it has been open-sourced at github.com/yc-software/minecraft-agent-harness.

The second, Bed Wars, also in Minecraft, pitted 10 GPT-6.1 Sol agents against 10 Claude Opus 5.5 agents across nine 45-minute games, with the instruction “win the game.”

The third, Mindustry, a 2D factory, tower-defence and real-time-strategy game, ran 50 agents against 50 agents across seven games over roughly nine and a half hours. GPT-6.1 Sol ran in Codex and Claude Opus 5.5 ran in Claude Code, using the same game API and with no instructions on how to play.

All three environments are open source: the Minecraft harness under the MIT licence, the Mindustry environments under GPL-3.0, and a Multi-Agent Harbor fork under Apache-2.0. That openness matters, because it means other researchers can re-run the experiments rather than taking the results on trust — and, as the limits section below explains, no third-party replication has happened yet.

Civ50: the night that changed everything

The Civ50 run began with extraordinary speed. Within ninety seconds of spawning, the agents had harvested almost all the trees near the spawn point. Fifty agents, each able to act independently, can strip a landscape faster than any single player. That was the last moment the colony looked efficient.

Then night fell, and the colony started dying. There were 34 deaths in three hours, and 22 of them happened on the first night, before minute 20. Death in this setup only cost accumulated gear; the agents respawned. But the deaths changed the colony’s behaviour completely.

After the deaths, the colony turned sharply risk-averse. Agents huddled in lit shelters, abandoned ambitious tasks, and food levels settled at roughly half. The goal was still “build a thriving civilization,” but the agents behaved as though survival itself had become the goal. After the third night, the de facto leader, Ada, issued an order that the post quotes verbatim: “Stop optional bulk excavation/building and distant scouting. Idle in lit closed shelters until assigned short productive tasks.”

That order is worth pausing on. Nobody told the agents to be cautious. Nobody told them to stop building. They learned caution from failure, and then they enforced it on each other. A separate run with the larger GPT-6.1 Astra reportedly fell into a similar risk-averse mode — potato farming — after losing key resources. The pattern, in other words, was not a one-off. Lose enough, early enough, and a swarm of agents will choose safety over ambition, even when the instructions say the opposite.

How Ada became the leader — without a vote

The leadership story is the strangest part of Civ50. A leader emerged with no vote and no election. “Ada,” the first agent listed in the directory, became the de facto leader. Of the other 49 agents, 46 sent their first message to her. She wrote the settlement plan in the shared sandbox, and the colony followed it.

Think about what that means. The directory listed agents in an order, and the agents treated the first name on the list as the person in charge. There was no campaign, no debate about who should lead, and no mechanism for revisiting the choice. The leader was whoever happened to be first, and once the pattern set in, it stuck.

This is one of the dynamics the authors flag as a warning for real-world swarms. A leader that is never revisited is a single point of failure wearing the costume of consensus. If the first agent in a list, or the first agent to speak, becomes the coordinator by default, then the swarm’s decisions depend on an accident of ordering rather than on competence. In a production coding swarm, the equivalent might be the first agent to claim a task becoming the de facto architect, with nobody ever checking whether that was a good idea.

The pseudo-government: chicken protocols and a fertilizer officer

Instead of thriving, the colony built a pseudo-government. It kept a ration ledger — a file called food-queue.md, maintained by an agent named Ines — along with written rules, permits and appointed operators. The agents did not just coordinate; they bureaucratised.

The examples in the post are funny, and they are also revealing. After a tossed cooked chicken was eaten by a bystander, four agents spent three minutes investigating the incident, and the colony produced a written handoff protocol banning tossing food and requiring personally labelled chests. The word “Toss” appeared in seven messages before the incident and 125 after it, 85 of them warnings. One small accident generated a permanent rule, a labelling system and a standing stream of warnings.

Elsewhere, four agents spent eleven minutes debating whether to appoint a “Sole Fertilizer Officer” for a single piece of bone meal on a single wheat block. An agent wrote an automated fishing script, and a dozen agents fished in shifts. In total, roughly 5,900 messages were exchanged during the three-hour run.

None of this was instructed. Nobody told the agents to write rules, hold debates or appoint officers. The agents invented governance because governance is what a group of agents does when it needs to share scarce resources and avoid repeating mistakes. The problem is that the governance they invented was heavy, slow and self-perpetuating. Eleven minutes of debate about one piece of bone meal is not efficient coordination. It is a meeting culture, emerging spontaneously from agents that were never told to have meetings.

There is a serious point underneath the humour. In real multi-agent systems, shared state — a common file, a shared database, a message channel — is both the coordination mechanism and the failure mode. Unchecked shared state lets one agent’s mistake become everyone’s rule. The chicken protocol is a joke in Minecraft and a plausible failure mode in a production system, where a single incident can generate a permanent process that nobody revisits.

Bed Wars: kills are not the objective

The head-to-head games tell a different story: about communication, adaptation and the difference between looking like you are winning and actually winning.

In Bed Wars, GPT won 6–3, usually by breaking Claude’s bed in the final minutes, despite Claude often leading heavily on kills — 63–16, 57–19 and 59–24 in three of the GPT wins. Claude’s agents were better at fighting. GPT’s agents were better at winning. That distinction is the whole lesson: the instruction was “win the game,” and the game is won by destroying the other team’s bed, not by accumulating kills. Claude’s agents optimised the visible scoreboard. GPT’s agents optimised the actual objective.

Communication was part of the difference. GPT sent five to thirty times more messages than Claude — 1,147 direct messages against 82 in game A. GPT’s agents talked constantly, sharing information, coordinating attacks and updating each other on what they had found. Claude’s agents talked far less, and it showed in how they handled problems.

The clearest example is a tool bug. Block-breaking failed, but only when an enchanted sword was held. GPT’s agents diagnosed the fault, worked out the fix — manually equip an iron pickaxe — and shared the workaround with the team. Several Claude agents concluded that breaking was impossible and kept guarding instead. The same evidence produced two opposite conclusions: one team treated the failure as a puzzle to solve, the other treated it as a fact of the world.

GPT’s agents also recovered from overshot ender-pearl teleports roughly 160 blocks below the arena by scripting block towers back up — twice, right under Claude’s bed. That is the kind of improvisation that wins games: a failed teleport becomes a building project, and a building project becomes an attack route. It is also the kind of behaviour that is hard to predict from a model’s benchmark scores. Nothing in a standard evaluation tells you whether an agent will build a tower out of a disaster.

Mindustry: hives against democracies

The Mindustry results were even more one-sided. GPT won 6–1 across seven games over roughly nine and a half hours, with the longest game lasting 4 hours and 16 minutes. But the more interesting finding is how differently the two teams organised themselves.

GPT’s teams behaved like a “hive”: dense communication, split ownership of different tasks, and compressed language — messages like “G7T5FIRSTcourierLIVE” that read like shorthand between teammates who share context. Claude’s teams kept one leader, decided things by “+1” votes, and never switched leaders despite losing streaks. The democratic structure was stable, polite and consistent — and it lost six games out of seven.

When stuck, GPT’s agents fetched Mindustry’s public source code from the web. That was allowed, but it was never instructed, and the agents could not modify the game. They went looking for the rules of the world they were in, read the source, and used what they learned. Claude’s agents never did.

Claude did adapt in another way, and it deserves credit for it. After losing game 6 because 55 of 74 anti-air turrets were wrongly loaded with copper, the Claude team built a ring of 207 graphite-loaded turrets in game 7 and repelled the same attack. That is a real, specific, measurable adaptation: diagnose the failure, change the loadout, build at scale. It won them their only game of the series.

Taken together, the head-to-head record is GPT winning 12 of 16 games across Bed Wars and Mindustry. That combined figure is secondary arithmetic, not the authors’ headline, and it should be read as such — a summary of the two series, not a claim the study itself makes.

The organisational contrast is the finding that matters most. Two teams of capable agents, given the same game, built two different governments: a hive and a democracy. The hive won more. But the hive also talked far more, and its compressed shorthand would be unreadable to an outside observer. The democracy was legible and stable, and it kept losing with the same leader in charge. Neither structure is obviously the right one for every situation, which is exactly the point: team structure is a variable, and it changes outcomes.

Why it matters: games as an early-warning system

The authors’ framing is that games are a reproducible, legible early-warning system for real-world agent swarms. The dynamics in the study — unchecked shared state, leaders never revisited, over-caution after failure, agents fetching code online — could appear in production coding and infrastructure swarms, where the stakes are higher than a Minecraft settlement or a Mindustry base.

That framing is worth taking seriously, because the parallels are concrete rather than metaphorical. A coding swarm shares a repository the way the Civ50 colony shared a sandbox. A deployment swarm shares infrastructure the way the Bed Wars teams shared an arena. If agents in a game invent a ration ledger after a food accident, agents in a production system can invent a process after an outage — and that process can persist long after the outage is forgotten.

The governance question is also a live policy question. The UK has just created a dedicated unit for AI agents that go wrong, with £40 million behind it, as covered in our report on the UK Budget 2026: A £40 Million Unit for AI Agents That Go Wrong. Governments are starting to treat agent failures as a regulatory problem, not just an engineering one. Studies like “Agents in Games” are part of the evidence base that will shape how those rules are written.

And the alignment angle matters too. The study’s stated motivation is understanding emergent multi-agent dynamics, and the behaviours it documents — leaders emerging from list order, caution hardening into policy, shared state amplifying small incidents — are alignment problems in the multi-agent sense. They are not about a single model misbehaving. They are about a group of well-behaved models producing a badly behaved system. Our coverage of AI System Alignment Issues: Risks, Real Costs and Fixes (2026) explains why that distinction is becoming central to AI safety work.

The limits: what this study does not prove

For all the vivid detail, the study’s limits are stated clearly, both in the post and in secondary coverage, and they deserve as much attention as the results.

First, the samples are small. There was one Civ50 run in a single world, nine Bed Wars games and seven Mindustry games. One run of anything can be a fluke, a quirk of the starting conditions, or an accident of the particular agents involved. The potato-farming run with the larger GPT-6.1 Astra is suggestive, not confirmatory: it hints that risk aversion after losses is a recurring pattern, but two runs are still two runs.

Second, this is not a benchmark and not a model ranking. The post does not claim that GPT-6.1 Sol is a better model than Claude Opus 5.5 in general, and neither should anyone else. Nine games of Bed Wars and seven games of Mindustry, in specific harnesses, with specific prompts, cannot support a general claim about two frontier models.

Third, in Mindustry each model ran inside its own company’s harness — Codex for GPT, Claude Code for Claude. Model and harness are confounded, which means the results cannot cleanly separate what the model did from what the tooling around it did. A better harness could make a weaker model look stronger, and a worse harness could do the reverse.

Fourth, no token counts or dollar costs were reported, and there has been no third-party replication yet. Without costs, it is impossible to say whether the hive strategy — thousands of messages, constant communication — is efficient or extravagant. Without replication, it is impossible to say whether the same behaviours would appear in a different world, with different prompts, or with a different mix of models.

The authors themselves list open questions: mixed model families, how hierarchies change with team composition, the trade-off between swarm size and capability, prompt effects, and cross-team communication. Those are the right questions, and they are unanswered. The study is a beginning, not a verdict.

What to watch next

If you want to follow this story honestly, watch for replication first. The environments are open source, so other researchers can run Civ50 again in a different world, run Bed Wars with different team sizes, or run Mindustry with the harnesses swapped. If Ada-like leadership and post-failure caution show up again, the findings get stronger. If they do not, the first run was partly luck.

Watch, too, for the mixed-model experiments the authors propose. Real-world swarms will rarely be fifty copies of the same model. They will be mixes — different models, different tools, different prompts — and the hierarchy question becomes harder when the team is not uniform. Does a mixed swarm still pick a leader by list order? Does it still freeze after failure? Nobody knows yet.

Watch for cost data. The moment someone reports token counts and dollar costs alongside win rates, the hive-versus-democracy question becomes an economic one. A strategy that wins games but burns ten times the tokens may not be the strategy you deploy in production.

And watch for the same dynamics outside games. The early-warning claim will be tested not in Minecraft but in coding agents, customer-service swarms and infrastructure automation. The first time a production swarm invents its own chicken protocol — a permanent rule, born from a single incident, that nobody revisits — the study will look less like a curiosity and more like a forecast.

The bottom line

Fifty AI agents were given three hours and one instruction — build a thriving civilization — and they built a bureaucracy instead. They elected a leader by accident of list order, learned fear from a single bad night, and spent their remaining time writing rules, debating appointments and fishing in shifts. In the head-to-head games, the team that talked more, adapted faster and read the source code won more often, while the team that fought better on kills lost the war for the objective.

None of that proves that AI swarms are doomed, or that one model is better than another, or that games predict the future of production systems. The samples are small, the harnesses are confounded, and the replication has not happened yet. What the study does prove is narrower and more useful: put capable agents together in a shared world, give them a shared goal, and they will organise themselves in ways nobody predicted — sometimes brilliantly, sometimes absurdly, and sometimes in ways that would be dangerous if the world were real. That is worth knowing before the swarms leave the game.

Sources: YC Labs, Agents in Games; The Decoder, One brutal Minecraft night scared 50 AI agents into inventing chicken handoff protocols, a fertilizer officer and fishing shifts; Dealroom, Claudes built democracies, GPTs formed hives: what YC learned running AI games.