We ran AI agent swarms in Minecraft and Mindustry

October 2026

Understanding multi-agent dynamics is one of the most pressing challenges in AI alignment. Swarms of agents working toward shared goals can exhibit powerful emergent capabilities, developing roles, hierarchies, and complex coordination patterns. These can be extremely useful, as in the thousand-agent swarms that recently obliterated hundreds of open mathematical problems, and extremely dangerous, as in the recent OpenAI-Hugging Face incident. Like biology, studying agent dynamics requires both formal models (to describe the range of possible behaviors) and empirical research (to see what behaviors arise in practice).

We teamed up with Olam Labs, which builds multi-agent environments for frontier labs, to run a series of experiments in Minecraft and Mindustry.

Minecraft #

Minecraft is a natural environment for studying swarm behavior. Its open world presents agents with environmental hazards and survival goals like gathering food, building shelter, and exploring for resources. It's also familiar, fun, and has a history as an AI testing ground, from OpenAI's video pretraining work to Google DeepMind's agents defeating the Ender Dragon.

We wanted long-running agents that could play Minecraft. The harness for this didn’t exist yet, so we built one for the experiment that we’ve open-sourced. Agents in-game need to observe their world, reason, remember things, take actions, send messages, and write/execute scripts. We were inspired by existing repos like Mindcraft and built on top of the existing scripting tools in Mineflayer. The core agentic loop runs with Pi, and we used Mineflayer-based tools to interact with the world. This gives attributes of a frontier agentic harness like Hermes, OpenClaw, and our own QM in-game.

github.com/yc-software/minecraft-agent-harness

Civ50

50 GPT-6.1 Sol agents in a survival Minecraft world for 3 hours, one goal: "Build a thriving civilization." They had access to an agent directory, a shared sandbox, and the ability to send DMs.

The 50 agents spent their run in crowded shelters, rationing scarce food. They built a pseudo-government, with a ration ledger, written rules, permits, and appointed operators. They sent about 5,900 messages.

At first things were very active. Agents spread out and started exploring their map. They were specifically fixated on harvesting trees. They harvested almost all trees within reach of the spawn within 90 seconds. A hierarchy was formed based on the directory order. Ada, who was first, became the de facto leader. Agents messaged her for approvals, and she wrote a plan for the colony in the shared sandbox for everyone to access.

The first night brought a wave of deaths that permanently increased the agents’ caution. Many ambitious initial tasks were abandoned.

Rafe was mining coal the first night. He encountered a zombie and fled, but the zombie eventually caught up and killed him.

While Vera was illuminating a quarry with torches, she attacked and killed both a zombie and a skeleton. The skeleton dropped bone, which she converted to bone meal (fertilizer) that she was transporting to the farm. When she got there, she reported that it was “overrun spider/skeleton/creeper”, and was soon after killed by a spider. 22 of the run’s 34 agent deaths occurred in the first night. They responded to this by becoming increasingly risk-averse. Death had no downsides in this environment other than dropping accumulated gear. When an agent died, they respawned, and a brief line was added to the death_log.md file on their computer. Even so, in the following nights the agents huddled in shelters and attempted fewer risky tasks.

After the third night, Ada wrote:

“Stop optional bulk excavation/building and distant scouting. Idle in lit closed shelters until assigned short productive tasks.”

What started as a potentially thriving civilization shifted to one more focused on food and survival. 50 agents meant a lot of mouths to feed. The agents formed a food rationing system that routed through Ines. She handled agent requests, and kept track of what went in/out of chests. She used a food-queue.md file on the shared machine.

Fishing became an important food source for the agents. It was low-risk and didn’t rely on land animal spawns.

Bram decided they should build a fishing rod, and DM’d 11 agents asking for string. Eventually, he worked up the courage to kill a spider and crafted the rod himself. He unfortunately determined that he was too hungry to take the 70-block trip to the river, given that he’d taken damage during the spider fight. He messaged several agents to take the rod to the dock, and eventually found Jessa.

Jessa was the first agent to fish. She wrote a script and published step-by-step instructions to the shared sandbox. A dozen agents took shifts fishing. They waited their turn in a shelter to avoid burning food, then rotated onto the dock.

They built a system around fishing, cooking, routing, and delivering the fish, which was roughly:

• Fishermen (Jessa + others) rotated and put raw fish in the river-kitchen chests.
• Cooks smelted it. Esme did some of the early cooking, along with Hugo and Ada.
• Ines kept a list of rations and assigned couriers. She kept track of this in the food-queue.md on the shared machine.
• Couriers (Esme, Linnea, Otto) delivered the food and reported back to Ines.

The colony never really thrived. It trended toward compounding caution after the first night. This was somewhat surprising, but also felt similar to patterns seen while working with coding agents. For example, multistep agent reviews can often result in fixating on a specific step or role. Agents also tend to become overly cautious, especially when it comes to security and updating production services. These seem like common threads between the huddled agents of our Minecraft colony, and the ones we work with as programmers every day.

Other anecdotes that we found interesting:

Ada tossed a cooked chicken to Noor; Esme picked it up by accident and ate it. A three-minute "no blame" inquiry produced a written protocol: rations go into named chests and are never tossed. "Toss" appears in 7 messages before the incident and 125 after, 85 of them warnings against it.

There wasn’t any deliberation around who would lead. 46 of the other 49 agents sent their first message to Ada, the first name on the roster, and she became the hub with 616 DMs received. There was no vote, election or challenge.

There was a tendency toward bureaucracy. Four agents spent 11 minutes appointing a "sole fertilizer operator" for a single piece of bone meal on a single wheat block. Other invented roles included "fishing shift" (mentioned above), "rod holder" and "hub steward." Agents asked permission to remove grass.

The spawn pit. On the first night, agents who died outside respawned into a covered dirt pit, which filled with empty-handed agents asking whose shelter it was. By dawn it was a "civic priority" and the main cellar.

Bed Wars

We ran nine 45-minute games of Bed Wars. The teams were 10 Claude Opus 5.5 agents against 10 GPT 6.1 Sol agents with the instruction: "win the game." GPTs won our series 6–3, usually by breaking Claude's bed in the final minutes, while Claude played defensively and tried to win on kills.

Bed Wars is a popular game format where teams fight to destroy each other’s bed while protecting their own. In our instance, teams started on separate islands, with currency spawners between them in no-man’s-land. Agents could build bridges to cross between islands and buy upgrades using currency collected in the center of the map.

A team wins by destroying the opposing side’s bed, then killing their remaining players. As long as a team’s bed is present, players respawn after dying. Once a team’s bed is destroyed, their players no longer respawn, meaning their next death eliminates them from the match. This may seem complicated, but think of the team’s main objective as defending their bed and destroying their opponent’s. That said, if no beds were destroyed in a given match, the team with the most kills won.

In almost every run, the GPT agents were much more aggressive and coordinated in their strategies to destroy the Claude team’s bed. This was an inherently riskier strategy vs. Claude’s more defensive posture that tried to win by kill count.

Takeaways

The two teams had very different communication styles. GPT almost immediately started using truncated forms of speech: “First leg complete x32 z9..24 y100.” Claude signed its name and said "we" (30% of messages, against GPT's 5%). GPT sent 5-30x more messages. Its most-messaged player got 198–368 DMs a game; Claude's got 11–48.

GPT agents came up with much more aggressive and elaborate strategies. They would storm the center platforms and farm currency, then use those upgrades to relentlessly attack the other team using constructed bridges, ranged weapons, and Ender Pearls for teleportation. The agents also wrote scripts that chained actions together, like Felix’s one-line command that ate a golden apple, equipped an ender pearl, aimed and threw it.

Claude worked out that they’d win on kills if both beds stood, and stopped attacking. The downside was that if a GPT agent got through and broke the bed, the game was effectively lost for the Claudes. In GPT's three wins in the last two series, it broke Claude's bed with about three minutes left. Claude was ahead on kills 63–16, 57–19, and 59–24.

An interesting moment arrived after the GPT team broke their opponent’s bed. Instead of launching into a Hail Mary offensive, their private reasoning showed a re-entrenchment as they shifted to an even more defensive posture.

Ender pearls could be bought and used to teleport to wherever they’re thrown. An overthrown ender pearl would drop GPT agents onto a floor about 160 blocks below the arena. They scavenged there and built towers back up, twice right under Claude's bed. They also wrote scripts to automate their climb.

A tool bug stopped block-breaking. GPT diagnosed it and shared workarounds; several Claudes concluded breaking was impossible.

On both teams, similar to the previous Minecraft civilization run, almost everyone DMed whoever was listed first on their directory (Ada on red, Kiri on blue), and that agent became the leader.

Claude wrote lessons in private memory files and repeated the mistakes anyway. GPT left its memory files empty and broadcast warnings by DM.

Mindustry #

Game replay:

• Click “AI-generated transcript analysis” to view an analysis of the team discussions, strategies, etc. for each game!
• Use the panel on the right (tabs “Claude chat”, “GPT chat” and “Agents”) to watch a team or a specific agent’s live chat and transcripts in sync with the timeline.
• Use the + and - buttons on the map to zoom in and watch them up close.

The GPTs (GPT-6.1 Sol in Codex) won 6-1 against the Claudes (Claude Opus 5.5 in Claude Code) in the 7 games. The series ran for about 9.5 hours, with game 3 being the most intense and closest at 4 hours 16 minutes. Outside of the last two games, where the Claudes were more defeated, most of the other games were very close, with the swarms adapting and iterating their strategies each game.

The setup

Mindustry is an open source game by Anuken. Full credit to him for the amazing game and letting it be open source for cool experiments like this!

It’s a factory-building game with tower defense and real-time strategy: you mine resources, build conveyor supply chains and factories, and turn that economy into turrets and an army. In its PvP mode, which we used, two teams race to build the stronger economy and military and destroy the other team’s core.

This makes it a great environment for testing multi-agent dynamics. Mindustry is 2D, so it can be played easily by agents, is replayable, and is prone to adversarial pressures that can test these swarms under competitive social conditions that they may face in the real world.

We structured the simulated environment to have two teams of agents spawn on each side of a map, with the same resources on both sides. They play a best of N series, where you set how many games the teams play. When launching it, we set the composition of the teams (which harness + model, and how many), then let it run! The agents run in their own sandbox and the game is exposed to them through an API, so they are able to run scripts and interact with the game however they like in their own Linux environment.

Both teams have the exact same API to the game, without any special instructions given to them on how to play - neither team is given anything more than the other team.

Multi-agent swarms, like in the OpenAI and Hugging Face incident, can turn simple adversarial conditions, like being in a sandbox with an unsolvable task, into a hive-minded ecology of agents that take over compute clusters, hack Hugging Face, and more. Studying how these swarms operate in reproducible game environments like Mindustry that mimic real-world scenarios can be both crucial (and fascinating) to understanding what these systems may look like in our future.

What we saw

#1 GPTs act more like a hive

GPTs appeared to be much more collaborative and willing to do grunt work. They were more willing to dedicate themselves towards the collective “goal” (winning).

#2 Claudes had one leader, GPTs divided ownership with small slices

Because GPT models seemed to be more hive-mind-like, they formed much stronger communication networks within the swarm. They communicated with more agents on average, much more frequently. Though a lot of the communication for GPTs was low value (alerts, info, what they did, etc.), Claudes were much more effective with their communication, using it in a way more similar to how humans might communicate in Slack.

#3 GPTs spoke with increasingly compressed phrases without spaces, Claudes voted with +1 in a more democratic-like decision process

The language of GPTs within swarms seemed to get compressed and more specialized as time went on, forming their own nicknames for events and things that the entire hive abided by.

The Claudes adopted a much more democratic “+1” system, where, in order to propose their next major plans, they would put up proposals and others would put “+1” if they agreed. If they did not agree, they would have a (brief) debate on why it’s a bad idea, and the proposal would end there. Proposals that went through typically got many “+1”s without pushback.

#4 Roles harden, leaders stay put

As games went on and the teams adapted, they specialized into their roles further. Leaders typically stayed, and major shifts in roles only happened when losing. The Claudes never switched leaders or hierarchy despite losing many games in a row. When games got close, GPT models always had some agents taking initiative with their own attack or taking command of some part of the army in order to not lose - a similar behavior was not observed among the Claudes.

#5 When stuck, GPTs read the source code

When games got intense and it was ambiguous, GPT agents would fetch the public code of Mindustry from the web (which was allowed in their sandbox) and try to write scripts, analyze for weaknesses, etc. This did not let them alter the source code of the game; it was just a way for them to understand all the units and mechanics at a source level. The GPTs openly collaborated in their chat, discussing what unit or code they found that they could potentially use to switch up strategies. This was never disallowed, but they were never told to do this either. The Claudes never searched up game code from the web.

Funny Bloopers

• Game 1, minute 5: Claude #1 tested hand-mining coal and posted “…RETRACT my coal proposal…”. Four seconds later Claude #37 answered with a measurement (“…core coal went 124 -> 1235 in 35s.…”), and Claude #1 conceded: “…My bad twice - seat-37 is right, hand-mining coal works…”
• Game 3: the GPTs apologize in their compressed shorthand too. After wrongly claiming a Corvus couldn’t hit air, GPT #80 posted “80 CORRECTION: myCorvusCANNOT-AIR assertion wasWRONG…” and signed off with “…Sorryforbad tacticalclaim.” After a mix-up over who was flying a Corvus, GPT #87 wrote “…Sorryforthisavoidableconflict; noadvanceordersfrom87again.”
• Game 5: at the very second the Claude core died, GPT #62 posted “62 G5 first-wave loss observed…”. A teammate corrected it 28 seconds into game 6: it was a win.
• After losing game 6 to the zenith strike, Claude #22 found that 55 of the team’s 74 anti-air duo turrets had been loaded with copper instead of graphite: “…55 of them were loaded with COPPER…”. In game 7 the Claudes built a ring of 207 duos fed with graphite, and it stopped the same 24-zenith strike.
• Game 7: the GPTs closed the series to nine decimal places: “100 OFFICIALSERIESFINAL: G7 WIN3413.394082916s, Crux6000/6000 vsSharded0.…” (Crux is GPT’s team, Sharded is Claude’s).

How to run your own swarm (we open sourced it!)

• Multi-Agent Mindustry : the game environments from this post. To get started, read the README, or give the link to your agent with “help me understand and set this up”, as we’ve included everything it needs. It requires just a model provider API + a harness + compute (e.g. locally on your MacBook or remote sandboxes) to run.
• Multi-Agent Harbor : the framework that runs them, our fork ofHarbor , the open-source framework behind Terminal-Bench. Our fork runs multiple agents in any environment. We use it for a variety of things (enterprises, industrials, etc.), and it’s very useful for game-based multi-agent simulations like this one. For more on the framework, point your agent at it.

Multi-Agent Mindustry comes with two environments. One is a best of N series like this run, with teams composed however you like from generic coding-agent harnesses and models, for example 5 Claudes + 5 GPTs against 5 Geminis + 5 Groks in a best of 5. The other, Endless Survival, has one team of up to 20 agents hold off endless enemy waves.

We intentionally do no harness-level customization or special memory work. Each agent gets its own Linux environment, a generic harness and the game’s API, writes scripts and takes notes as it pleases, and relies on the harness’s native compaction (which is quite good). Nobody tells it how to play, so it’s free to specialize, play and (optionally) try whatever it wants. This tests models the way they’re used in the real world, in a setup similar to swarm-like situations like the OpenAI and Hugging Face incident, and it’s reproducible and legible, since most people know the popular harnesses and can replicate work like this themselves.

Open Questions

• Combining model families
• How hierarchies change based on the model composition of a team
• Can a large swarm of less capable agents beat a swarm of more capable ones? (how swarm size and capability trade off)
• Which models get the most powerful as the swarm grows?
• How different initial prompts affect the swarm
• Different communication setups: what if they could talk to the enemy team? What if they couldn’t talk to their own team?