AI vendor lock-in: What to check before you buy

The worst thing you can do in today's AI market is spend the next two years building your company's analytical knowledge into a platform you can't easily leave.

Models are improving, new agents are emerging, and the way people work with data is changing constantly. Yet many analytics platforms still expect companies to encode business definitions, agent instructions, and analytical workflows inside proprietary systems.

The risk isn't necessarily choosing the wrong AI platform today. It's choosing one that makes it expensive to change your mind tomorrow.

Traditional BI lock-in was largely about migrating dashboards, retraining users, and rebuilding semantic models. AI adds a new layer: the business context that agents depend on, the models they use, and the analytical work they create.

Here's how to evaluate those dependencies before you commit.

1. Semantic model lock-in: Where should your business logic live?

Semantic models are valuable. They establish consistent definitions for metrics, dimensions, and relationships so everyone, including AI agents, can work from the same understanding of your business.

But where those definitions live matters.

If you've spent years defining revenue, retention, and customer segments inside a proprietary BI semantic layer, switching tools may mean rebuilding that work. And as more AI agents rely on those definitions, the cost of moving only grows.

An alternative is to prioritize portable semantic models across systems like dbt, Snowflake, analytics tools, or Cube, so you can access them from multiple analytical tools.

The industry is already moving toward open semantic standards. Apache Ossie, formerly Open Semantic Interchange, is an open-source effort to standardize how semantic definitions are shared across BI platforms and AI agents. It's an important step toward portability, although support for an open specification doesn't automatically mean every vendor can exchange models seamlessly.

Your context should work across agents, too

Semantic models are only part of the knowledge agents need.

Your team also maintains documentation, warehouse metadata, business rules, reference queries, and instructions about how to interpret data. Increasingly, that context represents some of your company's most valuable analytical IP.

Much of that knowledge already lives in your stack. Your dbt models, transformation logic, and application code contain context that isn't captured in your warehouse. The challenge is making it available to agents without recreating everything inside each new tool.

If your data team spends six months improving the context behind an AI agent, shouldn't that work make your other agents better, too?

For example, a definition of net revenue retention shouldn't need to be recreated separately for Hex, Claude, ChatGPT, and every new agent your company adopts.

The same principle applies to agent instructions. Business knowledge stored in reusable Markdown, YAML, SQL, or version-controlled repositories is easier to inspect, improve, and carry forward than instructions maintained exclusively in a vendor's configuration interface.

Hex can sync Markdown Guides and other context from Git repositories, so teams can maintain business rules and agent instructions in version-controlled files outside Hex. Its reference repository connections also let agents draw on existing application code, SQL, and documentation without recreating that knowledge in a proprietary context layer. Combined with semantic models maintained in dbt, Snowflake, or Cube, this lets teams build on context they already own rather than locking it inside Hex.

And as agents get used, they generate more context themselves. Questions, corrections, and analytical decisions all contain valuable signals. Hex's approach to context management helps teams capture those signals, identify gaps, and improve the underlying business knowledge.

What to test: Connect a semantic model from dbt, Snowflake, or Cube, along with business instructions maintained in Git. Update a metric definition or Markdown file and confirm the change reaches the agent. Then check whether the agent can draw on existing code repositories without copying that knowledge into the platform, and whether other tools and agents can reuse the same context.

Red flag: Your team has to rebuild business definitions or maintain separate copies of agent instructions inside the vendor's proprietary modeling environment.

2. Agent interoperability: Can you use the agents you want?

Today, your employees might ask data questions in Claude, build analyses in Cursor, or investigate metrics directly inside their BI tool.

Two years from now, those workflows could look completely different.

If your analytics platform only exposes its capabilities through its own interface, adopting a new agent means either abandoning that context or rebuilding the integration.

That's why interoperability is becoming a much more important consideration.

Technologies like MCP, APIs, and CLI let external agents interact with analytical systems. But their existence doesn't automatically eliminate lock-in.

An MCP server that only retrieves answers is very different from one that supports deeper investigations or lets an agent create and modify analytical work.

Hex provides MCP access to governed analytics and a CLI that lets coding agents such as Cursor and Claude Code create projects, write SQL and Python, run analyses, and save work back into Hex.

What to test: Ask the same business question in the vendor's native interface and an external agent like Claude or ChatGPT. Check whether they use the same definitions and permissions. Then use a coding agent to create or modify a reusable analytical project.

Red flag: The external agent can only retrieve a number, or your team must recreate business logic and workflows whenever it adopts a new interface.

The broader goal is simple: your investment in governed analytics should remain useful regardless of which agent your employees prefer.

3. Model optionality: Today's best model won't be tomorrow's

The pace of model development creates another kind of dependency that traditional BI buyers rarely had to consider.

The best-performing model for a complex analytical investigation today may not be the best choice six months from now. And a model that's excellent at writing SQL might be unnecessarily expensive for generating a chart title or making a simple formatting change.

Hex's DataBench benchmark illustrates how model performance, cost, and latency can vary considerably across analytical tasks.

That creates two questions for buyers.

First, can your analytics platform adopt new models as they become available, including models from different providers?

Second, can it use the right model for the right task?

Supporting a model picker is useful, but most users aren't going to know which model offers the best trade-off for every analytical question. A more sophisticated approach uses cheaper models for straightforward work and reserves expensive frontier models for tasks that need deeper reasoning.

This helps teams take advantage of improving model capabilities without making every question unnecessarily expensive.

What to test: Ask the vendor which models it supports, how frequently new ones become available, and whether models can be changed without rebuilding analytical context. Run the same set of questions with different models and compare accuracy, latency, and cost.

Red flag: You're dependent on one provider's roadmap and pricing, with no clear way to adopt a better or cheaper model when it becomes available.

4. Workflow portability: Can you take your analytical work with you?

Even if your data and semantic models are portable, your analytical work might not be.

Consider everything your team creates over a few years: SQL queries, Python notebooks, dashboards, interactive applications, scheduled reports, and the logic connecting them.

As agents take on more of that work, companies will accumulate analytical assets faster than ever.

But not all artifacts are equally portable.

A dashboard defined entirely through proprietary visual components may be difficult to recreate elsewhere. SQL and Python are generally easier to inspect, version, and reuse, although they may still depend on platform-specific functions, libraries, or environments.

That's an important distinction: exporting a dashboard's underlying logic isn't necessarily the same as exporting the complete application.

And as more people generate analytical work outside traditional BI, there's also the risk of AI data sprawl: dashboards, queries, and applications scattered across disconnected chat histories and local files, with no reliable way to review or maintain them.

Hex combines inspectable SQL and Python with shareable analytical projects. Its CLI lets teams work with that code from external tools, including importing existing analysis and managing projects programmatically.

Hex also uses existing projects as context, allowing agents to draw on trusted queries, charts, and analytical logic the team has already created. That makes completed work useful beyond the original dashboard or investigation.

Some publishing, application, and governance capabilities remain platform-specific. The advantage is preserving more of the underlying analytical work in formats that can be reviewed and reused.

What to test: Take an existing analytical project and export its SQL, Python, and supporting definitions. Can you understand and execute the core logic outside the platform? Can you version it in Git? What would need to be rebuilt to recreate the published dashboard or app?

Red flag: You can export the raw data, but the queries, transformations, definitions, and logic that make it useful remain inaccessible.

Your AI vendor lock-in checklist

Before committing to a platform, ask vendors to demonstrate these four workflows using your own data and context.

For each test, document what works, what requires manual effort, and what would need to be rebuilt if you left.

Not every proprietary component is a dealbreaker. A great product will always have some capabilities you can't perfectly reproduce elsewhere.

The question is whether you're knowingly choosing those dependencies, or discovering them after years of investment.

The safest AI platform might be the one that's easiest to leave

There's a somewhat counterintuitive argument for choosing an analytics platform that doesn't try to lock you in.

The easier it is to take your business logic, context, and analytical work elsewhere, the more confidence you can have investing in the platform today.

You're not betting that its current models, interfaces, or workflows will remain the best forever. You're betting that it can help your organization take advantage of whatever comes next.

That's the philosophy behind Hex's approach: supporting semantic models and business context maintained across your existing stack, making governed analytics accessible to external agents, and keeping the underlying analytical work inspectable and reusable.

The goal isn't to eliminate every dependency. It's to make sure your company's most valuable analytical knowledge doesn't become one of them.

The best AI platform doesn't just work with your current stack. It preserves your ability to change that stack as models, agents, and analytical workflows evolve.

Frequently asked questions

Should you build your semantic model inside your BI tool?

You can, but consider the switching cost. Semantic models built inside a proprietary BI platform may require rebuilding if you change tools. Maintaining definitions upstream in systems like dbt or Snowflake can make them reusable across multiple analytics platforms and AI agents.

What is Apache Ossie?

Apache Ossie is an open-source specification, formerly known as Open Semantic Interchange, for sharing semantic definitions across analytics and AI tools. It aims to make metrics, dimensions, and relationships more portable, although practical interoperability depends on vendor implementations.

Does MCP eliminate AI vendor lock-in?

Not by itself. MCP makes it easier for external agents to access tools and data, but the capabilities available through an MCP server vary. Buyers should check whether agents can conduct investigations, create or modify analytical work, and preserve governed definitions and permissions.

Can you avoid AI vendor lock-in entirely?

Probably not. Most enterprise products include proprietary functionality, configurations, or application components. The goal is to minimize unnecessary dependencies, particularly around business context, model choice, and the analytical logic your team builds over time.