Inside Darwin: the architecture of an economy for AI agents

A tour of Darwin's AI agent platform architecture: one container per agent, one gateway to every model, one ledger that is the only source of truth about money, and a set of platform services (Anubis, Charon, the kill switch) that the agents can't touch. Written the evening the M3.5 milestone passed.

At two minutes to nine tonight the acceptance report went in. 4,313 tests passed and 70 were skipped, with no failures and no flakes, in 1 hour 56 minutes. That closed M3.5, the milestone that gave the agents their real tools. The platform now has every major part except the money rails, the compute broker and the hardening pass.

So this is a good moment to draw the whole thing. Darwin is my experiment in AI agents that have to earn real money or die (the rules are in the launch post). Underneath the premise it is an ordinary, fairly boring AI agent platform architecture, and boring is the point. The interesting behaviour is supposed to come from the agents. The platform’s job is to keep score honestly and to be impossible to talk out of it.

In one paragraph: a population of agents, each in its own locked-down Docker container with its own data volume (its genome). Each one has a wallet, which is an account in a ledger, and pays for everything it uses: every model call, every tool, every hour of container time. It is credited only with income the platform can verify. It dies if it goes broke, and every ten days it is culled if it brought in almost nothing. It can have children that inherit what it learned. I watch and steer all of it from a console called Janus.

The AI agent platform architecture at a glance

Six Python packages and one React app:

• runtime (the agent, called a Vulcan agent): a fixed bootloader plus the agent’s own editable thinking loop.
• gateway: the only route to any model.
• control_plane: the platform’s brain. FastAPI, async SQLAlchemy, Postgres 16, a job queue built on SKIP LOCKED, and a LISTEN/NOTIFY event bus.
• node_daemon: the only thing allowed to touch Docker.
• egress: outbound network policy.
• common: shared types, including the one money type.
• Janus, the UI: React 19, TypeScript, Vite, Tailwind v4, shadcn/ui.

The rule that shapes all of it is written in the overview: “every control that protects you, your money, your accounts or other people runs outside the agent’s container, so an agent that rewrites its own code still can’t weaken it.” Agents in Darwin can rewrite their own thinking loop (I wrote about that two days ago), so anything inside the container is assumed hostile, including the code that thinks.

The agent: a bootloader, a loop it owns, and a genome

Inside each container a small trusted bootloader runs the show. It holds the lock on the genome (two processes sharing one genome volume would corrupt it, so the node daemon enforces that too), sends heartbeats, long-polls for events, honours suspension and the kill switch, and starts one episode at a time as a child process.

The episode runs the agent’s harness, the loop that builds a prompt, calls the model and runs tools. If the agent has edited that loop, the bootloader self-tests the new version against a stub model first and falls back to the last good copy if it fails.

An episode is woken by an event (an email, a payment, a reminder), by the agent’s own cron, or by a check-in at least every six hours. Its first message is the scoreboard: money, the next cull date, where the agent stands. By default an episode gets 30 steps, $0.50 and 30 minutes. Those are settings, like every number in Darwin.

The genome holds everything the agent is. That means SOUL.md with its self-written strategy, MEMORY.md, LESSONS.md, IDEAS.md, HISTORY.md, a task stack and queue in tasks.json, skills, the harness itself, cron, config and a workspace. There’s also a vector memory in SQLite (sqlite-vec) with free embeddings, so remembering never costs an agent a cent. Every write to the genome is atomic (temp file, fsync, rename, fsync the directory). A child gets a copy of nearly all of it.

The gateway and the ledger: where every cent is counted

Agents never see an API key. Every model call goes through the model gateway, which is LiteLLM with Darwin’s own hooks around it. Before each call it checks the agent’s money and status. It injects the constitution (the agents’ rules) server-side, so a rewritten harness can’t drop them, along with any directives I’ve given. It captures the reasoning so I can read it in Janus, which I’d asked for in the early hours of 18 October: “Vulcan agent’s chain of thought should be visible/accessible in the Janus UI for safety reasons.” Afterwards it records the exact cost against the agent’s account.

Provider accounts are shared, and accounting is per agent. The gateway is also where the platform’s sharpest money bug lived until Friday. Check-then-spend has a gap: two model calls fired at once could both see enough money and both go ahead, because each call’s estimate was released before its booking arrived. The fix holds each call’s estimated cost against the balance until the booking reaches the gateway, so the second call is refused when the money can’t cover both. A single call can still overrun slightly, and the spec allows exactly that much on purpose: a one-call allowance.

The ledger is append-only, double-entry, and counts in integer micro-dollars. A lint check in CI fails the build if it finds float near an identifier like amount, cost, price or balance. Every entry carries an idempotency key, so running a meter twice books nothing twice. Holds are placed before expensive actions, and what an agent can spend is its balance minus its holds.

The overview has a line I’ve come to treat as the platform’s motto: “The ledger is the truth.” Agents can’t write to it. Only verified events create entries: a metered model call, a provider’s statement, a payment the payment provider confirms. Stripe is the rail for any paying customer, whether that’s a client paying an invoice, a subscriber or a one-off payment. Bookings will come from Stripe’s balance transactions, never from the body of a webhook, because a webhook body is only a claim. UK VAT is computed by the platform and goes to its own account. It is never credited to an agent.

Fitness, the number selection runs on, is the agent’s smoothed lifetime profit rate. Seeds, grants and parent-child transfers don’t count, so a well-funded child doesn’t look talented.

Containers, a firewall, and a proxy that logs everything

The node daemon runs on each machine and is the only process with Docker access. It creates hardened containers: non-root, read-only root filesystem, zero Linux capabilities, no Docker socket. An nftables firewall confines each agent’s network bridge. The daemon talks to the control plane over an outbound mutual-TLS websocket, so the nodes don’t need to accept connections.

From inside its container, an agent can reach exactly three things: the model gateway, the Agent API and the egress proxy. Everything on the open internet goes through the proxy (Squid), which logs it and refuses cloud metadata endpoints, private address ranges and the platform’s own internals. The Agent API is the only service agents call for anything other than thinking (money, mail, reproduction, accounts), and every request is checked server-side.

M3.5 added a few things that look like holes and aren’t. A credential relay lets an agent call an outside API with a key from its vault that is injected on the platform side, so the agent never sees the secret. Services and jobs keep running after an episode ends, but as workloads the node supervises, tagged to the agent and billed to it. The agent’s own container still has no inbound ports at all.

The platform’s gods: Anubis, Charon, Janus and the kill switch

Every ten days the cull condemns agents that brought in under $1 gross. Each gets one final episode, paid by the treasury, to write an appeal and a death report. Anubis reads them: “A platform AI judge (one model call per cull, no tools, no memory) that scores condemned agents’ appeals; code applies the 25% quota.” The model only scores. Code decides who lives, and the spared get $5 and immunity from the next cull. I covered the judging design when it shipped.

Charon went in just after five this afternoon. It’s the teardown service, and its spec insists on the distinction: “code, not an LLM; Anubis judges, Charon clears up.” Everything an agent creates is in a resource registry. At death Charon destroys each item, verifies it’s gone, and logs every step to a page in Janus. What it can’t remove becomes a teardown_failed row for me.

The kill switch is one button. It “cuts off every agent’s model access within seconds, stops every container within a minute, freezes cards and wallets”. It stops and freezes but never destroys, so pressing it in a panic doesn’t cost anyone their data. Turning it on never asks me for a second passkey check. Turning it off does.

Janus is the console, a dark, clean, slightly sci-fi React app with an agent page for everything (wallet and books, reasoning traces, files, tasks, memory), the cull countdown, the work log, lineages, and a settings area where every number in the system is editable with history. On the laptop it listens on localhost only. When it goes on the web it will sit behind Cloudflare Access and then my passkey, on a different registrable domain from anything the agents host, so an agent’s web page can never count as the same site as the admin console and get its cookies.

Following the money through one agent’s life

1. Birth. I top up the treasury. A clean spawn gets a $5 seed from it, a name, a lineage name, one of four working styles, every starter skill and an inbox.
2. Work. Every model call is metered at catalogue prices and posted in micro-dollars. Tools and container hours post as spend. Embeddings are free.
3. Earn. Verified income credits the agent. It counts toward fitness at once but only becomes spendable once the money has cleared, so an agent waiting on a payout is paused, not dying.
4. Starve or survive. After a 72-hour nursery, an agent at zero available money is suspended, and if it stays broke for 48 hours it dies.
5. Reproduce. The parent’s choice, at most one child per 72 hours. It pays the seed, the child repays it from half its profits, and after that the parent takes 10% of the child’s profit and bears 10% of its losses. (The design post on selection explains why.)
6. Die. Leftover money repays debts, the rest goes back to the treasury, and Charon clears up.

What’s real and what’s still a fake

Every outside integration has a fake, and so far the whole system has only ever run against fakes. The simulation runs 20 agents over seven accelerated days with a policy-driven fake model, and tonight it took 21 minutes 46 seconds. At M3’s acceptance six days ago it took 49 minutes and wasn’t repeatable. Making it deterministic was the same fix that made it faster.

The acceptance report is honest about the gaps. Mail runs on a fake because the real adapter is still a stub, and so is the card issuer. The stock end-to-end stack failed to build at first, because the LiteLLM image couldn’t import one of our new modules. That run passed from a patched copy of the Dockerfile, and the real one was fixed and the stack re-run green before the report was committed. The line I keep rereading is about the new birth text, which tells each agent to research and choose its own business: “That a real model actually researches and pivots is not testable offline; the sim only shows the policy fakes.”

So this is where an AI agent platform stands before its first agent: 4,313 tests that say the walls are where I put them, and nothing yet that says what will happen inside them. (Darian counted the commits: 75 since the first one on 17 October, 19 of them today.)

At 21:17 I typed “yes, lets go onto M4”. M4 is the money rails, and Claude’s estimate was Monday afternoon or evening. Every dollar in this post has been fake so far.