The idea of one universal semantic layer is attractive. One place for every business definition, every metric, every relationship, every policy, and every AI context rule.
In real enterprises, that almost never happens cleanly. The finance team has governed metrics.
The BI team has semantic models. The data platform team has dbt models and tests.
The governance team has catalog tags and policies. The AI team has retrieval metadata.
The architecture team may have or need a knowledge graph. Replacing all of that with a single layer is usually too slow and too political.
The more practical 2026 pattern is a composite semantic layer: several semantic systems with clear ownership, integration rules, and serving paths for humans and AI agents. Gartner's direction toward context layers and semantic foundations supports this shift.
The winning move is not one layer to rule them all. It is one coherent semantic architecture.
Prefer to skip the debugging and have an expert handle this? Book a 30-min diagnostic →
Why One Universal Semantic Layer Usually Fails
Universal semantic layer projects fail because they underestimate ownership. Metrics are not only technical calculations. They are negotiated business contracts.
Sales, finance, product, success, support, and operations often need overlapping but not identical definitions. A BI semantic model may serve dashboard performance well but lack machine-readable policies for agents. A dbt semantic layer may govern metrics well but not represent document meaning or entity relationships deeply enough.
A knowledge graph may model relationships well but not replace finance-approved metric definitions. A catalog may store metadata but not serve low-latency business logic. Trying to force every semantic need into one product creates delays and workarounds.
Teams keep using their local definitions while the central project debates purity. A composite architecture accepts that different semantic systems exist, then defines how they coordinate: which layer owns which meaning, how conflicts are resolved, and how AI systems consume the result.
Related: AI Data Infrastructure, Data Engineering, Data Governance and Security Engineering, Book a diagnostic
The Components of a Composite Semantic Layer
A composite semantic layer typically includes six parts. The dbt semantic layer or metrics layer owns governed metrics, dimensions, and business calculations close to transformations. BI semantic models own dashboard-specific exploration paths, visual hierarchies, and user-facing analytical models.
A metrics API or semantic SQL endpoint exposes trusted definitions to applications and agents. A knowledge graph represents entities, relationships, dependencies, and multi-hop context that tables do not express naturally. A retrieval layer adds document metadata, chunk provenance, citation rules, and search filters.
An AI context layer assembles user, workflow, policy, semantic, and retrieval context for agents. These parts should not duplicate the same responsibility. They should reference each other.
A support agent asking about account health might use metrics from the metrics layer, account relationships from a graph, escalation notes from retrieval, and policy limits from governance.
How dbt, BI Models, Metrics Layers, and Graphs Fit
dbt is strongest where transformation logic, version control, testing, lineage, and metric definitions meet. BI semantic models are strongest where business users need governed exploration and dashboards. Metrics layers are strongest when the same KPI must appear consistently across dashboards, embedded analytics, products, and AI workflows.
Knowledge graphs are strongest when meaning depends on relationships: customer to contract to product to entitlement to incident to owner. None of these should be treated as the enemy of the others. The architecture question is ownership.
If finance owns net revenue, the metric layer should expose that calculation. If customer success owns health-stage logic, that definition should be versioned and tested. If product dependencies matter to incident risk, the graph should represent them.
If an agent needs all three, the context layer should compose them instead of asking the model to infer business structure from raw data.
Related: data platform engineering, enterprise agent data layer
Still Piecing This Together Yourself?
A senior engineer looks at your actual setup, not a generic checklist, and tells you exactly what's wrong and how to fix it.
Book a Diagnostic CallGovernance Rules for Composite Semantics
Composite does not mean messy. It needs governance rules that are explicit enough for machines. Define authoritative ownership for each business concept.
Maintain a registry of terms, metrics, entities, and policies with owners and source systems. Require versioning for definitions that agents use. Add tests for important semantic changes, especially metrics used in customer, finance, compliance, and operational workflows.
Track lineage from semantic concepts to physical tables, transformations, documents, and model outputs. Mark sensitivity and access rules at the semantic object level, not only in raw tables. Create conflict-resolution rules for terms with multiple meanings.
If active customer differs between finance and product, the agent should know when each definition applies. Finally, evaluate semantic quality with real questions. If an agent cannot answer the top 50 business questions consistently, the semantic layer is not ready regardless of how elegant the model looks.
A Practical Roadmap
Start by inventorying existing semantic assets: dbt metrics, LookML or Power BI models, spreadsheet definitions, catalog glossary terms, knowledge graph work, document metadata, and AI prompts that contain hidden business rules. Then choose one commercial workflow such as renewal risk, sales forecasting, financial variance analysis, incident response, or procurement review. Define the terms and metrics that workflow needs.
Decide which existing layer owns each one. Fill only the missing pieces. Expose the result through a stable serving interface for the agent or application.
Add evaluation questions and audit logs. Repeat by workflow. This avoids the trap of a multi-year semantic transformation that produces no near-term value.
It also gives the business a visible reason to fund the next layer: every missing definition, relationship, or policy is tied to a workflow that has revenue, cost, risk, or productivity impact.
What to Avoid
Avoid treating composite semantics as a committee exercise with no serving path. A glossary that cannot be queried by applications will not help agents. Avoid letting every AI team create its own definitions in prompts, because that creates semantic drift faster than any BI project did.
Avoid buying a knowledge graph because the term is fashionable when the actual pain is inconsistent metrics. Avoid forcing BI models to carry document meaning or asking a vector index to represent governed metrics. Avoid semantic ownership without review cadence.
Definitions change when pricing changes, territories change, products merge, compliance rules change, or source systems are replaced. The architecture should expect change. A composite semantic layer works when every concept has an owner, every important definition has tests, every agent-facing semantic object has an API or query path, and every production workflow has evaluation questions that catch semantic regressions before users do.
Related: semantic governance implementation, review the architecture
Get a Straight Answer, Not a Sales Pitch
Tell us what you're running into. We'll tell you directly what's causing it and what it takes to fix, before you sign anything.
Contact UsSigns the Pattern Is Working
You know the composite pattern is working when business users stop asking which dashboard is correct, AI teams stop copying metric logic into prompts, and platform teams can expose definitions through stable services. Agents should be able to answer common business questions with the same definitions that dashboards use, cite document evidence when needed, and clarify when two legitimate definitions exist. Engineers should be able to see which layer supplied which part of the answer.
Governance teams should be able to review ownership, access, lineage, and policy without reading application code.
Composite semantic layer architecture is the practical enterprise pattern for 2026 because semantics already live in more than one place. The goal is not to flatten every definition into one tool. The goal is to make meaning governed, connected, testable, and available to AI systems that need business context before they can be trusted.
Frequently Asked Questions
What is a composite semantic layer?
It is an architecture where multiple semantic systems, such as metrics layers, BI models, knowledge graphs, catalogs, retrieval metadata, and AI context services, work together with clear ownership.
Why not build one universal semantic layer?
Most enterprises already have different semantic systems owned by different teams. Replacing all of them is slow. A composite pattern coordinates them and makes them usable for AI faster.
Where does dbt fit in a composite semantic layer?
dbt fits close to governed transformations, metrics, tests, lineage, and version-controlled business logic. It can be one important component, not necessarily the only semantic layer.
How should companies start a semantic layer implementation?
Start with one workflow, inventory the definitions it needs, assign ownership, expose trusted definitions through an interface, and test against real business questions.
Sources
Get a Straight Answer on Your Setup
Tell us what you're running into. We read every message personally and reply within 24 hours with times for a free call.