TL;DR: I spent five-plus years in Unity before I built a single AI voice agent: freelance game work through university, then AR for fire response at ARCortex, clinical XR on a Vive Focus 3, a cross-platform C# SDK at Geonode, and a sports-tech platform as CTO at RAQTS. People treat that as an unrelated previous life. It is not. Five things transferred almost intact, because a voice agent is a real-time system with a human in the loop and so is a game. Three things did not transfer at all, and those were the expensive lessons. Here is the honest split.
Nobody hires a game developer to build their AI receptionist. When I started taking voice agent work, the assumption from every direction was that I was starting over, and that Unity was a charming detail on a CV rather than preparation.
That was wrong in a specific and useful way. Very little of what I use daily now is knowledge about Unity. Almost all of it is knowledge about building things that run in real time, in front of a human who will not wait, on top of sensors that lie. That describes an AR headset on a fire ground and it describes a phone call, and the second one turned out to be easier than the first.
What transferred
1. The frame budget is the latency budget
Unity teaches you that time is a hard resource before it teaches you anything else. At sixty frames per second you have sixteen milliseconds to do everything, and the discipline that produces is not "make it fast", it is knowing precisely what runs on the critical path and what can be pushed off it. You learn to profile rather than guess, to move work off the main thread, to amortise expensive things across frames, and to accept that an average is a lie because the user only ever feels the worst frame.
Every one of those habits is exactly what a production voice agent needs. A caller notices the slowest turn, not the median one. The work is the same shape: figure out what actually blocks the response, move the CRM writes and notifications off the call into automation that runs afterwards, cover an unavoidable wait with something rather than silence, and measure the tail. I wrote up how that decomposes for a phone call in the voice agent latency budget, and reading it back, it is the frame budget with different units. Sixteen milliseconds became about eight hundred, and the psychology is identical: past a threshold the thing stops feeling alive.
The AR work sharpened it further. On the ERIS XR platform and the AR tools I built at ARCortex, late meant wrong, because a label that lags the world is not a slightly delayed label, it is a lie about where something is.
2. Everything real time is a state machine, and the exits matter more than the states
Game developers spend their lives in state machines. Every character controller, every UI flow, every animation graph. What experience teaches you is that the bugs never live inside a state; they live in the transitions, and specifically in the transitions nobody wrote down. The player who opens the inventory mid-jump while a cutscene is loading finds the gap.
Designing a conversation flow is the same job. The nodes are easy. What determines whether the agent survives a real caller is the exit conditions: what counts as done, what happens when the caller answers something you did not ask, and where they go when the whole thing falls apart. I now write the exits before the happy path, which is a habit that came directly from character controllers, and it is the core of how I structure Retell conversation flows and reusable components and how I decide when the agent hands off to a human.
3. Sensors lie, and the system has to be designed around that
This is the transfer I did not expect to be so direct. Location-based AR runs on GPS and a magnetometer, and both are wrong in ways that are neither random nor constant. At Nystag we ran clinical eye-tracking diagnostics on a Vive Focus 3, where the entire product was a measurement taken from an imperfect signal that a clinician would later stake a judgement on. When I dug into why geospatial AR is a coordinate problem rather than a graphics one, the honest conclusion was that heading error, not position error, was what broke the illusion.
Speech recognition is that same class of input. It is a noisy sensor with structured failure modes, and the structure is knowable: it is worst on exactly the values that carry no redundancy, which is why names, postcodes, registration numbers and email addresses break while whole sentences survive. Once you have accepted that a sensor reading arrives with an implied confidence, you build differently. You validate shape downstream instead of trusting the reading, you confirm the values that matter in small chunks, you store confidence alongside the value, and you design a repair path that terminates instead of looping. That is the whole of capturing caller details on a bad phone line, and I arrived at it because AR had already taught me not to trust a number just because a device produced it.
4. Playtesting is adversarial QA, and unit tests will not save you
Anyone who has watched a real person play their game for the first time has learned something no test suite communicates: users do not follow the path. They walk into the wall, they press every button during the tutorial, they answer the question you did not ask.
Callers are players. They interrupt, they give you two facts at once, they go quiet, they ask something completely outside the agent's remit in the middle of a booking. The QA instinct that game work builds is to test with the adversarial user rather than the cooperative one, and it is why the pipeline I built at Fortell AI to build and test agents in minutes with Claude Code and Comet is aimed at difficult calls rather than clean ones. A voice agent that handles the ideal caller proves nothing at all. So does a game that only survives the developer playing it.
5. Shipping through a gate that does not care about you
Console and app store releases teach a specific kind of production discipline. There is a submission, a review, a rejection, a build that must be reproducible, and a rollback story you should have thought about before you needed it. Getting the Unity Lumo platform and mobile apps out through the App Store and Play Console as CTO at RAQTS, and building the Unity and Windows CI/CD pipelines around the Repocket SDK at Geonode, was where I learned that "it works on my machine" is a category of statement, not a defence.
Voice agents have their own gatekeepers, and they are less forgiving than they look: carriers, A2P registration, recording rules, healthcare and privacy constraints. Different rules, identical posture. Something outside your control can block the thing from reaching users, so you plan for it in week one rather than the day before launch.
What did not transfer
You cannot replay a phone call
Games are deterministic enough to be re-run. Same seed, same inputs, same bug, as many times as you need. That is the single largest thing I lost. A live call is unrepeatable: a different caller, different background noise, a model that will not produce the identical output twice. You cannot step through it.
The adjustment was learning to build the observability up front rather than the debugger. Transcripts, recordings, structured post-call outcome data, the full tool call trace. You are doing forensics after the fact, not stepping frames, so the discipline shifts to capturing enough evidence at the time that the reconstruction is possible later. Which is why I care so much about what actually gets measured on a production agent.
You can see a game and you cannot see an agent
Almost every visual bug in Unity announces itself. You look at the scene and the thing is in the wrong place. Voice agent failures are silent and look like success: the call completes, the transcript reads sensibly, the customer is never contacted because the email address was captured wrong. Nothing errors. I had to consciously replace looking with reading, and to build the habit of reading failed calls end to end rather than sampling random ones.
The engine is yours, the model is not
Unity is a dependency you can reason about, decompile, work around, and eventually understand completely. A language model is a dependency whose behaviour changes without a changelog and cannot be patched. You do not fix it, you route around it: keep the agent thin, put anything that must be correct in deterministic automation downstream rather than trusting the model to remember it, and constrain what it is allowed to say where the wording carries risk. That architectural conservatism is the biggest genuine change in how I build, and it is the shape behind how I build voice agents now.
Should a Unity developer make this switch?
If you want to, yes, and faster than you think. The parts of AI engineering that take people the longest are not the prompts. They are latency intuition, state design, tolerance for unreliable input, adversarial testing and release discipline, and a game developer already owns all five. What you are missing is a stack, and a stack is a few weeks.
What I would not do is treat it as a clean break. The reason I get hired for agent work is rarely the model layer, which is the commodity part. It is that the surrounding system holds up, and that came from years of building things that had to run at speed in front of a human. Same as what competitive programming actually left me with: the tools changed four times, and the underlying muscle never did.
I build AI voice agents, real-time systems and software for founders across the US, UK and Europe, from XR platforms to production phone agents. If you have something that has to work in front of real users, more about my background here, or book a call.