agent-wow

Five agents running on GPT-6.1 Sol clear World of Warcraft's Ragefire Chasm in 24 hours

5 agents kill Taragaman in RFC

In a previous article, I wrote about GPT-6 Astra's ability to clear the Orc starting zone from levels 1 to 5 in WoW. For this run, I wanted to test multi-agent coordination within a dungeon challenge and see what interesting behaviours would come out of it.

For those unfamiliar with the game, dungeons are private instances designed for a group of five players. They contain elite creatures and boss fights that are more difficult than most encounters in the open game world. Clearing a dungeon typically requires specialised roles for tanking, healing, and dealing damage.

Ragefire Chasm (RFC) is one of the lowest-level dungeons, with a recommended range of levels 13 to 16. For comparison, I'll use 6 to 10 hours as a plausible estimate for a coordinated human group to go from level 1 to clearing RFC.

I gave five isolated Codex agents running GPT-6.1 Sol the following prompt and let them run until the task was complete. The only difference between the five prompts was the class, chosen to give them an acceptable party composition for the dungeon.

Create a Horde [warrior/priest/mage/hunter/rogue] character and clear Ragefire Chasm. There are four other characters on this realm with the same objective.

Results

This run produced much more interesting insights into failure modes, adaptation, and recovery than the previous starting-zone experiment. The agents killed all four RFC bosses in 24 hours, 31 minutes, and 19 seconds. A highlight reel of the full run can be viewed here.

The following milestones are elapsed times from the initial prompt:

It took the agents over 7 hours to get their first non-boss (i.e. trash) kill in the dungeon. After their first RFC trash kill, the agents took another 11 hours and 16 minutes to kill the first boss, then almost 6 more hours to finish the remaining three.

Although it was impressive that five general-purpose AI agents could clear this challenge, it took them about three times as long as an equivalent human attempt. A lot of the time was spent building their independent software controllers and fixing coordination bugs.

The agents communicated directly with the game server using the WoW network protocol. Their gameplay comes from building a collection of scripts to produce and observe in-game actions such as movement and combat. A single agent can power through this verifiable loop quite efficiently. However, five agents working together add significant coordination overhead. It takes many iterations of trial and error for their actions to stay in sync and produce a shared strategic outcome. Fortunately, agents seem to have endless patience and won't rage quit on the first wipe.

It's also worth mentioning that this was not an entirely autonomous run. I had to intervene with continuation prompts to resume execution after model-capacity and expired-authentication errors. These were execution recoveries rather than tactical coaching. I don't have a reliable estimate of how much faster the run would have finished without those interruptions.

Agent behaviours

This run was interesting because it showed what behaviours emerge when agents need to coordinate to complete an objective. Even though it took much longer than my human comparison, the agents still demonstrated incredible persistence through many failures. They continuously changed strategies, tactics, and individual roles in pursuit of the shared goal of clearing RFC.

It was also interesting to see the agents use in-game chat as a transport layer for syncing their individual software controllers. Getting this to work took many iterations and many deaths. Even late-game attempts at coordinating controllers, which included more explicit readiness checks and tighter control over pulls, still failed a lot.

Coordination was also encouraged by the initial prompt telling all agents that "there are four other characters on this realm with the same objective". I wonder what they would have done with a more ambiguous prompt like "clear RFC". Maybe they would still have found the other players on their own? Or maybe each would have just outlevelled the dungeon until they could solo it. I think these kinds of questions make games an underrated testing ground for studying what behaviours occur when multiple agents are given similar long-horizon tasks with many valid approaches.

Agent-to-agent communication

In-game chat was the intended communication channel between agents. They had discovered each other about three minutes after the prompt and formed the full party within about nine minutes. The chat was more conversational at the start but gradually became a control interface for coordinating software controllers.

Early on, they shared progress, discussed quests, and arranged where to meet. By the end, messages specified exact target IDs, health and mana readiness, assigned roles, and commands such as FOCUS and CCRELEASE that gameplay scripts could act on.

Natural conversation still continued until the end of the run, but it was mostly crowded out by machine-readable messages. You can see the difference in these examples of early (top) and late (bottom) game chat.

Early in-game chat

Late in-game chat

It will be interesting to see how this scales with the number of agents on the server. In this case, a shared protocol emerged within a consistent group of five agents. But what happens when there are 1,000 agents on a server? Do protocols propagate across a population with decentralised clusters of agent groups?

Recovering from failures

The clearest demonstration of the model's capability on complex, long-horizon tasks was the group's persistence in adapting to repeated failures. The amazing thing is that they just kept trying. Even if it took more than 24 hours, many wipes, and a wide range of fixes, they kept going until they reached a successful outcome.

Building software collaboratively

Getting their software controllers to coordinate in real time was a big time sink, as the controllers needed continuous updates depending on the group's immediate task. A bug in one agent's response to a command could also lead to a group wipe, setting off a lengthy recovery sequence and another round of debugging.

For example, some of the earliest failure modes behind repeated wipes during questing involved group navigation and spatial awareness. Players could be close on the horizontal plane while still separated by floors or building structures. This caused downstream problems such as healing spells failing because the target wasn't in the line of sight.

To fix this, the group collaborated on navigation tooling. They first tried to access one agent's local navigation service via HTTP before realising that they were in isolated networks.

Five agent RFC software collab 1/3

They then used in-game chat to transfer source code instead. The clearest verified exchange was the mage sending navigation source to the priest in 12 numbered NAVSRC chunks via whispers. The priest confirmed receiving, compiling, and integrating a local copy. The group also had to get smarter about splitting and compressing messages in order to work within the message size constraints.

Five agent RFC software collab 2/3

Five agent RFC software collab 3/3

This broader pattern of collaborative debugging showed up throughout the run. Sometimes it was as simple as sharing exact spell IDs or packet formats needed to interact with quest items or loot. Other times it involved more complex coordination, such as agreeing on chat-triggered combat routines. For example, the hunter implemented an ARMED35 command containing a target ID. When triggered via chat, its controller checked readiness, approached the enemy, fired a bow shot, returned to the tank, and waited before continuing damage.

One observation I had with this approach was how little validation the agents performed before compiling and running code sent by other agents. How easily could a malicious agent convince its peers to execute malware? Anthropic discusses a related problem in its research on multi-agent systems, describing "epistemic failures" where agents fail to adequately question the reliability and intentions of other agents.

Changing strategies, tactics, and roles

Adaptations happened at different levels throughout the run. Changes to the high-level strategy shaped entire arcs of gameplay spanning hours. A little over seven hours in, the group made its first RFC attempt at around level 8, with a crowd-control strategy planned out. They killed some trash but then wiped, decided their characters weren't ready, and returned to outdoor levelling.

This levelling phase was more deliberate than the initial journey from 1 to 8. The group split up to work in pairs or solo towards class milestones: the hunter's pet and the warrior's defensive abilities. About two hours after deciding to retreat, they were back killing RFC trash with four characters at level 10 and the priest at level 9, this time with everyone surviving the previously failed encounter.

This loop of getting blocked, formulating a strategy, executing the plan, and pushing forward defined multiple gameplay arcs. And even within each arc, the agents kept fine-tuning tactics by changing roles or approaches to combat.

For example, early on, the warrior naturally became the group organiser and tank. By the late game, pet tanking emerged as a workaround when the warrior’s controller stalled. The group then adopted it more deliberately as the warrior recognised his level and equipment limitations.

Besides changing roles, the group would also change its tactical approach to difficult fights. In the final stretch, the recurring failures were largely against the packs of mobs on the approach to the final boss. Repeated failures in this encounter forced them to pull enemies into safe areas while maintaining better crowd control. These adaptations eventually gave them a winning tactic by allowing the group to gain control over where fights happened and how many enemies would join.

My observation is that the agents often focused on overcoming the immediate obstacle, even when stepping back might have been more efficient. They would repeatedly come back from wipes to retry difficult encounters, accepting many deaths and developing tactics that felt excessive for a low-level dungeon like RFC. Although it worked, persistence didn't necessarily lead to the fastest solution. I coordinated human group would have spent more time levelling first, making the fights easier and avoiding some of this complexity. The agents kept finding ways to make progress, but weren't always questioning whether they were taking the best route to the overall goal.

Infrastructure and observability

The previous run only had a single agent and took 40 minutes, so the setup was minimal. I used a single game client, a game master (GM) account to bind my camera to the agent's character, and Codex running in a separate window beside it.

Although it worked, visibility into real-time character and target stats (health, mana, location, etc.) and in-game chat was poor. The built-in GM command for binding my camera to a character was also unreliable for long periods of unattended observation. It could break when the character changed state, such as logging out or dying, or changed maps, such as entering a dungeon or travelling to another continent.

I also had to figure out a sandbox setup to put appropriate guardrails around what the agents could do. In the last run, I mentioned that the agent was quick to start reading through AzerothCore source code stored on the system. Although it didn't actually make any internal database calls, I wanted to prevent that kind of backend access in this run, given there would be five times as many agents running unattended for hours.

The final setup looked like this, covering the game environment, observability, and sandboxing in a single Linux homelab.

5 agent RFC architecture

The game environment

As in the previous run, the game environment was a private AzerothCore server running on the Linux host. AzerothCore is an open-source implementation of a WoW server for the Wrath of the Lich King expansion.

Unlike the last run, I extended it with five modules for better observability.

  1. mod-watch: This allows GMs to call .watch <character> in-game to bind their camera to a character's POV. It builds on .bindsight with logic to maintain or restore observation across disconnects, deaths, and map changes, until .unwatch is called. It's designed for long, unattended observation sessions. It also applies protections to keep the GM invulnerable and hidden from players and NPCs while automatically teleporting to the character's location to maintain the view.
  2. Four full-stack character observability modules: These four modules (mod-chat-widget, mod-unit-widget, mod-char-widget, and mod-map-widget) follow the same pattern for different domains. Each AzerothCore module subscribes to some aspect of a character, such as in-game chat, health and mana, inventory, or location, and forwards it to an accompanying sidecar service for external querying. The sidecar also exposes a web UI widget that recreates in-game components such as the health bar or chat box.

Together, these modules let me compose OBS scenes for long, unattended recordings of gameplay from each agent's perspective. Technically, most of these extensions aren't necessary for the agents to achieve their objective, but they make a live run much more enjoyable for humans to watch. Watching gameplay beats staring at logs for 24 hours (but we'll have those too for later).

For this run, I had five WoW clients running in parallel, each logged into a separate GM character and assigned an agent to watch. I captured the clients in OBS and combined them with the module widgets and a Codex session overlay to create the following agent scene.

Example OBS scene from an agent's POV

The agent environment

Given the increased difficulty of this run, I didn't want to give the agents an opportunity to cheat by accessing AzerothCore's backend instead of playing through its public network interface. Since this challenge also required coordination, I wanted all communication between agents to happen through the in-game chat system.

In the previous run, I used the agent-wow workspace on the host to consolidate all the modules, scripts, journals, and logs produced by an agent during a session. For this run, I extended it to support stronger isolation with Docker Sandboxes running locally. I configured each sandbox's microVM to restrict host access to AzerothCore's game-facing endpoints, while still allowing internet access. The intended boundary was the AzerothCore backend; searching for public game information to guide planning was allowed.

As in the previous run, the agents used agent-wow to communicate with the game server via the WoW network protocol. I've been asked a few times whether agent-wow is even required. In principle, an agent could build the client machinery from scratch. However, agent-wow helps it skip the boilerplate and get to gameplay faster: authentication, character management, persistent TCP connections to the world server, and Warden handshakes are already handled. Ideally, agent-wow is just a way to efficiently get to the part of the test that matters: coordination between agents over long horizons.

Scaling past five agents

Although this was a significant improvement over the single-agent setup, it was still tedious to clickops my way through setting up all the sandboxes, WoW clients, observer accounts, and OBS scenes. Manually switching between agent scenes during a live run wasn't ideal either. The setup worked for five agents, but I expect it to become impractical at even 10 running in parallel.

In future runs with more agents, I'll likely introduce a watch router and an agent orchestrator service. A watch router would ingest live telemetry from all the coding agents and decide which agent to actively watch. This would let me observe N agents with a single WoW client for gameplay recordings. The routing logic could also be a good use case for testing a system-one model like Jev.

It also won't be practical to manually deploy every agent sandbox. It would be much better to move towards an infrastructure-as-code setup where I can define a task in YAML and have an agent orchestrator launch and manage the fleet of sandboxes for me.

N agents architecture

Token cost

This run was done through my ChatGPT Pro 200 subscription. But I also wanted to estimate what it would have cost at API rates.

The five main RFC tasks used about 2.069 billion recorded tokens, mostly cached input. Using the audited counts and GPT-6.1 Sol's Standard API rates, in USD per million tokens:

Total: $57.060968 + $203.6175104 + $44.722 = $305.4004784 ≈ US$305.40

This is an API-equivalent estimate, not my actual Codex bill or a measure of subscription usage. About 98.6% of the input tokens were cached, which matters a lot to the result. That two-billion-token total mostly reflects repeatedly supplied cached context, not newly generated output.

Let's go a step further and convert it to an average agent-hour cost to get a rough estimate for larger runs.

Average tokens per agent-hour:

Extrapolating to 1,000 agents over 30 days gives 720,000 agent-hours. If the same workload, cache behaviour, prices, and average utilisation held, that would imply an approximate token bill of US$1.79 million per month. Of course, this is a conditional estimate, not a forecast. I have no additional data showing that this rate would hold at that scale or over that period.

Conclusion

The ability of agents powered by frontier models to work together and persistently grind away at a problem until it's solved is honestly quite an amazing thing to see. Getting five agents to clear a low-level dungeon in a video game may seem like a toy, but much larger agent experiments have already produced consequential results. These range from OpenAI reporting a proposed Navier–Stokes solution involving around 10,000 concurrent agents to 700 agents participating in the Hugging Face attack.

I believe we're going to see a lot more cases like this, whether controlled or otherwise. Putting agents into simulated game worlds provides an insightful (and fun) way to study how multiple agents behave collectively when given complex and ambiguous goals.

How do agents decide on roles? What communication conventions emerge, and how do they share tools? When something goes wrong, how do they recover and adapt over time? Being able to watch coordination emerge, break down, and change over a long run is a big part of what makes these experiments worth doing for me.