DEV Community: Sunitha Eswaraiah

What I learned building an agent pipeline — and where I stopped

Sunitha Eswaraiah — Thu, 06 Aug 2026 10:29:08 +0000

Post 8 of 8 in the game-factory series.

The runaway

One afternoon I watched an agent spend three hours and 138 dollars trying to edit a single file.

It was the Builder — the agent whose job was to take a theme spec and turn my slot machine's React code into a themed variant. It had opened the main game component, a 1,900-line file, and started making small surgical edits. One of them broke the syntax. The model ran the compiler itself, read the error, tried to fix it, broke something else, and kept going — nothing in the loop forced it to stop on a failed build. By the time I killed it, it had made 868 calls to the model. The file was a wreck: two export default statements, duplicate return (...) blocks, orphaned JSX floating between them.

Nothing about that failure was exotic. The agent did exactly what I told it to do. The problem was what I told it to do.

What the factory was

The short version, if you didn't read post 1: I built a real slot machine on AWS to learn the iGaming domain, then turned the theming into a pipeline of agents. Describe a theme in a sentence, and six agents in sequence design a spec, generate icons and a background, rewrite the code, test it in a browser, and deploy it. Designer, Image-Gen, Background-Gen, Builder, Tester, Deployer.

Five of those six behaved. The Builder was the one that kept me up. Every other agent in the pipeline had a clean output — a spec, a set of images, a test report, a deployed URL. The Builder's output was a code change to a large, interconnected React app, and code changes are where a model's mistakes compound instead of just being wrong.

The fix that mattered most

The Builder's task was: take the casino's SlotGame.js and edit it to match the theme. The file was 1,900 lines. The model couldn't do it reliably — it guessed at whitespace, patched the wrong one of twenty near-identical calls, broke the parse with unescaped apostrophes, and each miss compounded.

The insight I was slow to reach: the model was bad at editing that file because the file was hard to edit. It mixed theme-specific content into structural code. So I stopped asking the model to edit it at all.

I moved the theme-specific text into a config file the component reads at runtime:

// before: baked into the component, edited by the model
setMessage(`🎉 JACKPOT! You won ${spinData.win} credits! 🎉`);

// after: read from a config the component loads
setMessage(formatMessage(themeConfig.winMessages.jackpot, { credits: spinData.win }));

Now the Builder's job for that file was: copy it unchanged, and write a theme-config.json next to it. Generating a JSON config from a spec is ordinary Python — no model involved. There is no 1,900-line edit anymore.

I made the config back-compatible — with no theme specified, the defaults are the original strings, so the untouched casino renders identically. That mattered, because the casino is a live thing and I wasn't going to break it to make theming easier.

The result: the Builder became almost entirely deterministic. Copy the components verbatim, generate the config, run the color and font and API passes in plain code. The only step left for the model was optional cosmetic CSS — and even that was still the flakiest step in the pipeline.

What I observed across all six agents

Each agent taught something specific (posts 3-7 cover those), but patterns emerged across the whole pipeline:

In this pipeline, generation was reliable; editing was not. The Designer generating a spec from a conversation: reliable. Image-Gen producing icons from prompts: reliable. The Builder patching a large, interleaved file with an exact-string-match tool: fragile. Models can edit effectively with better tooling — AST-aware editors, bounded context, validation loops. But with the tools I had, every time I moved work from "edit this" to "generate that," reliability improved.

Explicit, inspectable handoffs made debugging possible. Every stage's output was a file on disk — a JSON spec, a set of PNGs, a test report. When a build came out wrong, I could open the intermediate files and see exactly where the pipeline diverged. The requirement isn't "files specifically" — it's that each handoff is durable, immutable, and something you can inspect without running anything.

Human gates belong where mistakes are costly. Three approval gates in the pipeline: the spec, the build plan, and the deploy. The spec because a bad spec poisons five stages downstream. The build plan because code modifications are hard to inspect after the fact. The deploy because shipping has external impact and rollback — while possible — carries risk. Every other stage ran without asking, because its output was cheap to redo.

Prompt caching changes the economics. The Builder's 868-call runaway cost $138 at Sonnet's list rates, with Bedrock's prompt caching enabled — each call paid a fraction of the full input cost for the conversation prefix it had already seen. Without caching, the same run would have been far more expensive. Caching made agent loops economically viable for normal runs. It also masked how expensive a runaway was becoming until an hour had passed.

Turn caps are the first safety measure, not the last. Before I understood why the Builder was failing, I added a sixty-turn cap. It didn't make the agent smarter — it made its worst case bounded. The capped runs that hit the limit aborted in minutes instead of hours and cost single digits instead of triple. Bound the loop before you trust the loop.

Test the deterministic core without the model. After the Builder redesign, I ran the whole deterministic phase — copy, config, code passes — with the model stubbed out, and compiled the result. It found four real bugs for zero dollars. Every part of an agent pipeline that doesn't require the model is testable like ordinary code. Pull work out of the model's reach not only for reliability, but so you can test it at all.

The honest ceiling

The pipeline runs end to end. It produces themed, deployed, playable games from a sentence. That's real.

It's also not a product. Here's what's still true:

Icon consistency isn't solved. Each image generation call is independent. Thirty icons come back in thirty slightly different styles. Prompt engineering narrows the range; it doesn't eliminate the variance. The games look themed. They don't look art-directed.
The Tester's navigation is fragile. Vision-as-judge works — a model looking at a screenshot can tell you whether the game looks right. But the model guessing CSS selectors to drive Playwright breaks often enough to produce false negatives. Accessible labels and stable test hooks would fix this. I haven't shipped that.
The cosmetic CSS pass still wobbles. Even after shrinking the model's job to "optionally adjust shadows and glows," it still hits the turn cap on some themes. The deterministic build is the floor. The model polish is unreliable upward pressure.

I stopped there. The deterministic Builder was proven — it produced a themed, compiling build with no model involvement. The lessons had stopped being about slot machines and started being about agents in general.

What transfers

Five things, distilled from months of building this:

Decide what should be an agent, not what could be. If a step can be generation instead of surgery, make it generation. Restructure the target before you blame the model.
Bound every model loop before you trust it. Unbounded while plus a paid API is a liability, not a feature.
Make every handoff explicit and inspectable. Files, versioned objects, whatever — as long as you can look at what one stage produced without running the next one.
Back-compat is how you refactor a live thing without fear. Defaults that reproduce the original behavior let you change everything around them safely. The casino still works without a theme config; that's what made the redesign safe.
Know when the lessons have outpaced the project. That's the signal to bank them and move on.

What's next

The game factory was a learning project. What it taught me about scoping agent work, managing cost, and designing for inspectability carries into whatever I build next. The factory itself stays where it is — functional, proven for what it does, but not something I'm polishing further.

The next thing is something different: applying what I learned here to a problem that isn't themed slot machines. The agent patterns transfer. The domain won't.

This is the final post in the game-factory series. The earlier posts cover each agent individually: the factory overview, Designer, Image agents, Builder, Tester, Deployer.

The Deployer agent and the multi-tenant backend

Sunitha Eswaraiah — Thu, 06 Aug 2026 10:14:07 +0000

Post 7 of 8 in the game-factory series.

The gate that says no

The Deployer is the last thing in the pipeline. Every other agent builds toward it: the Designer produces a spec, Image-Gen generates icons, Builder patches the React code, Tester plays the built game in a real browser. All of that work flows into a single question: does the Deployer run?

The answer isn't always yes. The Deployer reads the Tester's report before it touches anything. If the Tester flagged the build as broken — spin didn't work, win didn't register, login failed — the Deployer refuses to start. Not with an error. Just a refusal. The build exists on disk but it won't ship.

That refusal is the thing I'm most glad I built. Every automated pipeline I've seen either skips pre-deploy testing entirely or tests in a way that doesn't check whether the product actually works. The Tester runs a real browser, plays the game, and looks at screenshots to decide if it passed. The Deployer treats that judgment as a hard gate.

What follows, if the gate opens, is the part that involves AWS.

What it is

The Deployer takes a built React app and ships it to AWS using SAM — the Serverless Application Model, which is CloudFormation with a better syntax for serverless resources. The frontend ends up behind CloudFront, served from S3. The backend it points to is a serverless stack: API Gateway in front, Lambda functions handling game logic, DynamoDB storing player data and leaderboard entries.

It doesn't deploy silently. Before anything changes, it creates a changeset — CloudFormation's dry-run mechanism, which calculates what will be modified without actually modifying it — and shows it to me. If the changeset looks wrong, I can say no. This is the same "agent proposes, human approves" pattern that runs through the whole pipeline: the Designer waits for approval on the spec, the Builder shows its plan before touching code, the Deployer confirms before it ships.

The deploy has two halves. The backend goes through sam build and sam deploy — I show the changeset first, then run with the flag that skips the interactive confirmation, because the review already happened. The frontend is a separate step: aws s3 sync uploads the React build to the theme's S3 bucket, then a CloudFront invalidation busts the CDN cache so the new version is immediately live.

What it did

The obvious outcome is live games at real URLs. Two themed variants are deployed as of this writing: ancient-egypt-slots and norse-mythology-slots, both playable, both with functioning leaderboards and real DynamoDB tables behind them.

The less obvious outcome — and the one that took more work — is the backend architecture underneath both of them.

The original casino had a single-tenant backend. Every Lambda function, every DynamoDB table, every API Gateway route was built for one game. When I started generating themed variants, the straightforward path would have been to deploy a separate backend stack per theme: ancient-egypt-slots gets its own Lambdas, norse-mythology-slots gets its own Lambdas, every future theme gets another full stack.

That's expensive and it's unmanageable. Five themes means five stacks to maintain, five DynamoDB configurations to keep in sync, five deployments every time I fix a bug in the spin logic. The better structure was a shared backend with every read and write keyed by a theme_id.

So I forked the original casino backend into a multi-tenant version: one serverless stack — deployed to eu-west-1 — that serves every themed game at once. A new theme doesn't need its own backend. It registers as another tenant of the shared one.

What went wrong

Two categories of failure. They're quite different.

The multi-tenancy migration was a real migration. "Add a theme_id field" sounds like an afternoon. It's not, when the system you're adding it to was designed around one tenant and every path through it assumes that implicitly. I found cases where theme_id was being passed correctly to Lambda but wasn't making it into the DynamoDB query, so a spin in one game would sometimes read credit data from another. I found cases where the validation checked that the field was present but not whether it matched any known theme. Finding those cases meant writing tests that ran both themes simultaneously and checked for data bleed — not a standard integration test shape.

The migration also carried its own risk, separate from any theming work. DynamoDB doesn't let you alter an existing table's primary key, so I created new tables with theme_id as the partition key and migrated the application's queries to use them. On a development backend with no real player data, that was straightforward. In production with existing players, the same migration would mean careful data backfill and dual-read logic during the transition.

The lesson: making a system multi-tenant is a migration, not a configuration. Plan for it the way you'd plan for any schema change.

CloudFormation fails in its own language. The Deployer is the stage where the application code becomes irrelevant to the failure. A bug in the React build surfaces in the Tester, not here. If the Deployer fails, the failure is CloudFormation's, and CloudFormation doesn't speak Python or JavaScript.

I hit two of these. The first was a duplicate logical ID: two resources in the same SAM template with the same name. CloudFormation's error for this doesn't say "you have duplicate logical IDs." It surfaces as a schema validation error, and tracing it back to the specific duplicate took longer than it should have. The second was a ResourceExistenceCheck — a pre-flight check that validates whether a referenced resource exists before CloudFormation even creates a changeset. I had a reference to a resource the stack expected to already be there, and the check failed before a single resource was created or modified. The error arrived at changeset creation time rather than at deployment, which was useful, but still required reading CloudFormation event logs to understand.

Neither failure was in the application code. Both required CloudFormation documentation rather than anything else in the project's stack. The deploy step speaks a different dialect than every other step in the pipeline.

The good part: the test-report gate held every time. One build had a broken win state — reel symbols were rendering but win evaluation wasn't triggering. The Deployer refused it. I fixed the Builder's output, the Tester passed it, and the Deployer ran. The gate did exactly what it was supposed to do.

What to take from this

Three things.

Gate on real QA output, not on compilation. "The build compiled" is not evidence that the product works. A Tester that runs a browser, plays the actual game, and produces a structured report — which checks passed, which failed, screenshots for the failures — gives the Deployer something meaningful to block on. That check takes a few minutes. A broken game on a live URL is worse than a deploy that didn't run.

Key a shared backend by tenant ID — for low-stakes variants. For these themed games — same code, same owner, no compliance boundaries — one backend stack keyed by theme_id is simpler to operate than five isolated stacks. Every request carries the tenant key, every read and write is scoped to it, and adding a new variant is a registration step rather than a stack provisioning step. This wouldn't be the right call if tenants were separate customers with different security requirements. For variants of one game under one operator, it's the lighter path.

Budget separately for infrastructure failures. The Deployer is the first stage in this pipeline where the failure mode isn't in the Python or the React. CloudFormation errors don't look like application errors, don't point to line numbers in your code, and debugging them means learning CloudFormation's event model and pre-flight check behavior. That's a different skill than everything else in the pipeline requires. If you're building an automated deploy step, expect to spend time on this that feels orthogonal to the application work. It is orthogonal. It's also unavoidable.

The pipeline ends here. The chain runs end-to-end — one sentence in, one deployed game out, with a human approving three decisions along the way. Whether the result is good enough to call a product is a different question, and the answer is honest: not yet. The lessons from why are the subject of the final post.

Previous: the Tester agent. Next: the final post — observations and lessons.

The Tester agent — visual QA with Playwright and a vision model

Sunitha Eswaraiah — Thu, 06 Aug 2026 10:04:43 +0000

Post 6 of 8 in the game-factory series.

I ran the ancient Egypt variant through the pipeline for the first time and it passed everything. The Builder produced a clean build. The icons loaded. The themed strings were in the code. Then I ran the Tester, and it told me the login form was broken.

The form wasn't broken.

That failure told me more about where automated testing goes wrong than months of reading could have. It's where this post starts.

What the Tester agent is

The Tester is the QA stage in a pipeline: Designer, Image-Gen, Background-Gen, Builder, Tester, Deployer. Its job is to take the freshly built game, run it in a real browser, and decide whether it works before the Deployer touches anything. The Deployer reads the test report and refuses to proceed if the verdict is fail.

Mechanically: the agent spins up the built game as a local subprocess. It runs npm install, then npm start in the output directory, waits for port 3000 to respond, and launches a Playwright browser session. From there it runs a fixed battery of eleven functional checks: navigate to the app, complete the auth flow, place spins, verify themed strings appear, check for console errors, confirm that every API call carries the right theme ID. Then three visual checks.

The unusual part is how it judges those visual results. After the functional checks, it takes three screenshots — idle page, mid-spin, settled-after-spin — and sends each to a vision-capable model with a rubric:

"Does the title and color palette visibly match the spec? Are the symbols and patterns panel readable? Is the tutorial modal absent?"

The vision model scores the screenshot from 1 to 5 and lists any issues it can see. Playwright can assert on visibility and image dimensions, but my existing assertions didn't cover aesthetic defects — a background that loaded as a flat fallback color, a color palette that was technically present but visually wrong. A model looking at the actual screenshot catches those without writing a specific assertion for each one.

Two models share the work. Haiku handles the main orchestration loop: executing the checklist, clicking buttons, reading console output, filling forms. Sonnet handles the nuanced visual judgment on the idle screenshot, where theme fidelity matters most. The simpler visual checks (mid-spin, post-spin) also use Haiku, because the bar there is lower.

At the end the agent calls a terminal tool, mark_test_complete, with a verdict and a summary. That gets written to .test-report.json:

{
  "verdict": "pass",
  "functional": { "passed": 11, "total": 11 },
  "visual": { "average_score": 4.2, "evaluations": 5 },
  "findings": []
}

If verdict is fail, the Deployer reads that and stops. The game doesn't ship.

What it did

On a working build, the Tester runs the full happy path. It registers a fresh smoke-test user with a unique email each run (to avoid conflicts with previous runs), logs in, dismisses the tutorial modal, places a spin, waits for the animation to settle, and checks that a win or no-win message appears. It reads console output for errors and reads network traffic to verify every backend call carries the right theme ID. It runs up to 20 spins watching for themed strings: "Pharaoh's Fortune" for ancient Egypt, "Valhalla Jackpot" for Norse mythology.

The vision evaluation caught things I didn't expect. On one early build, the theme colors were correct but the background image hadn't loaded. The page was technically functional, the DOM had no errors, but the game looked wrong. The vision model flagged it with a score of 2 and the specific note that the background was a flat fallback color. A DOM assertion would have passed that build.

That's what the Tester is genuinely good at: looking at the actual rendered page and deciding whether it looks right.

What went wrong

The failure mode was in the navigation, not the judgment.

To drive the game, the agent had to find and interact with elements: fill the registration form, click the spin button, read result messages. The model did this by guessing selectors. It tried placeholder text, role attributes, visible text labels, CSS class patterns. Most of the time it got close enough. Sometimes it didn't.

The registration form was the worst offender. The form has five fields, and two of them are plain input[type="text"] — one for player name, one for country. There is nothing in the element's type to distinguish them. To fill both correctly, the agent has to know to target input[type="text"] with nth=0 for the first and nth=1 for the second. If it guesses wrong, the wrong field gets filled, the form submits with country empty, the browser's HTML5 validation silently blocks the submit, and nothing happens. No error. No network request. Just silence — which the agent records as a test failure.

Twice the run reported "couldn't find field X" when field X was there and working. Both times the automation had broken on its own selector guess, not on anything wrong in the product.

This is the worst kind of test failure. A real failure tells you something is broken in the product. A false negative tells you something is broken in the test infrastructure. Because the output looks the same, you don't always know which you're looking at immediately. I spent time debugging the auth form before I realized the selector was wrong.

The pattern matters: vision-as-judge was the reliable half; LLM-guessed-selector navigation was the fragile half.

Looking at a screenshot and deciding whether a slot machine matches an ancient Egypt theme is exactly the kind of ambiguous judgment a language model handles well. It can reason about color fidelity, symbol legibility, layout, atmosphere. Reverse-engineering a CSS selector for a button it has never seen the source of is a different task. It's brittle, failure-prone, and not something the model is particularly good at.

The fix is structural. The form fields should have accessible labels — aria-label or associated <label> elements — which also makes the game more accessible. Where a stable user-facing locator doesn't exist, the Builder should stamp data-testid attributes: data-testid="spin-button", data-testid="credit-display". Then the Tester queries by label or role first, falls back to testid, and only guesses as a last resort. That gives the automation stable hooks across every theme variant.

I haven't shipped that yet. It's on the backlog. The evidence for it is sitting in the test logs: two false negatives on builds that were actually working.

What to take from this

Use a vision model as a complementary judge of a rendered UI. It catches aesthetic defects that specific assertions weren't written for: wrong colors, layout that's technically valid but visually broken, a background that loaded as a fallback. It's not a replacement for deterministic assertions — it's probabilistic and occasionally inconsistent. But it covers the gap between "the DOM is correct" and "the game looks right."

But don't make the model navigate by guessing selectors. That's where it breaks. Navigation requires knowing the exact shape of the DOM, and a model with no source access is guessing. Every wrong guess is a potential false negative.

The design that works: give the automation stable, semantic hooks — testid attributes, ARIA roles, predictable form structure — and let the model focus on the judgment calls. Make the thing easy to drive, and reserve the model's cleverness for the evaluation.

For any pipeline where one agent builds an artifact and the next agent tests it, the cleanest version of this is a contract between the two. The Builder promises to produce certain testable hooks. The Tester relies on them. Both agents get simpler. Failures become easier to localize.

Previous: the Builder agent. Next: the Deployer agent.

The Builder agent — the code-modifier that fought me

Sunitha Eswaraiah — Thu, 06 Aug 2026 09:51:02 +0000

Post 5 of 8 in the game-factory series.

Three hours and no result

I was watching the terminal scroll when I noticed the agent had been running for over an hour. Build attempts, compiler rejections, patch attempts. Same file, same error pattern, a new proposed fix each time.

By the time I stopped it, the call count was 868. Three hours had elapsed. The file it had been working on had two export default statements, two return (...) blocks — one of them orphaned in JSX that didn't close — and a mix of correctly-themed and original-themed strings sitting next to each other like the model had started several attempts and stopped mid-thought. The React compiler had been rejecting it for the last hundred calls at least.

At list rates for the model, that run cost about $138.

The Builder hadn't done anything wrong by its own rules. There were no rules that said stop.

What the Builder is

The Builder is the fourth agent in the pipeline. By the time it runs, the Designer has produced a spec, Image-Gen has generated themed icons, and Background-Gen has produced a background image. The Builder's job is to take all of that and wire it into the actual code.

The Builder runs a flat while loop. Call the model, dispatch the tool it chooses, feed the result back, repeat until the model calls mark_build_complete or something goes wrong enough to abort. The loop itself is eight lines. What makes it interesting is the toolset inside it.

The Builder has more tools than any other agent in the pipeline. It can read a file, write a file, list the files in a directory, copy a file, patch a file (find an exact string and replace it), and call the terminal tool. Six operations, each corresponding to a real step in the job. The variety matters: most of the build is copy operations, some of it is writes, a small slice is targeted patches.

There are two human gates. Before the agent touches any code, it proposes a plan and waits for approval. When the build finishes, it presents the output and waits again.

In the version that burned $138, there was no mandatory compile gate. The model could see compiler output — it was running npm run build itself via the terminal tool, reading the errors, and attempting patches — but nothing stopped the loop when compilation failed. The model just kept trying. I added a hard compile gate later: compilation runs after the model signals done, errors feed back for a bounded number of fix rounds, and if it doesn't converge, the build rolls back. But that structure didn't exist during the failure I'm about to describe.

What it did

The casino codebase is a React application backed by serverless AWS functions. Every symbol in the game, every color, every win message is baked into the source code. The Builder's job was to fork it into a themed variant: copy the structural files unchanged, swap the colors and fonts and API endpoints to match the spec, and patch the main game component so the reels, win messages, and tutorial reflected the theme.

For an ancient Egypt variant: gold and lapis tones replacing the original palette, hieroglyph names replacing cloud service names in the symbol configuration, the win message changed from something about AWS architecture to something about pharaohs. Same code structure, different content surface.

The copy-and-patch pattern worked well for small, isolated files. The CSS config, the sound file manifest, the theme metadata — all clean boundaries. The Builder handled them without complaint.

The main game component was a different case entirely.

What went wrong

The file was too big to edit safely.

SlotGame.js was about 1,900 lines. It held the spin logic, the win-calculation state machine, the reel animation handling — and scattered throughout all of that: theme-specific strings. Win messages embedded in conditional branches. Tutorial copy baked into JSX. Symbol references in a dozen different places, each with slightly different surrounding syntax.

I had already moved the color swap, the font swap, and the static string substitutions into plain Python — deterministic passes that ran before the model got involved. That reduced the patch surface significantly. It wasn't enough.

The remaining patches still ran into the problem the patch tool created: to change a line, the model had to reproduce the surrounding block exactly. Every bracket, every indentation level, every blank line before and after the target. On a 1,900-line file, the model didn't have a reliable mental model of every whitespace detail. It guessed. Sometimes correctly. Often close enough to fail.

Themed names broke the parser.

Symbol names in a spec sometimes contained apostrophes. A symbol called Chef's Trio sounds reasonable in a design document. Dropped into a single-quoted JavaScript string, it breaks the parse. The model didn't consistently escape these. The compiler would reject the file, the agent would read the error, and in fixing the apostrophe it would shift an indentation level, which broke a different thing.

Each failed patch made the file worse.

Every edit left the file slightly different from what the model remembered. The model patched based on what it had seen from a prior read — but after each change, the file no longer matched that snapshot. So the model was proposing patches against a version that no longer existed on disk. The exact-string match would fail because the surrounding context had changed, and the model — not knowing what the file currently looked like — would guess at what the block might be now and try again, often wrong.

There was a way to bound this: force a full re-read of the current file before every patch. I hadn't done that. The token cost of re-reading 1,900 lines on every turn seemed wasteful on the runs that were going well. On the runs that weren't, it would have caught the drift early.

Duplicate structures were the signature failure. When the exact-match patch tool rejected the model's target string, the model would fall back to rewriting larger sections of the file via the write tool — sometimes inserting the replacement alongside the original instead of replacing it, producing two copies of the same block. Duplicate export default statements. Two return (...) calls. Orphaned JSX floating between structural blocks that no longer connected to anything.

The loop had no ceiling.

868 calls. Three hours. Over 413 million cached input tokens as the model re-read the same growing conversation on every call. About $138 at list rates for Sonnet — and that was with prompt caching enabled. Bedrock's caching meant each call charged a fraction of the full input cost. Without it, the bill would have been an order of magnitude worse. Caching made the Builder viable on normal runs; it also made the worst-case run cheap enough per-call that I didn't notice it was spiraling until an hour in.

I knew abstractly that an unbounded loop backed by a paid API was a risk. Knowing it abstractly and watching it happen are different experiences.

What the fix looked like, in outline

The eventual solution wasn't about making the model more careful. It was about removing the reason to edit that file at all.

The component was fragile to patch because it mixed structural code with content. Theme-specific strings were not isolated — they were woven into the spin logic and the win-calculation branches. The fix was to separate them: move the theme-specific text into a config file the component reads at runtime, so the Builder's job for that component becomes generating a JSON file rather than patching 1,900 lines of JSX.

Generating a JSON config from a spec is ordinary Python — a function reads the spec fields and serializes them into the shape the component expects. No model involvement, no string matching, no file editing. The component reads the config at runtime. The model never touches the component at all.

I'm not going to explain that fix in full here — the full redesign and what it teaches about which parts of a pipeline should involve a model at all is the subject of the final post in this series.

What to take from this

Two things, both short.

A code-modifying agent is only as safe as the size and shape of what you ask it to edit. Small files with a clean boundary between structure and content are workable targets. Large files with interleaved concerns are not. If your agent is patching a big file and behaving badly, examine the file before you examine the model.

Any model loop backed by a paid API needs a hard turn cap before you trust it with a real run. Not added later as a safety measure — as a condition of running at all. The cap doesn't improve the agent's reasoning. It makes the worst-case run affordable rather than surprising.

Previous: the image agents. Next: the Tester agent. The full redesign and the general lesson — about what should and shouldn't be an agent — is the final post in this series.

The image agents — prompt to PNG

Sunitha Eswaraiah — Thu, 06 Aug 2026 09:34:29 +0000

Post 4 of 8 in the game-factory series.

Icons are what people look at

You can theme fonts, colors, win messages, and sound effects. Change all of it and the game still reads like the original with a skin on it. Swap the icons — the actual symbols spinning in the reels — and it reads like a different game. The casino template I built by hand uses cloud service logos. Replace those with golden scarabs and ankhs and it becomes an Egyptian game. Keep the logos and give it an Egyptian color scheme and it doesn't.

A full theme has around thirty symbols. Each needs to be small enough to read at reel size, distinctive enough to tell apart mid-spin, and consistent enough that they look like they came from the same place. Getting that by hand for every theme is exactly what I wanted to avoid.

So two agents handle the visual layer: Image-Gen and Background-Gen. They're the shortest story in the pipeline — almost identical code, real results, and one failure mode I still haven't fully solved.

Two agents, one loop

The Designer's spec carries everything the image agents need. Each symbol entry has an icon_prompt — a short text description the Designer wrote to describe that symbol's appearance. The spec also carries a single background_prompt for the full-page background.

Image-Gen reads the spec, loops through every symbol, and for each one calls Stable Image Core on Bedrock with the symbol's prompt. It gets a PNG back, resizes it to 256×256 (the size the reels expect), and writes it into the app's public/images folder. After the icons are approved, it seeds DynamoDB — putting each symbol into a table the game queries at runtime to know which icons to load.

Background-Gen does the same process exactly once, for the background image.

That's the scope. I grouped them in one post because splitting them into two would mean writing the same agent story twice. They share the same architecture, the same failure modes, and the same lessons. The only thing different is the count of outputs.

What runs

The happy path is simple. Stable Image Core returns the image as base64; I decode it, resize it, write it to disk. A thirty-symbol run takes a few minutes.

The resize step looks like a footnote but it isn't. Stable Image Core returns full-resolution PNGs — much larger than the 256×256 the reel layout expects. At native size the images overflow their containers and the game renders incorrectly. No model parameter controls the output dimensions. It's a plain post-download resize call in Python, on every image.

The fallback is deliberate. Image generation calls fail: timeouts, model errors, prompts that get rejected. A single failed icon shouldn't crash a thirty-symbol run. A single broken icon means a known gap you can regenerate later. So the agent catches per-call failures, logs them, substitutes a placeholder image, and keeps going. The build finishes with a gap rather than a crash.

Where it broke

Consistency across a set is the real problem. Each call to the model is independent. It has no memory of the previous call. Generate thirty icons in a loop and you get thirty independent draws from the same distribution — which means thirty different art styles.

The scarab might come back painterly and textured. The ankh lands flat and geometric. The pyramid looks like concept art from a different project. All technically correct against their prompts. None of them obviously from the same game.

You can reduce this with prompt engineering. I added a style string to every call — "pixel art, dark background, warm palette, consistent line weight" — and it narrows the range. Keeping symbol counts lower helps. But I didn't solve it. Icon visual quality stayed the main limitation of the factory. One good icon is a solved problem. A coherent set of thirty isn't, not with independent calls to a generative model.

The games ship looking like themed games. They don't look like art-directed games. That's the honest description of the ceiling.

The path failure was invisible. Generated images land in public/images. The image agents write them correctly. But when deployed under a non-root path, referencing the background in CSS with a plain url('/images/background.png') silently fails — the browser doesn't find the file. No error, no 404 in the console; the CSS rule parses fine, the image just doesn't appear.

The correct way is a JavaScript inline style using process.env.PUBLIC_URL:

style={{ backgroundImage: `url(${process.env.PUBLIC_URL}/images/background.png)` }}

That resolves correctly across deployment paths. The fix is a one-liner. Finding it cost more time than that, because nothing in the output told me where to look. Technically a Builder problem — but discovered while debugging why generated images weren't showing up.

The size mismatch was boring but necessary. Images downloaded fine, the folder looked right, and the game was broken. I had to open the game in a browser to find out something was wrong, then trace back to the image dimensions. The resize step was ten minutes of work; discovering it needed to exist took longer.

What to take from this

Text-to-image models are strong at generating individual images. They're weak at consistency across a batch. That isn't a limitation of any specific model — it's what you get when each call samples independently. If you're generating a set of related images, plan for this before you start.

The options: put a strong, specific style string in every prompt and repeat it verbatim; use a fixed seed if the model supports it; generate one reference image first and use img2img for the rest; or set an explicit acceptance that the set will have variance and decide early what "good enough" looks like. Don't let the consistency problem surface when you're looking at thirty finished icons that don't cohere.

Own the boring post-processing in plain code. Resize, path wiring, fallback handling — none of that belongs in a prompt or a model setting. The model's job is to produce a good image. Your code's job is to put it in the right place at the right size and handle the call that fails. Keep those two responsibilities separate and both stay simple.

The fallback pattern generalizes beyond image generation: in any pipeline loop over independent, replaceable items, a per-item failure is recoverable. Catch it at the item level, substitute something visible (not silent), and let the build finish. A gap you can fill later is better than a crash you have to start over from — as long as QA can see the gaps.

Previous: the Designer agent. Next: the Builder agent.

The Designer agent — a spec from a conversation

Sunitha Eswaraiah — Thu, 06 Aug 2026 09:24:11 +0000

Post 3 of 8 in the game-factory series.

The only agent that talks back

Every agent in this pipeline reads files and writes files. The Designer is the exception. You describe a theme — "Norse mythology slots" — and it asks you things. What's the tone: whimsical or dark? Should the high-value symbols be characters or objects? Are there specific win phrases that should feel right for the setting? It consults the original casino's design constraints, checks a worked example, and runs back and forth with you until it has enough to produce a single JSON file.

That file is the contract. It doesn't deploy anything. It doesn't write any code. It describes the game — symbols with weights and prompts, a color palette, winning patterns, UI strings, fonts, sounds, a background prompt — and every later stage reads it. Image-Gen, Background-Gen, Builder, Tester, Deployer: they all start from that file.

That sounds like a narrow job. It turned out to be the most consequential one in the pipeline.

What the agent is

The Designer uses the Bedrock Converse API, the conversational format where you maintain a message history and pass it back on every turn. No framework. A Python class, the API, and three tools.

The tools define the job more precisely than the system prompt does.

generate_game_spec is the terminal tool. When the model calls it, the conversation ends and the spec is ready for human approval. Its input schema is the contract: theme_id, theme_name, symbols (each with a name, a weight from 1 to 10, a category, and an icon_prompt), color_palette, win_conditions, patterns, ui_strings, fonts, sound_theme, background_prompt. I defined that schema once and every downstream agent reads against it.

The other two tools are read-only. read_blueprint lets the model inspect the original casino's design constraints without those constraints being inlined in the system prompt. read_example_spec returns a worked example so the model can see what a correct, complete spec looks like. Both tools exist so the model can look things up on demand. Without them, the system prompt would need to carry several thousand words of context on every single turn — expensive, and stale the moment anything in the casino changes.

The conversation follows a short arc. You describe a theme. The model asks clarifying questions for anything underspecified. It reads the blueprint and example as needed. When it has enough, it calls generate_game_spec. The proposed spec appears, you read it, and you approve, reject, or ask for changes. Approved, it goes to disk as specs/<theme_id>-spec.json. Everything else reads from there.

What the spec is actually doing

The file is a few kilobytes of JSON. It doesn't feel load-bearing until you watch what depends on it.

Image-Gen reads symbols[].icon_prompt to generate each reel icon. If those prompts are vague — "a cool wizard thing" instead of "an ornate golden wizard hat against a dark purple sky, fantasy illustration style" — the icons come out generic. Builder reads color_palette and patches the casino's CSS variables. It reads ui_strings to replace the displayed text. It reads patterns to configure which symbol combinations win. Deployer reads theme_id to name the stack. The whole pipeline is downstream of whatever the Designer committed to disk.

A bad spec is quiet for a long time. The Designer doesn't know whether the prompts it wrote will produce good icons. Builder doesn't know whether the colors will look right in the browser. Tester is the first automated stage that catches it — and by then you're four stages in.

I reduced the risk slightly by making the example spec a tool result rather than a fixed block in the system prompt. The model can compare its proposed output against a well-formed reference before calling generate_game_spec. That helped. It didn't eliminate the problem. Reviewing the spec carefully before approving it — actually reading each symbol prompt, not just skimming the palette — is the single most valuable thing you can do in the whole pipeline.

What went wrong

Three things.

The recursion problem. The Designer was the first agent I wrote, and I wrote it with a recursive response handler. When the model calls a tool, _process_response feeds the result back by calling itself:

# Original Designer: recurse on every tool call
def _process_response(self, response):
    if tool_name == "generate_game_spec":
        return tool_input          # done
    result = self._call_model(append_tool_result(response))
    return self._process_response(result)   # recurse

# All later agents: flat while loop
while True:
    response = self._call_model(messages)
    if stop_reason == "end_turn":
        break
    # dispatch tool, append result, keep going

The recursion only goes a few levels deep in practice — the model rarely chains more than two or three tool calls in one turn. It never actually crashed. But it made the code harder to reason about, harder to log each step, and harder to interrupt cleanly. Builder, Tester, and Deployer all use the flat while loop because it's obvious where the iteration happens. The Designer is the one I wrote first and never went back to fix.

The first agent you build teaches you the shape. You just have to notice the lesson before you ship the next five.

Garbage in, garbage out — delayed. The spec is the contract, so the weakest spec produces the weakest game. A symbol with "icon_prompt": "mystical thing" gets an icon that looks like clip art. A win condition with no context gets an awkward label in the UI. Neither of those failures shows up until three or four stages later, and the root is back in the spec file. There is no automated check between "Designer approved" and "game looks bad" because the intermediate artifacts — icon files, styled code — are all valid even when the prompts that generated them were weak. The only mitigation I found was discipline at the approval gate.

The approval gate confused the web UI. The pipeline originally ran in the terminal. Human-in-the-loop meant input(). When I later put it behind a web UI, every Designer turn became a form in the browser — and the Designer's loop has two distinct kinds of turns: conversational turns where the model is asking a clarifying question, and approval turns where it has produced a spec. In the terminal, context makes these obvious. In the web UI, both appeared as the same text box, and users kept trying to approve a question as if it were a finished spec. I had to go back and tag each turn type explicitly — CONVERSATION vs APPROVAL — so the UI could render them differently and route the response correctly. The lesson: "a human in the loop" has a shape, and input() hides that shape until you try to put it somewhere real.

What to take from this

Two things, both concrete.

Make the boundary artifact explicit and inspectable. The spec file is not a convenience — it's the reason failures are diagnosable. When a game comes out wrong, I open the spec and the problem is usually visible. If the Designer had handed off implicitly — passing state in memory, writing values into a database you'd need tooling to query — inspection becomes a project instead of a glance. A flat file on disk is not sophisticated, and that's the point. When each stage's output is a file, you can look at it, diff it, and hand it to someone else without explaining an API.

Use a flat loop for anything conversational. Recursion reads naturally when you're writing it. A while loop is easier to reason about, has no depth limit, is easier to add logging to, and is easier to interrupt cleanly. I reached for the while loop on every agent after the first. Go back and apply the lesson to the first one.

Previous: the factory overview. Next: the image agents.

How a single game evolved into a game factory

Sunitha Eswaraiah — Thu, 06 Aug 2026 09:09:50 +0000

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.

The slot machine that turned into an agentic game factory

Sunitha Eswaraiah — Thu, 09 Jul 2026 12:39:00 +0000

Post 1 of 7 in the game-factory series.

What it is

There is a slot machine I built and deployed to AWS, and it looks, at first glance, like a novelty. The reels are filled with cloud service icons instead of cherries and sevens, a leaderboard tracks players in real time, and every so often a small quantum badge lights up in the corner of the screen for reasons that aren't obvious until you look under the hood. It has a tournament mode for live events, a hosted "big screen" leaderboard view for a projector, and a real-time risk gauge that most people don't expect to see on a slot machine at all.

AWS Slots — reels, responsible gaming monitor, and live leaderboard

Underneath that surface, it behaves like a real one. Random number generation with a defined design, return-to-player math, session tracking, bet escalation detection — all of the mechanics that make a slot machine a slot machine, implemented the way an operator would implement them. What it is not, deliberately, is gambling. There is no real money anywhere in the system: no deposit path, no cash-out, nothing a player can lose beyond a number on a screen. The cloud icons are the tell. Nobody wagers actual currency for the chance to line up three Lambdas.

That distinction — a slot machine built with the seriousness of a real product, but without the thing that would make it one — is the reason this project exists, and it's where the story actually starts.

Why I built it

I've worked with several clients in the iGaming space, and I came into that work knowing almost nothing about the industry itself. I had no real opinions about return-to-player percentages (the share of wagered money a machine pays back over time), volatility curves, or how a jurisdiction certifies a random number generator. I was walking into a domain with its own vocabulary, its own regulators, and its own math, and I needed to close that gap quickly.

Reading through documentation and sitting in on product demos told me what the industry talks about, but it didn't tell me how any of it actually works. That gap is where I usually end up building something — I learn a domain by trying to reproduce its hardest problems in code, not by reading about them. So I set out to build a slot machine that behaved like a real one: a random number generator designed the way a regulator would expect, responsible gaming features (tools and detection systems meant to catch harmful play before it escalates) implemented the way an operator is required to implement them, and session tracking structured the way a behavioral analytics team would actually query it. If I could get all of that working end to end, I would understand the industry from the inside rather than from a deck.

The AWS icons weren't just theming — they were the mechanic. Winning patterns in the game are architecture patterns: land two matching services and you score, land three of a kind and you score more, and the jackpot is landing a coherent AWS architecture across the reels. The symbols had to mean something for that to work, and cloud services were the natural fit. It also meant the game could teach a little AWS architecture on the side, almost as a byproduct of playing it.

Once I started, the project kept growing on its own logic. Learning about rule-based responsible gaming detection led me to want to try the ML-based version. Basic session tracking turned into a full analytics pipeline once I understood why operators care about it. A mentor of mine even suggested quantum-seeded randomness and then built the service himself, which gave me a real quantum RNG to integrate into a live spin path. What began as "understand how slot machines work" became "build the smallest complete iGaming platform I can, and treat every layer of it as if it had to survive a real audit."

What the game does

Strip away the infrastructure and the game itself is simple to describe: you spin, you bet, you try to land a pattern.

The basic win is matching symbols — two of a kind pays a little, three of a kind pays more. The interesting win is the jackpot, and it isn't a random combination. It's a real AWS architecture. Land S3 feeding Lambda feeding DynamoDB across the reels, for instance, and you've built something that actually deploys. The game keeps a small library of valid patterns like this, and hitting one is worth more than any three-of-a-kind. That was the whole point of choosing cloud services as symbols in the first place — the jackpot teaches the shape of a real system as a side effect of chasing it.

Sitting next to the reels is a live risk gauge, and this is the part that surprises people who've never thought about what's actually required of a gambling product. Every spin gets checked against a set of behavioral rules — are you spinning faster than a person normally would, are your bets climbing after a loss, have you been at this for half an hour straight. On top of that rule-based layer, a machine learning model periodically reassesses your session and produces a risk score, and the gauge moves accordingly. Because there's no real money in this version, nothing actually stops you when the gauge goes red — but the mechanism is the same one a real operator would use to intervene, and building it taught me more about responsible gaming than any article could have.

The badge in the corner is the quantum tell. Most spins draw their randomness from a standard, well-trusted source. Some spins, when a separate service is healthy and responsive, draw it from an actual quantum circuit instead — the service my mentor built, seeding the randomness from Amazon Braket (AWS's managed quantum computing service). I integrated it into the game as an experiment in whether quantum-sourced entropy could serve a live spin without anyone noticing the difference except for the badge itself.

And the whole thing isn't limited to solo play. Event mode turns it into something you can run in a room: players join with a QR code, a shared leaderboard updates live on a projector, and a tournament structure lets you run timed competitive rounds rather than open-ended play. That mode is what made the game night possible in the first place.

(A full technical writeup — Lambda counts, RNG seeding mechanics, security layers, analytics pipeline — is in the appendix at the end of this post, for anyone who wants the implementation detail.)

What actually happened

I ran the first version at an office game night. Booked a room, put the leaderboard up on a screen, and let people join by scanning a QR code so nobody had to type anything to get in.

Demoing the tournament mode to a small group, live leaderboard on screen

It landed better than I expected. A small crowd gathered around the screen — people watching the reels spin, waiting to see if the badge would light up, watching the leaderboard reshuffle as new players joined and started competing for the top spot. The room reacted to it the way a room reacts to an actual game, which told me the work had crossed some threshold from a personal exercise into something that functioned as a real product.

The tournament's live leaderboard projected during a later game night

The tournament mode scaled past that first small room, too. I ran a later event with a full leaderboard projected for a much bigger group, timed rounds, and a proper prize structure at the end.

Presenting final tournament results and prize winners

The game is still running today. Real production deployment, a real Cognito user pool, real DynamoDB tables that have held up under actual use. The player count is modest, but every one of them has a genuine account and a genuine leaderboard entry, and the system hasn't needed to be rebuilt to support any of it.

More importantly, for the reason I started, the learning stuck. I can reason about RNG design, responsible gaming obligations, session tracking, behavioral analytics, and tournament operations from having built each of those pieces myself, not from having read about them. When I'm in a conversation with someone who actually knows this industry, I understand what they mean.

And there was one more thing I noticed, standing at that first game night watching the reels spin — something that felt obvious the moment I saw it, but hadn't occurred to me at all before then.

What came next

Here's the realization, in one sentence: almost everything that made this a slot machine was infrastructure, and almost nothing that made it this slot machine was.

The thirty-four functions, the machine learning, the quantum RNG, the six layers of security, the analytics pipeline — months of work, and none of it specific to this particular game. What was specific to this game was small by comparison: a set of cloud icons that could have been any set of images, a handful of hex codes for the palette, win patterns in a database table, sound files in a folder.

Which raised an obvious question: if the infrastructure stayed exactly as it was and only the theme changed, could I produce an entirely different slot machine — wizards and wands instead of cloud icons, or iron thrones, or football clubs — without touching any of the hard parts again?

Doing that by hand would just be a customization service, not a factory, and it wouldn't have taught me anything new. The version I actually wanted to build was one where the variation itself was automatic — where I could describe a theme in a single sentence and have something else produce the specification, generate the artwork, patch the code, test the result, and deploy it, with no manual editing anywhere in the loop.

That project became game-factory: a pipeline of six agents — Designer, Image-Gen, Background-Gen, Builder, Tester, and Deployer — that takes a theme prompt and turns it into a themed clone of this casino, deployed to its own address. It works. Two themed variants are live as of this writing. Getting there took a lot of wrong turns, and those wrong turns turned out to be the more interesting story.

The next six posts in this series are about those wrong turns and the patterns that came out of fixing them. If you're building agents that modify code, generate assets, or check their own work, some of what I learned along the way should transfer directly.

Appendix: technical implementation

The section above stays at the level a player or a curious reader needs. This is the level an engineer would want.

AWS Slots Casino — solution architecture

Frontend. A React application, hosted on S3 behind CloudFront. Several distinct modes in the same codebase: solo play, tournament mode with a warmup phase and timed rounds, an "event" mode for hosting live sessions, an admin dashboard for credit resets and pattern approvals, and a big-screen leaderboard view for a projector. Fifty-plus AWS service icons make up the symbol pool. Three ways to win — two of a kind, three of a kind, or a valid AWS architecture across the reels for the jackpot — each with its own payout.

Backend. Thirty-four AWS Lambda functions written in Python, organized by responsibility: authentication (registration, login, verification, password recovery), game logic (spins, credit resets, leaderboard), machine learning (behavioral event tracking, risk score inference), events and tournaments (creation, joining, spinning within an event, ending a round), and admin (analytics, feedback, pattern approval). Amazon API Gateway sits in front of all of it, with a WAF web ACL applying OWASP rule sets (the industry-standard list of common web application vulnerabilities), IP reputation filtering, and rate limiting, plus its own throttling — 30 req/s sustained, 100 burst. Amazon Cognito (AWS's managed user identity service) handles identity, tokens, and password recovery. DynamoDB holds players, sessions, behavioral events, tournaments, event participants, icon metadata, and winning patterns, all as configurable data rather than anything hardcoded.

RNG design. In production, the spin function calls Python's secrets.randbelow, drawing from the OS's cryptographically secure entropy pool — sufficient for a real product. A second path exists for experimentation, running the quantum service my mentor built. That service runs on ECS Fargate in Rust, and on startup submits 32-qubit circuits to Amazon Braket, using either the SV1 simulator or IonQ hardware when it's available. Each qubit gets a Hadamard gate and then a measurement, and each measurement collapses into a zero or a one — genuine quantum randomness. Those bits seed a ChaCha20 stream cipher (a fast, well-vetted algorithm for expanding a small amount of true randomness into a much larger stream of it) that fills a 100MB entropy pool, enough for roughly 12.5M spins, with a background monitor topping it off whenever it drops below 20%. The spin function calls this service with a 500ms timeout and falls back transparently to the standard path if anything is slow or unhealthy. A field in the response, entropySource, tells the frontend which path served the spin — that's what lights up the quantum badge.

Responsible gaming. Two layers running side by side. Rule-based, on every spin: evaluates against six patterns — spins under 6s apart, bets spiking above 5x the running average, 3x bet increases immediately after a loss, credits dropping below 10, sessions past 30 minutes, and long streaks of rapid consecutive spins. Any of those firing writes an event to a behavioral table in DynamoDB. Model-based, every 10 spins: a function pulls the last 30 days of a player's session data, computes 26 behavioral features across three groups — temporal (session duration, frequency), financial (bet sizing, credit depletion), and behavioral (impulsivity, loss-chasing) — and sends them to an XGBoost model (a widely used, tree-based machine learning algorithm) hosted on Amazon SageMaker (AWS's managed machine learning platform), which returns a risk score from zero to a hundred driving the live gauge, with four levels from low to critical. There's no real money in the system, so the gauge is a demonstration rather than an intervention — in a real product, high or critical scores would trigger deposit limits or a referral to support.

Security. A defense-in-depth model across six layers, arranged so that if one fails, the next one is still standing. Edge: CloudFront and a WAF handling OWASP rules, IP reputation, and HTTPS enforcement, backed by AWS Shield Standard. Network: API Gateway throttling and CORS restricted to the production domain. Identity: Cognito verifying JWTs (signed tokens used to prove a logged-in user's identity on every request) against its JWKS endpoint, brute-force lockout, short-lived access tokens. Application: every credit and win calculation runs server-side, admin endpoints check the caller's JWT against an allowlist, players can only ever read their own data. Data: encryption at rest, per-function IAM roles scoped to exactly the tables each one needs, public access blocked on every S3 bucket. Detection: CloudWatch alarms, X-Ray tracing on every Lambda, CloudFront access logs flowing into S3. None of it arrived at once — each layer got added as the domain's actual threat model became clearer.

Analytics. The behavioral events table is the source of truth. Every night at 2AM UTC, a scheduled export job scans the table and writes the day's events into S3 as Parquet, where Athena queries it with SQL and QuickSight turns it into dashboards — player behavior over time, risk score distributions, tournament participation, session duration trends.

Tournament operations. Before a live event, a warmup script provisions 10 instances of Lambda concurrency on the event-spin function so cold starts don't interrupt play, then tears the concurrency down afterward so the cost disappears with it.

Next: What is an agent, actually?
Also useful: Agent scoping — the cheat sheet