The argument over an AI bubble has moved well beyond specialist finance circles. In June 2026, the Bank for International Settlements estimated that the five largest hyperscalers were set to spend more than US$1 trillion on AI-related capital expenditure across 2025 and 2026. It warned that commitments were outpacing earnings and free cash flow, while expected returns remained uncertain.1
That does not prove a bubble, still less tell us when one might burst. It does establish that organisations are adopting AI inside a commercially unsettled market: extraordinary investment, rapid technical change, subsidised or bundled access, proliferating suppliers and business models that have not all been tested through a downturn.
The most important planning distinction is therefore between the technology and the commercial structure around it. Investor wealth can be destroyed while a useful technology continues to spread. Excess capacity can lower prices. Failed suppliers can leave talent, infrastructure and intellectual property for stronger owners. A market correction may accelerate practical adoption even as it punishes those who financed the exuberant phase.
For an organisation using AI, however, that is not automatically good news. The capability may survive while the chosen vendor, product, model, interface or price does not. The prudent question is not simply whether AI will endure. It is whether the organisation can preserve what it has learned and built when the market changes around it.
A bubble can burst without ending adoption
Technology bubbles are often discussed as a verdict on the underlying invention. For organisational planning, that is the wrong level of analysis. A financial bust can coexist with durable adoption because the market is correcting the price, timing and ownership of the technology rather than erasing its usefulness.
This distinction matters because organisations can be right about AI and still make a poor commitment to a particular layer of the market. A successful pilot can become embedded in a workflow, acquire internal champions, accumulate proprietary data and shape job roles. By the time continuity is considered, the cost of moving may be much greater than the original cost of adoption.
Fear of missing out (FOMO) intensifies that risk. Urgency encourages leaders to treat supplier selection as an innovation choice rather than a continuity, dependency and governance choice. Reversible experiments quietly become operational commitments. A tool that began as optional becomes the place where prompts, decisions, source material, evaluation criteria and project history live. The organisation has not merely bought access. It has allowed part of its capability to become captive.
None of this is an argument for delay. Waiting until the market is settled may mean waiting until much of the learning advantage has passed. It is an argument for speed with reversibility: adopt, learn and exploit the present platform without confusing the platform with the capability being created.
Four ways an AI workflow becomes stranded
Supplier failure is the most visible scenario, but it is not the most likely disruption for every organisation. A platform can remain healthy and still change in ways that require costly migration. Four different failure modes should therefore sit in the same continuity conversation.
On a narrow screen, each failure mode is shown as a separate card.
| Failure mode | What changes | Organisational exposure | Planning response |
|---|---|---|---|
| Supplier distress | The company runs out of capital, enters insolvency or can no longer support the service. | Access, support, data recovery and specialist knowledge may disappear together. | Retain exports, documentation and a tested emergency exit route. |
| Ownership or strategy change | The product is acquired, integrated, repositioned or deprioritised. | Roadmaps, terms, people and integration priorities change even when the service remains. | Record which benefits depend on the current owner and what would trigger reassessment. |
| Model or product retirement | A model, endpoint, interface or feature is deprecated and replaced. | Behaviour changes, evaluation must be rerun and integrations may need rebuilding. | Use stable services for critical work and keep change tests outside the vendor. |
| Pricing reset | Bundled access is capped, metered, re-tiered or moved to consumption pricing. | A workflow that looked inexpensive at pilot scale becomes difficult to budget at operating scale. | Calculate a shadow cost under plausible metered pricing before dependence deepens. |
The examples are already visible. Builder.ai, once one of the best-funded British AI start-ups, entered insolvency proceedings in 2025; the related British company is now recorded as being in liquidation. The lesson is not that every young supplier is unsafe. It is that funding, prominent backers and market attention are not substitutes for a continuity plan.2
Acquisition creates a different kind of uncertainty. Cognition announced in July 2025 that it was acquiring Windsurf’s product, intellectual property, brand and business, with integration into Cognition’s products to follow. That may strengthen a product rather than weaken it. It still changes the dependency: customers who selected one company and roadmap find themselves relying on another.3
Large providers do not remove migration risk. OpenAI’s current deprecation policy says that generally available models receive at least six months’ notice, while preview models may be withdrawn on much shorter notice and are not recommended for business-critical production unless the customer can migrate quickly. This is responsible lifecycle management, not vendor failure. It is also a reminder that continuity has to be designed by the customer.4
Pricing can move just as quickly. Cursor explained in 2025 that difficult agent requests could cost it roughly an order of magnitude more than simple requests, then shifted from a fixed-request allowance towards included usage valued at application programming interface (API) prices. It later announced that a previously unlimited routing option would count against monthly usage. Anthropic now allows paid subscribers to move to usage credits at standard API rates after included limits are reached. These providers are not anomalies. They illustrate the pressure created when increasingly capable workflows consume highly variable amounts of compute.56
Flat-rate access can hide the operating model
Generous subscriptions are valuable precisely because they make exploration cheap. A skilled user can test several routes, attach long documents, run repeated reviews and discard weak work without calculating the cost of each attempt. That freedom helps organisations discover useful applications.
It can also create misleading unit economics. The workflow is designed while marginal use feels free. Long context is repeatedly reloaded. Entire project histories are carried forward. Expensive reasoning is used for routine transformation. Agents retry silently. Several review loops are added because the subscription price does not visibly change.
The problem often emerges after success. One person becomes ten seats. An occasional research run becomes a daily process. A bounded assistant becomes an automated workflow with tools, retrieval and background execution. The organisation then learns that its pilot price was a packaging decision, not a durable estimate of production cost.
Before a pilot becomes operational, leaders should therefore ask for a shadow cost. This is not a forecast of the vendor’s next tariff. It is a stress test based on the workflow’s actual consumption and the published metered prices available at the time.
On a narrow screen, each cost element is shown as a separate card.
| Shadow-cost element | What to retain |
|---|---|
| Representative run | Measure model calls, input and output tokens, tool use, retrieval, storage and human review for an ordinary completed task. |
| Volume cases | Price the same architecture at present volume, twice present volume and five times present volume. Record which assumptions drive the increase. |
| Commercial reset | Model the loss of bundled allowances, discounts or introductory terms. Separate seat charges from consumption and integration costs. |
| Cost controls | Identify which stages can use smaller models, shorter context, cached material, deterministic tools or human approval without weakening the outcome. |
This exercise does more than protect the budget. It exposes design choices. If a workflow becomes uneconomic when the same background material must be sent to the model on every run, the answer may not be a better contract. It may be a better way to preserve and reintroduce project state.
Platform agnosticism is a direction, not a purity test
Perfect platform neutrality is rarely possible and is not always desirable. Government guidance on cloud lock-in makes the useful distinction: switching can become difficult, time-consuming or disproportionately expensive, yet accepting some lock-in can still be rational when a managed service creates enough value. The objective is to maximise value and portability where practical, not to reduce every platform to the lowest common denominator.7
That is a better planning concept for AI than a promise that every component will be instantly interchangeable. An organisation may reasonably use proprietary interfaces, integrated tools or a particular model deeply. The risk begins when nobody can say which dependencies were accepted, what advantage they provide, how switching cost is growing or what event would make the trade-off no longer worthwhile.
Controlled portability treats lock-in as a recorded decision rather than an accidental condition. It separates the relatively durable organisational layer from the more mobile platform layer.
On a narrow screen, each layer is shown as a separate card.
| Layer | Examples |
|---|---|
| Keep organisationally owned | Business objectives; source data; prompts and instructions; taxonomies; evaluation cases; acceptance rules; approved outputs; decision history; handover records; cost and performance evidence. |
| May be platform-specific | User interface; proprietary connectors; model-specific optimisation; managed retrieval; deployment conveniences; vendor dashboards; selected integrations. |
| Must be explicit | Why the dependency was accepted; the value it creates; export limitations; estimated switching effort; accountable owner; review date; trigger for exit or redesign. |
The United Kingdom (UK) Government’s AI playbook tells public-sector buyers to consider vendor lock-in, ongoing support, data format, hidden costs and intellectual-property ownership when drafting requirements. The European Union’s Data Act similarly treats cloud switching as a market-design issue and will remove switching charges, including data-egress charges, from 12 January 2027. Regulation cannot make a poorly documented workflow portable, but it confirms that exit is not an edge-case concern.89
Design the capability to travel
Procurement terms matter, but architecture determines how much of the capability can actually move. One of the simplest and most useful design choices is to externalise state.
An AI conversation should not be the only place that knows what has been decided. At meaningful project stages, the system should create a compact, human-readable checkpoint: the objective, approved decisions, evidence posture, assumptions, rejected routes, unresolved questions, current assets and next authorised action. A later model, person or platform can resume from that document without replaying the entire history.
The immediate benefit is continuity. The less obvious benefit is cost. A well-designed handover acts as a compressed representation of project state. It reduces repeated context loading, duplicated reasoning and the temptation to return to the beginning each time work resumes. It also makes shorter context windows, cheaper models and alternative providers more usable because the important state has been separated from the transient conversation.
This does not mean reducing every rich project to a thin summary. Approved source material and full evidence should remain available where the task requires them. The design principle is to distinguish durable state from material that does not need to be carried through every subsequent step.
On a narrow screen, each design move is shown as a separate card.
| Design move | Why it improves resilience |
|---|---|
| Externalise state | Create stage handovers that preserve decisions, rationale, evidence limits, unresolved issues and next steps in a format people can read. |
| Version the operating logic | Keep prompts, business rules, taxonomies and evaluation standards outside one chat or proprietary interface. |
| Own the acceptance test | Retain representative cases, failure examples and quality thresholds so a replacement model can be assessed against the same work. |
| Separate process from model | Where proportionate, place model calls behind a replaceable interface rather than embedding one provider throughout the business process. |
| Preserve approved assets | Store data, source packs, outputs and decision records in accessible formats with clear ownership and retention rules. |
| Route by value | Use expensive reasoning where it changes the decision; use smaller models, deterministic tools or human action where they are sufficient. |
System-design rule: Do not make the model carry the whole organisation in its context window. Externalise operating state in compact, inspectable artefacts that survive the conversation, the model and the platform.
The AI Capability Survival Test
Before a pilot becomes a dependency, a leadership team should be able to complete the following record. It is not a demand for zero lock-in. It is a way to make the accepted dependency visible, priced and recoverable.
On a narrow screen, each test is shown as a separate card.
| Test | Leadership question | Minimum evidence to retain |
|---|---|---|
| 1. Capability | Can we describe the business outcome without naming the vendor? | Named outcome, owner, users and evidence of value. |
| 2. Owned state | Could another team or model resume from what we retain? | Exported data, instructions, decisions, handovers, evaluation cases and approved outputs. |
| 3. Dependency | Which benefits require this supplier, model or interface, and why are they worth it? | Dependency map, value rationale and known export limits. |
| 4. Price resilience | What would the workflow cost under metered pricing at current, two-times and five-times volume? | Dated shadow-cost model, usage evidence and spend controls. |
| 5. Substitution | What can be replaced directly, and what would need redesign or retraining? | Alternative suppliers, adapter points, rebuild estimate and skills requirement. |
| 6. Recovery | How long can the workflow be unavailable, and who owns the exit? | Recovery objective, emergency access route, supplier obligations and named accountable owner. |
| 7. Trigger and rehearsal | What event would force review, and when was the route last tested? | Price, deprecation, ownership, service or compliance triggers; dated migration or re-entry exercise. |
A red flag is not merely a weak pilot. It is a successful pilot with no owned handover, no shadow price and no tested route out. Success increases dependence faster than failure does.
Buy the platform. Keep the capability
No leadership team can select the final AI vendor landscape. Some suppliers will fail. Others will consolidate, retire products, alter terms or discover that present pricing does not support the work customers want them to perform. Large platforms will be more durable than small ones in some respects and more consequential to leave in others.
Organisations do not need to predict the bubble to plan intelligently. They need to identify the capability they are creating, understand which parts currently depend on the supplier, preserve the state and evidence required to move, and test whether the economics survive a different pricing model.
The right posture is neither paralysis nor false neutrality. Optimise for the present platform where it creates real advantage. Make the dependency explicit. Keep critical organisational knowledge in forms that can be carried forward. Reassess the bargain as the market matures.
The model can be rented. The capability should belong to the organisation.
Sources and evidence notes
Evidence posture: This article does not claim that an AI bubble is proved or predict its timing. Current evidence establishes plausible over-investment risk; the vendor examples illustrate mechanisms, not market frequency. Provider sources document their own policies. The portability and capability-survival framework is Andrew’s Intel editorial synthesis.
- Bank for International Settlements, “Progress and peril”, Annual Economic Report 2026, 28 June 2026. Sets the scale and risk context; it supports plausible exuberance, not a prediction that a bubble will burst.
- UK Companies House, ENGINEER.AI GLOBAL LIMITED company record. Financial Times, Builder.ai collapse report, May 2025. Companies House establishes current legal status; the report supplies contemporaneous funding and insolvency context. Allegations about revenue reporting are not used.
- Cognition, “Cognition’s acquisition of Windsurf”, 14 July 2025. Documents the acquisition scope and intended integration; acquisition is not presented as failure.
- OpenAI, API deprecations and model retirement notice periods, rechecked 29 October 2026. Establishes model-lifecycle and notice-period reality; it does not suggest that OpenAI is unusually unstable.
- Cursor, “Clarifying our pricing”, 4 July 2025. Cursor, “Updates to Teams and Auto”, 12 August 2025. Documents Cursor’s shift towards usage-based economics and its explanation of variable agent costs.
- Anthropic, “Manage usage credits for paid Claude plans”, rechecked 29 October 2026. Shows how a paid subscription can combine included limits with pay-as-you-go continuation at API rates.
- Government Digital Service and Central Digital and Data Office, “Managing technical lock-in in the cloud”, updated 3 September 2026. Supports controlled portability: some lock-in may be rational, but value, switching cost and exit conditions should be explicit.
- UK Government, Artificial Intelligence Playbook for the UK Government, 10 February 2025. Supports requirements concerning lock-in, maintenance, data format, hidden cost and intellectual-property ownership.
- European Commission, “Data Act explained”, rechecked 29 October 2026. Shows that cloud switching and egress cost are established policy concerns; it is not legal advice.
This article provides general decision support. It is not legal, regulatory, financial, procurement or technology-architecture advice.