I wanted AI to work directly with a real Xbox.
Not just generate code on a PC.
I wanted the same software project to be created or adapted, sent to Xbox, executed there, observed, corrected, and then evolved again.
That system became XCP.
And now it is open source.
👉 GitHub: https://github.com/Daniele-Cangi/xcp-xbox
👉 XCP Studio: https://xcpstudio.com/
The simplest way to understand it is this:
AI / developer
↓
project
↓
XCP
↓
Xbox Series
↓
execute + observe
↓
evidence
↓
next version
↺
AI builds. Xbox executes. XCP observes. The project continues.
What it already looks like
This is not only infrastructure.
I wanted to see actual software cross that loop.
Forge
Forge — created through the XCP workflow and executed on Xbox.
The interesting part is not that AI can generate code.
The interesting part is that the project can continue after generation: it can be executed on a real target, observed, changed, versioned, and executed again.
Minilens
Minilens — an authorized Godot project adapted through XCP and executed through the Xbox lifecycle.
This tested a different path.
Instead of starting from a new idea, XCP had to begin with an existing software project, observe its structure and behaviour, adapt what could be represented on the target, execute it, and compare the result.
I deliberately do not call this universal Godot compatibility.
It demonstrates something narrower and more useful:
A real codebase can cross from source software to Xbox execution and come back with evidence about what actually happened.
The project survives the generation
This is the part of XCP I care about most.
A lot of AI-assisted development still behaves like this:
prompt
↓
generate
↓
files
↓
done
I wanted this instead:
create
↓
execute
↓
observe
↓
correct
↓
evolve
↓
execute again
↺
The same project has an identity.
Its versions have identities.
Executions belong to those versions.
Evidence belongs to particular executions.
A later change does not erase what existed before.
One lifecycle I exercised explicitly went:
1.0.0 → 1.1.0 → 1.0.0
Update and rollback are operations in the system, not an informal reconstruction of old files.
That is why I describe XCP as a software lifecycle for AI-assisted development, not simply an AI code generator.
What has already been exercised
Two paths were especially important:
| Path | Result |
|---|
| New-project lifecycle | 28 / 28 operations |
| Existing-source lifecycle with Minilens | 14 / 14 operations |
| Declared semantic checks | passed for the published scenario |
| Version evolution | 1.0.0 → 1.1.0 → 1.0.0 |
The creation path tested whether an agent could stay inside a project lifecycle beyond generation.
The Minilens path tested whether existing software could enter that same loop.
In both cases, the important boundary was the same:
the software had to reach a real Xbox execution target.
{% details Click to see more about the two paths %}
Creating new software
An agent can create an explicit XCP project, validate it, prepare it for the target, execute it, inspect the result, correct it and continue from another version.
The public creation programme completed 28 out of 28 lifecycle operations across an interactive project and a utility.
Adapting existing software
Existing software is harder because a project is more than its files.
It contains behaviour: input, state, collisions, scene transitions, timing, persistence and assumptions about the original engine.
The Minilens programme completed 14 out of 14 lifecycle operations together with the declared semantic acceptance checks for the published scenario.
That is why XCP treats adaptation closer to semantic reconstruction than file conversion.
{% enddetails %}
Xbox is actually inside the loop
Xbox is not just the screen at the end.
It is an execution target that produces information for the next development step.
Imagine an agent changes movement.
XCP can prepare the candidate, execute it on Xbox, observe what happened, and return structured evidence.
The next iteration can start from that evidence.
change
↓
Xbox execution
↓
evidence
↓
next decision
The AI itself does not run unrestricted on the console.
The agent remains on the development side.
Xbox exposes bounded execution surfaces, and XCP mediates what reaches the target and what comes back.
That separation is intentional.
The virtual machine that made this possible
The project actually started from a smaller experiment.
I wanted to know how much programmable execution I could create inside the public Xbox application environment.
That produced XVM, a deterministic virtual machine.
For XCP, XVM's most important property is simple:
New bounded work can reach the Xbox execution target without every new behaviour becoming another native Xbox application.
That turned Xbox from a fixed endpoint into a programmable part of the loop.
{% details Click to see what is inside XVM %}
The current XVM v2 reference implementation includes:
- 26 admitted opcodes
- 16 registers
- typed memory
- structured control flow
- bounded loops and calls
- static execution budgets
- deterministic snapshot and resume
- canonical CPU execution
- GPU differential execution paths
The target still decides whether submitted work belongs to its admitted execution contract.
XVM does not remove the Xbox sandbox.
It creates a programmable layer inside it.
{% enddetails %}
“It ran” is not enough
Getting software to execute was only half of the problem.
A project can launch successfully and still be wrong.
Movement may work while collision behaviour changed.
A scene may appear correct while persistence is broken.
So XCP separates:
source behaviour
↓
semantic representation
↓
target implementation
↓
target observation
↓
evidence
This produced a rule that now sits at the centre of the project:
“It ran” is not the same claim as “it was preserved correctly.”
That difference is especially important when AI agents are involved.
Build succeeded gives an agent almost nothing to reason about.
Movement survived, but this collision consequence diverged gives it something concrete to fix.
{% details Click to see the deeper architecture %}
The broader pipeline is:
exact source
↓
source observation
↓
source model
↓
semantic IR
↓
capability admission
↓
target lowering
↓
execution
↓
observation
↓
differential evidence
Today the concrete public reference path is:
Godot → XCP → Xbox / XVM
Other source systems and targets are architectural directions, not completed compatibility claims.
{% enddetails %}
Now it is open source
This is the reason for this post.
I did not simply publish the original research repository.
That repository was a laboratory: Xbox experiments, runtime probes, games, adaptation prototypes, failed paths and multiple generations of the system.
Instead, I extracted XCP around the parts that should be reusable.
The public repository contains the platform, XVM, project tooling, semantic infrastructure, evidence contracts, conformance tooling and examples.
👉 https://github.com/Daniele-Cangi/xcp-xbox
You can start with the portable parts:
git clone https://github.com/Daniele-Cangi/xcp-xbox.git
cd xcp-xbox
python -m pip install -e '.[test]'
python -m pytest -q
xcp conformance all
You can also run the VM directly:
xcp xvm verify src/xcp/conformance/vectors/xvm-v2-call-chain.json
xcp xvm run src/xcp/conformance/vectors/xvm-v2-call-chain.json
Or inspect the project contract:
xcp project describe
{% details Click to see what I want people to extend %}
The first reference source adapter is Godot.
The first reference execution substrate is XVM.
The first real target is Xbox Series.
But the architecture intentionally separates those pieces.
Interesting contributions could include:
- another source adapter
- another runtime
- another execution target
- XVM tooling
- new conformance vectors
- evidence and verification tooling
- examples
- documentation
- or simply a case that breaks one of the abstractions
A broken abstraction is useful too.
It tells us where XCP still contains assumptions that should not be there.
{% enddetails %}
The next important result should not come from me
This is probably the biggest reason I wanted XCP open.
So far, Xbox has been the forcing function.
It forced the system to deal with a real target, a sandbox, bounded execution, hardware observation and the difference between “it ran” and “it behaved correctly”.
Now I want to know what happens when other people push on the boundaries.
Can somebody build another adapter without rewriting the platform?
Can another runtime use the same contracts?
Can another target preserve the evidence loop?
Where does the abstraction fail?
Those results are more interesting now than another feature I could add alone.
XCP
GitHub:
👉 https://github.com/Daniele-Cangi/xcp-xbox
Studio:
👉 https://xcpstudio.com/
For the longer story of how the Xbox virtual machine evolved into this lifecycle, I wrote about that separately:
https://coderlegion.com/28314/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on-top-of-it
The VM was the first piece.
Now the platform is open for other people to build on top of it.
AI builds. Xbox executes. XCP observes. The project continues.
