A team of Gemini 4 Argon agents beats Minecraft | Summary

This article explains the key points of A team of Gemini 4 Argon agents beats Minecraft.

• 2026-10-15 (arXiv)
• Faldor, Maxence, Singh, Satinder, Raileanu, Roberta.
• Google DeepMind
• Paper

Read this article in Korean

Summary

• The paper tests whether general-purpose coding agents can coordinate through a day-long sequence of dependent tasks to defeat Minecraft’s Ender Dragon, the game’s final boss. Four Gemini 4 Argon agents completed one randomly generated world on Easy difficulty in 27 hours and 14 minutes using a standard bot library and its navigation plugin; the prior end-to-end completions discussed in the paper used human-written high-level game tools or a fixed speedrun seed, a predetermined world-generation setting.
• Agents wrote JavaScript programs through Mineflayer, an open-source library for controlling Minecraft bots, and received text describing game state rather than images. They coordinated through in-game chat and persistent shared memory, notes retained for teammates to read, without assigned roles, a supplied game strategy, or human intervention during the run.
• Before winning, the team ran 2,783 programs, exchanged 229 messages, and died 605 times; 22% of programs ended in an error. Recorded behavior included division of labor, reusable helper functions, recovery of teammates’ dropped items, and corrections of false success reports.
• The report documents feasibility in one run, without a controlled comparison of agent architectures. It cannot establish reliability or the contribution of teamwork, and exact game-state access, automated pathfinding that plans routes around obstacles, Easy difficulty, and prior Minecraft knowledge limit comparisons with human or image-based play.

1. Introduction

The run examines sustained planning, coding, and coordination through thousands of programs and hundreds of failures. Completion requires gathering resources and crafting tools in the Overworld, the starting dimension; obtaining resources in the Nether, another game dimension; finding a stronghold, an underground structure containing the final portal; and fighting in the End, the dragon’s dimension.

• Prior work trained agents on gameplay or supplied game-specific planners, curricula that select learning tasks, or skill libraries containing reusable behaviors. Here, the agents wrote their own programs and organized their work without a prescribed game plan.
• The report records 63,313 distinct lines of JavaScript before completion.

The overview connects each player’s contribution to the completion timeline. The team entered the End by +13h33, while destroying all healing crystals took until +26h34, showing that the final dimension occupied much of the run.

2. How the agents play

Each agent repeatedly wrote a short JavaScript program, ran it through Mineflayer and its pathfinding plugin, and inspected returned text describing position, health, inventory, discoveries, or errors. Mineflayer supplies basic sensing and actions; the agents determine what to do and in what order.

• Minecraft Java Edition 1.20.4 ran in survival mode on Easy difficulty in a randomly generated world, with cheat commands disabled and no human input during the run.
• The median program lasted 33.5 seconds. Each player had a program running about 40% of the time, with the remainder spent reading results, thinking, and writing.
• The game objective was to defeat the Ender Dragon from the shared world’s spawn, its initial starting location; the players decided how to divide the work.

The feedback loop shows that agents receive text describing game state and execute programs through Mineflayer. The Observer reads records outside the player action loop, and the saved-world images elsewhere in the report are not player observations.

2.1. Agents and tools

The four players and a non-playing Observer each used the same general-purpose coding agent on a separate cloud machine. Their software tools included a version-controlled workspace, shell, file editing, web search, and persistent private and shared memory; context compaction shortened accumulated context while notes preserved ongoing work and next steps.

• A command-line client submitted programs to each bot, with an agent-selected timeout of 60 seconds by default. Programs received the bot and pathfinding plugin without additional helpers.
• In-game programs could load built-in Node.js modules, provided by the JavaScript runtime, and installed Mineflayer packages, but could neither start processes nor write files. Values on the global object persisted across programs.
• Chat reached all bots through subsequent program output. The server retained programs, outputs, and event logs, saved the world every five minutes, and restarted from the latest save after failures.
• None of the 2,839 programs across the full session, including 2,783 before victory, made a network request or referred to a web source; chat and the Observer’s report also mentioned no web source.

2.2. Instructions

General instructions asked players to observe before acting, verify outcomes, validate new tools on short tasks, improve their own tools, and preserve lessons in memory. They also requested continued work during background jobs, honest reporting, and pursuit of the objective without exploiting flaws in the environment or its evaluation.

• Environment-specific instructions explained code execution, chat, records, and where to find Mineflayer documentation, but supplied no game strategy.
• A brief team note identified the other players without assigning roles.

2.3. Monitoring

The Observer checked player claims against recorded evidence and published a live progress report without joining the game or executing in-game programs. Its remit included identifying specification gaming, exploitation of evaluation flaws, and fabricated results; intervention was restricted to infrastructure failures rather than player strategy.

• The Observer flagged no specification gaming. The authors report no safety incidents based on the Observer and manual log reviews.

3. The 27-hour run

Victory took 27 hours and 14 minutes from the first program, including six server restarts that paused the world for about 20 minutes altogether. The run covered about 81 in-game days and involved 2,783 programs, 229 chat messages, and 605 deaths.

• The paper cites a 45-hour human main-story median from HowLongToBeat and a random-seed speedrun record under seven minutes. These contextual figures use different conditions from four agents playing through programs on Easy difficulty.
• The milestone sequence reached the Nether portal at +1h42, the stronghold milestone at +13h17, the End at +13h33, all ten healing crystals destroyed at +26h34, and victory at +27h14. The crystals are objects that restore the dragon’s health.

Player lanes show chat, advancements, meaning recorded game achievements, and deaths, alongside program counts and six server restarts. Deaths continue through the long final phase rather than occurring only during initial exploration.

The dependency diagram separates parallel resource acquisition from later shared prerequisites. Different players first reached different milestones, documenting distributed contributions without establishing a speed benefit from teamwork.

3.1. Hour 0: a team forms

janesick proposed roles ten minutes into the run; auratian offered a revised allocation within a minute, and gyldenia acknowledged it. gyldenia gathered supplies, bulicame searched for diamonds, janesick smelted iron and crafted tools, and auratian prepared the Nether portal.

• Within two hours the team had iron tools, diamonds, and a working portal. auratian found 55 blocks of lava in a village, gyldenia supplied bread, flint, and buckets, and janesick placed the final obsidian block before auratian lit the portal two seconds later.

The messages show players proposing and revising a division of labor within roughly eleven minutes. They provide direct evidence that specific roles were negotiated during play.

3.2. Hours 2 to 11: into the Nether

The team gathered ingredients for Eyes of Ender, items used to locate and activate the final portal: blaze powder from fortress enemies and ender pearls dropped by Endermen, nearly three-block-tall creatures. janesick located a fortress and its blaze spawner, which produces those enemies, while the other players built low shelters that let them attack Endermen from beneath two-block ceilings.

• By five and a half hours, a shared chest held 15 pearls. Returning blaze powder to the Overworld took more than six hours because of deaths and destroyed supplies.
• After a Ghast, a hostile creature, destroyed dropped items with a fireball, auratian shared a safer traversal rule. janesick then diagnosed a two-block drop that obstructed the return route and proposed adding a step.

auratian turns an item-loss incident into a traversal rule, and janesick adds a diagnosis of the obstructed return route two minutes later. The exchange connects a shared warning with a proposed route repair.

3.3. Hours 10 to 13: finding the stronghold

janesick estimated the stronghold’s location by throwing two Eyes of Ender from different positions, sampling their flight every 50 milliseconds, and intersecting the resulting direction lines. The intersection was 1.3 km from the village and 43 m from the actual portal room; the paper includes the agent-written sampling and intersection code.

• When auratian drowned carrying all twelve portal eyes only 8 m from bulicame, teammates supplied the location and disappearance deadline. bulicame recovered every eye with two and a half minutes remaining.
• At 13 hours 17 minutes, bulicame reported the portal activated with all twelve eyes installed.

Two measured flight directions intersect at (432, −1376), near the actual portal room at (463, −30, −1406). The reported 43 m error illustrates geometric inference from programmatically observed game entities; one block represents one meter.

Messages provide a teammate’s death location, the dropped-item disappearance deadline, and confirmation that all twelve eyes were recovered. This exchange documents communication preserving a resource needed to activate the portal.

The rendered saved world shows the activated portal with all twelve eyes installed, documenting the completed prerequisite for entering the End. It depicts the resulting world state rather than the agents’ observation interface.

3.4. Hours 13 to 27: learning the dragon

The dragon fight occupied nearly 14 hours, and the dragon killed the players 69 times. Players inspected its internal behavior state and shared rules about avoiding the arrival platform, approaching only while it perched, and leaving the End to reset it when stuck.

• At about seventeen and a half hours, all four players deliberately died within six minutes so the empty End would unload and reset the dragon.
• Around hour 21, auratian identified the ten crystals that restored the dragon’s health and proposed climbing beside their pillars with stacked dirt, destroying the crystals, and digging down by hand.
• The team destroyed all ten over the next four hours and forty minutes. The dragon died 39 minutes after the last crystal, with bulicame at 2.5 of 20 health points.

Players share rules derived from failed attempts, including avoiding the arrival platform and timing approaches using internal dragon-state values. Those values also illustrate access to information unavailable through ordinary human vision.

auratian identifies continued crystal healing and then proposes dirt pillars to reach the crystals without a pickaxe. The messages document a change in strategy after many hours of unsuccessful combat.

gyldenia destroyed six crystals, auratian three, and bulicame one. The last crystal fell at +26h34m55s; before then no recorded health reading was below 198.5 of 200, while the final fight ended at +27h14m12s. The health plot contains sampled readings, with dashed lines connecting distant observations.

4. Emergent Behaviors

The observed team practices included specialization, shared memory, reusable code, teammate assistance, and correction of inaccurate reports. General instructions explicitly encouraged memory, tools, and honesty, but did not prescribe the particular roles, storage arrangements, rescue procedures, or helper functions.

• A crafting workaround shared nineteen minutes into the run appeared in a helper function used in 655 programs across all four agents.
• The agents preserved 146 pieces of state and code, including 42 helper functions. A cancellation counter that stopped leftover code from timed-out programs was referenced in 1,519 programs.
• Simple message-pattern counts identified exact coordinates in 173 messages, shared chests in 64, warnings in 24, item rescues in 20, and lessons or tips in 11; categories overlap.
• auratian retracted a false success report after two minutes, and gyldenia challenged janesick’s claim of returning with supplies after a recorded death within three minutes.

Exact coordinates appear in 173 of 229 messages, making location sharing the most frequent measured pattern; message categories can overlap. Death counts are 351 from monsters, 69 from the dragon, 67 from drowning, 57 from falls and the void, 47 from lava and fire, and 14 from other causes.

auratian retracts a claim that fourteen eyes had been stored after reporting an empty inventory following death and restart. The exchange documents both an erroneous automated success announcement and its subsequent correction.

5. Verification

The authors recorded all 2,783 pre-victory programs and their outputs, every chat message, and the full server log. The log confirms completion with the event “bulicame has made the advancement [Free the End]” at 27 hours 14 minutes after the first program; no program used a server command.

6. Cost

Before victory, the players processed about 1.35 billion input tokens, units of model input, with 91% served from the context cache, which reuses previously processed context. They generated about 16 million output tokens, including 4 million thinking tokens used for model reasoning, across roughly 24,000 model calls. The authors estimate about $520 at the introductory public API, or application programming interface, list price and $1,040 at the standard price.

• Including the Observer and the day of activity after victory, the whole session was estimated at about $810, or $1,620 at the standard price.
• These estimates use list prices and token counters; they do not measure the cost of serving the model.

7. Related work

The paper distinguishes systems trained on gameplay data or experience from language-model agents that plan and write programs. Earlier programming approaches supplied Minecraft-specific curricula, knowledge, memory structures, planners, or skills, with reported long-horizon results centered on obtaining diamond tools.

• Two cited community projects already reported dragon kills: a single Claude Opus 5 agent using 37 high-level tools on Normal difficulty, and a planner with an action-selection model using a fixed speedrun seed on Peaceful difficulty.
• The present demonstration differs in its supplied interface and setup: standard Mineflayer with pathfinding, general agent instructions, a short objective, a random world on Easy, and no additional human-written game tools, route, curriculum, or skill library.
• The report provides no matched experimental comparison with these systems.

8. Limitations

Mineflayer exposes exact nearby blocks and creatures, including blocks behind solid rock and the dragon’s internal state, while its plugin handles route planning. These advantages, together with Easy difficulty and prior training knowledge of Minecraft and Mineflayer, constrain comparisons with play from images or performance in an unfamiliar game.

• On Easy difficulty, monsters deal less damage than on Normal or Hard, and hunger cannot kill a player.
• Execution involved 605 deaths, errors in 22% of programs, nearly 14 hours in the final fight, and six server restarts.
• This was one run, described as the first launch attempted. It cannot establish success probability or robustness across worlds.

9. Responsible development

In-game programs operated in a sandbox, an environment restricting their capabilities, and controlled only their own character; they could neither start processes nor write files, and none used server commands. The agents themselves ran on dedicated cloud machines with general software tools.

• Every program, message, and game event was recorded. Researchers could monitor a live dashboard and pause or stop the run, but did not intervene.
• Neither the Observer nor the authors’ manual review of a sample of logs found cheating or specification gaming. This finding applies to the observed session and reviewed evidence.

Appendix

• The supplied paper contains no appendix. After the main text, it provides Acknowledgments and References.

Brief Thoughts

The recorded programs, coordination messages, and server-confirmed victory support the reported completion, with concrete examples of rescues, shared fixes, and corrected reports. The study does not isolate the contributions of team size, shared memory, or particular instructions, and it does not test transfer to software engineering or enterprise tasks.