AI is a tool, not a creator.
A model recombines what already exists; the genuinely new comes from people. Grounded in our Unreal MCP work on Ezekiel, the case for AI that removes drudgery so humans spend their hours on the part only they can do.
The most useful thing AI has done for the game studios I work with, NC Gaming among them, is boring. It is not a brilliant idea. It is not a finished level. It is the return of an afternoon that used to disappear into busywork, handed back to a person who can now spend it on the part of the job that actually needs them.
That sentence is unfashionable from both directions. The boosters want to tell you the model is a creative partner that dreams up worlds. The skeptics want to tell you it is a slop machine coming for every developer's seat. I have shipped games for twenty years and I have spent the last stretch building AI tooling that real studios use every day, and I think both camps are wrong in the same way. They have confused a tool with a creator.
A tool is a thing that makes a person's work easier. A hammer does not want to build a house. A compiler does not have an opinion about your architecture. AI is closer to the compiler than to the carpenter, and once you hold it that way, the fear and the hype both quiet down and you can see what the thing is actually for.
§ 01 The drudgery is the point
Most of game development is maintenance, not invention. It is not the part you imagine when you imagine game development: not the flash of a character's design or the moment a fight finally feels right. It is the long tail of work around those moments. Wiring the same kind of system for the fortieth time. Re-reading a design doc to remember which faction controls which region. Checking that an encounter you are building does not quietly break a rule buried in 13 design documents that someone set eight months ago. None of that is creative. All of it is necessary. It eats hours.
This is where a tool earns its place. Not by having ideas, but by removing the friction between a person's idea and the build. When a developer can ask a grounded agent "does this encounter violate any of our limits" and get a real answer in seconds instead of opening four documents, the hour they save does not vanish. It moves. It goes to the part of the work that needed a human the whole time.
The goal was never to make the machine think. It was to stop making the person look things up.
I want to be precise here, because precision is what keeps this out of the slop argument. The value is not that the tool produces more. It is that the people produce the same quality of work in less time, with fewer of the small mistakes that come from being tired and doing the boring part for the fortieth time. The output is more human, not less, because the humans had more room to be human.
§ 02 Why a model can't create
A model cannot truly create. That is the load-bearing claim of this whole piece, and I want it to land as something hopeful rather than a knock on the technology. A model is trained on what already exists, so everything it produces is a recombination of patterns it has already seen. That is not a flaw someone will patch in the next version. It is what the thing is.
Think about what training data is. It is a record of the past. A model learns the shape of everything humans have already made and gets very good at producing more things that fit that shape. Ask it for a steampunk city and it will give you a competent steampunk city, assembled from ten thousand steampunk cities it has read. What it cannot do is want a city. It has never been cold. It has never owed anyone rent in one. It has no stake, no taste formed by a life, and nothing it is trying to say. Creation, the real kind, starts from a person who has something they need to get out and into the world.
The genuinely new always comes from a human being. A designer who feels that combat in their game should reward patience instead of speed, and bends the whole system toward that conviction. A writer who has carried a particular kind of grief and puts it into a character so exactly that a stranger recognizes it. Those are not recombinations. They are origins. No amount of training data contains them, because they were not there until a person made them.
So when people worry that AI will flatten games into the same gray paste, they are right about one thing and wrong about another. They are right that a model left to originate the creative core will give you the average of everything that came before. They are wrong that this is inevitable. It is only what happens when you ask the tool to do the one job it cannot do. Point it at the work it can do, and the human stays exactly where the value is.
The model is the best apprentice you have ever hired and the worst artist. Hire it for the first thing.
§ 03 What we actually built on Ezekiel
This is not theory for us. At Marathon Variety we work as executive producer on Ezekiel: Noa and the Automaton Urbis, a steampunk-cyberpunk third-person RPG that NC Gaming is building in Unreal Engine 5.7. Alongside the production work, we built a custom Unreal MCP: a local server paired with an editor plugin that connects AI coding agents to the actual game.
The thing that makes it work is also the thing that proves the point of this article. A generic assistant relearns the project on every prompt and contradicts the canon as often as not. Ours does the opposite. It loads the studio's own Markdown as canon. For Ezekiel that is 13 documents, roughly 62,000 words: world canon, characters, factions, regions, visual and audio direction, the demo implementation, the combat-framework reference, and the Moral AI design. The agent already knows that a demo encounter caps at five to seven soldiers and two agents. It knows which Blueprint systems run the demo level. It does not have to be told twice.
Read that closely. The canon is the creative core, and it was written by people. Every word of those 62,000 came from the team at NC Gaming deciding what their world is. The tool does not invent any of it. It just stops the agent from forgetting it. The humans authored the world. The machine's job is to stop relearning it on every prompt and to stop arguing with it.
That is the whole relationship in one frame. The people make the world. The tool remembers the world so the people do not have to keep re-explaining it to a forgetful assistant. Nobody at the studio has handed creation to a machine. They have handed it the part of the job that was wasting their creators' time.
§ 04 The rails are the studio's, not the tool's
The safety model is where the philosophy turns into engineering, and it comes down to one rule: every Unreal operation the agent can perform is a typed, validated, logged tool, drawn from a surface of 132 safety-classed tools across 35 categories. There is no open-ended script executor in the default path. The agent never writes a .uasset or .umap file directly. Destructive actions need an explicit confirmation; deleting an actor requires repeating its exact path back. A deterministic mock runs alongside live Unreal, so a change can be tested with the editor closed. Raw Python and console commands are off by default.
Look at what that list actually describes. It is a tool on rails, and the humans built the rails. Every boundary encodes a decision the team made about how their project should be touched. The agent is powerful inside that frame and powerless outside it, on purpose. It accelerates the team's intent. It does not get to have its own.
The server is only half of it. We also built the agent that rides the rails: a specialized Unreal Engine agent, a behavior contract that makes a coding agent act like a careful Unreal developer instead of a generalist with editor access. It inspects before it edits. It treats the MCP as the authority on editor and asset state instead of guessing from filenames. It preserves the designers' and artists' work in the worktree, never hand-edits a binary asset, and verifies through the strongest path available before calling anything done. And when a check cannot run, it says UNVERIFIED instead of bluffing. We hold it to all of that with an evaluation harness, including a corpus of prompt-injection attacks it has to refuse.
This is the opposite of the slop story, and it is the opposite by design. Slop happens when a model is handed the wheel and asked to originate. We never hand it the wheel. There is a number we are quietly proud of in that case study: zero .uasset or .umap files written directly by the agent. Zero. The creative artifacts of the game are authored and owned by people, full stop. The tool works in the space around them.
A good tool is powerful inside the lines and helpless outside them. That is not a limitation. That is the whole design.
§ 05 Assist, not replace
The help is not abstract; it shows up as time. Iteration gets faster, because the agent does not have to be brought up to speed before it is useful. There is less yak-shaving, because the boring lookups and the boilerplate are absorbed. There are fewer canon contradictions, because the tool flags a conflict, a demo encounter slipping past its cap of five to seven soldiers and two agents, before an edit lands rather than after a reviewer finds it three weeks later.
Add those up and you get the thing that actually matters, which is time. A designer who is not spending the morning cross-referencing documents has the morning to design. A writer who is not babysitting a forgetful assistant has the afternoon to write. The tool did not make the game better by being creative. It made the game better by giving the creative people more of the only resource they were ever short on.
That is what "assist, not replace" means in practice. Not a slogan. A redistribution of hours away from drudgery and toward the work that only a person can do. The studio's headcount did not shrink. Its capacity to do the human part grew.
§ 06 The new comes from people
The new always comes from people. On Ezekiel, every one of the 62,000 words of canon was written by NC Gaming's team, not by the tool; the machine has authored none of it. I started building AI tooling because I was tired of watching talented people spend their best hours on their least valuable work. That is still the whole of it. The tool is not a collaborator with ideas of its own. It is a very fast, very patient assistant that has read everything and decided nothing. The deciding is ours. It always was.
There is a version of the AI conversation that makes people smaller, that frames every advance as one more thing the machine took. I do not believe that version, and the work does not support it. Everything the machine is good at is downstream of something a human already made. The training data is our past. The canon is our decisions. The rails are our judgment. Strip the humans out and there is nothing left for the tool to be good at.
Creation comes from people. The genuinely new, the thing that was not in any dataset because nobody had made it yet, has only ever come from a person with something to say and the room to say it. The best tools we can build are the ones that give people more of that room. That is what we are building. That is what it is for.
§ FAQ Questions we get about AI on Ezekiel
These four questions come up most when studios and developers ask how we use AI on a real game like Ezekiel. The answers come straight from the build: the 13-document canon, the 132-tool safety surface, and an agent that writes zero game files.
Can AI actually create something new?
A model recombines patterns from its training data, which is by definition a record of what already exists. It can produce things that are new to you, surprising, even useful. It cannot originate the genuinely new the way a person can, because it has no stake, no taste formed by living, and nothing it is trying to say. True creation, the part that did not exist anywhere before, comes from human beings. The tool accelerates the work around it.
Will AI replace game developers?
Not the ones doing the human work. The drudgery a developer wants gone, relearning canon, wiring the same boilerplate, hunting contradictions across documents, is exactly what a grounded tool absorbs. The design, the story, the feel of a fight, the taste calls, those stay with people. On Ezekiel the agent never originates the game. It accelerates a team's intent and gives them back the hours.
How does grounding an AI agent in a studio's canon help?
A generic assistant relearns the project on every prompt and contradicts the canon as often as not. The Ezekiel MCP loads the studio's own Markdown as canon, 13 documents and roughly 62,000 words, with an authority hierarchy for conflicts. The agent already knows the rules instead of rediscovering them, so it stops arguing with the world the humans authored and starts moving inside it.
Is using AI in game development the same as AI slop?
Slop is what you get when a model is asked to originate the creative core and nobody good is steering. That is not how we use it. On Ezekiel the creative core, the canon, is authored by people. The tool sits on rails the studio set, every operation typed and validated and logged, destructive actions gated. It removes drudgery so people spend more time on the parts only people can do.
Marathon Variety is Mark Laursen and Amber Sutera. We work as executive producer and AI engineer with studios building real games. The Ezekiel work is written up in full as a case study. If this is the kind of help your team needs, say hello.