In a recent X post, Chamath warned consulting firms that deploying Anthropic or OpenAI directly into their organizations is “letting the fox into the hen house.” That warning feels sharper after OpenAI launched the OpenAI Deployment Company, a majority-owned venture built to help organizations deploy AI systems, backed by $4 billion of initial investment and partners including TPG, Advent, Bain Capital, Brookfield, Bain & Company, Capgemini, and McKinsey (Consulting.us). Chamath’s point was that 8090’s Software Factory controls token generation and can route work to any model provider (Chamath Palihapitiya). I think that framing is pointing at the right danger, but the real issue is bigger than tokens.
Chamath’s framing gets the first control plane right: token routing matters because it stops one model from becoming the only path through which work gets done. But tokens are still the spend layer. The deeper control plane is context, because controlling context controls what the enterprise knows before an agent acts.
Model companies are doing exactly what any rational platform company would do. They are trying to move horizontally. They do not want to be a better API call forever. They want to sit inside workflows, provide agents, connect tools, remember state, learn from usage, and become the default path through which work happens.
There is nothing surprising or immoral about this. Anyone running a frontier model company would probably do the same thing as a matter of capitalist logic. The market rewards control points, and once you own one, you use it to expand into the adjacent layers. The enterprise mistake is pretending this is still only a model decision.
Right now, model lock-in is annoying but survivable. One model is a little better at coding this month, another is better at long-context analysis, and a third is cheaper for background work. You route around it. If the model is the dependency, switching is painful but conceptually simple.
Context lock-in is different. Once the same vendor owns the model, the agent layer, the workflow traces, the evals, the permissions, and the memory of how your company works, you are not switching APIs anymore. You are trying to extract your company’s working memory from someone else’s operating system. That is the part enterprises should be much more afraid of.
The first phase of AI competition was model quality: better model, better product. That was true enough for the first wave. But the gap between frontier models is already narrowing for many enterprise tasks. They are not identical, and benchmark wins still matter, but the practical difference between “good enough” models keeps shrinking in more workflows.
The second phase is the agent layer: planning, tool use, retries, evals, permissions, deployment, and UI. That layer matters a lot right now. Claude feels different partly because Anthropic has put real effort into the agentic system around the model. OpenAI, Google, and every serious enterprise vendor will copy the patterns that work, so that layer will converge too.
The third phase is context. Context will not converge, because it is unique to the company. Your customer promises, roadmap fights, support escalations, Slack debates, pricing exceptions, failed migrations, meeting rationale, owner history, and decision scars are not in the model weights. They are not universal. They are yours. This is why the next enterprise AI lock-in will be context lock-in.
Day one, letting the model provider deeper into the company feels magical. Their agent connects to Slack, Jira, Salesforce, GitHub, Drive, and the ticketing system. It summarizes meetings, updates records, drafts customer follow-ups, and answers questions that used to take an hour of internal archaeology. This is the MCP moment many companies are feeling right now: Anthropic describes the Model Context Protocol as a standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments (Anthropic). Tools suddenly connect, the agent can reach across systems, and the demo feels like the future.
But query-time reconstruction is not memory. Pulling from five tools when the user asks a question is useful, but it is not the same thing as a persistent context graph that the company owns and maintains over time. It does not necessarily preserve why a decision changed, which promise became stale, which prior attempt failed, or which owner quietly changed. It can create the feeling of memory before the company has actually built memory.
Month six, the dependency is quieter. People have built prompts, workflows, evals, habits, and internal expectations around that agent. Long-running agent traces begin to accumulate. The agent becomes the place where work is interpreted before it is acted on. The vendor’s representation of your company begins to matter more than your own. Year two, switching is no longer a procurement exercise. It is a memory migration.
The Microsoft analogy matters for structural reasons. I am not saying OpenAI or Anthropic is Microsoft, or that anything illegal is happening. Platform companies expand from control points into adjacent layers when the incentives are there. In the Microsoft antitrust case, the DOJ argued that Microsoft used operating-system power and exclusionary conduct to protect and extend its position in browsers and related software markets (U.S. Department of Justice).
The lesson is not legal. The lesson is structural. If a company controls the layer everyone depends on, it has every reason to bundle, steer, default, and absorb the layers around it. That is how platforms behave, not because the people are uniquely evil, but because the market rewards them for making themselves harder to remove.
AI makes this more dangerous than the old software version because the lock-in is less visible. In the old world, you could at least point to the database, file format, integration, or license agreement that trapped you. In the AI world, the lock-in may be a cloud of workflow traces, remembered preferences, tool histories, eval sets, prompt conventions, embeddings, permissions, and agent behavior. It will not feel like lock-in at first. It will feel like the system getting better.
This is also why forward deployment matters. OpenAI’s Deployment Company was launched to help organizations build and deploy AI systems, backed by $4 billion of initial investment, and is acquiring Tomoro, a 150-person applied AI consulting and engineering firm (Consulting.us). Anthropic, Blackstone, Hellman & Friedman, and Goldman Sachs have also announced a new AI services company where Anthropic Applied AI engineers will work alongside the company’s engineers to build Claude systems for customers (Anthropic).
Forward deployment is not bad. It is often how hard enterprise software becomes useful. Palantir proved that embedded deployment teams can create real value because they learn the customer’s actual operating environment instead of pretending the product works out of the box.
But the same mechanism that creates value also creates dependency. A forward-deployed team installs software, but it also learns how the company works. It sees the weird workflows, the unofficial process, the fragile spreadsheet, the hidden owner, the exception path, the reason the system of record is wrong, and the meeting where the real decision happens. If that knowledge gets encoded into the vendor’s agents and memory layer, the vendor is not merely serving the company. It is becoming the company’s operating memory.
Chamath’s token-control point needs to go one level deeper. Routing tokens to any model provider is useful. It gives you bargaining power on price, latency, capability, and availability. But token routing is not enough if the context layer is still trapped.
8090 is interesting here as a counterexample. EY describes its AI-native product development lifecycle, powered by 8090’s Software Factory, as an open ecosystem that orchestrates a mesh of AI agents with human oversight across the software lifecycle (EY). The instinct is right: separate the control plane from the model provider.
You can send a prompt to any model. That does not mean any model understands your company. The value is in the context pack: which customer promise matters, which Slack thread changed the decision, which Jira ticket is stale, which meeting produced the commitment, which owner is actually responsible, and which prior attempt failed. If those context packs are built inside one provider’s agent layer, you have only moved the lock-in downstream.
The right architecture is different. Enterprises should rent intelligence freely: OpenAI where it is best, Anthropic where it is best, Gemini, open-source models, specialized coding agents, small models, local models, or whatever comes next. There is no virtue in being religious about models. But the company memory layer should be neutral infrastructure.
That does not mean every enterprise has to build the whole thing from scratch. It does mean the owned enterprise context graph cannot be a black box controlled by the same vendor that owns the model and the agent harness. The company has to control it. It has to be inspectable, permissioned, portable, and transferable. Otherwise the enterprise is putting the life and blood of how it operates into someone else’s hands.
The memory layer should sit above source systems and below agents. It should know what happened, where the evidence lives, who is allowed to see it, what changed, what was promised, who owns it, and which ontology applies. Then any model can use that memory, any agent can act from it, and the company can swap intelligence providers without losing the context that makes intelligence useful.
A company brain is the memory infrastructure that lets humans and agents act from the same organizational state. It can have chat interfaces, search surfaces, and transcript sources, but those are not the thing itself. The thing itself is owned context.
In the next 24 to 36 months, many enterprise workflows will show something that sounds counterintuitive today: a decent model with a decent agent and excellent company context will beat a frontier model with a better agent and shallow context. In sales, knowing the last promise matters more than sounding smart. In support, knowing the account history matters more than prose quality. In engineering, knowing the prior failed migration matters more than another benchmark point. In finance, knowing the current exception and owner matters more than generic accounting knowledge.
It is fine to rent intelligence, and maybe even execution. The context layer is different: it is the operating memory of the company, the record of what happened, why it happened, who decided, what changed, what was promised, and what should happen next. Do you really want the same vendor that rents you intelligence to own that? I would not.
Rent the intelligence. Own the context.