AI tools can help a team make a game without appearing in the finished product. AI teammates are different. They have to respond while the player is waiting, behave inside the rules, survive edge cases, and run every time someone plays.
That turns player-facing AI into a live-game mechanic with a bill attached. The cost may be low enough to work, but it still grows with player-hours. So do the chances of a slow response, strange decision, or broken interaction.
AI teammates should not ship because the conversation sounds impressive. They should ship because they solve a player problem well enough to earn their cost per active hour.
AC&A read: the model bill is part of the mechanic. If the feature gets more expensive as players stay longer, retention is both a success metric and a cost driver.
AI Creation and AI Gameplay Are Different Businesses
PocketGamer.biz reports that more than 80% of Roblox’s top 100 games by hours played used AI to speed development in October 2026.3 That is a production workflow. The model can help create code or assets, then leave the cost structure before a player starts a session.
Naavik’s interview with Artificial Agency CEO Brian Tanner describes a different product.1 Artificial Agency is building an upcoming single-player mode for Owlchemy Labs’ Dimensional Double Shift in which three AI teammates replace human players in a cooperative VR experience. They read the game state, interpret intent, and take actions the designer has allowed.
The populations and measures behind those two reports are not comparable, but the distinction matters. “Using AI” can mean shortening production work or adding a running dependency to every session. One changes fixed development cost. The other creates variable serving cost, response-time requirements, behavioural QA, and a new failure path inside the game.
This is a separate question from the production argument in AI Makes Games Faster to Build, Not Cheaper to Grow. A studio can use AI throughout development and still decide that no model belongs in the player’s loop.
A Teammate Needs a Job, Not Just a Personality
The useful part of the Owlchemy example is not that the characters can talk. Players had asked for a way to play a cooperative game alone. The AI teammates are being built to fill the empty roles, understand requests, handle objects, and keep the shared task moving.
That is a product job with a visible alternative. The team can compare an AI teammate with matchmaking, a scripted bot, fewer required roles, or a redesigned single-player mode. If the agent does not help more players start, finish, or repeat the experience, better dialogue is not enough.
The job also sets the action envelope. A teammate might be allowed to fetch a tool, complete a step, recover from an interruption, or react to another character. It should not invent a new objective, spend scarce resources, or block the player’s plan unless the design explicitly permits it.
That keeps creative control with the game team. The model supplies flexibility inside a designed role; it does not quietly become the designer.
Latency Is Part of Game Feel
Tanner said the Owlchemy implementation targets a response between 500 milliseconds and one second after a player finishes speaking or acting. In the same hardware context, he estimated that even Artificial Agency’s smallest models would take two to three seconds if they ran on the headset, so the current implementation uses the cloud.1
That difference is not an infrastructure footnote. A half-second pause can feel like a teammate thinking. A three-second pause during a coordinated task can feel like the game missed the command.
Studio Atelico is pursuing the other direction.2 Its early-access engine runs language, speech, search, and character behaviour locally and says its scheduler can share hardware with rendering without frame drops. Local processing can reduce cloud cost and keep player data on the device. It also has to work across the performance range the game supports.
Cloud versus device is not an ideology. It is a product choice about response time, supported hardware, privacy, offline behaviour, and margin. A studio needs measurements on its own game and target devices before it can choose.
QA Moves From Lines to Behaviour
A scripted character can still break, but its possible responses are bounded by authored branches. An agent can combine intent, memory, game state, another character’s action, and a player’s unexpected request. That flexibility is the feature. It is also what QA now has to cover.
The team needs more than a list of prompts that produced good demos. It needs repeatable tests for what the teammate does when information is missing, two players issue conflicting requests, a required object is unavailable, the connection drops, or the cheapest safe action is not the most entertaining one.
The acceptance criteria should stay in game terms:
- Does the teammate recognize the player’s intended task?
- Does it choose only actions allowed for its role?
- Can the player understand and correct a bad decision?
- Does the game fail safely when the model or network is unavailable?
- Can support and community teams reproduce the behaviour a player reports?
The question is not whether the agent can surprise the player. It is whether the game can contain the surprise.
Prove Player Value Before Scale
Artificial Agency says it has reduced inference to single-digit cents per player-hour.1 That may be commercially workable, but a small unit cost becomes material when it follows every active player. It also changes with session length, concurrency, retries, model choice, and how often the mechanic is called.
The product test should connect that cost to a player result. For an AI teammate, that might be more sessions started without a full party, fewer abandoned missions, faster recovery after mistakes, or more repeat co-op play. For a reactive opponent, it might be better challenge matching without a rise in frustration or support complaints.
This follows the same restraint AC&A argued for in More Content Can Make a Live Game Harder to Love. A feature earns its place by improving the reasons players return, not by increasing the amount the team can say it shipped.
Before expanding a player-facing agent, use a five-part gate:
- Name the unmet player job. Start with the blocked session, empty role, repetitive task, or adaptive challenge the game cannot handle well today.
- Build the cheapest credible baseline. Compare the agent with a scripted bot, matchmaking change, simpler mode, or ordinary rules.
- Budget the full player-hour. Include inference, networking, retries, monitoring, moderation, support, and QA—not just the quoted model call.
- Set the behaviour boundary. Define allowed actions, protected resources, fallback behaviour, and the player’s route to correction.
- Scale on player evidence. Require a measurable improvement in access, completion, return play, or another named outcome before broad rollout.
In the episode below, Tanner and Naavik’s Alexandra Takei discuss the Owlchemy implementation, serving cost, response time, designer control, and the work still required before commercial deployment.
Make the Agent Earn Its Place
Player-facing AI becomes interesting when it makes a game possible or meaningfully better, not when it adds another place to chat. A teammate that lets someone play a cooperative game alone has a clear job. An opponent that adapts without cheating may have one too.
Those mechanics still have to fit the business and the feel of the game. The response must arrive on time. The action must stay inside the rules. The fallback must work. The cost must remain acceptable as successful players spend more time with it.
The right benchmark is not a convincing demo. It is a player outcome that remains valuable, reliable, and affordable for every hour the game runs.