What we need from your engine

Playthrough starts in the engine, not in a slide about agents.

If a studio wants agents that can play its game, produce matches a designer can reopen, and eventually become language modes, opponents, or other player-facing experiences, the first question is not which model we use. The first question is whether the build can tell an agent what moves are legal right now and let it take one of those moves through the real engine.

That interface is the foundation for everything that comes later.

Why the engagement starts here

Games become difficult to reason about when rules interact. A paper design tells you what should happen, a few internal playtests show what happened in a handful of cases, and scripted bots can cover paths you already anticipated. None of those gives you a system that can continuously play the actual game and produce matches a designer can inspect.

We design agents with the studio for that specific game. They play against the real rules, make different decisions depending on what happens, and produce matches the engine actually ran. A designer should be able to open one of those matches and know that every action in it was possible in the build.

For that to work, the agent needs a way into the game that is deeper than the rendered frame. It needs access to the same underlying machinery the game already uses to determine whether a move is possible and to apply it.

The legal-action interface

We think of the legal-action interface as a door, not a bot.

At any moment, the game already knows what the player can do: this unit can move here, this card can be played, this shop action costs this much, this ability is on cooldown, this target is out of range. The UI presents some version of those choices to a person, but underneath it the engine is maintaining the actual set of valid actions.

Agents enter through that same door. A scripted agent, learned agent, language-driven agent, or eventually a vision-driven agent all need to inspect enough state to make a decision, understand which actions are valid, choose one, and submit it. The engine then accepts or rejects the action and remains the authority over what happens next.

That distinction matters because an agent that cannot see what the game will accept is guessing, and an agent that cannot submit its move through the engine may be describing a game rather than actually playing one. When every kind of agent uses the same interface, the models can change without changing what counts as play.

Why we do not start with pixels and clicks

There is an obvious alternative: point a model at the screen and have it click as though it were sitting at a monitor. That is attractive because it can appear to require very little engineering work, but as the primary integration it gives up several properties that matter for design and QA.

You no longer automatically know that every attempted action corresponds to a move the engine accepted. A UI change can break behaviour without the game itself changing, and running thousands of games becomes much more expensive when every agent has to drive a client built for a person. Most importantly, the resulting matches become harder to trust.

That does not mean vision is unimportant. We expect models to increasingly understand games from what they see, much as people do, and the rendered frame can become another useful input to an agent. But seeing the game and acting in the game are different problems: a vision model can look at the frame while the action it chooses still goes through the same engine-level interface.

The same principle is why we do not begin by replacing the game with a thinner simulation or putting a generic bot on top of the title. Those can be useful tools, but they are not substitutes for playing the build your players will actually meet.

What this opens later

Once that interface exists, the space of possible agents gets much larger.

One direction we are interested in is JEPA-style models. Rather than learning by predicting every pixel of the next frame, these models learn representations of how a scene changes over time. Video versions can learn structure from sequences: where objects move, how situations develop, and which parts of a scene are worth predicting.

Games are unusually good environments for this kind of learning because the engine already knows much more than the frame reveals. A match contains positions, events, actions, timing, outcomes, and often replay or telemetry data. Those traces are the engine’s own record of what happened, which makes them useful both for training models and for helping designers find the moments they care about.

The architecture still stays the same. A future agent may look at the screen, reason over several possible futures, or accept an instruction in language, but when it decides to act it still submits a legal move to the game.

That is why the first integration matters beyond automated playtesting. Language control, queue opponents, phone modes, and vision-driven agents should not require four separate ways into the client. They can all sit on top of the same door.

What a technical director needs to make available

We do not need a new game. We need the current game to expose a few things it already knows internally.

The agent needs enough state to make a decision. That does not mean a dump of everything in memory, and it does not mean only the picture on the screen. It means enough structured information to understand the situation it is acting in, along with a way to ask which actions are currently legal and submit one of those actions back to the engine.

The build also needs to run without someone sitting at the controls. Ideally this is the same packaged artifact QA and certification already exercise, rather than a special version that only works inside the editor. Each run should carry enough identity to trace it back to the build, configuration, seed, and relevant tunables that produced it.

When the run is finished, someone on the team also needs to be able to open it again through a replay, demo, deterministic rerun, or equivalent mechanism. This part is easy to underestimate. If the only output of automated play is a score in a database, you have created another dashboard; the more useful unit is the match itself, because a metric should lead a designer back to something they can inspect.

The same applies to failures. If the engine throws, a provider fails, or an agent falls back to unintended behaviour, that should be visible rather than quietly becoming another number in the dataset.

A few additional pieces make the system cheaper to operate once this loop works. Known seeds or deterministic reruns make matches reproducible, versioned balance tables make changes attributable, and different agent architectures can share the same action interface rather than each getting a private integration. If automated games ever touch an environment that resembles live, their traffic should also be clearly identified and kept separate from player telemetry used by live-ops.

When this interface does not already exist, we build it with the studio. That work is not something that happens after the agents are finished; it is the beginning of the engagement.

This is an interface, not an SDK shape

Different engines represent state and actions differently, so we are not asking every studio to implement the same giant schema or replace its architecture with ours. The implementation can vary while the underlying test remains the same:

Can an agent inspect the game, choose a legal action, take it through the real packaged build, run at scale, and produce a match a designer can reopen?

If that loop works, we have what we need to start authoring agents. If some part of it is missing, that becomes the first thing we work on together.

What starting Playthrough actually requires

A studio does not need to arrive with agents already built, and it does not need a language mode, an AI opponent, a phone companion, or a vision model on day one. Those are later applications of the same underlying capability.

It also does not replace human playtesting. People still play the game, but they can start from a much larger body of machine-played matches and spend their time where human judgment is most valuable.

What Playthrough does require is a technical path into the real game: enough state to make decisions, legal actions, action submission, scalable execution, and matches that can be reopened. If those pieces are not available yet, building them becomes the first part of the work.

It is useful to discover that early because the interface compounds. Once it exists, better agents can be added without rebuilding the connection to the game every time the model changes.

How this usually starts

We sit down with the people who own the engine and the people who own design and QA, choose one title and one mode, and name the actions a player can take. Then we make those actions available to an agent through the game, run the build without a person at the controls, and open the resulting match.

That loop is small, but it is the important one. Once it works, we can author different agents, play large numbers of games, and put those matches into Playthrough Console. If part of the loop does not work yet, we improve that interface before worrying about which model should sit on top of it.

The models will change. The door is the part that compounds.