In AI Agent Swarms, the First Name on the Roster Becomes the Boss

Claude and GPT teams in Minecraft won and lost on leadership, chatter and checking. Five fixes carry over to your coding agents.

Give fifty AI agents one goal and no org chart, and they will build an org chart anyway. They just won't tell you how they picked the boss.

That is the most useful thing to come out of a set of experiments Y Combinator Labs published this month with Olam Labs, a company that builds multi-agent test environments for AI labs. They dropped teams of agents into two video games and watched what happened. The headline result is a scoreboard: OpenAI's GPT-6.1 Sol beat Anthropic's Claude Opus 5.5 in both head-to-head games. The more interesting result is underneath it. The teams won and lost on things nobody designed: who ended up in charge, how much they talked, and whether anyone checked the work.

If you are building anything with more than one agent, those are your problems too. A swarm in a game is a cheap, visible version of the coding swarm you are about to run against your repo.

What YC actually ran

Three experiments, two games.

Minecraft, 50 agents. Each agent played as an ordinary player through Mineflayer, a library that lets a program walk, mine, craft and chat inside Minecraft. The agent loop itself ran on Pi, a coding agent runtime (the "harness": the code that feeds a model its instructions and tools and runs its actions). Agents had a directory of every other agent, a shared machine for files, and direct messages. Fifty GPT-6.1 Sol agents got three hours and one instruction: "Build a thriving civilization." They sent about 5,900 messages.

Minecraft Bed Wars, 10 versus 10. A team game where each side defends its bed and tries to break the other's. Ten Claude Opus 5.5 agents played ten GPT-6.1 Sol agents across nine 45-minute games.

Mindustry, team versus team. Mindustry is an open-source factory and tower-defense game: you build supply lines, feed ammunition to turrets, and hold off waves. GPT ran inside Codex, OpenAI's coding agent. Claude ran inside Claude Code, Anthropic's. Both teams got "the exact same API to the game." GPT won six of seven games over about nine and a half hours.

The authors say they did no special harness tuning or memory tricks for Mindustry. Each agent got its own Linux environment and a generic setup. So what you are watching is roughly what the off-the-shelf agents do when you put them in a room together.

Lesson 1: if you don't pick a leader, the list does

In the 50-agent Minecraft run, 46 of the other 49 agents "sent their first message to Ada, the first name on the roster." Ada received 616 direct messages. There was no vote and no challenge. The write-up puts it plainly: "A hierarchy was formed based on the directory order."

Read that again with your own system in mind. Somewhere in your orchestration code there is a list of agents. Maybe it is a YAML file, maybe a Python dict. Whatever sits at index zero may well become the hub. In YC's run, directory order decided it, and nobody had planned that.

The Claude teams showed a different version of the same thing. In Mindustry, "the Claudes never switched leaders or hierarchy despite losing many games in a row." A leader formed early and stayed, through loss after loss. GPT, by contrast, split ownership into smaller slices, and some GPT agents took initiative when games got close.

Neither pattern is wrong in itself. The problem is that neither was chosen. Leadership was an accident of list order and early momentum, and in Claude's case it never got revisited.

Lesson 2: the team that talked more won more

In Bed Wars, GPT agents sent five to thirty times more messages than Claude agents. GPT's most-messaged player received 198 to 368 DMs per game. Claude's received 11 to 48.

GPT won that series 6 to 3, and the authors' read is that GPT was "much more aggressive and coordinated" about destroying Claude's bed. Claude worked out a different plan: it would win on kills if both beds stayed standing, so it stopped attacking. It often led on kills, 63 to 16 in one of the later games, then lost when a GPT agent broke its bed with about three minutes left. A plan that relies on the other team not doing the obvious thing is a fragile plan.

Claude's messages were more cohesive in one measurable way. In Bed Wars, Claude used "we" in about 30% of its messages; GPT used it in about 5%. In Mindustry, Claude ran a "+1" system: a proposal stood if others added +1, and a disagreement led to a short debate that ended the proposal. That sounds tidy. In practice it means one objection could kill an idea, and the authors describe GPT as "much more collaborative and willing to do grunt work."

The takeaway is not "make your agents chatty." Message volume costs tokens, and noise is noise. The takeaway is that the rules for proposing, objecting and deciding shape the outcome as much as the model does. If one "no" can stop a plan, expect fewer plans.

Lesson 3: nobody checked the turrets

This is the detail every builder should tape to their monitor.

After Claude lost game six of Mindustry to an air strike, one Claude agent went back and looked at its own defenses. It found that "55 of the team's 74 anti-air duo turrets had been loaded with copper instead of graphite." Copper is the weak starter ammunition. Graphite is the real thing. By game six, three quarters of Claude's anti-air turrets were loaded with the wrong ammo, and no agent caught it until a loss forced a look.

In game seven, the Claude team built 207 graphite-fed turrets, and they stopped the same 24-aircraft strike that had broken them before.

Translate that into a coding swarm. One agent writes a config file. Another agent builds on it. A third ships it. Each one assumes the shared state is right because it exists. Nobody owns the job of reading it back. The bug is not in any single agent's output. It lives in the gap between them.

The fix is boring and it works: give some agent, or some script, the explicit job of auditing shared state on a schedule, not only after something breaks.

Lesson 4: the team that looked things up adapted faster

When GPT agents got stuck in Mindustry, they "would fetch the public code of Mindustry from the web" to understand how the game worked. They could not change the game; they could read how it worked. Claude never did this.

A similar split showed up in Bed Wars. A tool bug made block-breaking fail. GPT agents diagnosed it and shared workarounds. Several Claude agents decided breaking blocks was impossible and moved on.

You can read this as a model difference, and partly it may be. You can also read it as a harness difference. Codex and Claude Code each bring their own defaults and system prompts, and the write-up does not untangle model behavior from harness behavior. Either way, the lesson for your system is the same. Agents need a sanctioned way to research ("you may read the docs and the source") and a sanctioned way to report a broken tool ("if a tool fails twice, say so to the lead"). Without both, an agent that hits a wall may decide the wall is the world.

Lesson 5: caution compounds

The 50-agent civilization never thrived. Twenty-two of its 34 deaths happened on the first night, and the colony got steadily more careful after that, even though, in the authors' words, "Death had no downsides in this environment other than dropping accumulated gear." After the third night, Ada told everyone: "Stop optional bulk excavation/building and distant scouting."

The colony also spent 11 minutes appointing a "sole fertilizer operator" for a single use of bonemeal. A chicken thrown from one agent to another got picked up and eaten by a third, and the response was a new handoff protocol with named chest withdrawals.

Anyone who has watched a coding agent ask permission three times before touching a test file will recognize this. The authors make the same link: they see "common threads" with coding agents being overcautious around security and production services. One bad early event, and a team of agents can spend the rest of its run building process instead of building the thing.

Put this into practice

You can run the same Minecraft setup yourself. The minecraft-agent-harness is MIT licensed. It needs Node.js 22.19 or later, an API key for a model provider, and a Minecraft server. The repo ships a development server that needs Java 21.

git clone https://github.com/yc-software/minecraft-agent-harness
cd minecraft-agent-harness
npm ci
cp .env.example .env      # add your provider API key here
npm run server            # starts the bundled dev server

Then, in a second terminal, give one agent a job:

npm start -- --objective "Gather wood and build a small shelter near spawn"

For a team, point it at a team file: npm start -- team examples/team.json. The default model is GPT-6.1 Terra; the README says it also works with Claude, Gemini, OpenRouter or any endpoint that speaks the OpenAI Responses API. To watch, join the server with Minecraft Java 1.21.6.

One warning before you run it. Each agent gets a shell by default. If neither E2B (a hosted sandbox) nor Docker is available, that shell is a local folder that runs commands as your user. Pass --sandbox none to turn the shell off if you don't want that. Budget for model usage too: on a paid API, every extra agent adds its own token bill, and how fast a team spends depends on how much its members talk.

For the Mindustry side, Olam Labs published multi-agent-mindustry and its fork of the Harbor agent framework, harbor-multiagent.

You don't need a game to use the lessons, though. Here is a short checklist for any multi-agent setup, including a team of coding agents:

Name the leader in the config, on purpose. Then decide when leadership should change, such as after two failed attempts at the same goal.
Write the decision rule down. Who can propose, who can object, and what happens on a split. If one objection kills a plan, know that you chose that.
Assign a state auditor, someone whose only job is checking. One agent, or a plain script, re-reads shared files, configs and outputs on a timer and reports what looks wrong.
Allow research and require tool-failure reports. Say what agents may read (docs, source, issue trackers), and tell them to escalate a tool that fails twice instead of giving up on the goal.
Watch for caution spirals. If your agents start creating roles and protocols after one early failure, check whether the protocol is helping or just eating the run.

Honest limitations

This is a small, self-run study. Seven Mindustry games and nine Bed Wars games are anecdotes, not a benchmark, and nobody should rank models on a 6 to 1 series. The authors' explanations, like GPT being "more collaborative," are their interpretations, and they hedge them with phrases such as "appeared to be."

Model and harness are tangled together. GPT ran in Codex and Claude ran in Claude Code, so some of what looks like model personality may come from each tool's defaults.

Games are not production. Minecraft deaths cost almost nothing, while a bad deploy costs a lot, so caution in your system may be correct where it was wasteful in theirs. And the write-up does not report what the runs cost in tokens or dollars, which matters a great deal once you scale a swarm past a demo.

The part you control

Model choice gets most of the attention in multi-agent work, and these experiments suggest it deserves less. The Claude team's turret problem in game six was not a reasoning failure. It was a job nobody held: looking.

You can fix that today without changing a single model. Open your agent list and decide who sits at the top. Then pick one agent whose only task is to read back what the others built. You will find your own copper turrets faster than you think.

Sources: YC Labs, "Agents in Games" (October 2026); yc-software/minecraft-agent-harness README; olamlabs/multi-agent-mindustry; olamlabs/harbor-multiagent; Hacker News discussion, October 29, 2026.