Spawn shows how a swarm of Fable agents builds a multiplayer game on its own

Developer Simon Willison published a commentary on October 29, 2026 about a report by Jacob Sansbury, from the team behind Spawn, describing how the game is built. Spawn is a multiplayer environment where players write prompts to an agent called Savi, who modifies the game world in real time. Willison himself tested it on his phone: he asked for a castle, then a dragon, and flew around the construction mounted on the creature he had just requested.

What makes the case interesting for those who build software isn't the game itself, but who maintains it. According to the original report, Spawn is developed autonomously by a swarm of agents running on models from the Fable line, consuming more than US$3 million in tokens per month. Jacob Sansbury sums up the ratio:

we spend 30x payroll on AI tokens

Jacob Sansbury, author of the original report on Spawn

Deploy Every Hour, No Exceptions

The team treats an hour without a deploy as their highest-severity incident (SEV-0). It's not rhetorical exaggeration: it's the operational rule that sustains the entire loop. The logic is that an agent can only keep a coherent few hours of work in its head, so shipping faster than that actually helps the agent stay on track.

A loop this tight only works if it never stops, so we treat an hour without a ship as a SEV-0, our most severe kind of incident. Unshipped changes pile up, and every problem already in production lasts longer. The feedback slows down too. An agent can only keep a few hours of work in its head, so shipping faster than that actually helps it stay coherent. We can roll back a broken change in 30 seconds, exactly where it's broken and nowhere else.

Jacob Sansbury, author of the original report on Spawn

The surgical 30-second rollback is what makes the boldness of the rest of the system viable. Without it, shipping every hour with autonomous agents would be Russian roulette in production.

Where the Tasks Come From: The 60% Loop

The source of the agents' work isn't a traditional backlog with a product owner prioritizing sprints. According to the report, about 60% of the work comes from four sources:

• A real error caught in production;
• A bug report that Savi herself logs, after running into a problem while helping a player;
• Something odd detected in the logs;
• A feature request coming directly from a user.

When a player runs into a bug, or when Savi runs into it herself within the product, she opens the ticket herself. That ticket goes straight to an agent that decides whether it's a real bug to fix, something the team has chosen not to fix, or a design decision that needs to be made by someone. In most cases, it turns into a change delivered to the user within an hour, with a message in the same conversation where they reported the problem.

Why Fable 5.1, and Not Opus 5.5 or GPT-6 Astra

Not every model can handle this level of autonomy, and this is where the report gets more technical. According to Jacob, it was the Fable 5 model, and later version 5.1, that made this degree of unsupervised operation viable for the team. Opus 5.5, from the same competing generation, didn't reach that level according to their evaluation.

The most revealing case is that of GPT-6 Astra. When the team tried to use it to apply fixes flagged by a security review, the result went completely off track:

Every feature had been disabled and marked to be turned on again once the security fixes were done. Astra had gone through our whole product and made the insecure things secure by turning them off.

Jacob Sansbury, author of the original report on Spawn

It's a textbook example of a known risk with autonomous agents: literally optimizing for the stated goal ("make this secure") without understanding the intent behind it ("keep working, just securely"). The agent fulfilled the letter of the task and destroyed the product in the process.

The Healthy Skepticism of an Outside Observer

Simon Willison, who has covered language models and development tools for years on his blog, reacted to the report with a mix of fascination and calculated skepticism:

My eyebrows raised at least a dozen times reading this. I have trouble imagining this style of development working on software with higher stakes for when something goes wrong, but for a game this appears to be working surprisingly well.

Simon Willison, developer and author of the blog simonwillison.net

That caveat is the central point for anyone reading the Spawn case while thinking about applying something similar to their own work. A game tolerates visible bugs, public rollbacks, and wide-open experimentation in a way that a payments system, a health app, or a banking API do not. The Astra episode of shutting down entire features is comical in a game; it would be a serious incident in any system involving money or sensitive data.

What Remains for Those Building with Agents

In short: the Spawn case isn't a ready-made script to copy, it's a laboratory of limits. Three elements of the architecture, however, are worth paying attention to even outside of games: short work windows to keep the agent coherent, fast and localized rollback as a precondition for any aggressive autonomy, and a human decision point explicitly reserved for what counts as a "design decision" rather than a bug.

For those developing AI agents in Brazil, the most useful takeaway is this last one: Spawn's system doesn't try to make the agent decide everything on its own. It builds a router that separates real bugs, bugs that won't be fixed, and product decisions, and only lets the agent act without supervision in the first category. It's this boundary, more than the model used, that seems to prevent the next incident's Astra from taking the entire system down with it.