Blog

How to self-host a semantic layer for AI agents

Agentic Analytics · June 23, 2026 · 4 min read

A semantic layer is what makes an AI agent’s answers correct, by defining metrics and rules once instead of letting the agent guess. If you want to run one yourself, on your own infrastructure, the options are more limited than they look, and the details matter. Self-hosting a semantic layer means running the metric definitions and the service that resolves them inside your environment, rather than depending on a vendor’s cloud. Here is why teams want that, where the catch is, and what actually self-hosts.

Why self-host a semantic layer

The reasons are the same ones that push teams toward open-source, self-hosted agents.

  • Control and no lock-in. Your metric definitions are core business logic. Keeping them in files you own, in your own repo and infrastructure, means no vendor owns the definitions your agent depends on.
  • Sensitive data. If your data cannot leave your environment, the layer that queries it cannot either. Self-hosting keeps the whole path inside your walls.
  • Cost and scale. A hosted semantic layer is priced per seat or per query. At scale, running it yourself can be the cheaper and more predictable option.

The dbt Cloud catch

Here is where it gets specific, because the most common semantic layer is dbt’s, and it does not fully self-host.

dbt open-sourced MetricFlow, the engine that compiles metric definitions into SQL, under Apache 2.0. That part you can run yourself. But the dbt Semantic Layer as a production service, the piece that serves those metrics to tools and agents over an API, runs in dbt Cloud and needs a paid plan. So self-hosting the dbt Semantic Layer with dbt Core alone is not really possible. You get the modeling engine, not the serving layer.

For a lot of teams that is fine. For teams that specifically need everything in their own environment, it is the thing to check before committing.

The open-source options

If full self-hosting is the requirement, a few paths exist.

  • MetricFlow on your own service. You can use the open-source engine and build or run the serving around it, which is real work but keeps everything yours.
  • Cube. An open-source semantic layer you can self-host, with an API designed for applications and, increasingly, agents.
  • Other OSS layers. The space is moving, and open-source alternatives to the dbt Semantic Layer are a live topic precisely because of the dbt Cloud constraint.

The right choice depends on how much you want to run yourself versus how much you want handed to you.

How it fits an analytics agent

The semantic layer is not a standalone win. It matters because of what sits on top of it.

An analytics agent that queries through a self-hosted semantic layer gets defined metrics without sending anything to a vendor. That is the combination teams with strict data requirements are after, an open-source agent and a self-hosted semantic layer, both in their own environment, so the data, the definitions, and the answers all stay inside. Open-source agents like nao are built for this, treating the context and metrics as files your data team owns and versions rather than a hosted service you rent.

The takeaway

You can self-host the modeling part of a semantic layer today, and with more effort the serving part too. The main trap is assuming the dbt Semantic Layer self-hosts fully. It does not. If keeping everything in your environment is the requirement, plan around MetricFlow, Cube, or another open-source layer, and pair it with a self-hostable agent so the whole path stays yours.

Can you self-host the dbt Semantic Layer?

Not fully. dbt open-sourced MetricFlow, the engine that compiles metric definitions, under Apache 2.0, so you can run that yourself. But the dbt Semantic Layer as a production service that serves metrics to tools and agents runs in dbt Cloud on a paid plan. With dbt Core alone you get the modeling engine, not the serving layer.

What is the best open-source semantic layer for AI agents?

It depends on how much you want to run yourself. MetricFlow is open source but is the engine, not a full serving layer. Cube is an open-source semantic layer you can self-host with an API built for applications and agents. The right pick balances how much infrastructure you want to own against how much you want provided.

Why self-host a semantic layer instead of using a cloud one?

For control, data residency, and cost. Your metric definitions are core business logic, and self-hosting keeps them and the data they query inside your environment, which matters for sensitive or regulated data. At scale it can also be cheaper than per-seat or per-query cloud pricing. The trade is that you run the infrastructure.