Building a Sovereign AI Factory – Part 1 of 4

Our agents don’t talk to each other. That’s the point. 

I spent a good part of this year on a question that has nothing to do with model quality: why does the distance between a good idea and a running system stay roughly the same no matter how good the models get?

The models did get better. Code generation stopped being a bottleneck a while ago, but what didn’t change is everything downstream of it. Somebody has to decide the idea is worth building, and then check that the thing which got built does what was asked. Then someone has to deploy it somewhere safe, write tests that aren’t just a restatement of the code, read the security scan, and decide whether it ships. Every one of those steps needs a person to vouch for it, which means total throughput is capped by how much attention my team has on any given Tuesday. Faster code generation just moves the queue.

So here at Edgescale, we built the other half. It runs on a single Edgescale Cube, it has been running continuously for months, and it is an early prototype – I want to be clear about that up front, because the interesting parts are structural and the rough parts are real.

What it does

An operator speaks an idea out loud, speech-to-text turns that into a structured idea record, and then a prototype builder writes the first working version of the code. From there a chain of independent agents ranks the idea, admits it or refuses it, deploys it into an isolated sandbox, writes tests against it, runs those tests, scores the result on quality, scans it for security problems, and either certifies it or cuts a repair order and sends it back around. Hands off, end to end.

As I mentioned, the agents run on one Cube. Model inference is served from a separate set of Cubes through a private gateway on a private mesh, which means inference stays inside our own fleet and never touches a public cloud or a third-party API. That matters more than it sounds like it does, and I’ll come back to it.

The foundational rule

Our agents never talk to each other.

There is no orchestrator, and there are no APIs between agents. Each agent is an independent loop that polls a shared object store, applies its single rule, writes a signed artifact, and goes back to sleep. The next agent in the chain polls for that artifact. Nobody calls anybody.

I’ll tackle the obvious objection first, because I had the same objection: polling a shared store is still coordination, so haven’t I just built an orchestrator and called it a bucket? Not quite, and the difference shows up in three places.

Failure isolation is the first. When an agent dies mid-task, nothing else notices. There’s no in-flight call to time out, no retry storm, no half-committed state living in an orchestrator’s memory. The artifact either exists in the store or it doesn’t, and when the agent restarts it picks up from what’s actually there rather than from what something else believed was true.

Extensibility is the second. Adding a gate means writing a loop that reads one artifact type and writes another. Nothing upstream or downstream gets modified, because nothing upstream or downstream knows the new gate exists.

The third is the one I care about most. With an orchestrator, the orchestrator is the thing you have to trust, and its logic is where every exception and override accumulates. Take it out and there’s nowhere for that to hide. Each agent’s rule is small enough to read in one sitting, and the only shared state is a set of artifacts you can inspect directly.

Every artifact is content-addressed with a SHA-256 hash and chained back to the idea it came from. That gives us a tamper-evident record of how any given prototype came to exist, all the way back to a person saying a sentence out loud. That record turns out to be the most valuable thing the factory produces, and it’s the subject of Part 3 of this series.

The gate chain

There are 8 gates (see graphic), each authorized by a governing principle rather than by whoever wrote it. Two of them are worth diving into a bit more detail on:

• The admission gate stamps every prototype on five checks – schema, integrity, identity, authority, and provenance – and it fails closed by construction: there is no downstream code path that accepts an unstamped artifact, so nothing can be waved through under pressure. Four of the five are mechanical and reject on the spot. The fifth, authority, is the one that does the heavy lifting – a prototype’s stated purpose has to be authorized by a governing principle before it’s allowed any further. Not reviewed by a person, not flagged for later – actually refused at the gate, in code. What makes that check credible is the set of governing principles it enforces against, and we’re still loading ours; until it’s populated, the authority stamp runs advisory, admitting anything not plainly unsafe. But the gate it runs in is already built to refuse, so the day those principles land, the refusals are wired and waiting – no new code, just content in the store.
• The test author writes acceptance tests from the idea’s intent and the deployed prototype’s actual command-line signature. It parses the entry point just far enough to recover that signature – the flags, which ones are required, the positionals – but it never reads the implementation, and it derives what output to expect from the idea, not from the code. This was deliberate, and it took a couple of tries to enforce properly. A test written from the code it tests will confirm that the code does what it does, which is repetition dressed as verification. Written from intent, it asks whether the thing the operator wanted actually happened. Those come apart more often than I expected.

The sandbox those tests run in gets zero GPU and no network egress. It can do exactly one thing, which is run the prototype.

What broke along the way

In short, plenty. But there were two key failures that were instructive.

The first was mundane. The pipeline that ingests our meeting transcripts sat there authenticating against nothing for longer than it should have, and because each agent is an independent loop that fails quietly, nothing raised its hand. It looked like a factory with no ideas in it rather than a broken connector. Independent loops are excellent at surviving failure and mediocre at announcing it. We fixed the auth and then fixed the observability, in that order, which was the wrong order.

The second was structural. We shipped agents that passed every gate and then fell over on deployment, because the gates scored the prototype and nobody scored the deploy. That’s now a permanent acceptance-test gate in the chain, which is a good illustration of the point about extensibility above: adding it took a new loop and no changes to anything else.

As of mid-July we’ve ingested 214 meetings and extracted 2,788 candidate ideas from them. The number of those that have made it through certification is much smaller, and honestly that ratio is the part I’m happiest about. A factory that certifies everything isn’t gating anything.

Why this can’t run in the cloud

The inputs are our own meeting transcripts. Our roadmap arguments, our customer conversations, our in-progress product ideas, including use cases and ideas we end up deciding not to pursue. That’s the raw material, and it’s the reason the factory produces anything useful at all.

Which means that if inference ran through somebody else’s API, we couldn’t run this. Not for policy reasons or procurement reasons. We’d be shipping our unreleased thinking to a third party as a condition of using our own tooling, and no reasonable person signs off on that.

That’s the same argument our customers make about process data. A plant’s sensor history and control logic are the most valuable thing it has, and the reason so much of it never reaches a model isn’t reluctance. It’s that the only available path required handing it over. Sovereign AI removes that trade. We ran into our own version of it building internal tooling, which is a much smaller problem than a refinery’s, and it stopped us cold anyway.

In Part 2 – the part of this that I think is genuinely hard to replicate anywhere else – I’ll cover what it means to test a prototype against physical evidence, and why a model in a data center can review your code but cannot tell you what happened when it ran.