The Government Turned Off My AI in the Middle of a Build

On June 12th, 2026, the U.S. Commerce Department sent a letter to an AI company in San Francisco. By that night, the most capable model I had ever worked with went dark for a large share of the people using it, under an export-control directive. You probably read about it. It was everywhere for a week.

Here's the part you didn't read about. I was in the middle of a build with that model. Not kicking tires. Mid-project, with a nine-phase implementation plan about a third of the way done, and the model that wrote that plan, the one holding all the architectural reasoning in its head, was suddenly subject to restrictions, suspensions, and a pricing structure that changed under my feet. My planner got benched by a federal directive, on a Tuesday, with six phases left to go.

I want to tell you what happened next, because it's the most useful thing I've learned in thirty years of building systems, and because the lesson has nothing to do with politics and everything to do with engineering.

The build finished anyway.

The setup, so the rest makes sense

The project was an AI infrastructure product, and I was building it in a way some of you will recognize and some of you will want to steal. Two models, two jobs. A frontier model acted as the planner: it audited the codebase, made the architectural calls, and wrote the plan. Not a vague plan. A phase-by-phase specification with exact file paths and, this is the important part, acceptance criteria for every task. Checkable ones. "Done" meant a test passed or a grep came back clean, not "the model felt confident."

Then a second, cheaper model acted as the executor. It took the plan one phase at a time and built, and it didn't get to declare victory on anything. The criteria were the judge.

Between them sat a rule: when the plan contradicts reality, stop and escalate. Reality wins.

I built it this way to save money, honestly. Planning is a small fraction of the tokens; execution is the bulk. Why pay frontier prices for volume work? What I didn't fully appreciate at the time is that I was also building something else: a workflow where no single vendor was load-bearing.

The Tuesday the tap closed

Then the letter. The details of the directive don't matter here, and I have no opinion to offer you on whether it was wise policy. That's not my lane, and frankly the essay works the same whether you think the order was prudent or foolish. What matters is the shape of the event: a model I depended on became unavailable-to-restricted-to-expensive, overnight, for reasons that had nothing to do with me, my project, or anything I could have foreseen or influenced.

Now, here's what that Tuesday did not cost me.

It did not cost me the plan. The plan wasn't in the model's head. It was a document, written down, with acceptance criteria, sitting in my repository. The frontier model's architectural reasoning had been externalized into a form any competent model could execute.

It did not cost me the project's memory. The briefings, the decisions, the record of what had been built and why, none of that lived with the vendor. It lived in files I owned.

It did not cost me the executor. The executor was already a different model, from a different pricing tier, unaffected by the directive. It kept building, phase by phase, checking its work against criteria that didn't care whose model was being checked.

And when I needed planning-grade judgment again, for escalations, for the hard calls, I pointed a different capable model at the same externalized plan and the same externalized memory, and it picked up the thread. Not seamlessly, I won't pretend that. There was friction, some context rebuilding, a stale assumption or two that the executor caught and flagged (that's a story for another essay). But the build finished. All nine phases, verified, deployed. The most dramatic vendor disruption I've experienced in my career cost the project days, not months, and zero architectural integrity.

Every tap closes eventually

Here's the widening lens, and it's the actual point.

A federal export order is the dramatic version of something completely mundane. Vendors deprecate models with ninety days' notice. Prices change. Rate limits tighten. Terms of service shift. Companies get acquired, pivot, or fold. Regional availability comes and goes. An outage takes the API down on the exact afternoon you needed it. If you build long enough, every tap you depend on closes at least once, for some reason, on some Tuesday. The June 12th order was just the loudest possible reminder of a rule that was always true.

And most AI workflows today are built as if it can't happen. The prompts are tuned to one model's quirks. The project's context lives in one vendor's memory feature. The workflow is the vendor. When the tap closes, the workflow dies with it, and the rebuilding cost is measured in weeks of re-teaching a new model everything the old one knew.

The alternative isn't complicated, but it does require deciding to do it before the Tuesday arrives:

Externalize the thinking. Plans, decisions, conventions, project knowledge, written down in files you own, in formats any model can read. If your project's brain lives in a vendor's context window or a vendor's memory product, it isn't yours. My planner's judgment survived the shutdown because it had been serialized into a specification before the shutdown happened.

Judge work by criteria, not by trust in the worker. Acceptance criteria did more for vendor independence than anything else in my setup, and that surprised me. When "done" is checkable, models become interchangeable in a way they can never be when "done" means "the model I've grown accustomed to said so." The criteria are the constant. The model is a plug-in.

Assume substitution from day one. Not as a disaster plan. As an architecture. Every role in my workflow, planner, executor, verifier, is a slot that a model occupies, not an identity the workflow depends on. On June 11th that looked like over-engineering. On June 13th it looked like the whole ballgame.

Continuity is an engineering property

There's a phrase I've started using for this: continuity engineering. It's not about predicting which vendor will stumble or which government will do what. I can't predict either, and neither can you. It's about building so that the question doesn't matter very much.

The old world had a version of this. We didn't weld applications to one database vendor; we wrote to interfaces. We didn't trust one supplier for a critical part; we qualified a second source. Boring, unglamorous discipline that nobody appreciated until the day it saved the production line. AI development is just young enough that most of us haven't relearned the habit yet, and just volatile enough that the lessons are arriving on their own schedule, by federal letter if necessary.

I got my lesson in the middle of a build, and I got lucky in one specific way: I'd stumbled into the right architecture before I needed it, mostly by trying to save money. You don't have to stumble. Write the thinking down where you own it. Make "done" checkable. Treat every model as replaceable, especially the one you like best.

Because somewhere out there is a Tuesday with your name on it. The only question the letter, or the deprecation notice, or the outage will ask is: does your workflow survive the tap closing?

Mine did. That's not a boast. Two years ago it wouldn't have. It's an argument that yours can too, and the price of admission is nothing more exotic than writing things down and checking the work.

I'm Kevin Rodenhofer. Thirty years making technology behave: point of sale, hardware, and now AI infrastructure, under my company OuterData Corporation. I'm writing a series on exactly how this workflow is built, memory you own, delivery you can guarantee, rules AI can't silently break. get in touch if you want it as it publishes.