Comparison·Updated 06 May 2026·~10 min read

Colrows vs dbt Semantic Layer: Enterprise AI Comparison

dbt Semantic Layer (MetricFlow) is a metric layer built on top of dbt transformations. Colrows is a semantic execution layer for AI agents. Both deal in "semantics" but at different altitudes. dbt SL standardises metric values for BI tools; Colrows compiles AI agent intent into governed SQL across entities, relationships, and policies.

Executive summary

The dbt Semantic Layer (powered by MetricFlow) brought metric consistency to the modern data stack. Defined in YAML alongside your dbt models, MetricFlow metrics resolve to consistent values whether they are queried from Tableau, Looker, Power BI, or a notebook. For BI tools that previously each maintained their own version of "monthly active users," that consistency is genuinely valuable.

Colrows is built for the layer above that. Where dbt SL stops at metric values, Colrows operates on meaning: a typed semantic graph of entities, relationships, multi-scope policies, and compile-time governance that AI agents reason on directly. Where dbt SL is hand-authored YAML refreshed by humans, Colrows builds and maintains its graph autonomously. Where dbt SL exposes a metric API, Colrows compiles agent intent into dialect-perfect SQL.

In short:

dbt Semantic Layer helps BI tools agree on metric values.
Colrows enables AI agents to compile intent into governed, deterministic SQL.

The two are complementary at the data layer and divergent at the application layer.

Two philosophies, two outcomes

dbt Semantic Layer assumes meaning is versioned alongside transformations. You author semantic_models in YAML, declare measures and dimensions, and rely on MetricFlow to stitch them into queries at runtime. The metric definition lives next to the dbt model that produces the underlying table - a sensible coupling that mirrors how analytics engineering teams already work.

Colrows assumes meaning is distributed across the enterprise. dbt models are one input, but so are the warehouse catalogue, BI tools, Confluence, runbooks, data dictionaries, and historical query usage. Colrows ingests these sources and constructs a typed semantic graph autonomously. The graph is multi-scope (global, datastore, persona, user) and uses multi-vector embeddings (definition, usage, combined per concept).

The downstream consequence: dbt SL keeps your BI tools in agreement on existing metrics. Colrows keeps an evolving graph in agreement with the entire data estate, ready for AI agents to reason on.

Metric layer vs. semantic graph

The most important architectural distinction is what the layer actually models.

dbt Semantic Layer models metrics. A measure (e.g. order_total), aggregated across dimensions, possibly filtered, possibly with time-based windows. The output is a value or a small result set.

Colrows models a graph. Concepts (Customer, Subscription, Order), the typed relationships between them (Customer has Subscription, Order belongs to Customer), governance predicates attached at every node and edge, and the proven join paths an AI agent must traverse to answer a multi-hop question.

Metrics are a subset of a semantic graph. Every dbt SL metric can become a node in a Colrows graph. Not every Colrows-graph node is a metric.

A concrete scenario: regulated SaaS retention analysis

An enterprise SaaS company runs dbt extensively. Its analytics engineering team has authored a clean dbt project, and a few dozen MetricFlow metrics power consistent dashboards across Looker and Tableau. Monthly recurring revenue, churn rate, expansion ARR - all accurate, all repeatable.

The customer success team now wants an AI agent that can answer: "Which mid-market accounts in EMEA at risk of non-renewal in the next 60 days have skipped key features in their adoption journey, and what does the regulatory scope of those accounts allow our agent to share back to the CSM?"

dbt SL can return the metric values: renewal_risk_score, feature_adoption_rate. But the agent has to reason across:

The Account, Subscription, FeatureAdoption, Renewal, and ComplianceScope entities and the relationships between them.
The CSM persona's permission to see specific account columns.
Regulatory predicates that vary per region (e.g. data minimisation rules in some EU customers).
An audit trail proving exactly which metric definitions and policies were in force when the agent answered.

None of these are metric questions. They are graph questions, governance questions, and compilation questions. With Colrows, the agent compiles its intent through a typed graph that already encodes those entities, policies, and scopes; the dbt-defined metrics are nodes in that graph, but they are not the whole story.

Why metric layers cannot do this alone

dbt Semantic Layer is excellent at one thing: ensuring metric consistency across BI consumers. It is not designed to:

Encode entity-and-relationship models for multi-hop agent reasoning.
Enforce policy at compile time across persona, tenant, and regulatory scope.
Build or maintain itself from documentation, runbooks, and usage signals.
Produce machine-readable compile traces for AI audit.
Resolve the same concept differently per tenant or persona without forking the metric.

Each of those is foundational for putting AI agents into production. Adding them on top of MetricFlow is not a configuration change - it is a different architecture above the metric layer.

Reframing the comparison

dbt Semantic Layer and Colrows operate at different altitudes of the stack.

dbt Semantic Layer = metric layer co-located with transformations. Optimised for BI consistency. Manual YAML authoring. Resolution at query time inside MetricFlow.

Colrows = semantic execution layer above the warehouse. Optimised for AI agent compilation. Autonomous graph construction. Resolution at compile time, with governance injected before SQL emits.

The two coexist cleanly: keep dbt for transformations and metric definitions; add Colrows for the agent-execution surface that ingests those metrics and compiles agent intent against the broader graph.

The bottom line

If your goal is consistent metric values across BI tools - one definition of revenue, churn, or active users - dbt Semantic Layer is well-suited and integrates cleanly with the analytics engineering workflow you already run.

If your goal is to put AI agents into production - to compile their intent into governed SQL with proven join paths, compile-time policy enforcement, and a continuously maintained semantic graph that evolves with your business - dbt SL alone is not the right architecture. The semantic execution layer above it is what matters, and that is what Colrows provides.

At the core

	dbt Semantic Layer	Colrows
Built for	BI metric consistency	Semantic execution for AI agents
Primary consumer	BI tools, notebooks, humans	AI agents, autonomous workflows
Core strength	One definition of each metric	Governed compilation of agent intent
Intelligence lives in	YAML metric definitions	Typed semantic graph

Semantic and intelligence handling

Capability	dbt Semantic Layer	Colrows
What is modelled	Measures, dimensions, time grains	Entities, relationships, policies, examples, multi-scope
Authoring model	Manual YAML alongside dbt models	Autonomous, ingests dbt definitions and more
Multi-scope resolution	No - one metric definition globally	Yes - global, datastore, persona, user scopes
Context preservation	Per-query	Cross-workflow, persistent
AI readiness	Indirect - via metric API	Agent-native by design
Explainability	Metric definition lookup	End-to-end (intent → semantics → SQL → source data)

Engineering and operational reality

Dimension	dbt Semantic Layer	Colrows
Compile-time governance	Limited - relies on warehouse policy	Yes - RBAC/ABAC injected into generated SQL
Join path proof	Implicit via dbt model lineage	Proven against typed graph at compile time
Drift handling	Manual updates by analytics engineers	Autonomous detection plus proposed mappings
Hosting requirement	dbt Cloud subscription	Free tier, Cloud, or self-hosted (Enterprise)
Audit trail	Query and version history	Point-in-time reproducible compilation trace
Coexistence	-	Ingests dbt SL definitions; dbt continues to transform

Frequently asked questions

Does Colrows replace dbt?

No. dbt is a transformation framework that builds and tests models inside your warehouse. Colrows sits above the warehouse and compiles AI agent intent into governed SQL. Most teams keep dbt for transformations and add Colrows for the agent-execution surface.

Does Colrows replace the dbt Semantic Layer (MetricFlow)?

Colrows can ingest dbt Semantic Layer metric definitions and use them to seed its semantic graph. Where dbt SL stops at metric values exposed to BI tools, Colrows continues into entity modelling, multi-scope resolution, compile-time governance, and agent-native compilation. For BI consistency, dbt SL is sufficient. For AI agent execution, the graph layer above it is what matters.

Why is a metric layer not enough for AI agents?

AI agents reason across entities and relationships, not just measures. A metric layer can return monthly active customers but cannot prove the join from Customer to Subscription to UsageEvent under tenant-specific governance, or inject row/column-level predicates into the generated SQL at compile time. Those are graph-level capabilities.

Do I need dbt Cloud to use the dbt Semantic Layer?

Yes - the dbt Semantic Layer service runs as part of dbt Cloud. Colrows runs independently of dbt Cloud and can connect directly to your warehouse, ingesting dbt model and metric definitions if they exist.

Can Colrows compile from dbt models without rewriting them?

Yes. dbt models continue to compile in your warehouse; Colrows becomes the runtime layer above them. The Colrows semantic graph maps to dbt model outputs and resolves agent intent against that graph, then emits SQL that runs against the existing dbt-built tables.

How does compile-time governance compare to dbt's access control?

dbt enforces access control at the project, model, and row-level via warehouse policies after queries arrive. Colrows enforces RBAC, ABAC, and row/column-level predicates at compile time, before any SQL is generated. Filtered-out rows are never read; unauthorised queries fail compilation rather than reaching the warehouse.