Level design with agents
Building level-designer agents through adaptive execution
The premise
We worked with studios, designers, and developers to understand where agents can contribute to level design. The work is open-ended, iterative, and difficult to evaluate—even for experienced teams. We found that agents become useful when they are narrowed around the problem: a stable contract defines what must hold, while an iterative runtime carries feedback from one decision into the next.
Game teams are already building with agents
If you work in games, you have already felt the shift. Agents write code, build complex systems, produce assets, test ideas, and even take on problems at the edge of mathematics. Across game development, work that once took days can now happen in hours.
But some kinds of work have proven harder to hand over. Agents can help with them—sometimes substantially—without quite owning the outcome.
Level design, particularly in mobile games, is one of those areas. It requires deliberate decisions about difficulty, pacing, progression, and how players encounter each new mechanic. At the same time, it depends on qualities that are much harder to describe: whether a level feels satisfying, surprising, elegant, or simply fun.
Designing a level is more like navigating a vast, many-dimensional space than following a recipe. Layout, difficulty, pacing, mechanics, and visual rhythm all influence one another—and countless valid combinations can still fail to feel fun.
The path changes as you walk it
Watch a level designer work and the process rarely follows a straight line. They try an idea, play it, double back, preserve one part, discard another, follow a promising direction, and frequently reach a dead end. Progress depends on deciding which possibility deserves the next attempt.
That decision requires taste. The space contains countless playable levels, but many are dull, obvious, frustrating, or forgettable. Rules can eliminate what is broken. They cannot reliably tell you which direction is worth pursuing.
The space also changes with every discovery. A successful level teaches the designer something new about a mechanic, the player, or the game itself. That discovery changes what the following level should accomplish. Each good result redraws the map ahead.
Modern coding agents approach problems differently. Give one a goal and it works toward a solution. It can create the necessary tools, script a valid workflow, and help a designer complete the task faster. For producing one level, that can be remarkably effective.
But studios are not looking for the same production process to become 20% faster. They want to produce at an entirely different scale: hundreds of levels, perhaps thousands of variants, without placing a designer inside every iteration.
This is where the usual coding-agent workflow stops scaling. It is designed to reach an answer, not to navigate a changing space of possibilities over time. The studio does not need a faster journey along the same path. It needs a different way to travel.
Coding agents are built to reach an answer
Modern coding agents are powerful because they are broad. Inside an unfamiliar project, they can search the repository, inspect logs, browse the web, write scripts, and run tests. When the path is unclear, they can first understand the system or build the tools they need, then return to the task with a better route to a working answer.
This is a natural fit for software engineering. A feature works or it does not. A test passes or fails. The agent can explore freely, gather what it needs, and continue until it has something it can return as the answer. Repository navigation, file editing, and test execution are central to modern coding agents because they help the agent converge on that answer. (Anthropic, SWE-agent, OpenAI)
Level design does not have the same kind of finish line. The first successful level is not simply an answer. It changes what the team understands about the mechanic, the player, and the campaign. That new understanding changes what should be explored next.
Used as-is, a coding agent treats each brief as another problem to complete. It may produce a good level. It may build useful tools along the way. It may make the designer considerably faster. But the designer still carries the taste accumulated across attempts, remembers which directions led nowhere, and decides how each discovery should change the work ahead.
Giving the agent more tools and more context does not automatically solve this. The builders of these systems have found that models can lose focus as their context grows, and that large or overlapping toolsets can distract agents from efficient strategies. Their guidance is to preserve the smallest set of high-signal context and choose tools selectively. (Anthropic on context, Anthropic on tools)
The mismatch is not one of intelligence. It is one of orientation. A general coding agent is equipped to become whatever the next task requires. Producing hundreds of levels requires an agent narrow enough to remain with one problem as the problem evolves.
In this kind of work, focus is not a limitation. It is the capability.
Taste determines where effort goes
A level designer does not explore every direction equally. They dismiss some ideas immediately, test others briefly, and remain with a promising few. Taste is already at work before the finished level exists: it decides where effort should—and should not—go.
Research on chess expertise found a similar pattern. Stronger players did not succeed by examining dramatically more moves or searching much deeper. They recognized better moves earlier and spent their time on lines more relevant to the position. (Cognitive Science)
A general coding agent works differently. It keeps its options open, gathers useful information, and searches until it finds a workable answer. Applied to level design, that breadth can produce many valid possibilities. It does not provide a reason to invest in one direction and abandon another.
That is the purpose of narrowing the agent’s world. Not to reduce what it can imagine, but to make evidence from the game strong enough to shape its next attempt.
Successful discovery systems follow this pattern. AlphaEvolve generates many programs, but progress comes from evaluating them, preserving promising ideas, and building later attempts from what survived. Research into level-design agents similarly treats design as a sequence of changes whose results influence the next move. Selection shapes exploration. (AlphaEvolve, PCGRL)
For a level-designer agent, that selection could come from the game’s rules, the resulting playthrough, its place in the campaign, and examples the studio has accepted or rejected. These do not dictate the finished level. They help the agent recognize which directions deserve more attention.
The difference between a level generator and a level designer is not what they can produce. It is what they learn not to pursue.
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.
Sparse, then generic, then rejected, then shipped
Deterministic conversion preserves the bird, the fanned tail, the eye spots and the dark negative space. No gameplay yet.
The board solves, but it is still an isolated sprite. Gameplay was added without building a composition around it.
Density reaches the corpus, but the regular border and flat fill make it a reusable template rather than a level-specific composition.
Four keys and locks create activity, but the mechanic competes with the subject and the composition reads as assembled rather than authored.
Mechanics move to the periphery, the bird stays dominant, and connected groups create pressure without hiding the image.
Three studios. Three different bars for success.
We worked with three mobile game studios facing different versions of the same problem. One needed to turn playable but flat outputs into a complete production campaign. Another wanted generated levels to match its unwritten design language closely enough to withstand expert review. The third needed levels to preserve a visual idea while remaining genuinely playable.
Each studio defined success differently. We narrowed an agent around that definition, then let it create, play, evaluate, and revise its work until it satisfied the studio’s bar.
All three engagements succeeded.
Success, measured against each studio’s own bar
Field reports
Read how the work unfolded
Case study · 13 minMake loops, not flowsGenerating playable levels was the easy part for a studio. Getting designers to accept levels generated by a program, however, is not.
→Code on GitHubsynnada-ai/recurse-sdk
Case study · 12 minNo rulebook, no tellsWe created a level-design agent without a rulebook and asked the designer of the studio in question to spot the additions of the agent.
→Code on GitHubsynnada-ai/recurse-sdk
Method · 11 min