XCP — Chapter 3
Chapter 1: I Built a Virtual Machine Inside the Xbox Sandbox. Then I Let AI Agents Build on Top of It.
Chapter 2: A System That Lets AI Work Directly With a Real Xbox — Now Open Source
Chapter 3: XCP Studio
In the first two posts I wrote about the larger XCP idea: turning an Xbox Series X in Developer Mode into a programmable execution target, and keeping AI-assisted software inside a continuous build → execute → observe → correct loop.
But most of that work has one place where it becomes visible.
XCP Studio.
Recorded XCP Studio workspace from the public XCP repository.
XCP Studio is the Windows development environment around XCP.
The idea behind it is deliberately simple:
the developer, the visual interface and the coding agent should not operate on three different versions of the project.
They should work on the same project authority.
One project, three ways to work with it
A project can be approached at different levels.
XCP PROJECT
│
┌──────────┼──────────┐
│ │ │
Guided Expert Agent
│ │ │
└──────────┼──────────┘
│
same state
Guided exposes higher-level project operations through the interface.
Expert gives direct access to the detailed development workflow.
Agent allows coding agents to work through the same project lifecycle and portable XCP tooling.
The important part is not the existence of three interfaces.
It is that they do not create three separate project models.
If a developer changes the project, the agent works from that project.
If an agent creates or adapts something, Studio works from the same authority.
There is no hidden AI-only version of the software that has to be reconciled later.
That becomes increasingly useful when development moves back and forth between humans and agents.
Studio does not stop at generation
A lot of AI development tools effectively end here:
prompt
↓
code
↓
files
XCP Studio was built around a longer lifecycle.
idea / source
↓
XCP Studio
↓
project
↓
validate
↓
build
↓
Xbox execution target
↓
result + evidence
↓
inspect / correct
↺
Studio can create or open a project, validate it against the available contracts, build it, prepare execution and inspect the resulting evidence.
The coding agent remains on the development side.
The Xbox remains the execution target.
The two are connected through XCP's admitted project and execution contracts rather than by giving an agent unrestricted access to the console.
That distinction is important.
AI builds and modifies software. Xbox executes admitted work. XCP records what happened.
The next iteration can then start from the result of a real execution instead of only from what the model expected to happen.
Why I wanted Studio at all
Technically, much of XCP could have remained a collection of command-line tools.
The portable repository already exposes operations such as:
xcp project describe
xcp conformance all
xcp xvm verify ...
xcp xvm run ...
But the larger system needed a place where the entire project lifecycle could remain understandable.
Source, project state, target capabilities, validation, builds, execution and evidence are related.
Once AI agents enter that lifecycle, keeping those relationships visible becomes even more important.
So Studio is not intended to be an AI code generator with an "Run on Xbox" button attached to it.
It is the control surface around the lifecycle.
developer ───────┐
│
coding agent ────┼──► XCP Studio / project
│ │
tools ───────────┘ │
▼
admitted build
│
▼
Xbox Series X
│
▼
evidence
│
└────► next iteration
The project survives every individual generation.
That is the part I care about most.
Now it is part of the open-source stack
XCP Studio is included in the public XCP source tree.
The repository contains the portable XCP contracts, XVM, project tooling, evidence infrastructure, source adaptation work, the reconstructed Windows development stack and the native Xbox worker components.
The portable parts can be explored without owning an Xbox.
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
On Windows, the repository can also rebuild the development distribution containing XCP Studio and the supporting runtime components.
One evidence boundary is worth keeping explicit: the preserved product path was exercised historically on a physical Xbox Series X, while the newly reconstructed public development packages are still marked NOT_TESTED_ON_XBOX until independently reproduced on hardware.
That separation is intentional.
XCP treats a successful historical run and a newly rebuilt binary as two different claims.
The small idea behind Studio
The UI is not really the interesting part.
The interesting part is the shared object underneath it.
human
│
├─────────┐
│ │
▼ ▼
Studio agent
│ │
└────┬────┘
▼
XCP project
│
▼
real execution
│
▼
evidence
Humans and AI do not need separate development worlds.
They need a shared project, explicit capabilities and evidence from the machine that actually executed the result.
That is what XCP Studio is trying to provide.
XCP is open source
GitHub:
https://github.com/Daniele-Cangi/xcp-xbox
XCP Studio:
https://xcpstudio.com/
Previous chapters:
- I Built a Virtual Machine Inside the Xbox Sandbox. Then I Let AI Agents Build on Top of It.
- A System That Lets AI Work Directly With a Real Xbox — Now Open Source
AI builds. Xbox executes. XCP verifies. Studio is where the loop stays visible.
Top comments (0)