Live mobile games run on a content treadmill. A hyper-casual or hybrid-casual hit stays healthy by shipping a steady stream of small features: limited-time events, collection mechanics, store offers, seasonal reskins. None of them is the headline feature. All of them keep the game fresh and hold retention. And each one moves through the same assembly line: write the design document, get it reviewed, generate and clean the art, build the UI, wire it into the engine, test it, ship it.
Most of that work is repetitive, and most of it lands on senior people whose time is worth more than the task. One of Europe's largest mobile game studios came to us with exactly this problem on one of its long-running hits: a hyper-casual arcade game, played by millions, of the sort where you steer a growing hole through a city and swallow everything in its path. It is easy to play and relentless to operate, and they wanted to take the low-value, repetitive half of that operation off their engineers and designers without turning it into a black box nobody could trust. This is the pipeline we built for them, and the engineering decisions that made it trustworthy enough to ship real features into a production game.
Why a single long agent run does not work
The obvious first attempt is to point one capable coding agent at the game repository and let it work the whole feature from top to bottom. We tried that. It fails for a structural reason, not a prompt-tuning reason.
A single agent conversation accumulates everything as it goes: tool output, console logs, screenshots, its own corrections. Over a multi-hour build that context keeps growing until quality drops. The model gets cautious, starts second-guessing itself, and begins deferring the decision back to the human ("should I continue?"). One of our early runs stretched past fourteen hours with repeated stops. The context window, the very thing doing the work, was also the thing degrading.
So the design question was never "which agent is smart enough." It was "how do we keep every unit of work inside a fresh, bounded context, and still deliver a coherent feature."
Two phases, one human gate
The pipeline splits a feature into two phases separated by a human approval gate.
The first phase turns a short brief (often a single paragraph: what the feature is, what metric it should move, the constraints) into a full design document. The document is grounded. The agent reads the actual game repository, the existing systems, the design conventions, and the analytics definitions, so it designs a feature that fits the game rather than one invented in a vacuum. It also produces on-brand UI mockups and a one-page summary a busy stakeholder can read in two minutes.
Then it stops. A human reviews and approves the design before anything gets built. Nothing reaches the game on an unapproved design. That gate is where the studio keeps creative control, and it is deliberate. The teams we work with want a co-pilot they steer, not an autonomous system that surprises them.
The second phase takes the approved design and builds it: Unity C# code committed to a real feature branch, 2D and 3D assets generated and validated, UI assembled, remote-config and A/B shape, and automated tests. This is the part that runs unattended.
The core idea: a managed context per stage
The second phase is driven by a deterministic controller written in plain Python, with no model context of its own. It is not an agent orchestrating other agents. A controlling agent would itself accumulate every stage's history and reacquire exactly the degradation we set out to avoid.
The controller sequences the build into stages (plan, assets, code, UI, integration, verify) and spawns one fresh agent worker per stage. Each worker is born with exactly the inputs it needs (its own procedure, the approved design, the current run state), does one stage, writes a machine-readable result, and exits. No worker inherits another stage's accumulated context. The expensive, degradation-prone resource, the model's context window, is bounded to a single stage and thrown away between stages.
The workers themselves are Claude agents (built on the Claude Agent SDK), and they reach the outside world through Model Context Protocol tool servers: the open-source akiojin Unity MCP server driving the Unity editor, Blender for the 3D work, Figma for the design system, and Scenario for generated 2D and 3D art. The engine here is Unity, but the pipeline does not lean on the engine's own built-in tooling (Unity AI). It composes those specialized services under one controller instead. The controller never reads their prose. It reads a small structured result from each stage and decides the next move: advance, retry, recover, or stop at a gate. Because the schedule is strictly sequential, the shared game editor is only ever driven by one worker at a time, which removes a whole class of concurrency bugs for free.
Two properties fall out of this design. The build is fully resumable from files on disk, because the state lives in the run folder and not in a live session. And a controller made of plain code cannot degrade over time, which is the failure mode we started with.
Trusting the output: five layers of verification
An agent that writes code and reports success is not enough, because a headless agent can stop mid-task and still exit cleanly. An exit code means "no crash," not "the work is correct." So the controller never trusts a worker's own verdict. It re-checks the evidence before advancing.
Every quality claim is machine-checked through a five-layer stack. The assets come from Scenario, with 3D produced through image-to-3D and inspected in a headless Blender pass, and the first layer is a set of deterministic geometry checks that confirm a 3D asset has sane topology and scale. Rendered-pixel computer vision checks the UI for contrast and overlap against the approved mockups. A structured vision-model review reads the rendered screen the way a human reviewer would. An automated play-mode smoke test boots the feature and drives it. And a real-boot integration contract asserts the feature actually works in a full game boot, not in an isolated prefab render.
That last layer earns its place. On one build, every visual check passed while a runtime integration contract caught five real gameplay bugs that the pixel-level checks had missed. "Looks right" and "is right" are different questions, and the pipeline answers both. The playable gate is guarded so it can only be satisfied by a genuine full-game boot. A synthetic render can never fake it.
The result
The payoff is a feature that runs in the actual game, built from a one-paragraph brief and an approved design with no human input in between. In our pilot, a feature's full art set was generated and machine-validated in under an hour, against a manual baseline of roughly two hours per asset. A clean end-to-end build reached a playable state in about three hours, hands off.
The screenshot above is one of those builds running in the editor: a live event assembled by the pipeline, its generated art imported and validated, playable on the home screen. Every asset in that frame, the icons, the header art, the 3D collectable, came out of the pipeline and passed the verification stack before a person looked at it.
And because every run is versioned and pinned to an exact code commit and input, any output traces back to precisely what produced it. When a designer asks why the feature was built a certain way, the answer is on disk: the design it came from, the decisions it made, the checks it passed.
What this means
The lesson here is not that agents can now build software on their own. It is that autonomous delivery becomes real when you treat the agent as one component inside an engineered system, with bounded contexts, hard gates, independent verification, and full traceability, rather than as a single clever process you trust on faith. The generation is hands-off. The trust comes from the engineering around it.
We build these systems for teams that want AI moving real work through their pipeline without giving up control or accountability. If that is the kind of automation you are trying to stand up, let's talk.
