A forcing function. A cost absorber. A bridge with a fuse. Skip any one and you can have the better protocol, the unanimous endorsement, and twenty-eight years of waiting to show for it.
On January 1, 2002, twelve countries threw out their money. Not metaphorically — the franc, the mark, the lira, the peseta, nine others, gone, replaced overnight by a currency that had never existed in physical form. It is the most complex coordination change in human history: hundreds of millions of people, every cash register, every vending machine, every bank across a continent, all switching at once.
It took three days.
By January 3, 96% of the euro area's cash machines were dispensing euros. Within a week, more than half of all cash transactions were in the new currency. A physical changeover across twelve nations was substantially complete before most people had finished their New Year's resolutions.
Now hold that next to a different migration. IPv6 — the replacement for the internet's address system — was standardized in 1998. It is unambiguously better than the IPv4 it replaces: vastly more addresses, simpler routing, built-in features that IPv4 bolts on awkwardly. Every major network operator endorses it. And on March 28, 2026 — twenty-eight years later — it finally crossed 50% adoption for the first time.
A continent reissued all its money in three days. The internet took nearly three decades to half-adopt a protocol everyone agrees is superior. If your instinct is "the currency thing must have been simpler," it wasn't — it was wildly harder, involving physical logistics IPv6 never faced. So what actually determines whether you can kill a piece of coordination infrastructure and replace it?
It turns out there are three conditions. When all three are present, migrations succeed — sometimes in weeks. When any one is missing, they stall — sometimes for decades. And the reason this matters to you, if you've ever tried to deprecate an API, migrate a schema, or push an org off a format everyone hates but no one will leave, is that "the new thing is better" is not one of the three conditions. It never has been.
The cleanest natural experiment in the history of standards is sitting in your kitchen, in whatever units your measuring cups use.
The metric system is objectively a better measurement standard, and essentially every country on Earth adopted it. The United States did not. People reach for cultural explanations — American exceptionalism, cowboy individualism — but the real reason is duller and far more useful. In 1975, the US passed the Metric Conversion Act, which declared metric the preferred system and made conversion "completely voluntary." No deadline. No penalty for staying with inches. The US Metric Board was created, accomplished little, and was disbanded in 1982.
Here is the tell: the metric system succeeded in every country that made it mandatory and failed in the one that made it optional. Same system, same era, same global trade pressure. The only variable was whether there was a forcing function — a date after which the old way costs you something. France made metric compulsory in 1840 and the rest of Europe followed. The US made it a suggestion, and fifty years later you're still buying a pound of coffee.
This is the first and most ruthless condition. Voluntary migrations do not happen, because "better" is a weak, abstract motivation competing against the concrete, immediate cost of switching. You need a moment after which the old standard becomes more expensive than the new one. The euro had a legal one: national currencies stopped being legal tender on February 28, 2002. HTTPS had a softer one — in July 2018, Google's Chrome began stamping every plain-HTTP page with a "Not Secure" label, turning a passive default into an active embarrassment. Norway, pushing its car market electric, made the forcing function purely economic: punitive taxes on combustion engines, climbing toward the value of the car itself, plus a target date to end new gas-car sales. None of these banned the old way outright. They just attached a deadline and a cost to it.
If your migration plan is "we'll announce the new system and people will adopt it because it's better" — you do not have a plan. You have a hope, and hope has a measured half-life of about fifty years.
Every shared standard has a brutal collective-action problem at its center. Switching is expensive, and the benefit only arrives once everyone else switches too. So every rational actor waits for the others to go first, and nobody moves. The standard that everyone privately wants dies in a standoff of mutual waiting.
The only thing that breaks the standoff is an entity powerful enough — and willing enough — to absorb the upfront cost that no individual participant would pay alone.
For the euro, that was the European Central Bank and the national central banks. Before the switch, they manufactured roughly 15 billion banknotes and 52 billion coins and pre-distributed them to banks and shops starting months ahead, so the cash was simply there on day one. No individual merchant could have coordinated that; a central bank with a mandate could.
For HTTPS, the barrier had been money: a security certificate used to cost $50–$300 a year, which was enough friction to keep most of the web unencrypted. Then Let's Encrypt launched in 2015 and made certificates free, and Cloudflare made them one click, and Google ate the engineering cost of re-architecting Chrome. Two or three large players unilaterally changed the cost structure of the entire web. Nobody voted on it. The browser was the ballot.
For Norway, the cost absorber was a sovereign wealth fund built on oil revenue — over a trillion pounds — that bankrolled three decades of EV tax breaks, free tolls, and charging stations. It is, tellingly, the one condition no other country can easily copy, which is exactly why Norway is an outlier rather than a template. For the EU's USB-C mandate, the cost absorber was Apple: the regulator set the standard and Apple paid to rip Lightning out of its supply chain. Apple resisted for years — right up until the legal deadline made resistance more expensive than compliance, at which point the "courageous" connector quietly vanished.
When you plan a migration, name the entity that will pay the coordination tax. If the answer is "each team will get to it when they have bandwidth," you have already failed. Somebody has to build the adapters, write the codemod, run the dual system, and absorb the pain so the individual actors don't have to. If no one will, the standoff wins.
The third condition is the subtlest, because it can fail in two opposite directions.
Migrations that are all-or-nothing maximize resistance, because they force everyone to bear the full switching cost simultaneously with no escape hatch. The Soviet Union learned this the hard way in 1929, when it tried to abolish the seven-day week in favor of a five-day continuous rotation with staggered days off. There was no transition period — workers were simply reassigned to new cycles overnight. The result was that families and friends no longer shared a day off, society fractified into mismatched schedules, and after a decade of dysfunction the whole thing was rolled back. No bridge, maximal resistance, collapse.
So you need backward compatibility: a window where both standards coexist and the cost of switching is spread out and de-risked. The euro ran old and new currencies side by side for up to eight weeks, and had fixed the conversion rates three full years earlier so the financial plumbing could adapt quietly. HTTP pages kept working after Chrome started shaming them — nothing was blocked, you were just nudged. Norway never banned the combustion car you already owned; it only made the next one expensive. Each migration left the old standard standing while the new one proved itself.
But here is the trap, and IPv6 is the cautionary tale: backward compatibility can be too good. IPv6's adoption didn't stall because IPv6 is hard. It stalled because IPv4 turned out to be too easy to keep alive. A technology called NAT let entire networks hide behind a single IPv4 address, quietly defusing the address shortage that was supposed to force everyone onto IPv6. A secondary market sprang up to buy and sell the old addresses. "Dual-stack" setups ran both protocols at once and worked fine. Every workaround that made IPv4 survivable also made IPv6 optional — and optional, per Condition 1, means perpetual. The bridge never burned, so nobody crossed it. Current projections don't see the transition completing until around 2045, nearly half a century after the replacement was ready.
That is the synthesis of all three conditions in one comparison. The euro and IPv6 were both clearly superior replacements with strong institutional backing. The euro had a hard legal deadline (Condition 1), central banks that pre-paid the entire coordination cost (Condition 2), and a tight, time-limited dual-currency window (Condition 3). IPv6 had no deadline, no entity willing to make IPv4 painful, and backward compatibility so generous it removed the reason to ever finish. One took three days. The other is taking fifty years. The protocols had almost nothing to do with it.
So the rule on Condition 3 is not "provide backward compatibility." It's "provide backward compatibility with an expiration date you actually enforce." Too little and you get the Soviet calendar. Too much and you get IPv6.
One honest caveat, because the framework has a blind spot. Sometimes a coordination standard isn't replaced at all — it's skipped. Between 2013 and 2016, mobile payments in China grew roughly twenty-six-fold, and a country that had never built deep credit-card infrastructure jumped straight to phone-based payments. There was no forcing function, no cost absorber, no dual-circulation period for credit cards, because there was no entrenched credit-card standard to migrate from. You can't be trapped by infrastructure you never installed.
The lesson for builders: the three conditions govern replacing an incumbent. If you're entering a domain with no entrenched standard, you may be in a leapfrog situation instead — and the playbook there is speed and ubiquity, not deadlines and adapters. Knowing which game you're in is half the battle.
The next time you propose deprecating an endpoint, migrating a database schema, sunsetting a data format, or moving an organization off a tool everyone complains about, run the three-question test before you write a line of migration code:
The deepest and most counterintuitive lesson is the one the euro and the metric system and IPv6 all teach from different directions: the quality of the new standard is almost never the deciding factor. The deciding factors are structural — a deadline, a payer, and a bridge with a fuse. Engineer those three and you can move a continent in three days. Skip any one and you can have the better protocol, the unanimous endorsement, and twenty-eight years of waiting to show for it.
If your migration is stuck, don't argue harder that the new thing is better. Everyone already agrees. Go find the missing condition.
The trust stack you're trying to deprecate already has its IPv6 problem.
Most agent fleets are still on the patchwork — bespoke per-vendor auth, ad-hoc rating heuristics, no shared provenance — and the migration to a unified coordination layer keeps stalling on exactly the conditions the essay describes: no forcing function, no team willing to eat the integration cost, and a bridge so permissive nobody crosses it. The Agent Trust Stack is the new coordination infrastructure; the three conditions are how you actually move your fleet onto it. Set a deadline, name the cost absorber, time-limit the dual-stack. Or ship another decade on the legacy patchwork.
pip install agent-trust-stack · npm install agent-trust-stack
vibeagentmaking.com → · See the stack in action