Voxeltron: where AI-built software goes to run
Ask a coding agent for an internal tool on a Monday and you can have something working by lunch. Then someone has to decide where it runs. Who can reach it. What it’s allowed to talk to. What happens at 3am when it falls over, and who gets woken up. That part still takes weeks, and it takes them from the same small platform team that was already stretched before the agents arrived.
This is the imbalance I keep coming back to. AI made writing software cheap. Shipping it, running it and trusting it didn’t get any cheaper, and in some ways they got harder, because there’s so much more of it.
More software, written faster than anyone reads it
Think about what changes when agents do a lot of the writing.
There are more things to run. Small services, one-off tools, scheduled jobs, internal apps that used to be a spreadsheet. Each is cheap to write and each still needs somewhere to live, a way in, a way to be updated and a way to be rolled back.
The code is less familiar. When an engineer builds a service, at least one person understands it well. When an agent builds it, the people responsible for running it may never have read most of it. You don’t need to distrust it on sight. You do need to run it as if you haven’t fully read it, because you haven’t.
And it changes more often. Agents don’t get tired of small fixes, so the number of deploys goes up. Every deploy is a moment where something can go wrong.
Most deployment platforms were designed around a different rhythm: a team of people who wrote a service, know it well, release it carefully, and run it for months. They’re good at that. They weren’t built for a world where the writing is nearly free and the running is where the effort goes.
What Voxeltron is for
Voxeltron is where software built by AI goes to run. It’s the second half of what we’re building at Deep Thinking. Kizuna is where agents build software under your rules. Voxeltron takes what they build and keeps it running.
Concretely, it’s meant to do a handful of things well.
Deploy without a ticket queue. When a change has been built, checked and approved, getting it running shouldn’t need a person to hand-write the plumbing. Rolling it back shouldn’t either.
Keep each piece of software in its own space. Every workload runs isolated from the others, so a tool an agent wrote last Tuesday can’t wander into the payments service next to it. If you’re running code you haven’t read line by line, that’s the minimum.
Secure by default. What a piece of software can reach is decided up front and enforced, rather than left open until someone remembers to close it.
Keep it running. This is where I think the interesting work is. Voxeltron includes an operations agent that watches what’s running, notices when something goes wrong, works out what’s likely to be the cause, and proposes a fix. Within limits you set, it can apply routine fixes itself. Beyond those limits, it brings a proposal to a person and waits. Either way, what it saw, what it proposed and who approved it end up in the same record as the change that caused the problem.
We’ve been putting a lot of effort into making that operations agent trustworthy, and we wrote up what we learned measuring it against a public benchmark in what it takes to trust an operations agent. The short version is that measurement and hard checks matter much more than clever prompting.
On your own ground
Voxeltron is designed to run where you choose: your own infrastructure, a private cloud, or a hosted control plane run by us. For some organisations, especially regulated and public-sector ones, the first of those is the only one on the table, and we wanted that to be a first-class option rather than a cut-down edition. On your own ground is about why that choice matters.
What we’re not claiming
Earlier versions of this post quoted speed and density figures. I’ve taken them out. They came from our own testing, and until we can publish a benchmark anyone can reproduce, I’d rather not ask you to take numbers on trust. When we have something reproducible, we’ll publish the method alongside the result.
The same honesty applies more broadly. Voxeltron is in development. We don’t have customers, and nothing here is running anyone’s production systems yet. We’re opening a pilot programme for teams who are already feeling the gap between how fast they can build and how fast they can safely run.
Questions to ask about where AI-built software runs
If you’re deciding where your agents’ output should live, these are the questions I’d start with.
- If one workload is compromised or simply badly written, what else can it reach?
- How does a change go from approved to running, and how does it come back out? Who has to be involved?
- When something breaks, what notices first, and what can it do without waking someone?
- Where is the record of what happened, and is it the same record as the change that caused it?
- Can it run entirely on infrastructure you control, with nothing important missing?
None of these are new questions. What’s new is how many times a week you’ll be asking them.
If you’re working on this, we’d like to hear from you.