The sovereign option — whose computer, whose laws

Agents at Work — CC BY 4.0

You’ve built an agent. Here’s a question the build never asked you: whose computer is it actually running on, and whose laws does your data fall under while it’s there?

For most people the honest answer is “a very large company’s, in another country, under that country’s laws” — and they’ve never thought about it, because the tool just works. This lesson is about thinking about it, because for some of the work an agent does, the answer changes what you should build.

The trade-off, stated straight

There’s a real trade-off here, and pretending otherwise helps no one.

• A public frontier tool — the big US-hosted models — is, right now, usually the most capable option. It’s also the one where your data leaves your control: it sits on infrastructure owned by a company under another country’s jurisdiction. Under the US CLOUD Act, US authorities can reach data held by US-owned providers wherever in the world it physically sits. For a lot of ordinary work, that trade is fine and you’d make it knowingly.
• A sovereign option — a model running on your own machine, or on New-Zealand- or EU-hosted infrastructure you control — keeps custody. Your data stays under your hand and your law. The cost is real too: it can be less capable, more work to set up, and it won’t have the polish of the big public tools.

Neither is “the right answer.” The point is to make the choice on purpose, matched to what the agent touches — which is Anchor 3, AI goodness at the foundation, applied to infrastructure rather than instructions.

When custody should win

Run it back through the data question from Tier 1. The more the agent touches other people’s personal information — applicants, patients, members, whānau — the more the custody side of the trade weighs. “It’s more convenient on the public tool” is a weak answer when the thing you’re feeding it is a stack of other people’s lives, held in trust.

This is also where the te Tiriti obligation stops being abstract. If an agent would touch information about or belonging to Māori — individuals, whānau, hapū, iwi — the question of whose infrastructure and whose governance is not a technical footnote; it’s a data-sovereignty obligation (Tier 4 takes this up properly). An agent quietly sending that data offshore to a public model is precisely the decision that shouldn’t be made by default.

The same pattern, a different foundation

The good news is that nothing you learned changes. The build pattern from the last lesson — scope, criteria, guardrails, test — is identical whether the model runs on a public tool or on sovereign infrastructure. The agent’s design doesn’t care where the inference happens. So the sovereign option isn’t a different skill; it’s the same agent with its feet on ground you control.

That’s the direction our own work points — the Village exists to be the sovereign end of this spectrum: the same kind of agent, running on infrastructure under New Zealand and European jurisdiction rather than offshore. It’s honest to say that end of the spectrum is younger and rougher than the polished public tools; the demo is a starting point, not a finished article. But the reason it exists is exactly this lesson: so that “keep custody” doesn’t have to mean “do without an agent.”

The build move

For the agent you’d build, ask the question the tool never asks:

• What does it touch — my data, or other people’s held in trust?
• Where does the inference happen — whose computer, whose jurisdiction?
• Does the sensitivity of the data justify the capability trade — public-and-capable, or sovereign-and-in-my-control?

Sometimes the answer is the public tool, chosen knowingly. Sometimes it’s sovereign infrastructure, because custody matters more than polish for this data. The wrong answer is the one you never actually made.

Next

Tier 4: putting the agent to work, watching it while it runs, the law you’re actually under, and the duties you carry to the people on the other side of it.