Karl Gluck
The founding thesis of Believer was that making the games players deserve requires a devotion to making them differently. In particular, we believed AI would be the most important technological shift for empowering creatives since the personal computer.
In principle, we were correct. In practice, we were very wrong.
Most of the roadblocks we’ve faced have been that our aspirations were far too dreamy for how nascent the technology was at augmenting the practical daily work of most game developers. One of our biggest roadblocks, though, has been the fundamental disconnect between our favorite AI tools and the Unreal Engine itself.
Bridging the Unreal ↔ LLM gap
Most of a UE project isn’t in text files. It lives in the binary assets and in-memory data structures that only a running editor understands. An agent can produce a clean compile and still be blocked the moment it needs to verify anything actually works.
Claireon is an Unreal Engine plugin that exposes an MCP server for structured access to live editor state, native APIs, Unreal assets, and engine internals. We use it daily with Claude Code at Believer, and today we’re open-sourcing it under MIT: github.com/believer-oss/claireon
We actively test against UE 5.5.4 but support other versions. The repo contains the core plugin, 600+ tools spanning everything from anim graphs to perf traces, the reliability infrastructure that keeps agent sessions alive across editor restarts, and the workflow scripts we use in-house.
Claireon has rapidly become the single most powerful tool in our AI toolkit, enabling most developers (even non-technical ones) to supercharge their core workflows in Unreal. It has been transformative for us at Believer, doubling our delivery into the game across its first three months, and continuing to accelerate the more we use it. We understand deeply that delivery is not the same as making our game better, which is why we play test our game relentlessly.
Claireon has been an enormous boon for us. We’re excited to share it openly with the hope that it helps all of us make better games.
A few important design choices
The tool surface is small. 600 tools would blow out any agent’s context. Inspired by Code Mode, an agent using Claireon only sees three tools: python_execute, tool_search, and proxy. This design saves tokens and round-trips while still providing full catalog access. Long output results spill to grep-able files on disk so an agent’s built-in tools can take over from there. The practical result is that typical daily usage by a Believer engineer fits inside a Claude Max plan.
Crashes are first-class. Unreal Editor is infamous for its instability, and writing code means recompiling the editor. Typically, either would disconnect the agent from the MCP server and require manual reconnection. In Claireon, a local proxy sits between the agent and the in-process plugin so the session survives. Inside the plugin you’ll find Structured Exception Handling, GC barriers, deferred operations, automatic undo transactions, save-state checks and more. None of this is glamorous, and all of it is the difference between a demo and dozens of agents running across real sprints.
The tool catalog is extensible. Any Unreal module can register its own MCP tools through a tool-provider interface, so proprietary asset types and studio-specific workflows stay in your environment without forking Claireon. Most studios have unique systems to handle things like VO, damage flows, character lifecycles, and world scripting. With Claireon, you can write new tools that manipulate these concepts without having to modify the plugin. The result is that updating the plugin doesn’t mean merging a bunch of custom code.
The merge button is human-only. The plugin-served /claireon:workflow drives long-running work through a 9-stage state machine: plan, refine, fracture, singleton-ize, loss check, sequence, implement+test, verify, and finalize. The agent seeks input at key checkpoints and never approves or merges its own work. Every workflow begins and ends with a human in control of requirements, design decisions, and verification.
Long work survives interruption. Workflow state is persisted as JSON on the branch, so any future agent session can resume it. This saves us from crashes, context compaction, merge conflicts, and shifting priorities.
The workflow is a markdown file, not code. The orchestrator that the agent follows is written as prose, and so is every stage it enacts. Forking or debugging it takes no frameworks or compilers. The agent runs the spec a human would read to do the same thing.
Burning down our tech debt
One of our prototype systems had been sitting in the “too expensive to remove” pile for about a year. The problem was that it was everywhere: code, config, assets, references, content folders, and downstream assumptions. Removing it manually would have meant weeks of coordination and churn. We paid the carrying cost for a year.
Then, I put Claude+Claireon on the job.
The agent (Opus) and I interactively planned the removal with a live Claireon connection. /workflow hardened the plan into ~40 stage-by-stage instruction documents that subagents could execute atomically without drifting or running out of context. It selected models based on how tricky each stage was: Sonnet for most, Haiku for CI watch, and Opus for architecturally tricky bits. Once I was confident in the plan, I let the agent loose for the weekend.
By Monday, there was a clean PR waiting for my review. Over the weekend it had traced dependencies, removed code and content, adjusted references, compiled, fixed bugs, authored and run regression tests with Untested, pushed a branch, watched automated builds fail, repaired the emergent issues, and repeated until everything was green.
This autonomous work removed 40,000 lines of code, deleted thousands of assets, removed 500MB from the repo, and resulted in no failing tests, no change in gameplay, and no disruption to work in flight.
Once finished, the agent asked for some manual cleanup to handle the parts that weren’t in reach of its existing tools. Because the tool catalog is extensible, it was straightforward to use /claireon:workflow to build those tools and invoke them interactively to wrap up.
A pluripotent interface for all our creative disciplines
Jesse Perring, one of our senior designers, uses Claireon for work that previously blocked on engineers. For Jesse, the agent is a comprehensive interface to the project, not simply a code editor. Much of a designer’s job is editing and manipulating assets, and that used to mean mouse clicks, copy-paste, and spreadsheets. Without bespoke tools from engineering, we had no way to test whether players would actually see items drop at the rates we wanted. Jesse built a gameplay event simulator on top of data Claireon extracted, ran it against configurable rulesets, and worked backwards from the crafting times he designed to the drop rates that would produce them. He then fed the simulation results into our backend so playtesters could jump to progression milestones without playing end-to-end. Claireon amplifies designer skills, it doesn’t replace them: “I had to go through event data line by line to show Claude some basic math/reasoning was incorrect. Staying skeptical helped.”
In another example, we are using Claireon as a makeshift narrative pipeline. Shankar Gupta-Harrison, our creative director and writer, does much of his narrative work in Notion. Normally, putting copy in-game would mean converting it into JSON or some other format and having a designer place it, or building a tool to do it. Instead, Claude reads the copy directly from Notion and injects it through Claireon into the correct places in the game. Shankar does not have a minute of experience working in the Unreal Editor. This is not going to be our production narrative pipeline, but it shows how quickly we can develop, test, and iterate on work in the game regardless of a developer’s skill level.
And by the way, Claireon has completely streamlined our localization process.
A foundation for our most ambitious ideas
Historically, the cost of experimentation was always what killed our most ambitious ideas, and nerfed our ability to fix what’s wrong with our game. In late winter, we realized our core progression system wasn’t working, and over the course of a day and a half we envisioned its entire structure. The problem was that we were adding numerous subsystems, changing a chunk of the core game loop, and doubling the amount of UI. With Claireon, a small team of engineers, led by Andrew Rudoi, was able to stub in working versions of all of this in less than a week. We were able to quickly test and validate the direction before committing to the pivot. Without Claireon this would have been a quarter-long effort.
Andrew built new Claireon tools along the way for Data Tables and Widget Blueprints. Those tools became immediately usable by the rest of the studio: “Adding those tools wasn’t a negotiation with a tools team, it was barely a detour from my work.” The tools an engineer adds in service of an effort become available for other engineers, designers, and artists alike.
Who Claireon is and isn’t for (for now)
Claireon is a great fit if you author gameplay systems in C++, run an MCP-capable agent as a daily driver, and use UE 5.5.4. Using source control with CI and tests is a bonus. It’s currently built for Git, which the workflow scripts assume. Retargeting to Perforce should be tractable.
Use of Claireon is not without some risk. Its python_execute runs unsandboxed, so a repo with untrusted contributors is a real concern. There is a possibility you may experience loss or corruption of local data, but this goes for nearly any use of coding agents. If working on a team, Claireon is best when paired with a merge-queue and strong CI guardrails.
Believer isn’t in the game tooling business. We make games. We have finally begun to see consistently transformative ROI making our game with AI and with Claireon in particular. We now want to share that with other studios, so we all can make better games together. That’s what players deserve. Please check it out.