How Four AI Agents Defeated a Dragon in Minecraft

Four AI Agents Beat the Ender Dragon in Minecraft

To get from a random spawn to a fight with the dragon in Minecraft, you need to gather resources, craft tools, find a stronghold, and build a portal to another dimension. You also have to survive dozens of setbacks and remember what to do next.

Four Gemini 4 Argon agents completed the challenge in 27 hours and 14 minutes. They wrote 2,783 programs, exchanged 229 messages, and died 605 times. No one assigned them roles or mapped out a route: the team divided up the work, recorded what it learned, and retrieved items from dangerous places on its own.

Behind those numbers is a test of whether coding agents can stay focused on a shared goal over a long task, rather than just carrying out individual commands. That’s why the researchers chose Minecraft: the journey to the dragon involves many dependent steps, and a mistake at any one of them can slow down the whole team.

Fourteen hours from the first steps in the world to defeating the dragon; the diagram marks thirteen key milestones and the player who reached each one first.

How the Agents Played

Each agent controlled a separate character through Mineflayer, a library for writing programs that interact with Minecraft. The agents couldn’t see the game or press keys. Instead, each wrote a short JavaScript program—for example, to travel to a location and mine nearby ore. The program ran, and the agent received a text response with information about its position, health, inventory, and the outcome of its actions. Then it decided what to do next.

It’s a bit like a programmer operating a system through commands and checking the results. Programs ran for about 34 seconds on average. The players spent around 40% of their time running programs; the rest went to reading the responses, thinking, and writing the next step.

The researchers gave the team one goal—defeat the dragon—and a brief introduction to the tools. They provided no ready-made strategy, gameplay instructions, or human-written programs. All four agents could chat in the game and use a shared memory to record important coordinates and observations.

An agent writes a program, a game bot executes it and returns a text response, and the players coordinate through chat and shared notes.

How the Team Reached the Dragon

Within minutes, the agents started dividing up the work. One gathered food and useful supplies, another searched for diamonds, a third made tools, and a fourth prepared a portal to the Nether. They worked out this division in chat, without instructions from the researchers.

After two hours, the team had iron tools, diamonds, and a portal. Next, they needed to find Ender pearls and blaze powder—the ingredients for Eyes of Ender, which help locate the underground stronghold and open the way to the dragon. While some agents searched for pearls, another found a Nether fortress and a blaze spawner.

When things went wrong, the team turned mistakes into instructions everyone could use. After a fireball destroyed items they’d dropped, the agents noted that dangerous items shouldn’t be left on the ground near enemies. When a teammate died, they shared exact coordinates so someone could retrieve the dropped items before they disappeared.

The team found the stronghold through calculation. One agent threw an Eye of Ender from two different locations, tracked its flight, and worked out where the two trajectories crossed. The calculation pointed to a spot about 43 meters from the portal room. The players then brought the items they needed there. One died while carrying all twelve Eyes, but the others got the location of the death in time to recover them.

Using the flight paths of two Eyes of Ender, the agent calculated the stronghold’s location; its estimate was about 43 meters from the portal room.

The journey from the portal to the dragon was the longest part. In the Nether, the team lost resources, and the dragon killed the players 69 times in the End. Between attempts, the agents recorded rules: don’t linger at the spawn point, approach the dragon only when it lands, and reset its behavior if it gets stuck. To do the last one, all four returned to the Overworld: after a character died, it respawned by a bed, and the empty dimension unloaded.

The turning point came after about 21 hours. One agent noticed that crystals on obsidian pillars were restoring the dragon’s health. It also found a way to reach them without a pickaxe: build a dirt pillar, climb up to a crystal, and break it by hand. The team destroyed all ten crystals, and a few hours later, the dragon was defeated.

The team destroyed all ten crystals that restored the dragon’s health; on the right, the dragon’s health bar drops during the final battle.

What the Team Figured Out on Its Own

Over time, the players settled into different kinds of work, but they could still help one another. One gathered resources, another crafted tools, and a third searched for locations. In the end, the player who had done the least scouting landed the final blow.

The team also built its own software helpers and saved them between runs. These included functions for counting items and moving characters. Shared memory helped the players pass knowledge around: once someone had solved a problem, the others could reuse that solution rather than figure it out again.

Failures also needed checking. At one point, a program reported success when it hadn’t actually succeeded. Two minutes later, the agent corrected the message and explained that the code had taken a branch that didn’t verify the result. Another player noticed that a report about returning with supplies didn’t match the sender’s death. The agents weren’t just sharing plans—they were checking their claims against what had happened in the game.

What the Results Show—and What They Don’t

The victory shows that a shared AI agent can work through a long chain of game tasks if it can write programs, check their results, and retain what it learns. The same approach could matter beyond games: software development and enterprise systems also require teams to maintain a shared plan, pass on knowledge, and recover from mistakes.

But the experimental setup matters. Mineflayer gave the agents precise information about nearby blocks and creatures—including details a person couldn’t see through stone. Built-in pathfinding helped them avoid obstacles. The agents played on Easy, and the model had already encountered Minecraft in its training data. So the experiment tested whether they could apply that knowledge to a long, collaborative task—not whether they could learn the game from scratch.

Finally, this was a single run, not a series of repeated trials. The victory took more than a day and 605 deaths; 22% of the programs ended in errors. The researchers estimated that running the models until victory cost about $520 at the API’s introductory pricing, or roughly $1,040 at the regular rate.

Conclusion

The team completed Minecraft because the agents could divide up the work, share what they learned, and revise their plan after setbacks. That’s meaningful progress on long tasks where individual actions need to add up to a shared result.

But one victory doesn’t prove that agents can handle real-world work just as reliably. That will take repeated trials and environments where the system isn’t handed ready-made information about the world. For now, the result shows something narrower: with a clear goal and constant feedback, AI agents can maintain a multistep plan on their own—even if it takes hundreds of mistakes to get there.