AI in Your Pipeline, Not in Your Game

This is Part 1 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 has a command called p4 obliterate. It does exactly what the name says: it removes files and their entire history from the server, permanently. Not “delete,” which version control can undo. Obliterate erases the record that a file ever existed, which is the one thing version control exists to prevent.

I spent years as a Solutions Engineer at Perforce working with game studios, and I learned early that nobody says that word casually. A game depot is not a code repo. Next to the code sits every texture, every animation take, every recorded line of dialogue, years of work from artists who may not even be at the studio anymore. A lot of it cannot be regenerated from anything. The depot is not a backup of the game. In a very real sense, it is the game.

I think about that command a lot lately, because the tools industry is busy wiring AI agents into everything that touches a game pipeline, and I am one of the people doing the wiring. Agentic AI is arriving in game development whether studios are ready for it or not. So before the hype writes the rules, I want to put mine on paper.

The whole thesis fits in the title: AI in your pipeline, not in your game. This post is what that sentence means, and where the hard lines are.

What “agentic” actually means (and what it doesn’t)

The word “agentic” is doing a lot of marketing work right now, so let me take that work away from it.

An agent is a program that can take multiple steps toward a goal without a human driving each one. It reads something, decides what to look at next, calls a tool, repeats, and reports back. That is the entire trick. It is genuinely useful, and it is nowhere near “AI that does your job.”

Two very different products hide under the buzzword. There are agents that want to work in your game: generate the level, write the gameplay code, restyle the art. And there are agents that work under your game: read the pipeline that builds it and tell you the truth about it. ButterStack is the second kind, on purpose, and this series is about the second kind.

Here is why the second kind is worth your attention. A studio’s pipeline is not one system. It is Perforce holding the binary assets, Jenkins running builds on machines that can’t move to the cloud, Jira holding the plan, the engine producing cook logs, Steam and the console portals each with their own upload tooling, and Slack or Discord carrying the alarms. Those tools do not talk to each other. Every “who broke the build?” is a human carrying evidence between six tools by hand, usually late, usually the same human every time.

That assembly job, walking the seams and laying the evidence out in one place, is exactly what agents are good at and exactly what burns engineers out. So that is the deal: the agent reads across your pipeline and surfaces evidence. A person decides what to do about it. The agent reads, you decide. If you take one line from this post, take that one.

What it must never do

This is the half most AI writing skips, and it is the half I care about more. Four lines, and they are design decisions, not legal disclaimers.

It must never act on a shipping build without a human. A console cert failure costs weeks. Game rollbacks are not web rollbacks; there is no thirty-second redeploy, and “rolling back” usually means shipping another build through the same pipeline that just failed you. Anything on the path to a cert submission or a shipping build stays a recommendation until a person says go.

It must never present a guess as a verdict. An agent that names the wrong changelist with total confidence is worse than no agent, because it sends your engineer down the wrong road at speed. The standard is evidence with sources: what changed, when it landed, what it touched, with links so you can check. Verdicts are the human’s job.

It must never touch the creative work. No rewriting gameplay code, no regenerating assets, no submitting to the depot on a hunch. I said this in the first thing I ever wrote about ButterStack and it has not moved: I am not here to tell you how to make your game.

It must never run an irreversible command on its own. Our own Perforce agent ships with a hard block on server-lifecycle commands, and it will not go near an obliterate without spelling out the consequence and getting an explicit yes. That is not caution theater. That is the memory of every admin I ever watched hover over the Enter key.

Part 2 of this series turns these lines into a working framework, including a trust spectrum that runs from “suggests in a comment” to “fully autonomous.” The short version: for anything that matters in game dev, stay at the levels where a human approves the action. The rest of the spectrum is for people whose mistakes can be rolled back.

Why now

Fair question: game pipelines have been fragmented since long before I got into this, and “read across the seams” was always the answer. Why is it only becoming a product now? Three specific things changed.

Models learned to read the artifacts. A ten-thousand-line Unreal cook log, linker errors sprayed across three modules, a flaky test’s stack trace. This is unstructured text that no regex ever tamed, and reading messy text is the thing large language models are actually good at.

Tool access got standardized. The Model Context Protocol gave agents a common way to be handed a tool, whether that tool is a Perforce connection, a Jenkins API, or a Jira project. Reading across many tools used to be a systems-integration project for every vendor and every studio. It is turning into a socket you plug into.

Keeping the evidence became cheap. Object storage costs so little now that retaining every build log, every event, and every artifact is a rounding error. The record an agent needs to read can simply exist, instead of getting rotated away to save disk.

Here is what did not change: models are still confidently wrong sometimes. Point a generic coding agent at a Perforce depot and watch it reach for Git muscle memory on files that are read-only until checkout. We caught real bugs in our own agent only when we ran it against a live server, a story that gets its own post later in this series. The technology arrived, and its failure modes arrived with it. That is exactly why the lines in the previous section are load-bearing.

What ButterStack is

ButterStack is the visibility layer under everything I just described. It connects the tools a studio already runs, Perforce, Jenkins, Jira, Unreal and the rest, and reads them together into one timeline, so commits, builds, tickets, and assets stop being separate tabs. On top of that sit the agents. The first one most people meet is the Build Investigator: when a build goes red, it walks the Jenkins log, the changelists that landed since the last green build, and the assets they touched, then hands you a probable root cause with the evidence attached. You read it, you make the call. We built the connective tissue first for a reason. An agent can only be as trustworthy as what it can see, and giving it honest sight across the whole pipeline is most of the work.

Holding the line

We did not write this post and then go looking for reasons to believe it. We built a real game inside ButterStack, a small platformer called Butter Up!, on a real Perforce depot with Jenkins, Jira, and Unreal Engine 5, and we point our own agents at it every day. Before we trusted our Perforce agent near anyone else’s depot, we validated it against a live server with roughly 8,700 changelists of history, and reality corrected it in ways the documentation never would have. Dogfooding is cheap to claim and expensive to fake, which is why the back half of this series is receipts.

Here is the road ahead. Part 2 is the framework: the anatomy of a pipeline agent and the trust spectrum. Parts 3 through 5 walk the three loops we think studios should actually build or buy: asset validation, build failure investigation, and pipeline insights. Part 6 is the story of our Perforce agent eating its own dog food, and Parts 7 and 8 are Kevin’s devlogs of Butter Up! taking shape on the exact stack we sell.

I have spent about twenty years building software, and the years around game studios convinced me that the gap between a calm team and a burned-out one is usually visibility, not headcount or talent. I think pipeline agents are the fastest road to that calm, but only if the people building them hold their lines in public, where customers can point at them later. So here is mine, one more time, where you can hold me to it.

AI in your pipeline, not in your game. The agent reads, you decide.

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.