Grab the prompt kit I built to audit your AI platform lock-in — before your switching costs compound past the point of no return

Earlier this week, I wrote about Sam Altman winning a war he didn’t have to fight: the Pentagon deal, the $110 billion raise, the Stateful Runtime on Bedrock, the infrastructure geometry that gives AWS the enterprise agentic future while Azure keeps the stateless API. If you haven’t read that piece, go read it first. Everything here builds on it.

This piece is about what happened next: OpenAI engineers accidentally leaked the existence of GPT-5.4 by committing internal code to a public GitHub repo — twice, in five days — and the internet made it about the model. Prediction markets. Hype threads. “Generational leap” speculation. The usual cycle.

I don’t care about the model. Neither should you. And the explanation requires going somewhere that nobody in the AI discourse has gone yet, because it requires holding several technical concepts in your head simultaneously and most commentary can only hold one.

Here is the thesis: The company that first makes enterprise-scale context genuinely usable — not just stored, but retrievable, reasoned about, and acted upon across trillions of tokens — doesn’t just win the AI market. It becomes the new enterprise data platform. It subsumes the SaaS stack. It becomes the system of record for organizational knowledge in a way that makes Salesforce’s lock-in look like a magazine subscription. OpenAI is betting $600 billion in infrastructure that they can get there first. Anthropic may already be getting there by accident, through the organic weight of daily enterprise coding on Claude. And the thing that determines which approach wins is a technical problem that almost nobody is discussing: retrieval at a scale that has never existed in software.

Here’s what’s inside:

• What the leak actually tells you. Not the model; the sprint, and what it reveals about the problem better models alone can’t solve.

• The SaaS stack is a filing cabinet. Why the real value was never in data storage. It was in synthesis, and synthesis is what AI does.

• The four things that have to work together. Intelligence, memory, retrieval, and execution — where the failure of any one collapses the entire play.

• The retrieval problem nobody is talking about. Why RAG can’t solve enterprise-scale context, and why whoever cracks this first has a lead competitors can’t even assess.

• The flywheel that eats everything. How comprehension lock-in compounds and what builders should do about it this week.

Let me show you why, starting with what the leak actually reveals.

Note: As of this writing (March 4, 2026), GPT-5.4 has not shipped. It exists internally at OpenAI — two auditable pull requests and a deleted employee screenshot confirm that — but there are no public benchmarks, no API availability, and no official announcement. The confirmed features from the code leaks are full-resolution image support and a priority inference tier. The 2M context window, persistent memory, and “generational leap” claims are unsubstantiated speculation. What follows is an analysis of strategic direction, not a prediction of what GPT-5.4 specifically contains.

Subscribers get all posts like these!

Subscribed

Grab the prompts

The kit includes a Quick Kit (two prompts, about ten minutes) and a Deep Kit (two prompts for full strategic assessment). Run the Quick Kit before your next leadership meeting and you'll have a map of where your organizational context is actually accumulating and a switching cost estimate broken into categories your CTO or CIO can act on. The Deep Kit adds a compound capability scorecard rated against your real production usage, plus a leadership-ready strategy brief with specific options, timelines, and first steps.

What the leak actually tells you

On February 27, an OpenAI engineer opened a pull request in the public Codex repo adding full-resolution image support. The minimum model version was set to (5, 4). Seven force-pushes later — five hours of scrambling — it was changed to (5, 3). Five days after that, a second PR referenced GPT-5.4 in a “Fast mode” slash command. Scrubbed within three hours. In between, an OpenAI employee posted a screenshot showing GPT-5.4 in the Codex app’s model selector, then deleted it.

Confirmed features: full-resolution image passthrough that skips compression (useful for schematics and UI mockups), and a priority inference tier with a /fast command. Unconfirmed: the 2M context window, persistent memory, and “generational leap” claims trace to a single Twitter thread with zero sourcing. The “alpha-gpt-5.4” model string that went viral appeared on a third-party API endpoint, not an official OpenAI service — and has no independent sourcing behind it.

The confirmed features are incremental Codex improvements. The unconfirmed features are what OpenAI needs to ship to execute the larger strategy. The hype machine conveniently conflated the two.

But the leak reveals something more important than any feature: the sprint. Six major model versions in seven months. Engineers committing internal references to a public repo twice in five days. Seven force-pushes to clean a version number. This is what it looks like when the development pace outruns coordination — and the pace is driven by a problem that better models alone cannot solve.

The a16z enterprise survey showed 75% of Anthropic’s enterprise customers already running Sonnet 4.5 or Opus 4.5 in production while OpenAI customers stick with older models because they’re “good enough.” The capability gap between frontier models has compressed to the point where enterprises choose on integration, reliability, and workflow fit — not benchmarks.

So what are the models for? They’re components of something else. Something that requires better models the way a car requires a better engine: necessary, but not the product. The product is usable context at enterprise scale.

The SaaS stack is a filing cabinet

There’s a question that sounds abstract but has concrete trillion-dollar implications: where does organizational knowledge live?

Not the documented kind. The real kind. The knowledge that determines whether a company executes well or poorly, ships fast or slow, makes good decisions or bad ones.

Right now, in virtually every enterprise on the planet, that knowledge is fragmented across a dozen systems that don’t talk to each other. The code lives in GitHub. The architectural decisions live in Confluence pages that nobody updates. The customer context lives in Salesforce. The project status lives in Jira. The informal reasoning — the why behind the decisions — lives in Slack threads that scroll past and are forgotten, in meeting transcripts that nobody reads, in the heads of senior people who eventually leave. The strategic context lives in Google Docs and PowerPoints that get shared once and then gather digital dust.

Every one of these systems is a filing cabinet. A place to put things. Some of them are very expensive filing cabinets with sophisticated search and nice UIs. But they are fundamentally passive stores of information that require humans to do the work of synthesis — to read the Jira tickets AND the Confluence docs AND the Slack threads AND the code AND the customer feedback and assemble a coherent picture of what’s actually happening and what to do about it.

Every one of those systems is full. The information exists. The problem is that the only thing connecting what’s in one filing cabinet to what’s in another is a person — and people are bandwidth-limited, they context-switch constantly, and they leave when they get a better offer. When a senior engineer quits, every cabinet is still full. What’s gone is the only system that knew which cabinets mattered, in what order, and how their contents fit together.

Now imagine a system that does what that person did — but across every filing cabinet in the organization simultaneously. It ingests from all of them, maintains a coherent model of the organization’s knowledge, and reasons about connections at a depth no individual can match. That system is the synthesis layer. Not a search engine. Not a chatbot. The thing that knows which cabinets matter, in what order, and what their contents mean together.

That is what the Stateful Runtime Environment is designed to become.

And if it works — if the compound capabilities required to make it work actually come together — it doesn’t just add a new product to the enterprise software stack. It fundamentally restructures the stack. Consider what happens when your AI agent has coherent, retrievable institutional memory: the filing cabinets become data sources, not systems of record. Jira is no longer where project knowledge lives — it’s where the agent ingests project signals that it integrates with code changes, customer feedback, architectural context, and strategic priorities into a coherent understanding of project state. Salesforce is no longer where customer knowledge lives — it’s where the agent picks up transaction data that it synthesizes with support tickets, product usage patterns, engineering escalations, and market context into a unified customer picture that no CRM has ever been able to provide.

The AI context platform is not a new product category. It’s the new enterprise data platform. It subsumes the value of every system of record it connects to, because the value was never in the data storage — it was in the synthesis, and the synthesis is what AI does.

Salesforce and ServiceNow were collectively worth half a trillion dollars a year ago for owning fragments of enterprise data. They’ve lost a combined $200 billion in market cap since the AI synthesis thesis started landing. The company that owns the synthesis layer across all enterprise data captures the value that both of them generate but neither can access alone.

Why the context layer alone is worthless

But — and this is the correction I want to make to the framing I used last week — the context layer alone doesn’t do this.

A trillion tokens of organizational memory sitting in a runtime is a landfill, not an asset. An engineer asks the agent to refactor a payment processing module. The organizational memory contains ten trillion tokens. The relevant context — the original design rationale, the security review that flagged a vulnerability, the patch that introduced an edge case, the customer complaint that surfaced because of it, the internal debate about whether to fix it properly — might be 2,000 tokens spread across five sessions over eight months. Finding those 2,000 tokens in ten trillion is not a storage problem. It’s a reasoning-about-what-matters problem, and it’s qualitatively harder than anything current AI systems do well.

The actual bet is a compound — four capabilities that must work together, where the failure of any one makes the entire play collapse.

The four things that have to work together

Intelligence × context is multiplicative

Give a mediocre model a million tokens of organizational history and it drowns. It pattern-matches on surface-level similarity, finds a discussion that sounds related but was about a different service in a different context, and synthesizes confidently from it — coherent, well-sourced, and subtly wrong.

Long context with weak reasoning is actively harmful. A strong reasoning model changes this. It distinguishes between a relevant decision and a superficially similar one from a context that doesn’t apply. It weighs conflicting evidence across sessions. It recognizes when context is insufficient. The relationship is multiplicative: each increment of reasoning expands the scope of context the model can productively use.

This is why every GPT-5.x point release is load-bearing for the context bet, even if benchmarks look incremental. They’re building the intelligence floor that determines how much organizational context the synthesis layer can use. If reasoning plateaus, the context layer degrades from “institutional memory” to “very expensive RAG pipeline that hallucinates organizational knowledge.”

Memory that doesn’t rot

Today’s AI memory is a coworker who remembers your coffee order but forgets every substantive conversation by Monday. What the Stateful Runtime needs is institutional memory at a depth that has never existed in software.

Consider what organizational knowledge actually looks like inside a large engineering organization. It’s the architect who built the payments service in 2019 and knows — but has never written down — that the retry logic has a specific interaction with the rate limiter that causes cascading failures under a particular load pattern. The only reason this hasn’t been a production incident is that the team manually scales the threshold during peak periods. It’s the decision eighteen months ago to use eventually-consistent reads, with the rationale that strong consistency would add 40ms of unacceptable latency, documented nowhere except an archived Slack thread and a design review that three people attended, two of whom have since left. This knowledge evaporates constantly. Every departure, every reorg, every on-call rotation that rediscovers the same surprising behavior the previous rotation found and explained informally but never recorded.

But organizational context isn’t static. The decision correct six months ago may have been superseded. The architectural pattern recommended last quarter may have been abandoned after performance testing. Memory that preserves context without updating it — that treats historical decisions as current truths — is worse than no memory at all. It’s institutional hallucination: the AI equivalent of the engineer who’s been at the company a decade and confidently explains how things work based on how they worked five years ago. The memory system has to maintain, resolving contradictions, deprecating stale knowledge, and tracking what’s current versus superseded versus historical-but-relevant. Whether models can do this over months of continuous operation is an open research question, not an engineering problem with a known solution.

The retrieval problem nobody is talking about

This is the crux. When your agent has access to trillions of tokens of organizational history, finding the specific context relevant to a given task is a problem that the current retrieval paradigm cannot solve. Not “solves imperfectly.” Cannot solve. The architecture is wrong for the problem.

The dominant retrieval paradigm in production AI right now is RAG — retrieval-augmented generation. Chunk your documents into passages, embed each passage as a vector, store the vectors, and at query time find the nearest vectors and feed those passages to the model. This works for factual lookup: “What’s our refund policy?” “What parameters does this API endpoint accept?”

It breaks completely for the kind of retrieval that enterprise-scale organizational context requires. And it breaks in specific, predictable ways.

It can’t handle relational queries across time. “Find the chain of decisions that led to the current vulnerability in the payment module” requires understanding temporal sequence, causation, and organizational structure. The original design document, the security review, the patch, the customer complaint, and the deferral discussion are five separate events spread across eight months with no explicit links between them. Embedding search might find documents that mention “payment module” — but it will return hundreds of hits, most irrelevant, because the word “payment” appears constantly in an organization that processes payments. The relevant context isn’t defined by topical similarity. It’s defined by causal relationship — and causal relationships are invisible to vector similarity search.

It can’t distinguish between context that applies and context that merely resembles. An organization that’s been running for years has had conversations about the current version of systems, previous versions that were rewritten, and proposed changes that were never implemented. Vector similarity treats all of these equally — same keywords, same entity names, same technical vocabulary. Distinguishing “this discussion is about the current system” from “this discussion is about a version that no longer exists” requires temporal reasoning and state tracking that embedding-based retrieval doesn’t do.

The third failure is the most fundamental: performance degrades as the corpus grows. As the organizational memory grows from millions to billions to trillions of tokens, the ratio of relevant to irrelevant passages for any given query gets worse. More false positives. More near-miss retrievals. More opportunities for the model to synthesize confidently from context that doesn’t actually apply. The naive solution — retrieve more passages, let the model sort it out — runs into the intelligence problem: a model’s ability to identify relevant context within a large retrieved set degrades as the set grows, especially for relational queries where relevance depends on connections between passages rather than the content of any single passage.

The strategic kicker is that retrieval quality at enterprise scale is invisible in benchmarks. Nobody runs evals on “can the model find the right 2,000 tokens in a ten-trillion-token organizational memory when the relevance is defined by causal chains across eight months?” There’s no leaderboard for this. The capability only becomes visible in production, at scale, over time. The company that solves it first has a lead that competitors can’t assess from the outside, because the evidence is locked inside enterprise deployments that nobody external can observe.

Retrieval is the bottleneck that determines whether the other three capabilities produce an institutional memory system or an institutional hallucination system. And it’s the one capability where a genuine architectural breakthrough — not just a bigger model or a longer context window — could create a durable advantage that no amount of benchmark improvement can replicate.

Execution at the speed of trust

When an agent runs autonomously across hundreds of tasks over weeks, a 5% per-task failure rate compounds into systemic risk. The target is closer to 99.5%, sustained across diverse tasks — including situations where organizational context is ambiguous, contradictory, or incomplete. Each capability reinforces the others: better retrieval means more relevant context, better intelligence means more careful reasoning, more coherent memory means context reflects reality. The compound improves together or fails together.

OpenAI’s Codex is improving on this axis. GPT-5.3-Codex outperforms Opus 4.6 on terminal-based debugging, catches logical errors and edge cases Claude sometimes misses, and developer communities are converging on hybrid workflows that use Codex for review precisely because of its methodical approach. But “outperforms on debugging benchmarks” is a long way from “reliable enough to run unsupervised for weeks using organizational memory.” That gap is the difference between a good tool and a trusted autonomous coworker.

The new system of record

Consider a concrete scenario. A product manager asks the agent: “Should we build the real-time analytics feature that Enterprise Customer X has been requesting?”

Without institutional context, this is a one-dimensional question. Check the feature request, estimate the effort, make a call.

With twelve months of accumulated organizational context and a working synthesis layer, the agent can draw on: the original conversation where Enterprise Customer X described the need (pulled from CRM data and meeting transcripts), the three other enterprise customers who made similar requests with different constraints (cross-referenced from support tickets and sales notes), the engineering team’s assessment from six months ago that the current data pipeline wouldn’t support real-time at the required scale (from architecture review documents), the infrastructure upgrade completed last month that removed that constraint (from deployment logs and engineering standups), the competitive analysis showing two rivals shipped similar features in Q4 (from market research and customer churn data), and the CFO’s directive that all new features need to demonstrate payback within two quarters (from the last board deck and strategic planning sessions).

No individual person in the organization has all of that context. The PM has some. The engineering lead has some. The sales team has some. The finance team has some. The synthesis — the thing that turns fragmented organizational data into a coherent basis for a decision — currently requires getting all of those people in a room, or running a weeks-long planning process, or (most commonly) just making the decision with incomplete information and hoping for the best.

The context platform does the synthesis in seconds — not because it’s smarter than the people, but because it has access to all the filing cabinets simultaneously and can connect information that no individual could connect because no individual has read everything.

The lock-in implication is deeper than anything enterprise software has produced before. When an enterprise’s organizational understanding lives on the context platform, switching providers doesn’t just mean losing accumulated institutional memory — it means losing the synthesis layer that connects every other system in the stack. The agent that knows how the customer data in Salesforce relates to the engineering decisions in GitHub relates to the strategic priorities in the board deck — that understanding can’t be exported or migrated. It exists only in the accumulated context of the platform that built it. Salesforce’s lock-in comes from data, and data is portable. The context platform’s lock-in comes from comprehension, and comprehension isn’t. That compounds with every day the platform operates.

The flywheel that eats everything

When the compound works at a specific enterprise, the progression is relentless. Month one: smart but generic agents, a talented new hire who read the wiki. Month three: agents have processed hundreds of code reviews and architectural discussions, synthesizing across silos. Month six: agents know things no individual knows — connecting decisions across teams that would never surface in normal human workflows. Month twelve: agents are the institutional knowledge layer. New engineers onboard in weeks. Product decisions draw on synthesized context spanning every department.

Now ask: what would it cost to switch? Forget the subscription — think about the understanding. Twelve months of accumulated synthesis — decision histories, cross-team connections, pattern recognition from hundreds of code reviews and incidents. All gone. The enterprise goes back to humans as the integration layer. That’s institutional capture at a depth enterprise software has never seen. And it compounds: the longer you stay, the deeper the understanding, the higher the switching cost. There’s no natural ceiling.

The race that’s already happening

Everything I’ve just described applies symmetrically. The flywheel works for whoever triggers it first. The thing that should worry OpenAI is that Anthropic may already be triggering it — not through a stateful runtime announcement, but through the accumulated weight of daily enterprise usage.

Claude Code at 54% of the enterprise coding market isn’t just a usage metric. It’s organizational context accumulating on Anthropic’s stack, right now, every day. CLAUDE.md files. Workflow patterns. Team muscle memory. Project histories. Accumulated codebase understanding built session by session across months. The context isn’t labeled “strategic asset” in anyone’s roadmap. It’s the invisible residue of developers choosing Claude Code every morning and building institutional knowledge through it without thinking about platform implications.

Anthropic’s latest projections target positive cash flow by 2028 — pushed back from an earlier 2027 estimate as compute costs scale, but still ahead of OpenAI, which burned $8 billion in 2025 with no public break-even target. The difference: OpenAI is building the infrastructure for organizational-scale context capture architecturally, with the exclusive backing of the world’s largest cloud provider and $110 billion in capital. Anthropic’s context accumulation is organic, product-driven, bottom-up.

Which approach wins depends on which direction enterprise AI adoption flows.

If it flows bottom-up — developers choosing tools, teams building workflows, organizational context accruing through daily usage — Anthropic has a significant head start. The developers who chose Claude Code six months ago have already begun accumulating institutional context that creates switching costs. OpenAI’s Stateful Runtime hasn’t shipped yet. By the time it does, months of enterprise context will have accumulated elsewhere.

If it flows top-down — CIOs signing platform contracts, procurement teams choosing infrastructure, IT organizations standardizing on a runtime — OpenAI’s Bedrock partnership and Frontier enterprise platform position it to capture context at the organizational level. A CIO who signs an AWS Frontier deal doesn’t just buy a tool. They buy a runtime that accumulates context across every team at once, at a scale that bottom-up adoption can’t match.

What makes it closer than the capital gap suggests: context accumulated organically through daily usage may be more valuable than context accumulated architecturally through a runtime. Organic context reflects how people actually work rather than how a platform assumes they work. The developer who’s been using Claude Code for six months has built workflows, habits, and institutional patterns deeply integrated into their actual process. A runtime that starts capturing context on day one is capturing context about workflows that haven’t yet adapted to its existence.

The outcome is genuinely uncertain — not something I say often about markets where one player has an 8x capital advantage. But capital buys infrastructure. It doesn’t buy the twelve months of organic context accumulation already happening on the other side.

What builders should do with this

Three questions. Ask them this week, not next quarter.

Where is your organizational understanding actually accumulating? Not your data — your understanding. Which tools are your teams using in ways that generate synthesized institutional knowledge? If your engineers are on Claude Code, your product team is on ChatGPT, your analysts are on Gemini, and nobody has thought about this, you’re building the most valuable asset in your organization — the synthesis layer — by accident, through individual tool preferences, without anyone choosing deliberately. And whatever platform those habits settle on is the platform you’ll be structurally unable to leave in eighteen months.

Is the compound improving on your platform? The model is one component — what about the rest? Is the intelligence improving alongside the memory, the retrieval, the execution? Or are you watching one capability advance while the others stall? A platform with a great model but poor retrieval wastes your organizational memory. A platform with good retrieval but unreliable execution finds the right context and botches the task. Evaluating the compound requires sustained, serious use on real workflows over weeks — not a benchmark eval, not a vibe check, not a Twitter thread comparing outputs on a toy problem.

What would it cost to leave in twelve months? I don’t mean the subscription — I mean the understanding. If you spend twelve months accumulating organizational context on a platform — decision histories, cross-team synthesis, institutional patterns, the synthesized understanding that connects every system in your stack — and then switch, you lose all of it. Your agents start over. Your synthesis layer resets. Make that decision deliberately, right now, while the context accumulation is still shallow enough that switching is merely painful rather than impossible.

The GPT-5.4 leak doesn’t matter. The model doesn’t matter. What matters is whether the compound bet — intelligence, memory, retrieval, execution, all working together at enterprise scale — gets close enough to working that the context flywheel starts spinning. Once it starts, it doesn’t stop. Once the synthesis layer is deep enough that the enterprise can’t function without it, the game is over. And whoever’s flywheel starts first has an advantage that no amount of capital can overcome — because the advantage isn’t technology. It’s accumulated organizational understanding that their customers can no longer afford to leave behind.

The game hasn’t been won. But the pieces are on the board, the clock is running, and most of the players are staring at the wrong piece.

I make this Substack thanks to readers like you! Learn about all my Substack tiers here and grab my prompt tool here

Subscribed