Why We Build a Game to Test Our Own Perforce Agent

This is Part 6 of the “Agentic Game Dev” series. Part 1: The Manifesto → Part 2: The Framework → Part 3: Asset Validation → Part 4: Build Failure Investigation → Part 5: Pipeline Insights → Part 6: Dogfooding Our Perforce Agent → Part 7: Butter Up! Devlog #1 → Part 8: Butter Up! Devlog #2.

Perforce files are read-only until you check them out. Ask any game developer and they’ll tell you this in their sleep. Ask a general-purpose AI coding tool to change a file in a Perforce depot and it forgets: it reaches for Git muscle memory, tries to write, and either the edit fails outright or it strips the read-only bit and quietly desyncs your workspace from the server. That second failure is the dangerous one, because nobody notices until a submit goes sideways at the worst possible moment, usually the night before a milestone.

We know that failure shape well, which is exactly why we went looking for it on our own game.

We’ve been building a real game, Butter Up!, inside ButterStack itself. If you missed it, Devlog #1 and Devlog #2 cover how a walking stick of butter named Pat learned to jump, melt, and dive for the fridge before he turns into a puddle. It runs on the exact stack we sell to studios: a real Perforce depot (//sample-game), Jenkins for builds, Jira for the backlog, Unreal Engine 5 for the game. And the whole time we’ve been building it, we’ve been pointing our own Perforce agent at the same depot. This post is about why we eat our own dog food, and what it’s quietly teaching us about where ButterStack is headed.

Why build a whole game just to prove a tool

We sell software to game studios, so we asked ourselves an uncomfortable question a while back: do we actually use it the way our customers do? For a long time the honest answer was “sort of.” Our demo was a coherent fiction, seeded data that looked like a studio. It showed the UI fine, but it couldn’t answer the question a technical buyer really asks, which is “show me a real problem, and show me your tool catching it.”

So we started building a game we own, on a depot we never reset. Butter Up! is small on purpose, but every changelist in it is real. That gives us two things at once. It gives us a demo where “trace this build back to the changelist that caused it” has an actual answer. And it gives us a test rig for our agents, a place to trip over Perforce’s sharp edges ourselves, on a project we can never embarrass, before a customer ever hits them. If our own Perforce agent can’t keep our own depot sane, it has no business being anywhere near yours.

What the Perforce agent actually is

We built the agent read-first, and that word does a lot of work. Its center of gravity is observing and analyzing a Perforce system, not driving it. It knows the model that generic tools miss (depot to client to changelist, files read-only until p4 edit), so it reasons about your depot the way a technical director would, not the way a Git-shaped tool guesses.

Day to day it answers questions. Ask it the state of your workspace and it reports your connection, your ticket, your open files, pending and shelved changelists, reconcile drift, and who’s holding locks. Ask it to analyze the month and it surfaces submission velocity, CI-trigger health, and where the depot is bloating with large binaries. Ask “who’s blocking me” and it finds the exclusive locks and the people holding them. The heavy operations are there too (checkout, submit, shelve, reconcile, resolve), but they’re the supporting act, and they’re gated. It never obliterates without spelling out the consequence and asking by name. It prefers a shelve to a revert. It dry-runs a big sync before it runs the real one. It ships with a hard backstop that blocks server-lifecycle commands outright, because irreplaceable art and audio deserve that caution.

Here’s the line I want to land, because it’s the whole philosophy: the agent doesn’t touch your game. It reads your pipeline and tells you the truth about it. Diagnosis, not rewriting. That’s a deliberate choice, and it’s the same one I’ve been making since the first thing I wrote about ButterStack: I’m not here to tell you how to make your game.

Three things it does for us while we build Butter Up!

The first is keeping the version-control layer under the game healthy. The Perforce agent doesn’t author Pat’s jump code, that’s other agents and humans. Its job is the depot the game is built from: watching the Perforce-to-Jenkins handoff, flagging when a trigger looks unhealthy, catching drift before it becomes a broken build. It’s the observability under the pipeline, not a hand on the gameplay.

The second is fewer merge and version conflicts. A butter platformer is still full of Unreal .uasset and .umap binaries moving through Perforce with exclusive locks, and locks are where small teams bleed time. “I can’t check this out, someone has it locked, who, and are they even still working on it” is a five-minute Slack detour every single time. The agent answers it in one question, so the interruption never happens.

The third is the quiet one, and it’s the one I care about most: cognitive load. Perforce is powerful and it is genuinely weird if you didn’t grow up in it. Every time someone on the team has to stop making a game to go remember whether it’s merge-down-then-copy-up or the other way around, that’s creative energy spent on plumbing. Handing those questions to an agent that actually understands the plumbing keeps people in the fun lane, the one where they’re building a game instead of fighting the tool that stores it.

The part that took us by surprise: using it made it better

Before we trusted the agent on Butter Up!, we validated it against a live Helix Core server with real assets and roughly 8,700 changelists of history. Running it against a real depot, instead of just reading the Perforce docs, is what caught the bugs. A structured-output flag that silently wasn’t structured. A describe command whose optional argument we’d been passing wrong for so long it had become a latent bug copied straight out of our own production code. None of that showed up in theory. It showed up the instant real data flowed through.

Each of those corrections folded straight back into the agent. That’s the loop in miniature, and it’s the loop I’m most excited about: point the agent at reality, let reality correct it, ship the correction. Butter Up! is just our reality. As we help other studios with their pipelines, every one of them is a different reality, a different server topology, a different asset mix, a different set of sharp edges we haven’t hit yet.

Here’s where we want to take that, and I’ll be straight that this is direction, not a finished feature: we want those hard-won lessons to compound. When the agent learns something running against a real studio’s pipeline, we want that lesson, anonymized and stripped of anything that belongs to that studio, to make the agent better for the next studio, and the one after that. A self-improving tool that gets sharper across every depot it touches, without any one studio’s code or content ever leaving their control. The first public step is out: our Perforce agent, the first of a series of gamedev agents, is open source at github.com/ButterStack/gamedev-agents, MIT licensed. What we learn running this stuff in production folds straight into it, and real-depot reports from other teams will make it better for everyone.

What we’re actually building

Strip away the butter and the flywheel and here’s the plain-English version. ButterStack is becoming an agentic observability layer over the whole game-dev pipeline. Perforce, Jenkins, Jira, asset tracking, builds, all of it readable together, with agents on top that read across the seams and hand you the answer. The Perforce agent is the first one because Perforce is where the pain is loudest, but it’s the same shape as the agentic workflows we’ve been writing about all series: the agent reads, the agent surfaces evidence, the human decides. The connective tissue is the hard part. The agent on top is what that tissue grows into.

We’re not here to touch your code

That’s the promise, and building our own game is how we keep ourselves honest about it. We stay out of the creative lane. We put agents to work on the boring, version-controlled plumbing underneath it, so they can diagnose the problems you shouldn’t have to, and you can get back to shipping and iterating. If you’ve ever lost an afternoon to a lock nobody remembered holding, or a build that broke for a reason buried three tools deep, that’s the pain we’re building for.

If any of this sounds like your studio, I’d genuinely like to hear which part hurts most.

Get started with ButterStack

Thanks!
Ryan L’Italien
Founder and CEO of ButterStack

Want to see what pipeline observability looks like? Try ButterStack free and connect your first integration in minutes.

Or just email me at: ryan@butterstack.com.