enterprise context is becoming the new ai platform lock-in

Microsoft Build 2026 had plenty of normal launch noise: more agents, more Copilot surfaces, more model choice, more reasons to pretend your backlog is about to become self-aware.

The part I keep coming back to is Microsoft IQ.

Not because the name is great. It sounds like a dashboard metric invented in a meeting with too much coffee.

But the shape of the product is important. Microsoft is turning organizational context into a platform layer for agents: Work IQ for Microsoft 365 signals, Fabric IQ for business data, Foundry IQ for application and agent context, and Web IQ for fresh web grounding. Work IQ APIs are scheduled for general availability on June 16, and the licensing page says API usage will be billed through Copilot Credits.

That is the real announcement.

The enterprise AI platform is no longer only the model. It is the context layer around the model.

And context is sticky.

the model is getting easier to swap

For the last two years, a lot of AI strategy sounded like model procurement.

Which model is best? Which provider has the longest context window? Which benchmark should we trust? Which one is cheapest for summarization? Which one can write better React code? Which one is allowed to see customer data?

Those questions still matter, but they are becoming less decisive.

The big platforms are all moving toward model routing. Microsoft talks openly about model diversity across OpenAI, Anthropic, its own MAI models, and other providers. GitHub and cloud platforms are also getting more comfortable with the idea that different agents may use different models for different work.

That is the sensible direction. A company should not bet its whole engineering workflow on a single model forever. Models improve, prices change, latency changes, risk profiles change, and some tasks simply need different tradeoffs.

But if the model becomes easier to swap, the durable lock-in moves somewhere else.

It moves to the layer that knows the company.

context is where the enterprise lives

Enterprise software is mostly local truth.

The architecture diagram is useful, but the real rule is in the migration note. The roadmap says one thing, but the customer escalation thread says another. The public API contract is in docs, but the important exception is buried in a pull request from 2023. The compliance requirement is in a policy document nobody reads until the audit week. The team decision happened in a meeting, then got half-summarized in Teams, then became a Jira ticket with the interesting sentence removed.

This is why generic agents hit a wall inside real organizations.

They can write code. They can explain APIs. They can search the web. They can be impressive in a clean repository with a good prompt.

But most useful enterprise work depends on knowing who decided what, which system owns which behavior, what the organization is allowed to do, and where the weird exceptions live.

Microsoft IQ is interesting because it goes straight at that problem. The official framing is a unified intelligence layer where agents and Copilot interactions are grounded in a shared understanding of the organization. Work IQ exposes Microsoft 365 context while preserving permissions and governance controls. Web IQ offers MCP-native grounding for external knowledge.

That is not just better retrieval.

That is the vendor saying: your agents should think through our map of your company.

this is useful and uncomfortable

I do not want to pretend this is bad technology.

If your company already lives in Microsoft 365, a context layer that understands mail, calendar, Teams, SharePoint, OneDrive, documents, organizational relationships, and existing permissions is genuinely useful.

An agent helping with a project should know the meeting where the decision happened. It should know the file the finance team treats as the source of truth. It should respect the same access controls a human employee has. It should not ask every team to rebuild enterprise search from scratch just so a model can answer "what is the current plan for this migration?"

That is the good version.

The uncomfortable version is that context is not portable in the same way a model endpoint is portable.

Once your agents depend on Work IQ semantics, Microsoft 365 permissions, Copilot Credits, Fabric ontologies, admin controls, MCP tools, and whatever ranking logic decides which internal fact matters, you have built more than an app. You have built on a vendor's interpretation of your organization.

That may be worth it.

But it is still lock-in.

lock-in is not always a trap

Engineers sometimes talk about lock-in as if it is automatically a moral failure.

That is too simplistic.

Every useful abstraction creates some lock-in. Postgres locks you into Postgres behavior. Kubernetes locks you into Kubernetes concepts. Stripe locks you into Stripe's payment model. GitHub locks you into GitHub's pull request workflow. The question is not "is there lock-in?" The question is whether the value is worth the exit cost.

For enterprise context platforms, the exit cost may be higher than teams expect.

Moving from one LLM API to another is annoying, but manageable if you planned for it. Moving from one vector store to another is also annoying, but at least the data shape is somewhat visible.

Moving away from a context layer that has become the nervous system for agents is harder.

What exactly do you export? Documents, yes. Calendar events, yes. Messages, maybe. Permission models, organizational graphs, ranking behavior, implicit relationships, access checks, tool definitions, skills, policies, and usage history? That is where it gets messy.

The most valuable part of the system is not only the raw data. It is how the platform turns the raw data into usable context at runtime.

That runtime behavior is hard to reproduce.

context governance becomes platform work

The practical question is not whether companies should use Microsoft IQ. Many will, and for good reasons.

The practical question is who owns the context layer.

If agents are going to reason over company memory, then context cannot be treated like a magic backend feature. It needs platform ownership.

Someone has to answer boring questions:

Which data sources are allowed to ground agents?
Which agents can use Work IQ, Web IQ, Fabric IQ, or custom MCP servers?
How are permissions inherited and audited?
What happens when an agent cites stale context?
Which teams can publish tools or skills into the agent environment?
How is usage billed, budgeted, and explained?
What is the fallback path if the context provider is unavailable?
How do you test whether the retrieved context was good enough?

Those questions sound operational because they are.

The mistake would be letting every team wire agents directly into whatever context source is easiest, then discovering a year later that nobody can describe which agents know what.

That is how "AI adoption" becomes another enterprise archaeology project.

microsoft is not the only one doing this

Microsoft is just the clearest example this week.

AWS is packaging agent tooling with IAM, CloudTrail, CloudWatch, managed MCP, docs retrieval, and sandboxing. GitHub is exposing cloud-agent configuration through APIs. Docker is hardening images and MCP servers. Everyone is converging on the same truth: agents need governed context, tools, permissions, logs, and runtime boundaries.

The model is the flashy part.

The platform is the part enterprises actually buy.

This is also why "model-agnostic" claims need careful reading. Web IQ being MCP-native and model-agnostic is useful. It means you are not necessarily locked into one inference provider. But a model-agnostic context layer can still be a context lock-in.

You may be able to swap the brain.

You may not be able to swap the memory.

what i would do before standardizing

If I were evaluating this inside a real company, I would not start with a grand AI architecture diagram.

I would start with one workflow where context is obviously the bottleneck.

Maybe support escalation summaries. Maybe engineering design reviews. Maybe compliance-heavy product changes. Maybe internal developer onboarding. Pick something where the agent needs real organizational memory, not just a web search and a codebase.

Then measure the unglamorous stuff.

Did the agent find the right source documents? Did it respect permissions? Did it cite useful evidence? Did it miss important context? Did it retrieve too much irrelevant noise? Did humans trust the answer more, or did they spend the same amount of time verifying it? What did the workflow cost in Copilot Credits or equivalent usage units?

Most importantly: document the dependency you are creating.

Which APIs are now in the critical path? Which data sources matter? Which admin settings define the security boundary? Which vendor-specific semantics would be painful to replace?

That is not anti-vendor paranoia. It is basic engineering hygiene.

the punchline

Microsoft IQ is a good signal for where enterprise AI is going.

The winning platforms will not just offer better models. They will offer better access to the messy, permissioned, constantly changing context inside the company.

That is useful. It is also where the next generation of lock-in will live.

The old cloud lock-in was compute, storage, databases, and deployment pipelines. The new AI lock-in is organizational memory, tool permissions, grounding behavior, and the agent runtime that makes those things usable.

So yes, use the context layer. The generic assistant that does not understand the organization will be too shallow for serious work.

But do not treat context as a free ingredient.

Context is infrastructure now.

And once your agents depend on it, it deserves the same boring attention as every other piece of infrastructure: ownership, observability, cost controls, security boundaries, portability plans, and a clear understanding of what happens when it lies.