Six Bots Run a Mobile Game on One Build Method

A mobile game developer runs his game with six AI bots: some watch the data, some make ad creative, some fix bugs, and every decision that involves spending waits for his nod. By his own public account, the data showed that players mostly play in pairs, so the bots switched the ads from a "party" theme to a "couple" theme, and the cost per install dropped from $15 to $1. What actually made it work was not any particular prompt, but a method for building bots.

First, look at the bot team

The case uses xAI's Grok Bots (cloud-resident AI agents, currently in beta). Developer Ryan Perry set up six bots for his mobile game Rank'em, each responsible for only one thing:

Bot	Responsible for	Explicitly does not
Dispatcher	Manages the app stores and assigns work to the right bot	Does not do the specific work itself
Data	Ad and product data, the only bot allowed to draw conclusions	Does not change code or spend money
Creative	Turns data conclusions into ad plans and multiple versions	Never buys ads itself
Development	Changes the app and backend according to the data bot's requests	Does not decide on its own what to build
Release	Every launch must pass through it, and it handles rollbacks	Does not bypass checks
Bug fixing	Scans for errors overnight and fixes them	—

The rhythm runs on scheduled tasks: ad spend is summarized every night, product data is reviewed every morning, and install cost and revenue are compared every Monday.

These figures are the developer's own public claims. We have not verified them, and we have not used Grok Bots ourselves.

Why it works: three habits

• One role per bot: None of them is a "do-everything assistant." The narrower the role, the more useful the context it accumulates; a bot that handles everything accumulates noise.
• Evidence before done: Only the data bot can give conclusions; development deliverables must include screenshots or before-and-after comparisons. A "completed" task without evidence is not completed.
• Run only when something changes: Polling every quarter hour means close to a hundred runs daily, and each one spends usage. If an event can trigger it (a new email, a new PR), do not poll on a timer.

Build it yourself: a six-step SOP

These six steps apply to both people and agents. Give them to your agent, and have it check itself against the "done" criteria after each step.

Security baseline (do this before starting)

• All bots share one cloud computer: If one bot logs into a website, the other bots can use that login. Do not treat different bots as isolated vaults.
• Use dedicated accounts with minimum permissions: Do not let a bot log into your personal bank account or your admin account.
• Do not paste passwords or API keys into the chat: Use the tool's built-in credential storage or a secure form.
• Use a separate low-limit card for anything that costs money, and require your approval for every transaction.

Common pitfalls

• Automating without a manual run first: Grok Bots have no "dry run mode," and test runs will actually perform the actions.
• One bot handling everything: Poor results, and it costs more credits.
• Letting a bot change live code directly: Have it gather context and write clear requirements, hand implementation to a dedicated coding agent, keep the merge button in your hands, and protect the main branch on GitHub.
• Putting multiple bots in a free-chat group: Easily leads to duplicated work, looping, and high credit use. Connect them only when work truly needs to be handed off.
• Only checking "click succeeded": An action may look successful on the page while the server never accepted it. Require links, file paths, or screenshots.

To build a team like this in code yourself, see the advanced tutorial Standard workflow for agent teams; for a simplified staffing model for a one-person company, see the case One person building a product, with a team of bots that each do one thing.