Sigma Computing runs its own semantic layer - the same product it sells to customers - as versioned code inside a dbt project, with Dagster handling orchestration. Matt Senick, the company's lead data platform engineer, laid out the setup at dbt Summit 2026.

Senick said the semantic layer serves three purposes in the LLM era: embedding guardrails such as PII restrictions and SQL formatting rules into model-level instructions; keeping metric definitions consistent across every AI surface in the company; and giving agents model context, synonyms and verified queries so they can go beyond generic text-to-SQL guesswork. Drawing on Anthropic's published research, he argued that once a question maps cleanly to a defined metric, an agent should call a function and return the single number every other surface already agrees on.

Inside Sigma's dbt project, semantic objects are defined and version-controlled in SQL and Jinja, mapped to specific warehouse tables, with column-level control over what business users see. Models are split by business function - sales, marketing, customer success, product and others - and a small set of dbt packages (dbt-sigma-data-model, dbt-semantic-view and dbt-cortex-agent) compiles the definitions into Sigma data models, Snowflake semantic views and Cortex agents as ordinary dbt nodes.

Dagster runs 63 jobs that continuously build and deploy across the 2,883 models and 6 data regions: it downloads the dbt manifest from S3, runs a state-aware dbt build, syncs the resulting Sigma data models back through Sigma's API, then re-uploads the manifest for the next run. Senick also previewed Open Semantic Interchange, nicknamed Ossie, which aims to let teams convert between a Snowflake semantic view, a dbt metric and a Sigma data model without locking into one vendor's format.

Source: dbt Labs Blog