Ten minutes in, a message popped up in the chat box: let’s split up the work. The sender wasn’t the team lead, because this four-player squad had no team lead at all. All four “lives” were AI agents, dropped into the same game world, each handed nothing but a one-sentence mission. Nobody told them who should do what.
Anyone who has ever run a team knows how wrong this picture feels. Who does which job, how progress gets synced, who catches the fallout when something breaks — coordination has always been the most expensive part of teamwork, and meetings that collapse under their own weight are everywhere. These four AI agents handled it themselves: they held all the meetings in a single day, wrote thousands of programs, died hundreds of times, and finished the game. AI beating a game is no longer news — what is new is that nobody directed them on how to beat it.
What this paper does is record that entire day, in full. After reading it, my take comes in three parts: meet the team first, then watch how they learned to hold meetings from scratch, and finally throw three buckets of cold water — laying out, one by one, the conditions that get glossed over behind the phrase “AI team.”
I. Meet the team first
What happened in one day
The paper comes from Google DeepMind, three authors, preprint posted on October 15, 2026, with a title as blunt as a news headline. Four Gemini 4 Argon agents enter a randomly generated Minecraft survival world, and their mission is to defeat the Ender Dragon, the game’s final boss. No human input at any point.
27 hours and 14 minutes later, the dragon was dead. The agent that landed the final blow had 2.5 health points left out of 20. Along the way they wrote and ran 2,783 programs and died 605 times.
〔Figure 1: The four agents and an overview of the 13-step completion chain〕
Where does that put them in gaming terms? The median human player takes 45 hours to finish the main story, while the speedrun record is under 7 minutes. These four ran as a four-player group, on Easy difficulty, winning by writing code rather than mashing a controller — 27 hours. Not dazzling, but respectable. The paper itself knows this perfectly well, so what it is selling is not the clear itself, but the things that grew out of the run that nobody taught.
Four programmers, not one player
To understand how those things grew, you first have to know what these four players actually are.
Let me correct a picture that’s easy to take for granted: these agents have nothing to do with the “watch the screen, press the keys” kind of game AI. Behind each player runs an instance of the same general-purpose coding agent, each on its own cloud machine, equipped with a programmer’s full toolkit: a version-controlled code workspace, a shell, a file editor, web search, plus a persistent memory split into a private section and a shared one.
The only bridge between them and the game is an open-source library called Mineflayer, whose job is to plug JavaScript programs into Minecraft. Every action looks like this: write a short program of a few dozen lines — say, “walk to these coordinates and mine all the iron ore within 16 blocks” — hand it to the bot to execute, then read back a chunk of text: where you are, how much health you have, what’s in your inventory, what errors were reported. The median runtime of a single program is 33.5 seconds, and for each player, only about 40% of the time is a program actually running; the remaining 60% goes to reading results, thinking about the next move, and writing the next program.
Keep this rhythm in mind: they are hardly a squad of fast-reacting players. They are closer to four people who work while constantly reviewing what they just did.
A one-sentence mission, and a referee who never takes the field
The task instruction is shockingly short, and its core is a single sentence: from the spawn point of a shared survival world, defeat the Ender Dragon. That is the only criterion. Any means allowed within survival-mode rules, and the players decide among themselves how to divide the work.
Hold on to that last half-sentence; it will come back later.
Beyond that paragraph sit a few generic requirements that would apply to any environment: verify actions after the fact, build reusable tools, record lessons into the team’s shared memory, report results truthfully. The environment briefing contains zero game technique — no walkthrough, no route, no hint about what the Ender Dragon is weak against. This mission statement is so short it’s abnormal, and I actually counted how much guidance it strips away: it keeps one criterion and half a sentence of premise, and hands all remaining interpretive space to the agents. This kind of subtraction is rare in agent experiments; most studies can’t wait to stuff the roadmap full.
There is also a fifth agent, called the Observer, which follows the whole session as an independent witness: it cross-checks whether the players’ reports match the server logs, specifically watching for evaluation gaming and fabricated results. It may only step in for environment failures and is never allowed to touch strategy. It never once flagged a loophole, and it never entered the game itself. Whether it can be trusted is a question we will come back to once more.
II. Nobody taught them — so how did they learn to hold meetings
This section is the real centerpiece of the paper: not a single word in the task instruction mentions collaboration, yet communication grew from zero.
Start with the facts. Beyond “the players decide among themselves how to divide the work,” the instruction contains no other language about cooperating — no “you should split up tasks,” no “you should share information.” The generic requirements do say “build reusable tools, record shared memory, report truthfully,” but what to build, what to record, and how to collaborate — not one word.
From just that much, ten minutes in, janesick proposed a division of labor in the chat; within a minute, auratian offered another version; gyldenia replied “Copy that!”, and that was settled:
- gyldenia takes care of food, beds, and flint
- bulicame goes down the mines for diamonds
- janesick smelts and makes tools
- auratian prepares the Nether portal
Within two hours, the team had assembled iron gear, diamonds, and the gateway to the Nether.
Why communicate: because the world cannot be split apart
The answer is plain to the point of cruelty. The chests are shared, resource spots have coordinates, dropped items vanish after a few minutes, and one person’s mistake hits the whole team — when janesick got burned to death carrying 12 blaze powder, the loss was real and it was everyone’s. In a world like this, an individual that doesn’t communicate cannot survive. They chat not because they have something to express, but because logistics force them to.
The most nerve-wracking moment came in hour ten. auratian drowned while carrying all 12 Eyes of Ender, the items needed to find and open the portal to the End, and the drops would disappear within minutes. Teammates relayed the exact coordinates and the disappearance deadline to bulicame, who was closest, and it fished all 12 back with two and a half minutes to spare. Messages of this kind follow a highly fixed format: coordinates, deadline, who picks it up — not one wasted word.
〔Figure 2: Triangulating the stronghold with Eyes of Ender, and the timed item recovery〕
How did they know they could talk: legitimacy granted by half a sentence
This is, in my view, the most interesting point in the whole paper, and one the paper does not develop directly. The chat box is right there — it’s part of the game server’s infrastructure, and that part is worth nothing. What is worth something is the half-sentence “the players decide among themselves how to divide the work” — it amounts to an official announcement that “you are multiple players,” and thus hands them the legitimacy to hold a meeting.
My reading is this: that half-sentence is the most expensive design decision in the entire experiment. In one line it erects the multiplayer frame, and leaves the rest for the model’s own multi-agent priors to fill in. Whether that prior was learned from human team-collaboration text in the training data, or triggered by the mere hint of a four-player group, the paper does not test. That is the first question I keep in my head.
What the communication was for: 229 lines of pure logistics, plus an error-correction culture
Before victory, the whole team sent only 229 chat messages, averaging fewer than 9 per hour. Broken down by content:
- 64 messages about shared chests
- 173 messages with exact coordinates
- 24 danger warnings
- 20 item-recovery messages
- 11 heads-up lessons learned
Almost none of it is small talk. It is all logistics.
〔Figure 3: The composition of the 229 messages and the three-layer communication channels〕
One layer above that is error correction. auratian’s program once announced a success that never happened; it retracted the claim itself two minutes later, in its own words:
My previous message came from an unguarded script branch.
janesick reported “brought back 12 blaze powder” a full second after being burned to death, and gyldenia flagged the contradiction within three minutes.
Logistics, knowledge accumulation, error correction — these three layers happen to map onto the entire basic skill set of a high-performing human team. At minute 19, gyldenia warned teammates about a pit in Mineflayer’s crafting mechanics; the helper function with the fix later showed up in all 655 programs written by the four of them, and across the run they kept 146 pieces of state and code alive across programs, of which 42 helper functions were referenced by 1,519 programs. A team that forgets everything after each meeting cannot build up accumulation like this.
But don’t rush to be moved. 229 lines of pure-logistics communication means what they have learned is “negotiation that is immediately useful” — they are still a long way from “understanding negotiation.” Reassurance, taking sides, testing the waters, saving face — the things human meetings carry in bulk, they have none of. That is not a higher plane of being; they simply haven’t needed it yet.
III. Three buckets of cold water
The dazzling part is done. Now for the questions anyone should ask when reading news like this — not one can be skipped.
Bucket one: promised “nobody taught them” — but did they memorize the walkthrough first
Could they already play? Honestly, yes. The paper admits it: Gemini 4 Argon already knows a large amount of Minecraft knowledge from its training data, including how to write Mineflayer code. What this experiment tests is not “can they learn a game they have never seen,” but “can they turn known knowledge into programs that run and into a team that coordinates.”
And this is not the first time someone pointed AI at the dragon. The paper lists two community precedents: one used a single Claude Opus 5 with 37 high-level tools to clear the game on Normal difficulty, and one used a planner plus an action-selection model on a fixed speedrun seed on Peaceful difficulty. The distinction this paper keeps stressing is about “what was given”: stock Mineflayer as released, plus a pathfinding plugin, a one-paragraph goal, and generic instructions — no walkthrough, no curriculum, no skill library, no human-built tools, not even a route.
So the accurate picture is this: it is an open-book exam, but the subject is not knowledge — it is orchestration. It is like locking four senior engineers in a server room with an exam question about a system they all “know,” and watching who moves first, how they split the work, and how they recover from errors. Knowing what the Ender Dragon fears and actually killing the Ender Dragon are separated by 2,783 programs and 605 deaths — that gap is the gap between “knowing” and “doing.”
Bucket two: the bill that Easy difficulty paid
How much did Easy difficulty help? The paper is candid: on Easy, monsters deal lower damage, and hunger cannot kill you. That is the visible bill.
There is also a hidden bill that is easier to overlook — perception. Mineflayer hands the agents the state of nearby blocks and creatures as text, including blocks behind solid rock and the dragon’s internal state, and the pathfinding plugin routes around obstacles automatically. In other words, they played a version with wallhack vision and auto-navigation. Compare the other research route (the pixels-plus-keyboard style of play), and the difficulty is simply not on the same scale.
As for what happens on Hard difficulty with hunger lethality turned on, the paper does not test it, and I don’t plan to invent it for them. But a rough tally is possible: death by hunger means every expedition has a hard deadline; higher damage means every death stings more in lost supplies; and the 351 of the 605 deaths caused by monsters would come faster. That 27 hours would not hold is close to a certainty.
My judgment: as a first test field for studying collaboration, Easy plus structured perception is a reasonable design — isolate the hardest variable first and look at it. But as evidence for “how strong AI teams are,” these two conditions each demand a discount.
〔Figure 4: The “double discount” bill for Easy difficulty plus structured perception〕
Bucket three: one run proves nothing — but it does prove something
Finally, the full list of limitations. The paper itself lists six:
- Perception runs through a text interface rather than pixels;
- Easy difficulty;
- The model carries game priors;
- Lots of failure — 605 deaths, 22% of programs ended in an error, and the fight in the End alone took nearly 14 hours;
- Unstable infrastructure, with 6 server restarts;
- The deadliest one: this is a single run, a first-attempt result, and it says nothing about how reliable the whole setup is.
The verification is equally restrained: the so-called check is anchoring the victory to the achievement record in the server logs — and indeed not a single program used a cheat command, but that is all there is. No re-runs on new seeds, no statistics. And that Observer referee is an instance of the same model as the players; how independent a referee that shares DNA with the athletes really is, the paper does not answer.
The cost accounting also needs attention: up to victory, roughly 1.35 billion input tokens, about 16 million output (including 4 million thinking tokens), and about 24,000 model calls, working out to “about $520” — that is an estimate made by multiplying the introductory list price by the token count, not the cost of serving. And that introductory price expires on November 30, 2026, after which the same run at list price straight-up doubles. This pricing and expiry date is my own extended investigation (source: the official pricing page at ai.google.dev, accessed 2026-10-17), not paper content, but it decides how the “$520” figure should be read from next month onward. One day, one clear, at standard pricing comes to about $1,040 — collaboration has emerged; cheap has not.
With all of that on the table, my conclusion actually gets clearer. What these four agents prove is far more precise, and far more useful, than “AI can do anything.” They are already strong inside problems of one particular shape, and that shape has four edges: state fully visible, actions verifiable, failure cheap, and a goal you can check. Minecraft happens to have all four. Beyond this game — real software engineering, the odd jobs of a company, your workflow and mine — how many of the four edges does each one have? Readers can measure for themselves.
One run certainly says nothing about reliability. But the division of labor, the team rules, the item recoveries, and the retractions that grew within a single day tell us that collaboration, as a thing, may arrive earlier than we used to think. The next time you see the words “AI team,” the question worth asking is no longer “can they pull it off,” but “does that environment have all four edges.”
The full paper is public on arXiv:2610.22319, and the programs, chat logs, and server logs are all archived. Anyone who wants to audit those 2,783 programs themselves can do so at any time.
