{"slug": "i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on", "title": "I Built a Virtual Machine Inside the Xbox Sandbox. Then I Let AI Agents Build on Top of It.", "summary": "A developer built XCP, a system that runs a virtual machine inside the Xbox application sandbox and lets AI agents operate on top of it, turning one-shot code generation into a continuous create-execute-observe-correct lifecycle. In public trials, an AI-driven, human-directed workflow completed 28/28 lifecycle operations, and a port of the authorized Godot 2 project Minilens completed 14/14 lifecycle operations and 5/5 declared semantic acceptance checks on Xbox Series X. The developer frames the result narrowly: real source software crossed the full path from source observation to an Xbox execution and a measured decision, rather than claiming general engine compatibility.", "body_md": "[XCP turns one-shot code generation into a continuous software lifecycle: create, execute on Xbox, observe, correct, evolve, repeat.](https://github.com/Daniele-Cangi/XCP-Research)\n\nAI agents are getting very good at producing software.\n\nWhat interested me was what happens after the code exists.\n\nA generated project can compile and still be wrong. A port can launch while losing important behaviour. An agent can make a convincing change without knowing how that change actually behaves on the machine that has to run it.\n\nI wanted the software project to continue beyond generation.\n\nThe same project should be able to change, run on a real Xbox Series X, produce evidence about what happened there, return that evidence to the development side, receive another correction, become a new version, and run again.\n\nThat eventually became XCP.\n\nBut it started somewhere much smaller: with a virtual machine inside the Xbox application sandbox.\n\nThe project should not disappear after generation\n\nA lot of AI-assisted development still has an implicit shape:\n\nprompt\n\n  ↓\n\nagent\n\n  ↓\n\nsource files\n\n  ↓\n\nbuild\n\n  ↓\n\ndone\n\nI wanted a loop instead.\n\nAI agent / developer\n\n        ↓\n\n     XCP project\n\n        ↓\n\n create / modify / adapt\n\n        ↓\n\n    target candidate\n\n        ↓\n\n     XBOX SERIES\n\n        ↓\n\n execute + observe\n\n        ↓\n\n structured evidence\n\n        ↓\n\n correct / evolve\n\n        ↓\n\n     next version\n\n        ↺\n\nThe agent does not run unrestricted on the console.\n\nIt works from the PC side, where the project can be inspected and modified. Xbox executes the prepared candidate. XCP records what happened and brings that information back into the project lifecycle.\n\nThe next iteration can therefore start from real target behaviour, not only from what the agent expected the software to do.\n\nThat distinction became the core of XCP for me.\n\nXCP turns an AI agent from a one-shot code generator into a participant in an ongoing software lifecycle.\n\nThe project survives the generation.\n\nIts versions have identities. Executions belong to specific versions. Evidence belongs to specific executions.\n\nThat makes continued work possible without treating every new generation as an unrelated pile of files.\n\nCreate, adapt, and keep going\n\nXCP currently enters that lifecycle in two main ways.\n\nA project can start from an idea.\n\nIn the public creation programme, an AI-driven, human-directed workflow completed 28/28 lifecycle operations across an interactive project and a utility.\n\nThe interesting part was not that an AI produced code. We already know models can do that.\n\nThe interesting part was that the work continued through the wider lifecycle: project creation, preparation, execution and subsequent decisions.\n\nThe second path starts from existing authorized software.\n\nThat is substantially harder because a real project is more than source files. It has state, input behaviour, timing, scenes, persistence, assets, engine conventions and interactions between systems.\n\nThe first public real-source case uses Minilens, an authorized Godot 2 project.\n\nThat case completed 14/14 lifecycle operations and 5/5 declared semantic acceptance checks on Xbox.\n\nI am deliberately not describing that as “Godot compatibility”.\n\nIt is a narrower and more useful result: real source software crossed the full path from source observation to an Xbox execution and a measured decision.\n\nAnd then the project can continue.\n\nOne of the public lifecycle sequences is:\n\n1.0.0 → 1.1.0 → 1.0.0\n\nA later version was produced, exercised, and the lifecycle retained the ability to return to the earlier known version.\n\nThat is a small example, but it captures an important idea: evolution is part of the system, not an afterthought.\n\nThe software is expected to be changed again.\n\nThe Xbox became part of the development loop\n\nThe Xbox is not only the place where the final result gets deployed.\n\nIt is an execution target inside the loop.\n\nConsider a simple behavioural change.\n\nAn agent modifies movement. XCP prepares the next candidate. The candidate runs on Xbox. Target observations are recorded. Those observations are compared against the behaviour the project was supposed to preserve. The result becomes evidence attached to that version.\n\nThe next correction can then work from that result.\n\nThis pattern can repeat.\n\nThat is very different from asking a model to generate another implementation after someone manually reports that “movement feels wrong”.\n\nThe target itself contributes information to the next development step.\n\nThis is also why I became less interested in “AI-generated software” as a category.\n\nGeneration is one operation.\n\nMaintaining an evidence-bearing relationship between an agent, a software project and a real execution target is a much larger problem.\n\nThe virtual machine that made this possible\n\nThe Xbox side began as a separate research problem.\n\nI wanted programmable execution on a retail Xbox Series console while staying inside the public application environment.\n\nThat produced XVM, a deterministic virtual machine used by the current reference runtime.\n\nXVM v2 currently has 26 admitted opcodes, 16 registers, typed memory, bounded control flow, static execution budgets, deterministic snapshot/resume, a canonical CPU path and GPU differential execution paths.\n\nThose details deserve their own article.\n\nFor XCP, the more important property is simpler:\n\nnew bounded work can be submitted to the execution target without every new behaviour becoming a completely new native application.\n\nThe VM gives XCP a programmable target.\n\nIt also gives the target the ability to reject work that does not fit its current execution contract.\n\nThat is enough to keep a useful separation between the software producer and the machine executing what it produced.\n\nXVM does not remove the Xbox sandbox.\n\nIt creates a programmable layer inside it.\n\nRunning the software was not enough\n\nOnce the VM worked, another problem became much more important.\n\nReal software does not begin as VM instructions.\n\nIt begins as behaviour.\n\nA player moves. A collision fires. A value survives a restart. An input changes some state. A scene transition happens.\n\nThe implementation of those behaviours can be completely different on another runtime.\n\nThis forced XCP to separate three things:\n\nsource behaviour\n\n      ↓\n\nsemantic representation\n\n      ↓\n\ntarget implementation\n\nThe current reference source family is Godot, while Xbox/XVM is the first reference target.\n\nThose environments do not share the same engine, scripting model, APIs, scene implementation or runtime assumptions.\n\nSo XCP cannot simply copy structure and call the result equivalent.\n\nThe source side has to expose enough meaning for the target side to reason about what can actually be preserved.\n\nAnd then the result still has to be measured.\n\nThat produces another distinction which now runs through the project:\n\nexecution is not fidelity.\n\nA candidate can launch successfully and still behave incorrectly.\n\nA movement path may work while collision semantics changed. A scene may look right while persistence is broken. A playable subset can still contain behaviour that was never observed.\n\nXCP therefore keeps operability, fidelity and stronger equivalence claims separate.\n\nThis is not mainly about being conservative with wording.\n\nIt makes the evidence useful to the next iteration.\n\nIf the system can say where behaviour diverged instead of merely returning “build succeeded”, an agent has something concrete to work on.\n\nXbox is the first target, not the definition of XCP\n\nToday the concrete path looks like this:\n\nGodot → XCP → Xbox / XVM\n\nBut that is not the architecture I want to stop at.\n\nThe source side and target side are being separated deliberately.\n\nThe future model is closer to:\n\nGodot ─────┐\n\nUnity ─────┤\n\nUnreal ────┤\n\nCustom ────┘\n\n           ↓\n\n          XCP\n\n           ↓\n\n      target contract\n\n       ↙         ↘\n\n Xbox / XVM    other runtimes\n\nOnly the first path has public research evidence today. The other arrows are directions for the architecture, not current compatibility claims.\n\nThis is where XCP becomes much more interesting.\n\nThe long-term value is not moving one Godot project to one Xbox. It is making source systems and execution targets independently extensible.\n\nIf another developer can eventually write an adapter for a different engine without rewriting the core, that tests the semantic boundary.\n\nIf someone can implement another XVM runtime from the same contract, that tests the execution boundary.\n\nIf another target can consume XCP projects while preserving the evidence model, Xbox has done its job as the first forcing function rather than becoming a permanent limitation.\n\nThe next test is other developers\n\nMost XCP development still lives in a large private research repository.\n\nThat repository is useful as a laboratory, but it is not what I want to publish as the platform.\n\nIt contains years\n\n [of experiments, Xbox runtime work, product prototypes, operational tooling, evidence pipelines and branches that should not become accidental public APIs.](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fhig97iko6okjneyne70s.png)\n\nSo I am preparing a clean open-source extraction instead.\n\nThe current model is roughly:\n\nspec\n\nruntime\n\nsemantic\n\nadapters\n\nevidence\n\nconformance\n\nsdk\n\nexamples\n\nGodot would begin as the reference source adapter.\n\nXVM would begin as the reference execution substrate.\n\nXbox Series would remain the first reference target.\n\nXCP Studio is the product environment around that platform.\n\nThe experiment I care about after that is not another demo produced by me.\n\nIt is somebody else building the next adapter, runtime or verifier.\n\nThat will expose very quickly whether the abstractions are actually general.\n\nFrom a VM on Xbox to a continuous software lifecycle\n\nI originally wanted to see how far programmable execution could be pushed on Xbox.\n\nThat produced XVM.\n\nXVM made repeated target execution possible.\n\nRepeated execution made it possible to return structured information from the hardware.\n\nThat information made a continuous agent loop possible.\n\nAnd that loop became XCP.\n\nAI agent\n\n    ↓\n\nsoftware project\n\n    ↓\n\nreal execution\n\n    ↓\n\nevidence\n\n    ↓\n\nnext decision\n\n    ↺\n\nThe VM is still an important part of the system.\n\nXbox is still the first real target.\n\nBut the project is no longer mainly about either one.\n\nIt is about keeping software alive after the AI finishes writing the first version.\n\nAI builds. Xbox executes. XCP verifies.\n\nThen the project continues.\n\nCurrent public work\n\nXCP Studio: xcpstudio.com\n\nXCP Research: github.com/Daniele-Cangi/XCP-Research\n\nXCP-Research currently contains the architecture description, the public XVM model, selected bounded Xbox evidence and offline verification tooling. The implementation remains private while the active research branches are consolidated and the open-source platform boundary is extracted cleanly.\n\nWriting note: I used AI as an editorial assistant to help restructure and edit this article. The project, experiments, technical claims and final publication decisions are mine.", "url": "https://wpnews.pro/news/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on", "canonical_source": "https://dev.to/danielecangi/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on-top-of-it-ef0", "published_at": "2026-09-22 22:16:31+00:00", "updated_at": "2026-09-22 22:22:43.634729+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["XCP", "Xbox Series X", "Minilens", "Godot", "Daniele Cangi"], "alternates": {"html": "https://wpnews.pro/news/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on", "markdown": "https://wpnews.pro/news/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on.md", "text": "https://wpnews.pro/news/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on.txt", "jsonld": "https://wpnews.pro/news/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on.jsonld"}}