Post 2 of 8 in the game-factory series.
One sentence in, one game out
The game factory is a pipeline of agents that turns a one-sentence theme into a deployed, playable slot machine. I type "ancient Egypt treasure slots," approve a few decisions along the way, and some minutes later there is a themed game on a URL: golden scarab reels, a papyrus background, win messages about pharaohs, a working leaderboard. I didn't draw an icon, write a line of React, or touch a console.
Post 1 was the single slot machine I built by hand to learn the iGaming domain. This post is how that one game became a line that produces variants of it on demand — what the six agents are, how they hand off, and where a human still stands in the line.
Why a line of agents, not one
The obvious version is a single clever agent: "here's a theme, here's the codebase, make me a game." I didn't build that, and the reason matters.
A slot machine variant isn't one task. It's a spec decision, then image generation, then code changes, then a browser test, then a deploy — each with different tools, different failure modes, and different places a human wants to look before continuing. A single agent doing all of it holds too much in its head, fails in ways that are hard to localize, and gives you nothing to inspect between steps. So I split it into a pipeline, where each stage is a small agent with one job and a clean output the next stage can consume.
An agent here is nothing fancy: a model in a loop, given a set of tools and a condition that ends the loop. Call the model, let it call a tool, feed the result back, repeat until it signals done. No framework — just the Bedrock API and Python, on purpose, so I understood every part. The interesting engineering isn't in the loop. It's in scoping each agent's job so the loop actually terminates well.
The six stages
The pipeline runs in order. Each stage reads what came before and writes something the next stage needs.
one sentence in
│
▼
┌────────────────┐
│ Designer │ ──▶ the spec (a JSON contract)
└────────────────┘
│
▼
┌────────────────┐
│ Image-Gen │ ──▶ symbol icons
└────────────────┘
│
▼
┌────────────────┐
│ Background-Gen │ ──▶ the page background
└────────────────┘
│
▼
┌────────────────┐
│ Builder │ ──▶ the themed React code
└────────────────┘
│
▼
┌────────────────┐
│ Tester │ ──▶ a pass / fail QA report
└────────────────┘
│
▼
┌────────────────┐
│ Deployer │ ──▶ a live URL
└────────────────┘
│
▼
a deployed, playable game
1. Designer. You describe a theme; the Designer asks questions and produces a spec — a single JSON file that every later stage reads. Symbols and their weights, a color palette, winning patterns, UI strings, fonts. It's the contract for the whole build:
{
"theme_id": "ancient-egypt-slots",
"symbols": [{ "name": "Scarab", "value": "scarab", "weight": 3 }],
"color_palette": { "primary": "#C8A24B", "background": "#1A0F0A" },
"win_names": { "three_of_a_kind": "PHARAOH'S FORTUNE" }
}
2. Image-Gen. For each symbol in the spec, it generates an icon from a prompt, then resizes it to the size the reels expect. The reels stop being cloud-service logos and start being scarabs and ankhs.
3. Background-Gen. The same idea, once, for the page background.
4. Builder. The one that turns the casino's React code into this theme's code. This is the code-modification agent, and it's the one that fought me hardest — enough that it gets its own post and a redesign story.
5. Tester. It runs the built game in a real browser with Playwright, takes screenshots at each step, and a vision model judges whether the game actually plays — do the reels spin, does a win display correctly, does the UI look right. Automated QA that judges by looking, not by asserting on the DOM.
6. Deployer. It builds the app and deploys it to AWS — the frontend to CloudFront, wired to a serverless backend — and it refuses to run unless the Tester's report says the game passed.
Where the human stands
The line isn't fully autonomous, deliberately. Between stages there are approval gates: the Designer proposes a spec and waits for a yes; the Builder proposes a plan before it changes code; the Deployer confirms before it ships. The pattern is agent proposes, human approves. It keeps a person in the loop at exactly the points where a wrong decision is expensive to undo, without making them do the work.
The handoffs are boring on purpose. The spec is a file on disk. The icons and background are files on disk. The test result is a file on disk. Each agent reads the artifacts of the ones before it. Boring handoffs are inspectable handoffs — when a build looks wrong, I can open the spec and the images and see exactly what the next stage was handed.
Takeaway
If you're building something that turns a prompt into a real artifact, the shape worth copying isn't "one agent that does everything." It's a pipeline of narrow agents: each with a single job, a plain-file output the next stage reads, and a human gate wherever a mistake is costly. It localizes failure — when a game comes out wrong, I know which stage to blame, because I can see what it produced. And it lets you replace or harden one stage without touching the others, which is the whole reason the Builder could get torn down and rebuilt later without disturbing the five agents around it.
Each stage gets its own post next, in order, same three questions each time: what it is, what it did, and what went wrong.
Previous: the slot machine that became a factory. Next: the Designer agent.
Top comments (0)