Problems
A mismatch between planning horizons and capability velocity is one of the defining—and underappreciated—features of the current AI environment.
Most large-scale AI implementation plans, whether for enterprise deployment, public services, national infrastructure, or defense, still follow multi-year cycles. Power procurement, permitting, construction, integration testing, workforce preparation, and regulatory alignment routinely take years. Meanwhile, frontier capabilities, agent architectures, inference efficiency, and the relative position of open-weight and closed systems can shift within months. A plan developed in 2024 or early 2025 may therefore be operating against a substantially different technical and geopolitical landscape by late 2026.
Several pressures make this mismatch consequential.
Physical infrastructure lags software. Data-center projects announced years earlier can still face grid-connection queues, local opposition, and supply-chain constraints for transformers and advanced cooling. Average U.S. interconnection queues run about five years from submission to commercial operation. In major European hubs such as London and Amsterdam, waits can be eight to ten years. AWS has said that securing grid connections in Europe can take up to seven years—more than the roughly two years needed to build a data center. By the time capacity comes online, assumptions about the workload mix—training versus inference, dense versus sparse models, centralized versus edge computing—may have shifted. Similar risks apply to specialized compute networks and national AI infrastructure.
Capability jumps can rewrite requirements. Plans optimized around current limitations—export-controlled chips, limited context windows, unreliable agents, or high energy costs per token—can be partly invalidated by progress in model efficiency, distillation, or specialized hardware. A constraint that appears permanent may prove temporary; an anticipated improvement may not arrive.
Geopolitical and regulatory feedback loops shift assumptions. China’s draft AI export controls, changes to U.S. chip rules, and the growing role of private labs in setting de facto capability and safety norms can all alter the premises of existing strategies. Planners face a difficult choice: rely on globally distributed systems that remain dependent on foreign supply chains and policy decisions, or build sovereign, ring-fenced infrastructure. Emerging sovereign AI initiatives are currently forcing many governments into rigid, multi-year capital expenditures. This perfectly illustrates the tension: these sovereign investments offer control but lock institutions into massive, slow-moving physical builds that are highly vulnerable to obsolescence. A middle-power strategy built on continued access to particular open weights or cloud services, for example, could be disrupted by a single policy shift.
Institutions adapt slowly. Defense acquisition, energy regulation, and international standards bodies were not designed for technologies that evolve at this pace. Procurement and doctrine built around stable platforms struggle when the underlying software stack may change every 12 to 18 months.
The mismatch is real, but neither technical progress nor infrastructure timelines are uniform. Two qualifications sharpen the diagnosis.
Capability progress is jagged rather than smoothly exponential. METR evaluations found that the task horizon of frontier AI agents doubled roughly every seven months over six years, with the post-2023 doubling time accelerating to about 4.2 months. The Stanford AI Index reports that frontier models gained 30 percentage points in a single year on Humanity’s Last Exam, a benchmark designed to remain difficult for years. Yet progress varies sharply by task. Models can win a gold medal at the International Mathematical Olympiad while reading analog clocks correctly only about half the time. Agentic systems still fail a substantial share of structured computer-use tasks—often about one in three. There is also credible evidence of a “constraint plateau” in some language-model metrics, where performance flattens because of post-training alignment overhead and infrastructure bottlenecks. For planning, this means the risk is not only being surprised by a capability jump. A plan can also be undermined by stagnation in the specific capability layer on which it depends. Strategies optimized for average progress can be blindsided in either direction.
Physical timelines are not entirely fixed. The contrast between months-scale software change and years-scale infrastructure remains important, but some physical constraints can be eased. Virtual power plants can deliver capacity in six to eighteen months. Grid-enhancing technologies can unlock 5–50% more capacity from existing transmission lines in weeks to eighteen months. Flexibility-aware siting has been estimated to achieve first energization in twelve to eighteen months, reducing timelines by roughly 3.5 to 4 years compared with conventional processes.
These approaches are not universally available, and they do not eliminate the mismatch. They do, however, change the planning question. Rather than treating every physical constraint as fixed, planners should distinguish hard constraints from institutional bottlenecks and identify which can be relaxed through procurement design, siting choices, or flexible demand.
None of this makes long-term planning futile. Secure energy supply, high-quality data regimes, talent pipelines, physical security, and clear lines of human accountability can remain valuable even as technical assumptions age. The more durable strategies treat roadmaps as provisional, emphasize modularity and continuous reassessment, and prioritize optionality over detailed five-year forecasts.
The recurring problem is not simply poor foresight. It is the structural consequence of combining rapid, uneven technical change with linear institutional and physical timelines. The practical challenge is to design implementation plans that anticipate partial obsolescence and can adapt without requiring a complete rewrite each time assumptions change.
Possible Solutions
The central challenge is to preserve enough continuity to execute at scale while treating technical and geopolitical assumptions as provisional. Pure agility is difficult to sustain in capital-intensive infrastructure and institutions. Pure long-horizon planning, meanwhile, risks brittleness.
A practical framework combines five mutually reinforcing disciplines: keep a stable core, preserve options around changeable choices, monitor the assumptions that matter, set rules for adaptation, and fund the capacity to adapt. These are not separate remedies. Together, they form an operating model for planning in a high-velocity environment.
The approach draws on lessons from modular open systems in defense acquisition, real-options logic in energy and infrastructure investment, staged capacity contracts in cloud and power markets, and open-architecture design in naval and aerospace engineering. None faces AI’s exact tempo, but each has developed ways to keep expensive foundations stable while allowing capability layers to change.
1. Keep a stable core; modularize selectively
Anchor the architecture in elements with useful lifetimes measured in years rather than months: energy supply and grid access, facility security, data quality and provenance, clear lines of human accountability, and basic networking and resilience standards. Treat models, agent frameworks, inference stacks, and some chip generations as more replaceable components.
The aim is to let the expensive, slow-to-change foundation remain relatively stable while software and capability layers can be updated. The U.S. Navy’s Acoustic Rapid COTS Insertion (A-RCI) program illustrates this principle. Historically, submarine sonar combined proprietary hardware and software in a tightly coupled system that could become obsolete well before a submarine’s 30-year service life ended. A-RCI separated the durable physical sensors on the hull from the internal processing hardware. By requiring an open architecture and using commercial off-the-shelf server racks, the Navy could update algorithms and swap server blades every few years without replacing the entire sensor suite through a multi-year dry-dock overhaul.
Modularity is not free. Disaggregated AI systems can add communication latency and operational complexity, eroding the agility they are meant to provide. Monolithic supernode architectures may offer simplicity and performance density that loosely integrated stacks struggle to match. The lesson is to modularize at boundaries where interfaces are mature and replacement is feasible—not to fragment every layer. The goal is a replaceable capability layer without unnecessary integration costs in the core system.
2. Preserve options around uncertain choices
Prefer staged commitments, parallel pathways, and reversible decisions to detailed multi-year technical prescriptions. For example:
- Contract for power and land that can support multiple generations of hardware density and cooling. Where feasible, use flexible demand, virtual power plants, or grid-enhancing technologies to shorten or de-risk connection timelines.
- Maintain multiple access routes to closed frontier models, open-weight ecosystems, and domestic alternatives rather than making the strategy depend on one provider or model family.
- Design evaluation and safety regimes around capability thresholds and risk classes rather than specific model names or architectures.
- Stage compute contracts and capacity commitments to hedge not just against rapid acceleration, but specifically against a “constraint plateau” where model capabilities or scaling returns temporarily stagnate.
This reflects real-options thinking: preserving the ability to choose among future paths can be more valuable than optimizing too early for one. In a geopolitical environment shaped by export controls, distillation races, and sudden capability changes, optionality is a form of resilience. It also hedges against the possibility that an apparently fixed physical constraint—such as grid capacity, cooling, or siting—can be partly relaxed through a different procurement or demand-management approach.
The same logic appears in other sectors. Utilities may reserve flexible load rather than firm peak capacity, while cloud providers may stage data-center shells so power and cooling can be expanded as hardware generations arrive. AI programs that commit to a single model stack or power pathway bear more of the downside when assumptions change.
3. Monitor the assumptions that matter
Implementation plans need ways to detect when their assumptions have shifted enough to justify action. Monitoring should be tied to decision gates, not treated as a separate reporting exercise. Useful components include:
- Regular, independent technical horizon scanning.
- Domain-specific metrics for the capabilities on which the plan depends. These might include energy cost per useful token, agent reliability on real workloads, performance on a relevant task class, or access to critical components.
- Triggers for both capability jumps and stagnation in the particular layer the plan relies on; aggregate measures of progress are not enough.
- Parallel monitoring of physical constraints, including whether grid queues, permitting, interconnection, and cooling bottlenecks are easing through new technologies or procurement approaches.
Because progress is jagged, monitoring should focus on the assumptions that could change a decision—not on collecting indicators for their own sake. Without this discipline, organizations may ignore obsolescence until it becomes a crisis or react to every change with a wholesale rewrite. Both responses carry costs.
4. Set adaptation rules in advance
Sensing creates value only if someone can act on what it reveals. Plans should specify which changes trigger reassessment, who has authority to make adjustments, and which decisions can be made at each level. Pre-agreed decision rights can prevent every mid-course correction from escalating to the highest political or leadership level.
Guidance should emphasize durable principles and constraints while leaving technical means flexible. Examples include human oversight for specified classes of decisions, verifiable data provenance, physical resilience standards, and minimum energy and security requirements. Detailed five-year model roadmaps and procurement lists can age quickly; the principles behind them often last longer.
This distinction is especially relevant to public-sector and military AI strategies. Doctrine and acquisition processes that lock in specific technical solutions are difficult to adapt. Processes that establish decision rights, accountability, interfaces, and performance requirements can accommodate changing tools. Modular open-systems approaches in defense provide a partial template, even though AI capability may change faster than traditional platform-refresh cycles.
5. Fund adaptation, including the cost of partial obsolescence
Some wasted effort is an expected cost of operating in a high-velocity domain, not necessarily evidence of planning failure. Organizations that assume every major investment will remain optimal throughout its design life are likely to underprepare for change. It is critical to acknowledge upfront that modularity brings integration overhead, latency penalties, and operational complexity.
Adaptation also requires people and organizational capacity. Continuous partial obsolescence can undermine workforce morale if it is not managed well. Procurement officers need to be comfortable with reversible decisions; engineers need expertise in reconfiguration as well as initial deployment. Organizations that maintain modest redundancy, retain specialized technical talent, and preserve in-house evaluation capacity can absorb change with less disruption.
The budget should account for the cost of adapting, not merely the cost of the initial investment. Staged procurement and shorter capacity commitments can reduce exposure to a single architecture release, but they require deliberate contract design and engineering capacity. The aim is neither to maximize modularity nor to hedge every bet. It is to invest enough in adaptability to avoid catastrophic rewrites without sacrificing the performance density that makes large-scale systems work.
Putting the framework into practice
Together, these disciplines create a continuous planning cycle. Establish a stable core, keep uncertain choices open, monitor the assumptions that could change a decision, define in advance who can respond and how, and budget for the people and resources needed to adapt. Then reassess those assumptions at decision gates rather than waiting for a plan to become visibly obsolete.
The most adaptive designs do not try to make every component replaceable. They preserve a stable physical and institutional foundation, modularize only where interfaces are mature, stage commitments across technical and power pathways, and track both capability jumps and plateaus. They recognize that some physical constraints can be eased while some expected capability gains may not arrive.
The goal is not perfect foresight. It is to build plans that degrade gracefully and can be updated without a full rewrite whenever the frontier moves—or stalls. For any plan already underway, a useful first test is simple: name the two assumptions most likely to age first, and decide in advance what evidence would trigger a revision.