Building a game with a team of AI agents

I'm building a game on the side. A roguelite strategy game, since you ask. More about the game itself when it's ready.

This post is about how it gets made. I'm not doing it alone, and I'm not doing it with a studio either. My team is a small group of AI agents, each responsible for one part of the work. I'm the creative director. They do a lot of the rest.

It's part experiment, part design process, and so far it works better than I expected. Here's the setup.

Meet the team

An agent is an AI assistant with one specific job, its own instructions, and access to only the parts of the project it needs. Keeping their areas separate means several of them can work at the same time without tripping over each other.

A lead agent coordinates, and seven specialists handle the rest. The tag on each card shows which Claude model the agent runs on and how much effort it puts into thinking. The heavy thinkers get the big model.

• Isabel

  Creative director

  I decide what the game should be. I approve plans and rules before anything gets built, play every milestone, and have the final word on how things feel.

  Human, final say
• The Steward

  Lead agent

  The agent I talk to directly. It turns my requests into plans, hands tasks to the specialists, makes sure their work fits together, and asks me when a decision is needed.

  Opus, high effort
• The Rulewright

  Game designer

  Writes the rules for each part of the game, including the odd edge cases, so everyone builds from the same description.

  Opus, high effort
• The Mechanist

  Gameplay engineer

  Writes the code that runs the rules behind the scenes, along with automated tests that check it works.

  Opus, high effort
• The Stagehand

  Godot engineer

  Builds what players see and touch: screens, menus, controls and animation.

  Opus, medium effort
• The Cardsmith

  Content author

  Creates the game's content as data files, which are checked for mistakes automatically.

  Sonnet, medium effort
• The Chronicler

  Lore keeper

  Looks after the story, names and tone of the world, and keeps the writing consistent with what things actually do.

  Sonnet, high effort
• The Reckoner

  Balance analyst

  Runs thousands of simulated games to find anything unfair or too slow, then reports what needs adjusting.

  Sonnet, medium effort
• The Warden

  QA reviewer

  Reviews each piece of work before it's accepted, and checks that each milestone meets its goals.

  Opus, high effort

Yes, they have names. Naming them made the roles easier to remember, and a lot more fun to work with.

From idea to playable build

Every new feature goes through the same steps. It's a design process, just with a very fast team.

1. I set the goal. I describe what we're building and how we'll know it's done. The goal is always about how it plays, not how it looks: this should be fun with plain rectangles instead of art.
2. The Steward plans it. It breaks the work into tasks and assigns them. I review the plan and adjust it before anything gets built.
3. The rules get written. The Rulewright writes down exactly how the feature works, including the rare cases. I approve the rules.
4. Building happens in parallel. The Mechanist writes the code and its tests while the Cardsmith and the Chronicler create the content and its writing.
5. It goes on screen. The Stagehand builds the interface, with support for both mouse and controller.
6. Testing. The Reckoner simulates a thousand games to check balance and pacing, and the Warden checks the work against the original goal.
7. Automatic checks. Every change is submitted as a pull request. The tests run automatically, and nothing joins the game until they all pass.
8. I play it. If it isn't fun yet, notes go back to the Rulewright and we go around again. Art comes last, once the plain version plays well.

The first and last steps are mine on purpose. The agents are fast, but deciding what "good" means, and noticing when something feels off, is still a human job. It's also the best part.

Shared memory

AI agents don't remember earlier conversations. Every session starts from zero. So anything important has to be written down, and the project's files become the team's memory. Each agent reads what it needs when it starts, and updates it before it stops.

• House rules. The first file every agent reads: how the project is organised, how work gets handed over, what needs my approval, and how changes are saved.
• The design document. The full design of the game. Agents can update it, and every change is logged with what changed, why, and who made it.
• The status board. What's done, what's in progress and what's next, updated at the end of every session.
• Handoffs. If an agent stops partway through a task, it leaves a note: what's done, what's left, and any open questions. The next one picks up from there.
• Specs. The detailed rules for each part of the game, approved by me before any code is written.
• Decision records. Short notes on important choices and why we made them, so we don't argue about them twice.
• Lore. The game reads its text straight from these files, so what players see always matches the source.

Funnily enough, this is the same thing I nag human teams about. Write down decisions. Leave a handoff note. Keep one source of truth. Agents just can't get away without it.

Guardrails

With several agents working at once, a few rules keep the project from falling over.

On top of that, every change to the game's design goes into a changelog: what changed, why, and which agent did it. When something breaks, I can see exactly how we got there.

The roadmap

The first goal is small but complete: a short version of the game with a full run from start to finish. It's split into six milestones, and each one has to meet its goal before the next begins.

1. 1Milestone 1Foundations
2. 2Milestone 2Core fights
3. 3Milestone 3The map
4. 4Milestone 4Full loop
5. 5Milestone 5Variety
6. Milestone 6Style

We're at the start, with the foundations laid: the project, engine and tests are set up, and the first bit of content has already been added by an agent. Every milestone has a goal written as a feeling, not a feature list. The last one isn't done until outside players ask to play again.

Shipping builds

The same system that runs the tests also packages the game, so there's a fresh version to try after every approved change.

• Every change: Windows and Linux builds, made automatically for me and the agents to test.
• Later: private playtests with a small group of testers.
• At the end: wider testing on Steam, then launch. Steam Deck support is planned from the start.

What I've noticed so far

This setup is a lot like leading a design team. Clear roles. A shared goal. Written decisions. Small steps you can test. And someone who holds the vision and says "not yet" when it isn't fun.

The difference is speed. Ideas become something playable much faster, so I spend more time on the parts I care most about: deciding what the game should feel like, and playing it until it does.

More when it's ready.