What an AI game agent actually needs (it isn't a bigger model)

There's a demo everyone has seen: someone types "make me a platformer" into a chat window, a few hundred lines of code appear, and a canvas element in the corner shows a square jumping. It's genuinely impressive and it is not a game studio, for a reason that has nothing to do with model quality.

The square-jumping demo works because it deliberately chose the one target where code is the deliverable. Ask for a real game, with imported art, an audio bus, touch controls, a build you can send someone, and the model's output stops being the answer and starts being step one of about nine. Those other eight steps are the product.

The four things an agent must have in hand

Writing a game requires reasoning. Producing one requires tools, and specifically four of them.

An engine, at a version

Not a framework the model invents, and not a rendering loop written from scratch: an actual engine with an actual scene format, because that's where the ecosystem's solved problems live. Physics, animation, audio buses, input maps, an export pipeline that produces a build. The agent needs the engine's CLI on its PATH and needs to be able to read what it prints when something is wrong.

Version matters more than it looks. Engine APIs move, and a model's training data is a snapshot of several versions at once. An agent working against an engine it can actually run will discover the mismatch in a second and correct it. An agent generating code blind will produce something plausible against a version that doesn't exist.

An asset pipeline that lands in the right shape

This is the least glamorous requirement and the most common failure. A generated sprite sheet is only useful if it arrives at the cell size the animation code expects. A generated model is only useful if its scale, axis convention and material slots survive import. Audio has to be in a format the engine's importer accepts, at a sample rate that won't be resampled into mush.

When these are wrong the failure is nasty, because it doesn't look like an asset problem. It looks like buggy animation code. A model staring at correct animation code and a broken animation has no way to see the cause, which is why the pipeline has to guarantee the shape rather than hoping.

A way to run the thing

The agent must be able to build and launch its own output, and read the result. Not "generate code and hope": actually export, actually load, actually collect the errors. Most of what goes wrong in generated games is invisible in source and obvious on load: a missing resource path, a shader that doesn't compile on the web target, an autoload registered twice.

Somewhere to publish

The pipeline should end at the artifact you actually ship. If the agent tests a desktop build and publishes a web build, it has verified the wrong thing: web export has its own failure modes (threading, memory limits, shader compilation) that a desktop build will never surface. Same build, tested and shipped.

Give it a machine, not a sandbox

The architectural decision that matters most is boring: one persistent machine per session, kept warm across the conversation, rather than a fresh container per message.

It matters because of what lives on disk between messages. The engine's import cache. Compiled shaders. Generated assets. The previous build's artifacts. With those in place, "make the jump snappier" is a two-second edit and a partial rebuild. Without them, every message re-imports every asset from scratch and the second change costs the same as the first.

Users forgive a slow first build; they were expecting a game to take a while. They do not forgive a slow tenth change, because by then they're in a loop and the loop is the product. A cold sandbox per message turns a conversation into a queue.

The mitigation for the obvious downside: a warm VM costs money while idle: is an idle timeout, plus a hard lifetime ceiling so a runaway build can't run forever. That's a configuration decision, not an architectural one.

Where the model actually matters

Having said all that: the model is not interchangeable. What separates a good one here is not raw code quality but one-shot coherence : getting a whole game's worth of interlocking decisions right on the first attempt, so that the physics, the level layout and the difficulty curve agree with each other.

Iterating your way to coherence is expensive when each round trip is a build. A model that produces a self-consistent first draft, even a rough one, beats a model that produces individually better files that don't add up. This is also why the strongest results come from genre pastiche: the model has a dense, coherent prior for what a 16-bit mascot platformer is, and coherence is exactly the thing that's hard to assemble piecemeal.

The shape of the whole thing

brief
  → session VM (engine + toolchain + agent, kept warm)
      → write project files
      → generate assets → import at expected shape
      → export web build
      → load in headless browser → boot / fps / console errors
          ↳ failures go back to the agent, not the user
      → publish to CDN behind the player's arcade subdomain
  → "the jump feels floaty"
      → same VM, warm cache, incremental rebuild

Nothing in that diagram is a research problem. It's an integration problem, which is why bigger models don't solve it and why the interesting work sits in the loop rather than in the box at the top.