Dario Amodei published “We Must Pace the Frontier” on September 12, calling for voluntary coordination among leading AI labs around certain development trajectories. Sam Altman and Demis Hassabis endorsed the general direction publicly. What followed in the next week was a useful illustration of how quickly a consensus call can dissolve on contact with the underlying disagreement it was meant to bridge.
Tomasz Tunguz put a sharper frame on it in “What Does Pacing Mean?”, published September 14. His observation: “pacing” means five different things to five different constituencies, and not one of them named an actual mechanism or speed. The debate is real, but it is not yet a coherent position.
That distinction matters for enterprise leaders in a way that most coverage of the pacing debate has missed.
mindmap
root((Five camps on AI pacing))
Interpretability
Understand models before<br/>adding more capability
Labor
Workers and institutions<br/>need adaptation time
Economics
Growth must service capital<br/>already deployed
Geopolitics
Preserve US position<br/>vs. competitors
Regulatory capture
Block new rules<br/>from being established
The five camps — and what none of them agreed on
Tunguz maps five positions that share the “pacing” label but mean different things in practice.
The interpretability camp wants time to understand model behavior — specifically, to develop the tools to know what a model is doing before deploying more capability. The labor camp wants time for workers and institutions to adapt without catastrophic displacement. The economics camp wants the growth trajectory to continue at a pace that services the capital already deployed in AI infrastructure — a very different concern from either of the first two. The geopolitics camp wants to preserve the competitive position of US-based labs against international peers, which in some framings means pacing is acceptable if China paces too and disastrous if it doesn’t. And the regulatory capture camp — Tunguz names it plainly — simply wants to prevent new rules from being established, using voluntary coordination as a way to preempt legislation.
None of these camps proposed a specific number. The one concrete threshold that had existed — a training-compute trigger at 10^26 FLOPS, proposed in 2023 — was obsolete before any model crossed it. What exists instead is a label everyone agrees on and a mechanism no one has defined.
For enterprise leaders, the relevant question is not which camp is right. It is which camp your vendors are in.
For the working software engineer
The camp your vendor operates from shapes what you can build with their tools. This is less obvious than it sounds.
A vendor in the interpretability camp may slow release cadences to allow safety evaluation to keep pace — which means the model you are building on today may remain the current model longer than you expect, and the next version may ship with capability constraints your current workflows do not handle well. A vendor in the economics camp is running to maintain growth — which means aggressive pricing cuts, faster releases, and an API surface that changes faster than your integration layer can absorb.
Both are legitimate positions. Neither is visible on a product spec sheet.
Keep a short inventory of the vendors whose behavior would materially disrupt your workflow if it changed. “Changed” means: slower releases, API changes, pricing restructures, access restrictions, or regulatory intervention. If you cannot describe the disruption in concrete terms, you have not mapped the dependency. Map it before it becomes a production incident.
For business owners and operators
When you hear that the AI industry is aligning on voluntary pacing, the accurate version of that sentence is: the industry is aligning on the word “pacing” and disagreeing on what it means. That matters for how you interpret vendor signals over the next two years.
An AI vendor’s camp is visible in its behavior: how often it releases, how it prices new capability, what it publishes about safety evaluation, what regulatory positions it takes, and who it partners with. These are not just product decisions — they are bets on how the next 24 months unfold. Your vendor relationships are, by extension, bets you are making whether or not you have made them consciously.
Most enterprise AI procurement still treats vendor selection as a technology problem: capability, cost, integration complexity, support quality. Vendor philosophy is a secondary consideration until it is not. The time to add it to the evaluation criteria is before a critical workflow depends on a vendor that pivots sharply.
The practical question to answer now: what is the range of outcomes across my vendor stack, and which of those outcomes would disrupt a core business process?
My take
The First American engagement gave me an early look at what vendor fragmentation costs at scale. The company had acquired more than 80 organizations over a decade, and the result was 700 software applications that needed to be audited, consolidated, and rationalized. Each acquisition had brought its own architectural choices, vendor relationships, and foundational technology bets — none of them wrong at the time they were made, but accumulating into a remediation effort that consumed years and significant capital.
The architecture work I did there — the analysis that became known internally as the Livermore Report — was essentially a map of accumulated divergence. The board needed to see that map before they would fund the consolidation. Once they could see it, they did. The lesson was not that acquisition is bad or that technology diversity is always a problem. It was that organizations rarely map the philosophical divergence across their technology stack until it has become structural debt.
The AI vendor stack today is earlier on that curve. The camps Tunguz identifies are not yet visibly diverging at the product level in ways enterprise buyers can readily see. They will. The interpretability-driven vendor and the economics-driven vendor look similar today; they will not look similar in two years. The enterprise teams that mapped this early will have optionality. The ones that did not will be running consolidation projects.
