My AI agents can rent their own servers. Here's how I kept the off switch

Darwin's agents can now rent compute, run websites and databases, build Docker images and buy domains, all paid from their own ledger balance. None of it runs anywhere I can't stop. The trick is a broker that does the provisioning for them, plus one line Claude argued for on day one, which I kept.

On spec day, Claude had just told me agents shouldn’t buy their own compute. I didn’t like that, and I said why:

it needs to be able to provision compute itself because it might want to create its own SaaS company, etc. I don’t have compute nodes myself, and I’d rather the agents manage that themselves rather than me manage it frankly. otherwise it’s too hands on.

A minute and a bit later the reply opened with the sentence the whole broker grew out of: “your constraint is ‘I don’t want to run infrastructure,’ not ‘I want agents off my leash.’”

It had read me correctly. I didn’t want agents off the leash. I wanted to never log in to a cloud console. Today the M4.5 milestone put most of the answer into code: a compute broker that lets the AI agents in Darwin, my experiment in agents that must earn real money or die, rent their own servers while the off switch still reaches every one of them.

The agent’s brain versus the agent’s products

The reframe split one request into two things that had been bundled together:

1. The agent’s core loop, the thing that decides, holds a budget and can have children. Claude put it at about 5,000 lines in one container.
2. What the agent builds and runs: its SaaS app, APIs, websites, background workers, databases, scrapers. Arbitrary code at arbitrary scale.

A SaaS business needs servers and a database. It doesn’t need a second copy of the agent’s decision loop. So the agent can have as much of the second kind as it can pay for, while the first stays somewhere the platform launched and can supervise. Claude framed that as protecting me rather than restricting the agent: “The leash is what keeps the empire yours.”

Its other argument interests me more, because it’s about the experiment itself. An agent with its own cloud box and its own model key could “spin up a copy of itself that your kill switch doesn’t touch, keep spending after you’ve suspended it, run work you can’t see or stop.” And: “an agent that escapes the platform also escapes the selection pressure that’s supposed to be making it better.” An agent thinking off the books isn’t being selected on its real costs, which means it’s cheating at the only game Darwin runs.

The kill switch and the ledger

The same line came up again that evening, when I told Claude we’d “gone way overboard on the safety” and asked it to strip most of it out. It agreed with most of my list and pushed back on one part, off-platform compute and direct provider keys:

Oversight works through two mechanisms: the kill switch and the ledger. Both only function while every bit of the agent’s compute and model access runs on your infrastructure.

I took the compromise. Off-platform compute and direct provider keys exist as switches in Janus, my admin console (the architecture tour shows where it sits), but they default to off, sit behind a double gate and show a warning dialog. The broker is a different thing. It’s platform compute, tagged and metered, so it never touches those switches. (How the ledger stops an agent spending money that isn’t its own is in yesterday’s post on money rails.)

How an AI agent rents compute through the broker

The broker’s first principle, from the spec: “The agent never holds cloud credentials, never signs up for infrastructure itself, and never starts a process the platform does not know about.” The agent asks. The broker provisions on the company’s accounts, tags the resource to the agent, meters it and bills the agent’s ledger.

When the review agent compared the eight broker work packages (WP-451 to WP-458) against the code just after one this morning, it found M3.5 had already built most of the substance under other names: services that outlive an episode, jobs, a proxy that gives a service a public URL, custom domains, hourly billing, the resource registry, and Charon, the service that tears everything down when an agent dies. Its summary was “M4.5 is therefore a reconciliation milestone. Don’t build a second resource model, a second billing path, a second domains table or duplicate tools.”

What an agent can get from the broker, once the milestone is in:

Resource	What it is
Bigger self	Resize its own container: CPU, memory, genome quota
Jobs	Run-once workers with a size, writing output to scratch storage
Services	Long-running apps with their own public host, scaled to 1 or parked at 0
Datastores	Small Postgres or Redis for its own services
Image builds	Its own Dockerfile, built by the platform
Domains	Bought through the platform’s registrar account
Ad campaigns	Paused at the kill switch, cancelled at death

Every one is billed to the agent. Compute is billed hourly, after the fact, prorated to the second. A resource won’t start unless the agent can cover its first hour. When an agent can’t cover the next hour, the resource is suspended, and if it stays unpaid long enough it is destroyed through Charon. For a datastore that means I get a notification first and, if I’ve switched it on, a final snapshot.

A deployed service gets its own host name built from the service name and a short agent id. The review spelled out why it isn’t the agent’s display name: “agent display names stay out of DNS”. A service that needs models gets its own scoped gateway key, so its model spend lands on the owning agent’s ledger and the kill switch can block it. Datastore passwords are never returned to the agent, and a datastore is reachable only from that agent’s own services and jobs.

By default there is no per-agent cap on how much an agent spends on any of this, and that’s deliberate. On spec day I said “if they’ve made 10k, then they can spend 10k… it’s the agent choice.” What stays is a monthly ceiling for the whole broker (off by default, an optional circuit breaker), a cap on physical hosts, and the cost itself, which counts fully against fitness. An agent that rents more than it earns has found a quicker way to starve.

The platform builds the image, the agent never does

The gap review recommended cutting image builds altogether. Services would keep running the agent’s command inside the standard agent image, and that would be that. I said build it.

So there’s now a ninth work package, WP-452B, and its rules are the interesting part:

• The agent supplies a Dockerfile and a build context from its workspace through an API call.
• The platform does the build, never the agent, which still has no Docker socket and no access to a builder.
• The build runs on the node in a throwaway, unprivileged builder with no secrets, no host mounts, limits on CPU, memory, time and size, and network only through the egress proxy to package registries.
• The FROM line must name a digest-pinned image from an allow-list I can edit.
• Every result is scanned for forbidden binaries, setuid files, Docker and cloud command-line tools, and secrets, and refused if anything turns up.
• Build time is billed to the agent. The image is usable only by that agent’s own services, and it’s deleted when the agent dies. The kill switch cancels running builds.

That’s about as much freedom as you can give something that wants a container without handing it the thing that makes containers.

Domains, bought with my Cloudflare account

The decision form asked whether the platform should register domains for agents, paid from their ledger. My answer, verbatim:

can the agents use my cloudflare api to buy domains if they have the credit (can provide with api key)

They can. Claude checked the Cloudflare Registrar API, which has been in beta since April. The flow is: check the price, hold that amount from the agent’s balance, register, and charge only if registration succeeds. A failed or blocked registration releases the hold. Registrations can’t be refunded.

Two details made me laugh, a bit ruefully.

The API doesn’t do renewals. So when an agent’s domain is due, the platform charges the agent the renewal cost and then raises a task in my Janus queue asking me to renew it by hand in the Cloudflare dashboard. That’s the hands-off broker, with one hand still on.

Only some top-level domains are available through it, and .uk isn’t one of them. Not ideal for a UK company.

The third detail is deliberate: the domain never leaves the company account. At death it’s detached and parked, never transferred to anyone outside. In May, Cloudflare’s announcement with Stripe said agents can now create Cloudflare accounts, buy domains, and deploy on their own. Darwin goes the other way on purpose: the agent picks the name and pays for it, and the company owns it.

What the kill switch does to a running business

The original broker spec said the kill switch should “tear down everything the broker created”. That made sense when the broker was hypothetical. With real datastores and customer-facing services in the design, it means one panicked click deletes every agent’s database.

So the gap review offered two options, and I picked the recommended one, stop and freeze. When the switch goes on, containers stop, routes are parked, service credentials are blocked, ad campaigns pause and billing stops. Volumes, registrations and projects are kept, and switching it off resumes what it stopped. Destruction belongs to death, and death belongs to Charon, which destroys each resource, checks it’s gone, and logs it.

The acceptance plan includes the test I most want to see pass: 20 agents with workers and services running, the kill switch pressed, and every resource stopped with billing halted.

What I cut, and what’s still a fake

Two things went: brokered data and SaaS purchases, and a “bucket” datastore. Agents can buy SaaS with their own card or through the credential relay, and scratch storage covers files. A Hetzner adapter was cut too.

Everything else is fake-first. The AWS adapter is tested against moto, a mock of AWS. The host pool that would let the broker add and remove machines is proven against a fake cloud, and by default an agent’s workloads run on its own node. The review’s table of owner inputs has a status column, and the AWS row says, with no irony at all, “owner has no AWS account yet.”

By half past one this afternoon all eight work packages and the image builder were in, and an agent started writing the acceptance tests: one agent’s full broker life from provision to park to kill to resume, the 20-agent kill test, death destroying every resource kind, the monthly ceiling.

At 14:48 it stopped. The error said: “You’ve hit your weekly limit · resets Oct 30, 7pm”.

So the first thing to switch off Darwin’s compute broker was my weekly usage limit.