The debate about an AI bubble asks whether future revenues can justify today’s investment. A different question deserves equal attention: are the organisations building AI still equipped to discover better ways of building it?
John Langford’s account of leaving Microsoft makes that question concrete. Alongside the organisational dispute sits a technical proposal: let a transformer reuse more of the computation it has already performed.
The evidence supports an architectural opportunity. It does not establish that frontier AI costs can already be halved, or that large AI companies have collectively abandoned research. The consequential possibility is that predictable gains from scaling can crowd out uncertain experiments that might change what scaling costs.
What Langford’s departure tells us
In his November 6, 2026 account , Langford describes AI Frontiers as a roughly 50-person group reorganised into Microsoft AI in early September. He characterises the receiving leadership’s philosophy as “scaling, and aggressively not research,” and says he could not get architectural innovations seriously considered for use.
That is a participant’s assessment of priorities and access to production. It is not an independent audit of Microsoft’s research culture. Microsoft’s lab page describes an organisation committed to research and open publication; the version available during this review did not independently settle the disputed account of its ending.
Langford also acknowledges the business logic: returns to scale are more predictable than returns to research. That concession matters. An organisation can make individually understandable investment decisions while gradually weakening its ability to explore alternatives.
The technical opportunity: a wider feedback channel
The Full-bandwidth transformer paper , submitted in August 2026, targets a specific bottleneck. Standard decoding feeds the selected token back into the model. Cached attention states retain information, but the previous top-layer output does not directly return to the bottom of the stack.
The proposed architecture combines that output with the next token’s embedding through a gated mechanism. Richer internal computation can therefore receive further processing without first becoming text.
The authors report experiments with one-billion-parameter models trained on up to 400 billion tokens, matching or approaching conventional baselines trained on roughly 1.5 times more tokens, with negligible additional per-token decoding overhead. Training uses scheduled extra passes, so data efficiency must be distinguished from compute efficiency.
This remains a transformer modification, rather than evidence for an entirely different intelligence paradigm. Its published experimental scale also limits what can be inferred about frontier deployment.
ByteDance Seed’s Recycler explores a similar feedback idea using a lightweight adapter. Its summary reports favourable comparisons with models having two to three times more parameters. That is a reported evaluation result, not a universal equivalence between model sizes or an independently measured production saving.
Why fewer training tokens do not mean half the bill
The distinction is easy to lose in a headline. Three quantities must remain separate:
- Data efficiency: performance reached per training token.
- Training efficiency: performance reached per total training compute or expenditure.
- Serving efficiency: cost of generating useful results at a specified quality and latency.
Even before accounting for extra training work, matching a baseline that consumes 1.5 times as many tokens implies approximately one-third fewer tokens relative to that baseline: 1 − 1/1.5. It does not imply a 50% saving.
Additional passes can reduce or eliminate the compute advantage. A smaller model may be cheaper to serve while requiring more work per training token. Actual savings also depend on hardware utilisation, batching, context length and output length.
The decisive comparison would hold total training resources constant, then measure serving cost at comparable quality. Independent replication and disclosed implementation details would make the result more persuasive. Until then, “potentially valuable architectural improvement” is defensible; a general cost-halving claim is premature.
Scaling laws do not choose an architecture
There is no contradiction between believing that scale works and investigating better ways to use it.
The Chinchilla research already demonstrated why this distinction matters. Its authors studied how to allocate a fixed compute budget between model size and training data. Their 70-billion-parameter model outperformed the 280-billion-parameter Gopher after using more training data within the same compute budget.
The lesson is methodological: an established investment recipe can leave substantial performance unrealised. Research changes the allocation problem; scaling applies resources within it.
Architectural improvements could similarly shift the available trade-offs. They might make existing compute more productive and strengthen the case for scaling an improved design. Efficiency alone predicts neither the collapse nor the continuation of infrastructure demand.
How a successful strategy can narrow its own future
The institutional concern is a hypothesis about incentives, not a finding established by one departure.
Imagine a company with a working training pipeline, committed hardware capacity and a release schedule. More data and a larger run fit existing ownership structures. A feedback architecture requires experiments, revised training procedures, implementation work and a sponsor willing to delay more predictable deliverables.
The alternative can lose before it receives a fair technical comparison. Nobody needs to oppose innovation explicitly. Teams can simply optimise for objectives that reward extending the current pipeline.
This is technological path dependence: past success shapes which future experiments are easiest to fund. Existing infrastructure may remain useful under the alternative, so the obstacle need not be stranded hardware. It may be the difficulty of changing organisational commitments.
If modest changes within the transformer family face that hurdle, more distant paradigms could face a larger one. That is a reason to examine research portfolios and adoption pathways, rather than assume all unconventional approaches are being suppressed.
Connect the architecture to useful outcomes
In The Machine That Makes Its Own Infrastructure Obsolete , the central risk is the assumed persistence of today’s relationship between capability and physical resources. Latent feedback supplies a concrete research example relevant to that argument, without establishing infrastructure obsolescence.
The Triple Squeeze of AI Economics adds the operational test: cost per correct decision. A benchmark gain matters commercially when it lowers the total cost of dependable work, including review, retries and failures.
Richer hidden states do not themselves establish truth, calibrated uncertainty or an inspectable audit trail. As argued in Falsification and AI , correctness needs evidence that can challenge a proposed answer.
A research strategy should therefore protect a route from architectural experiment to controlled evaluation to production. Scale and research both need accountable budgets and explicit success criteria.
The horse-racing analogy captures the remaining question. Financial analysis asks how much money is riding on the horses. Research strategy asks whether anyone is still funded to develop a different kind of horse—and whether it can get onto the track.