DEV Community: DaC

I Built a Virtual Machine Inside the Xbox Sandbox. Then I Let AI Agents Build on Top of It.

DaC — Tue, 22 Sep 2026 22:16:31 +0000

XCP turns one-shot code generation into a continuous software lifecycle: create, execute on Xbox, observe, correct, evolve, repeat.

AI agents are getting very good at producing software.

What interested me was what happens after the code exists.

A 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.

I wanted the software project to continue beyond generation.

The 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.

That eventually became XCP.

But it started somewhere much smaller: with a virtual machine inside the Xbox application sandbox.

The project should not disappear after generation

A lot of AI-assisted development still has an implicit shape:

prompt
↓
agent
↓
source files
↓
build
↓
done

I wanted a loop instead.

AI agent / developer
↓
XCP project
↓
create / modify / adapt
↓
target candidate
↓
XBOX SERIES
↓
execute + observe
↓
structured evidence
↓
correct / evolve
↓
next version
↺

The agent does not run unrestricted on the console.

It 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.

The next iteration can therefore start from real target behaviour, not only from what the agent expected the software to do.

That distinction became the core of XCP for me.

XCP turns an AI agent from a one-shot code generator into a participant in an ongoing software lifecycle.

The project survives the generation.

Its versions have identities. Executions belong to specific versions. Evidence belongs to specific executions.

That makes continued work possible without treating every new generation as an unrelated pile of files.

Create, adapt, and keep going

XCP currently enters that lifecycle in two main ways.

A project can start from an idea.

In the public creation programme, an AI-driven, human-directed workflow completed 28/28 lifecycle operations across an interactive project and a utility.

The interesting part was not that an AI produced code. We already know models can do that.

The interesting part was that the work continued through the wider lifecycle: project creation, preparation, execution and subsequent decisions.

The second path starts from existing authorized software.

That 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.

The first public real-source case uses Minilens, an authorized Godot 2 project.

That case completed 14/14 lifecycle operations and 5/5 declared semantic acceptance checks on Xbox.

I am deliberately not describing that as “Godot compatibility”.

It 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.

And then the project can continue.

One of the public lifecycle sequences is:

1.0.0 → 1.1.0 → 1.0.0

A later version was produced, exercised, and the lifecycle retained the ability to return to the earlier known version.

That is a small example, but it captures an important idea: evolution is part of the system, not an afterthought.

The software is expected to be changed again.

The Xbox became part of the development loop

The Xbox is not only the place where the final result gets deployed.

It is an execution target inside the loop.

Consider a simple behavioural change.

An 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.

The next correction can then work from that result.

This pattern can repeat.

That is very different from asking a model to generate another implementation after someone manually reports that “movement feels wrong”.

The target itself contributes information to the next development step.

This is also why I became less interested in “AI-generated software” as a category.

Generation is one operation.

Maintaining an evidence-bearing relationship between an agent, a software project and a real execution target is a much larger problem.

The virtual machine that made this possible

The Xbox side began as a separate research problem.

I wanted programmable execution on a retail Xbox Series console while staying inside the public application environment.

That produced XVM, a deterministic virtual machine used by the current reference runtime.

XVM 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.

Those details deserve their own article.

For XCP, the more important property is simpler:

new bounded work can be submitted to the execution target without every new behaviour becoming a completely new native application.

The VM gives XCP a programmable target.

It also gives the target the ability to reject work that does not fit its current execution contract.

That is enough to keep a useful separation between the software producer and the machine executing what it produced.

XVM does not remove the Xbox sandbox.

It creates a programmable layer inside it.

Running the software was not enough

Once the VM worked, another problem became much more important.

Real software does not begin as VM instructions.

It begins as behaviour.

A player moves. A collision fires. A value survives a restart. An input changes some state. A scene transition happens.

The implementation of those behaviours can be completely different on another runtime.

This forced XCP to separate three things:

source behaviour
↓
semantic representation
↓
target implementation

The current reference source family is Godot, while Xbox/XVM is the first reference target.

Those environments do not share the same engine, scripting model, APIs, scene implementation or runtime assumptions.

So XCP cannot simply copy structure and call the result equivalent.

The source side has to expose enough meaning for the target side to reason about what can actually be preserved.

And then the result still has to be measured.

That produces another distinction which now runs through the project:

execution is not fidelity.

A candidate can launch successfully and still behave incorrectly.

A 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.

XCP therefore keeps operability, fidelity and stronger equivalence claims separate.

This is not mainly about being conservative with wording.

It makes the evidence useful to the next iteration.

If the system can say where behaviour diverged instead of merely returning “build succeeded”, an agent has something concrete to work on.

Xbox is the first target, not the definition of XCP

Today the concrete path looks like this:

Godot → XCP → Xbox / XVM

But that is not the architecture I want to stop at.

The source side and target side are being separated deliberately.

The future model is closer to:

Godot ─────┐
Unity ─────┤
Unreal ────┤
Custom ────┘
↓
XCP
↓
target contract
↙ ↘
Xbox / XVM other runtimes

Only the first path has public research evidence today. The other arrows are directions for the architecture, not current compatibility claims.

This is where XCP becomes much more interesting.

The long-term value is not moving one Godot project to one Xbox. It is making source systems and execution targets independently extensible.

If another developer can eventually write an adapter for a different engine without rewriting the core, that tests the semantic boundary.

If someone can implement another XVM runtime from the same contract, that tests the execution boundary.

If 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.

The next test is other developers

Most XCP development still lives in a large private research repository.

That repository is useful as a laboratory, but it is not what I want to publish as the platform.

It contains years of experiments, Xbox runtime work, product prototypes, operational tooling, evidence pipelines and branches that should not become accidental public APIs.

So I am preparing a clean open-source extraction instead.

The current model is roughly:

spec
runtime
semantic
adapters
evidence
conformance
sdk
examples

Godot would begin as the reference source adapter.

XVM would begin as the reference execution substrate.

Xbox Series would remain the first reference target.

XCP Studio is the product environment around that platform.

The experiment I care about after that is not another demo produced by me.

It is somebody else building the next adapter, runtime or verifier.

That will expose very quickly whether the abstractions are actually general.

From a VM on Xbox to a continuous software lifecycle

I originally wanted to see how far programmable execution could be pushed on Xbox.

That produced XVM.

XVM made repeated target execution possible.

Repeated execution made it possible to return structured information from the hardware.

That information made a continuous agent loop possible.

And that loop became XCP.

AI agent
↓
software project
↓
real execution
↓
evidence
↓
next decision
↺

The VM is still an important part of the system.

Xbox is still the first real target.

But the project is no longer mainly about either one.

It is about keeping software alive after the AI finishes writing the first version.

AI builds. Xbox executes. XCP verifies.

Then the project continues.

Current public work

XCP Studio: xcpstudio.com

XCP Research: github.com/Daniele-Cangi/XCP-Research

XCP-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.

Writing 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.

I Wanted a RAG System That Could Show Its Work, So I Built Alchimista

DaC — Wed, 02 Sep 2026 14:33:16 +0000

Most RAG demos stop at the answer.Alchimista

You upload a document, ask a question, get a plausible response, maybe see a few source chunks, and that's where the story ends.

But I kept coming back to a different problem:

What happens when the answer itself isn't enough?

What if I need to know which evidence was used, what happened to sensitive data before processing, which policy was active, whether two tenants could ever see each other's documents, and what the system actually did rather than what its architecture diagram claims it should do?

That's where Alchimista started.

The idea

Alchimista is a self-hosted document intelligence and AI governance system built around a fairly simple principle:

An AI answer should leave evidence behind.

The basic path looks like this:

document → privacy processing → ingestion → retrieval → cited answer → decision evidence → audit

That sounds straightforward. Making all of those boundaries agree with each other was considerably less straightforward.

RAG wasn't the difficult part

Retrieving chunks and generating an answer is only one piece of the system.

The more interesting questions appeared around it.

A document belongs to a tenant. Retrieval has to respect that boundary.

An answer needs citations. Those citations need to point back to actual indexed evidence.

Sensitive information may need to be detected or pseudonymized before it reaches an external model.

If privacy processing fails, silently continuing with the original text is not an acceptable fallback.

And if the system records an AI decision, the audit trail shouldn't accidentally become another place where sensitive data leaks.

So Alchimista gradually became less of a "RAG application" and more of an infrastructure layer around the complete evidence path.

Privacy as part of the pipeline

Alchimista currently has several privacy modes.

At the strictest level, sensitive values are pseudonymized before chunking and embedding, meaning the normal retrieval index never receives their cleartext representation.

Reversible mappings live separately in an AES-256-GCM encrypted vault.

More importantly, enabled privacy policies fail closed. If the privacy service is unavailable or produces an invalid result, processing stops instead of quietly bypassing the protection.

That behavior matters more to me than adding another checkbox labelled "privacy".

Local first

An earlier version of the project leaned heavily on cloud infrastructure.

That worked, but eventually I wanted the core system to be independently runnable and inspectable.

The current baseline needs:

Docker with Compose
Python 3.11+
PostgreSQL

No GCP project, external vector database, Auth0 tenant, object store, or paid service is required.

The cloud integrations still exist as optional adapters, but they are no longer prerequisites for proving that the system works.

Starting it locally is intentionally boring:

git clone https://github.com/Daniele-Cangi/Alchimista.git
cd Alchimista
python scripts/init_local_env.py
docker compose up --detach --build --wait

Then the application is available locally with Documents, Ask, Privacy, Audit, Governance, and System in the same interface.

I wanted a proof, not just a demo

One thing I've become increasingly skeptical of in my own projects is a green UI that proves very little about the system underneath it.

So Alchimista has an end-to-end self-hosted smoke test.

It doesn't just check that the containers started.

It exercises ingestion, privacy detection, pseudonymization and restoration, protected persistence, SQL retrieval, citations, tenant isolation, AI decision evidence, audit metadata, the encrypted vault, cleanup behavior, and persistence across a PostgreSQL restart.

The successful end state is deliberately unexciting:

SELF_HOSTED_SMOKE_OK

But that line means much more to me than a screenshot of a chatbot answering a document question.

Some deliberate limitations

There are also things I don't want Alchimista to pretend.

It implements technical controls; it does not magically certify GDPR, the EU AI Act, or any other regulation.

PII detection cannot promise to identify every possible sensitive value.

The default local embedding path is designed to make the complete system independently runnable and test retrieval mechanics. It isn't a claim that a deterministic offline embedder is the best semantic retrieval system available.

And stronger pseudonymization can affect retrieval quality, which means strict privacy modes have to be evaluated against the actual domain rather than assumed to be free.

I think being explicit about those boundaries makes the system more useful, not less.

What's next

Alchimista is now at the point where I'm less interested in adding features for the sake of feature count and more interested in attacking the boundaries.

What breaks under larger document collections?

How much retrieval quality is lost under different privacy strategies?

Which pieces of AI decision evidence are genuinely useful during an investigation months later?

Where should the trust boundary actually sit when an external model is introduced?

Those are the experiments I'm interested in next.

This is also my first proper post on DEV, so I'll probably use this space less as a release feed and more as a place to document those experiments — including the ones that don't work.

Alchimista is open source and available on GitHub.

Feedback on the architecture, privacy model, or places you'd try to break it is very welcome.