Your hot path has a foreign policy.

You’ve got four dependencies, none of which you control, all sitting in the hot path of a conversation your customer thinks is happening between them and you.

1. It depends on a corporation's terms of service staying friendly.

2. It depends on a government's export list staying unchanged.

3. It depends on a GPU region's capacity allocation, decided by people who have never heard of you.

4. It depends on a queue i.e. your caller's next sentence waiting behind whoever else is talking to the same frontier model that second.

Your product has a foreign policy that isn't yours.

In software we're used to dependencies being boring. Libraries, uptime SLAs, the usual. But these are not that kind.

These are dependencies with politics in them, and the industry has quietly built a voice that talks to your customers on top of all four at once. Revocable is the word

Start with the softest dependency, the corporate one. Access to a frontier model is not a capability you have since it’s a permission you've been granted that’s revocable:

• by terms-of-service enforcement,
• by a sanctions-compliance decision,
• by a deprecation notice,
• by a pricing change,
• by an acquisition,
• by a policy shift after an election.

Every centralized provider works this way.

All of them. The ones you like too.

The providers publish lists of countries they don't serve. They deprecate models on their own schedules.

They change terms when regulators lean on them, because they have to. None of that is scandalous, but add it up and be honest about what you're holding.

A capability that can be withdrawn by someone else's decision was never a capability. It was a subscription to one.

For a chatbot, maybe that's fine. For the phone line your customer calls when their card is stolen, "subscription to a capability" is a strange foundation to have chosen.

The silicon has a passport.

Now the harder dependency, the one no contract can fix is where the compute physically is, and who decides that.

Frontier models run on a class of chips that governments treat as strategic material. Export controls decide which countries can buy them, in what quantities, under what licenses.

Those decisions are made on security relationships, not on where the demand is. Which produces the sentence that should bother anyone building a global product:

Compute is mainly distributed along diplomatic lines.

Which frontier capability can run in which part of the world is settled in Washington before any CTO gets a vote.

Capability has a passport, and it gets checked at the same borders yours does. If your callers are in Jakarta, Lagos, or São Paulo (which is to say, if your callers are most of the people on Earth), the best model's proximity to them is a geopolitical variable.

Expensive, restricted, distant, and queued.

Four adjectives, every one set by someone with no stake in your product working. The industry's answer to this has been to hope. Hope the allocations grow, hope the tiers loosen, hope your region makes the next list.

Sovereignty isn't buying the GPUs.

Here's the trap in the obvious response.

"Fine, we'll run our own models on our own hardware."

The export controls are precisely why most of the world can't. The same policy that decides where the frontier providers can operate decides where you can rack an H100.

Sovereignty-as-procurement is available to a handful of governments and hyperscalers, and no one else.

But there's a version of sovereignty that doesn't require winning a chip allocation, and it falls straight out of taking the agent apart.

Most of your agent isn't a model.

It's routing, logic, state, assembled speech. Structure. And structure runs on ordinary server CPUs.

Those aren't free of politics either. Sanctions regimes reach general computing equipment, and the top of the server market has controls of its own.

But they sit in a different tier of scarcity entirely: commodity parts, decades of installed base, already racked in effectively every country you'd want to serve.

Nobody allocates them by diplomatic relationship. Nobody waits eighteen months for one. No datacenter is being built from scratch to house them.

Nobody is rationing the silicon that runs a lookup table.

Run the agent's structure locally — inside your region, inside your walls, on hardware that isn't being rationed — and reserve the frontier for the exception, consulted with redacted questions, its answers consumed off the hot path.

Then walk back through the four dependencies and watch what happened to them. The ToS, the export list, the allocation, the queue: all still exist, all still outside your control but now they can only degrade your exception path.

The conversation itself, the thing your customer actually experiences, runs on hardware you already have, in a region you already operate.

Changing which frontier you call is not a rebuild.

One supplier's outage, price change or regional restriction stops being an existential event and becomes a routing choice.

It uses the best models in the world the way a well-run country uses imports, gladly, by choice, with a domestic base that doesn't collapse when a ship gets stuck.

I don't know which dependency breaks first for whom — a ToS change, a regional restriction, a deprecation on a bad week.

I'm fairly sure that for every builder it eventually is one of them, because four uncontrolled dependencies in a hot path is not a stable arrangement; it's an incident that hasn't picked its date.

The fix isn't to hate the frontier. It's to stop living in it.