Software written by agents needs somewhere built to run it

Everyone has seen the demo by now. You type a sentence into a chat box, a general-purpose assistant picks up the task, and a minute later the restaurant is booked, the inbox is sorted and a reply is waiting for you to send. For that kind of work it really is good, and it’ll keep getting better.

Then someone tries to point the same thing at real work. Build us a service we can put in front of customers. Run the month-end reconciliation every night, with a named person approving the exceptions and a record we can hand to an auditor. Keep two hundred workers on the same case file without them treading on each other. The demo doesn’t survive any of these, and the model usually isn’t the reason. The thing around the model was built for one person’s afternoon.

The part nobody demos

When people compare agent products they compare models and prompts, because those are the visible parts. Underneath sit two less glamorous layers that decide almost everything.

The harness is what turns a raw model into a worker for a particular job. A coding harness knows how to plan a change, edit a repository, run the tests, read the failures and try again. An operations harness knows how to read what a system is telling it, work out what’s wrong, and pick a fix that stays inside the rules. I’ve argued before that the harness is the product, and I still think so.

The runtime is where all of it actually lives. Where state is kept, what happens when a machine dies halfway through, how many workers see the same picture, who is allowed to do what, and what the whole thing costs per hour once it’s busy.

A general assistant makes reasonable choices for its job. One user. One session. State that lives in a conversation and disappears when it ends. No strong promise that an action really happened. If the machine fails, you start again. Those choices are why it feels light and quick. They are also exactly the choices production software can’t make.

Three jobs, three shapes

It helps to put three kinds of work side by side.

Building software is long work. A real change runs for hours, touches a codebase hundreds of times, fails on step ninety and has to pick up again without losing what it learned. It needs state that outlives the session and a record of what changed and why.

Running a governed business process is coordination work. Many agents act on the same case, a person approves the parts that need a person, and the output has to carry its own account of how it was produced. It needs a shared view that every worker trusts, and rules that sit on the path of every action rather than being checked afterwards.

Running either of those at the size of a real organisation is an economics problem. If every worker needs a heavy environment that’s slow to start and expensive to keep idle, the infrastructure bill is what ends the project, long before the model bill does.

One general runtime can’t be all three at once, because the shortcuts that make it good at the assistant job are the ones the other jobs can’t afford. You can bolt durability, shared state, governance and cheap isolation onto it afterwards, but in my experience you end up rebuilding the runtime one patch at a time and still not trusting it.

What the place needs to be like

This matters more as agents write more of the software. A team that used to ship a handful of services might soon be running dozens, many written by agents, most never read line by line by the people who operate them. Whatever runs that software has to assume a few things.

That any workload might be badly written, so each one is kept in its own space and can only reach what it was explicitly allowed to.

That machines will fail, so work survives the loss of the machine it was running on and carries on from where it got to, not from some checkpoint an hour ago.

That nobody will remember what happened, so operational events land in the same record as the change that caused them, and an incident review is a matter of reading rather than reconstructing.

That nobody wants to be paged for routine problems, so there’s an operations agent watching, proposing fixes, applying the routine ones within limits you set, and asking a person about the rest.

And that the bill matters, so starting a fresh, isolated environment for a piece of work is cheap enough that you don’t have to cut corners on isolation to save money.

None of these are exotic. Good platform teams have wanted all of them for years. What’s changed is the volume and the unfamiliarity of the software arriving at their door.

Where Voxeltron fits

This is the thinking behind Voxeltron, the half of Deep Thinking’s work that deals with running what agents build. Kizuna is where agents build software under your rules. Voxeltron is where that software is deployed, isolated, secured and kept running, on infrastructure you choose. There’s more on what it’s for in Voxeltron: where AI-built software goes to run, and on the operations agent in what it takes to trust an operations agent.

I want to be careful about tense. Voxeltron is in development, and some of what I’ve described above is still being built. We have no customers yet. What I’m confident of is the direction. The hard properties of production software come from the place it runs, and the right place looks different for different jobs.

It’s easy to wrap a model in a loop and demo an agent. Building somewhere that agent’s work can run safely, for years, is slower and less photogenic, and I think it’s where most of the value will end up.

If you’re working on this, we’d like to hear from you.