The claim · agents cannot own level production

They said agents can’t design production-grade puzzle levels. Ours ship hundreds.

Not a copilot and not a level generator — a production loop that composes campaigns, simulates every candidate, reads the playthrough back, and improves the next batch without a designer reviewing every board. We build the loop; the studio ships the game.

~120 levels shipped and climbing · 90% acceptance · expert detection at chance

Build this for my game → Explore the field reports →

Engagement: hit mobile puzzle game ·3 posts

Start with the part you don’t believe

Three ways into the work

One system, three field reports. Pick the question that matters most to your studio — the whole engagement is written up as it happened.

Playable Was the Easy Part

The whole arc: a studio arrives with playable-but-flat levels from their own agentic workflow; a first review rejects three of four; the bar rises every time it's cleared — until a full campaign ships.

the story · can it learn?

No Rulebook, No Tells

The blind test as engineering: caught 14 of 20 in twenty minutes, a physics model that was wrong twice, and the five days that took an expert's detection rate to a coin flip.

the proof · would you catch it?

You Can’t Design What You Can’t Solve

The method: a level is art, play, progression, and product pressure at once — and the agent only improved when it stopped generating boards and started editing one, gate by gate.

the method · how does it work?

The last manual bottleneck is the product itself

The uncomfortable gap

Before we built any of this we spoke to more than ten people who actually make mobile games — studio founders, level designers, product managers. They told us the same thing, in nearly the same words.

Everything around the game had gotten faster. Engineering had copilots. Art had generators. Marketing had more testing capacity than it knew what to do with. And level production — the one discipline that decides whether a player stays, churns, or pays — still scaled exactly the way it did before any of it: by adding people.

“AI might make designers 20% faster. It will never run level production.”
What we heard, repeatedly, before the engagement

Several of them had already tried pointing an agent at it. Every one of those attempts had stopped in the same place, and none of them believed the rest was possible.

We are not a game studio and have no ambition to become one. We are an AI infrastructure company. We build loops — and this was a domain where the loop did not exist yet.

the gapautomation across game development

Three disciplines accelerated, one untouched

Engineering

Copilots, tests, refactors, prototypes.

Accelerated

Creative

Concepts, variations, production assets.

Accelerated

Marketing

Ads, audiences, localization, testing.

Accelerated

Level design

One designer. One board. One bottleneck.

Still manual

The uncomfortable gap. The one discipline that determines retention is the one still priced in headcount.

A coding agent can design a level. That was never the question

The real question

Give an agent your tools, a brief, and a designer’s feedback and it will help with the next iteration. Useful — but the human is still the loop. You get roughly 20% more leverage for the same design team, not a new production model. The question is what stands between that and a system that owns the output.

the forkcopilot · versus · production loop

Two ways to put an agent on level design

Agent inside the designer’s loop

~20%

The agent drafts, the designer reviews, the agent revises.

A useful tool — and the same designer still sits in the critical path of every level.

Result · ~20% more output, same bottleneck.

Agent owns the production loop

~120

Generate hundreds, continue the campaign’s flow, watch how players move through the funnel.

Turn that evidence into the next batch, at production scale.

Answer · yes, when the loop is engineered.

The question we tested. Not whether an agent can draft a board — that was settled — but whether it can own the loop that turns boards into a campaign.

The job

A studio hand-crafts its levels because resistance is the product: a level has to be figured out, not just cleared. Their own LLM pipeline already produced levels that loaded, validated, and exported cleanly — and played flat. Every board slid apart in a few obvious moves.

Solvable is a floor, not a bar. The bar is a human expert who can't tell your levels from theirs.

That became the acceptance test, fixed before any engineering: shuffle 20 generated levels into 20 production levels and let the studio's own designer mark the machine's work. Success means his detection rate is statistically indistinguishable from guessing.

the domainlevel 72 · shipped campaign

A board in the studio's own schema

The product. A real shipped board — cell geometry, the four pixel-pipe footprints and the central key read from the campaign’s audit record. Pieces, mechanics and objectives in the game’s native format — exported as board.json, loaded straight into the studio's editor.

The loop, for this domain

Actions · instruments · truth

Loop engineering means building the domain around the reasoning model. For level design that world is:

Actions — edit tiles, place pieces and mechanics, export board.json in the studio's own schema.
Instruments — a simulator that replays every candidate; feature extractors measuring each board against 100 production levels (solve length, symmetry, dead ends, opening pressure).
Truth — certification gates with thresholds learned from the corpus, and behind them the blind test: a human expert trying to catch the machine.

the mechanismreason → act → observe → evaluate → ⟲

The loop, keyed by stage

reasonchoose the next promising move from measured state

actedit tiles, place mechanics, export the schema

observethe simulator replays the board and reports

evaluatecorpus-derived gates pass, review, or fail it

Causality, not sequence. A failed gate names what's missing; the next reasoning step starts from that measurement, not from a fresh guess.

recorded runlevel 249 · rev 4

One revision through the loop

reasonopening too loose — add pressure near the goal row

actedit 6 tiles · re-export board.json

observesimulate → 31-move solve · 2 chokepoints

evaluate✕ opening-pressure 0.42 < 0.55

reasonpressure fails at the mouth, not the row — narrow the mouth

evaluate✓ opening-pressure 0.58 · all gates pass

Worked example. The same trace format the homepage plays — two passes through the loop, one failed gate, one shipped fix.

Every level has a job. The sequence is the design.

The loop in practice

A production system does not emit a hundred disconnected boards. It gives each level a job, then makes that level do it — and the revisions are not a straight line. The peacock below is the clearest record we have of one level being made to do its job: five stages, four revisions, and two rejections that came from a human, not a gate.

Frozen pixelized peacock source art — **Stage 0 · admit artRecognizable source**
Deterministic conversion preserves the bird, the fanned tail, the eye spots and the dark negative space. No gameplay yet.

**55.6%**occupied
8colors
Freeze the art

First playable sparse peacock level — **Stage 0 · admit artRecognizable source**
Deterministic conversion preserves the bird, the fanned tail, the eye spots and the dark negative space. No gameplay yet.

**55.6%**occupied
8colors
Freeze the art

the outer loopship → observe → recompose → ↻

Then the campaign reads the players back

ship the sequencea batch that encodes an intent: teach, practice, pressure, near pass, relief

read the playerswhere did they retry, exit, recover, and convert?

find the disagreementthe sequence shipped with an intent; performance shows where reality disagreed

change the next batchadd a bridge before the friction spike, change the mechanic mix, move the test, preserve what worked

Player behavior → next progression ↻ That disagreement is the input to the next hundreds — generated and certified without a human translating every signal into every edit.

What happened

The engagement is written up in full in the three posts below; the short version spans three moves.

Deconstruct first, prompt later. Before generating anything, the agent's world was built by measuring the studio's hand — 100 production levels reduced to the features a designer feels but hadn't named. The first review still rejected three of four levels, and the physics model behind the simulator turned out to be a hypothesis that was wrong twice. Each miss became a gate.

The bar moves every time you clear it. Early wins exposed the next tell: levels that solved cleanly but sat outside the corpus on symmetry; art that read as noise; openings without pressure. The agent changed from a generator into an editor — revising one board repeatedly until art, play, progression, and product pressure told the same story. The peacock that finally shipped took five stages and four revisions.

Rejected generated coral reef level — **Rejected**“Coral reef” became noisy color fields without a legible reef.

Rejected generated hot air balloon level — **Rejected**“Coral reef” became noisy color fields without a legible reef.

Then the lineup. Round one, the designer caught 14 of 20 in twenty minutes. Round three, five days and three physics models later, his hit rate met his false-positive rate.

fig 01engagement · headline numbers

From caught to indistinguishable

14/20caught in round one — in twenty minutes

3physics models until the simulator told the truth

5 daysfrom caught to chance-level detection

90%acceptance rate in production operation

Fig 1. Numbers from the blind-test engagement; full context and method in the posts below.

fig 02blind lineup · rounds 1–3

Detection rate by round, against chance

chance · 50%

70%

100%

58%

round 1
screenshotsround 2
played in-engineround 3
played

Fig 2. Percent of each lineup flagged as machine-made. The round-2 spike — every machine level unsolvable in-engine — was the most useful failure of the project. Round 3 is not significantly above chance (p ≈ 0.12).

fig 03deconstruction · feature space

Where generated levels sit inside the studio corpus

corpus range (100 production levels)agent level

solve length

mirror symmetry

dead-end count

Fig 3. The tell the designer felt but hadn't named: levels that solved cleanly yet sat outside the corpus on one feature. Out-of-band boards go back through the loop.

Can AI design good mobile game levels? Definitively, yes.

The verdict

Can an agent design good mobile game levels? Definitively, yes — but not by generating one level and waiting for a designer to fix it.
What the engagement settled

The system plans a progression, generates and certifies against gates learned from the studio’s own corpus, observes what players do, and updates the next batch. The designer sets the intent; the loop carries it at scale.

The bottleneck was never the drafting. It was that “good” lived only in a person’s head.

What transferred

Level design was the domain; the discipline is portable. Three things we'd tell you to steal:

lessonsportable across domains

The loop-engineering takeaways

Fix the acceptance test first

A human expert trying to catch you bends every decision toward what he can see that you can't measure yet.

The simulator is the truth layer

Nothing ships on plausibility. When the physics model was wrong, the gates were wrong — so the physics became the work.

Regressions teach the most

Every failed gate named a feature the corpus knew and the agent didn't. The bar rising is the system working.

Portability. Swap the simulator and the schema, keep the discipline — the same loop structure runs query optimization, QA, and model training.