--- title: "AtScale vs Context Layer: What's the Difference?" url: "https://atlan.com/know/ai-agent/semantic-layer/atscale-vs-context-layer/" description: "AtScale vs context layer: see what AtScale's semantic layer covers, what a governed context layer adds, and how the two work together for AI agents." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-09-07" updated: "2026-09-07T00:00:00.000Z" --- --- AtScale is a universal semantic layer: it models a metric once and serves the same number to Power BI, Tableau, Excel, and now its own MCP server. Since June 2026, its ACE engine has run embedded directly inside Snowflake's own Semantic Views, in Private Preview.[1] Atlan's Enterprise Data Graph is a different job. It decides whether that metric, and everything else an agent touches, is fresh, owned, permitted, and current before an answer ships, using a governed vs. ungoverned agent access distinction that matters now that both sides ship their own MCP server. AtScale's move matters because analysts are pricing semantics as core AI infrastructure, not a BI nicety. According to Gartner's Rita Sallam, speaking at the 2026 Data & Analytics Summit, organizations that put semantics in place before deploying agents could see agentic AI accuracy rise by up to 80% and costs fall by up to 60% by 2027, with 92% of data and analytics leaders already running or planning a semantic layer.[2] That is a strong case for having a semantic layer. It says nothing about who decides whether the number it produces can be trusted right now, which is the question this page answers. | Dimension | AtScale | Governed context layer (Atlan) | |---|---|---| | What it answers | "What does this metric mean, and how is it computed correctly?" | "Is this metric, and everything else the agent touches, trustworthy right now?" | | Primary users | Analytics engineering and BI teams | Governance, data platform, and AI platform teams | | Core object | Metric and dimension definitions | Catalog entries, lineage, policy, and certification | | Delivery to agents | Its own MCP server, scoped to metric definitions | MCP server serving the full context stack | | Column-level lineage | Not a primitive in the model | Traces a metric to the physical columns it reads | | Estate-wide catalog | Not a data catalog, by its own description | Enterprise Data Graph, across the entire estate | | Best fit | Consistent numbers across BI tools and warehouses | Trust signals on every number, including ones a semantic layer already computes | Every AtScale claim here is footnoted to AtScale's own materials or an independent source, verified 2026-09-07. Capabilities no public source confirms are not asserted either way. --- ## AtScale vs context layer: what's the difference? These are two layers of the same stack, not two competitors for the same budget. Staging them as a feature fight produces a table nobody can act on, because one is a modeling decision and the other is an operating decision that sits above it. The modeling decision is where a metric lives and how it computes, the job [a semantic layer for analytics](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-for-analytics/) is for. [What is a semantic layer](https://atlan.com/know/semantic-layer/) is still one of the most searched definitional questions in this category, and for good reason: most buyers start here before they know a second question even exists. The operating decision is what happens once that metric, and every other one, reaches an agent that has to decide whether to act on it: is it owned, certified, current, and consistent with the policy behind it. [What is a context layer](https://atlan.com/know/what-is-context-layer/) and [context layer vs semantic layer](https://atlan.com/know/context-layer-vs-semantic-layer/) answer that second question directly, and so does [context layer vs data catalog vs semantic layer](https://atlan.com/know/ai-agent/semantic-layer/context-layer-vs-data-catalog-vs-semantic-layer/). A better semantic model does not answer it on its own. Neither does [a data catalog on its own](https://atlan.com/know/data-catalog-vs-context-layer/). A third party has already drawn this line independently. Timbr, itself a vendor in the space, sorts the market into three camps: a metric-governance camp (Snowflake, dbt, Cube, AtScale) that defines a metric once and serves it everywhere; a context-layer camp (Atlan, Promethium, Collibra) that wraps governance, lineage, and usage signals around definitions that already exist; and an ontology camp (Palantir Foundry, Microsoft Fabric IQ, Timbr) building full business semantic structure, the same three-way split [ontology vs semantic layer](https://atlan.com/know/ontology-vs-semantic-layer/) works through in more depth.[4] That a competitor-adjacent analyst, not Atlan, drew this boundary is worth noting. It is not a line Atlan invented to win an argument. Some of the confusion is fair, because AtScale's own language blurs it. AtScale's co-founder and CTO Dave Mariani has said the semantic layer "supports the implementation of comprehensive data governance policies, including data stewardship, compliance, and privacy regulations."[5] That is true and narrower than it sounds. Query-time row and column access control inside AtScale's own model is real governance. Estate-wide lineage, ownership records, and unstructured knowledge are a separate, unaddressed job, one AtScale's own documentation elsewhere describes as outside its scope. Precision on a metric is not the same as trust in everything an agent reaches for. --- AtScale's own CTO has taken this exact question live, on the record, in conversation with Atlan's Director of Data Strategy.[8] The two men agreed the vocabularies overlap and the architectures do not, which is the same distinction this page draws in prose. The question worth asking of any semantic layer, AtScale included, is not whether it can compute a number correctly, since a mature one usually can. It is whether anything governs the estate that number lives in. --- ## What is AtScale? AtScale is a universal semantic layer that defines metric and dimension logic once and serves it consistently across BI tools, warehouses, and now AI agents through its own MCP server, one of the vendor-neutral picks on [best semantic layer tools for BI and AI agents](https://atlan.com/know/best-semantic-layer-tools/). It virtualizes the model rather than moving data, so the same "active customers" or "net revenue" definition reaches Power BI, Tableau, and Excel without a separate copy computed in each tool, the same drift [semantic layer vs traditional data marts](https://atlan.com/know/semantic-layer-vs-traditional-data-marts/) describes when there is no shared model at all. AtScale's newest distribution move is real and worth crediting fully. Since June 2026, its ACE engine has run embedded directly inside Snowflake's own [Semantic Views](https://atlan.com/know/snowflake/snowflake-semantic-views/), in Private Preview.[1] The free, native version reaches Power BI, Excel, and Snowflake's own AI surfaces. Tableau, Looker, and true multi-warehouse modeling still require the full AtScale Enterprise license, a real limit on how far the embedded version alone goes.[1] [AtScale and Unity Catalog](https://atlan.com/know/ai-agent/databricks/atscale-unity-catalog/) covers the equivalent question on Databricks, where an MCP server rather than an ACE-in-warehouse embedding is the relevant integration, and [Databricks Unity Catalog Metrics](https://atlan.com/know/ai-agent/databricks/unity-catalog-metrics/) is the warehouse-native feature it sits alongside. Teams still deciding between platform-native and portable semantic layers altogether want [Snowflake Semantic Views vs Cube vs AtScale](https://atlan.com/know/ai-agent/semantic-layer/snowflake-semantic-views-vs-cube-vs-atscale/) instead of this page. The company has also sharpened its pitch. Mark Palmer joined as Chief Marketing and Strategy Officer in April 2026 to frame AtScale's category as "Deterministic Context," positioning precise, pre-modeled metric resolution as the fix for AI hallucination in analytics.[3] That framing is accurate as far as it goes. A metric someone has already modeled in AtScale's cube resolves deterministically. A question that falls outside that cube, a policy document, a process norm, or an unstructured knowledge source, has nothing deterministic to resolve against, because AtScale never modeled it. ### Core components of AtScale - **ACE engine:** the virtualization layer that serves consistent metric and dimension logic across warehouses without physically moving data - **Metric and dimension definitions:** modeled once and served everywhere, the "define once, query everywhere" pattern - **Multi-BI serving:** native XMLA-embedded reach to Power BI, Excel, and Snowflake's own AI surfaces for free; Tableau, Looker, and true multi-warehouse use require the full AtScale Enterprise license - **MCP server:** governs access to AtScale's own metric definitions for AI agents, a real, shipped capability rather than a gap - **Snowflake Semantic Views embedding:** the ACE engine runs OEM'd directly inside Snowflake's own semantic object, in Private Preview since mid-2026 AtScale is a genuinely strong metrics engine on the slice it models, part of the same headless serving pattern [headless BI 101](https://atlan.com/know/headless-bi-101/) explains from first principles. The market backs the category broadly: [dbt's semantic layer](https://atlan.com/dbt-semantic-layer/), [Cube](https://atlan.com/know/ai-agent/semantic-layer/cube-semantic-layer/), and AtScale itself all sit inside a semantic layer segment that keeps drawing new vendor investment and analyst attention as agentic AI adoption grows. None of that growth changes what the category was built to do: model and compute a metric, not decide whether an agent should trust it, the buy-versus-build framework in [Regovern: building a semantic layer guide](https://atlan.com/know/regovern-building-semantic-layer-guide/) covers before a team commits to either. --- Inside Atlan AI Labs & the 5x Accuracy Factor The ebook on why context, not a bigger model, is what actually moves agent accuracy, and what a compounding context loop looks like in production. Get the 5x Accuracy Ebook --- ## What is a governed context layer? A governed context layer is the estate-wide substrate that connects a catalog, column-level lineage, unstructured knowledge, and policy into one place an AI agent can query alongside any metric definition, the standing gap [semantic layer for AI agents](https://atlan.com/know/ai-agent/semantic-layer-for-ai-agents/) names directly. Atlan's Enterprise Data Graph is one working example: it covers the [data catalog](https://atlan.com/know/data-catalog-for-ai/) an agent needs to search, functioning as [an LLM's actual knowledge base](https://atlan.com/know/data-catalog-as-llm-knowledge-base/) rather than a browsing tool for humans, plus lineage, unstructured knowledge, and skills, in a single governed layer rather than six disconnected tools, the same layering [semantic views: human meaning to materialized context](https://atlan.com/know/semantic-views-human-meaning-to-materialized-context/) traces from raw definition to governed asset. Skip this substrate and a well-modeled metric still ends up as one more entry in the pile [semantic layers ≠ failed context graphs](https://atlan.com/know/semantic-layers-failed-context-graphs/) describes, technically correct and contextually useless. The case for it is not hypothetical. Rita Sallam of Gartner has framed the shift plainly: "context with semantic coherence will become a cost-control and trust strategy, not a nice-to-have."[2] Charlotte Ledoux, an independent data and AI governance specialist, puts the same point more bluntly: "If your AI strategy depends on 'we have a catalog,' you have a documentation strategy, not a meaning strategy."[7] A catalog that nobody keeps current is not a governed layer any more than a semantic layer with no lineage is one. What makes this job different from a semantic layer is that it compounds: it gets more accurate with every correction, not merely faster with every query the way an aggregation engine does, the same distinction [metadata layer for AI](https://atlan.com/know/metadata-layer-for-ai/) draws between static documentation and a living layer. How that compounding actually works in Atlan's own architecture is worth its own section further down; the principle that matters here is that a governed context layer is a job, not a specific vendor's feature list, and any semantic layer's definitions, AtScale's included, are meant to sit inside one. ### Core components of a governed context layer - **Enterprise Data Graph:** an estate-wide catalog, lineage, unstructured knowledge, and policy in one governed layer instead of six - **Column-level lineage:** traces a metric back to the physical columns it reads, wherever it was defined - **Unstructured knowledge:** procedures, norms, and tribal knowledge a semantic layer has no primitive for - **Compounding context:** a trace, certify, and promote loop that improves with every correction, not a static definition - **MCP server, full stack:** serves the full context stack, not one governed slice, to any agent that asks A context layer does not model or compute a metric. That is genuinely the semantic layer's job, and a well-modeled semantic layer makes governance easier by giving a context layer one clean definition to certify instead of six informal ones scattered across BI tools and pipelines to reconcile. --- ## AtScale vs context layer: head-to-head comparison The comparison that helps is scope against scope, not capability against capability. AtScale and a governed context layer are accountable for different failures, so ranking one above the other misreads what each was built to do. | Dimension | AtScale | Governed context layer (Atlan) | |---|---|---| | Primary focus | Modeling and computing metric and dimension logic consistently across warehouses | Deciding whether that logic, and everything else an agent touches, is trustworthy right now | | Metric definitions | Authored once, virtualized via the ACE engine, served to BI tools and agents | Ingests semantic layer definitions from dbt, Cube, LookML, and AtScale, and binds governance metadata to them | | Query-time access control | Real, row and column-level access enforced at query time inside its own model | Real, plus estate-wide policy that travels with the definition wherever it is queried | | MCP exposure | Its own MCP server, scoped to metric definitions only | MCP server serving the full context stack, definition, owner, lineage, and freshness together | | Column-level lineage | Not a primitive, traces logic within its own model rather than back through source systems | Traces a metric to the physical columns it reads, across every source system | | Estate-wide discovery | Not a data catalog, by its own description | Enterprise Data Graph, a catalog across the entire estate, not one modeling layer | | Unstructured knowledge | No concept, models structured metric and dimension logic only | Procedures, norms, and tribal knowledge captured alongside structured metadata | | Failure mode | A correctly computed metric an agent cannot tell is stale, disputed, or unowned | Governance metadata with no real, well-modeled metric to attach it to | **A scenario that shows why both rows matter:** An agent is asked what the company's active customer count is. AtScale's ACE engine returns a number computed consistently from the modeled definition, correct, fast, and identical whether the request came from Power BI or an agent. What it cannot tell the agent is that finance shipped a conflicting "active customer" definition in a BI tool last quarter, that the source table backing this number has not loaded since Tuesday, or that the definition's original owner left the company in March. A governed context layer carries those three facts alongside the number, in the same MCP call, the mechanism [an MCP-connected data catalog](https://atlan.com/know/mcp-connected-data-catalog/) makes concrete. Neither layer alone answers the full question an executive is actually asking; together they do. --- Find the gap before an agent does Score how much of your metric estate has an owner, a certification state, and lineage an agent could actually read today. Run the Gap Calculator --- ## How do AtScale and a context layer work together? Most enterprises run both, the same way they run a warehouse and a catalog. One computes the logic; the other governs whether to trust it, and the field pattern across accounts running both (Deckers, Sky, Brooks) is coexistence, not a rip-and-replace decision. ### Metric definitions and governance, delivered together Atlan's Enterprise Data Graph ingests AtScale's semantic-object definitions the same way it already ingests [dbt Metrics, Cube, and LookML](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-vs-data-catalog/) definitions, then binds ownership, certification, and lineage to each one, the pattern [agent context layer tools compared](https://atlan.com/know/ai-agent/agent-context-layer-tools-compared/) surveys across the wider tool set. AtScale contributes the modeled, virtualized metric definition itself. Atlan contributes the owner, the certification status, the column-level lineage, and the freshness signal, delivered the way [why MCP matters for AI agents](https://atlan.com/know/mcp/why-mcp-matters-for-ai-agents/) describes rather than bolted on after the fact. The combined outcome is that an agent gets a governed, citable answer instead of a fast but unverifiable one, closer to [an agent context layer than a RAG pipeline](https://atlan.com/know/ai-agent/agent-context-layer-vs-rag/) retrieving the same document twice. ### Snowflake Semantic Views as a shared distribution surface AtScale's ACE engine now serves definitions through Snowflake's own Semantic Views XMLA endpoint, and a governed context layer can discover and govern those same semantic objects as estate assets rather than a Snowflake-only silo, the gap [Why platform-native context layers fail](https://atlan.com/know/why-platform-native-context-layers-fail/) covers in more depth. AtScale contributes wider distribution of one metric slice into Power BI, Excel, and Snowflake's own AI surfaces. Atlan contributes discoverability and governance of that same object alongside everything else in the estate. The combined outcome is distribution without losing estate-wide traceability. **When to start with AtScale alone:** metric consistency across BI tools is the acute pain, one team owns the modeling, and the warehouses in scope are ones AtScale supports well. Teams at this stage choosing between the two leading portable semantic layers want [AtScale vs Cube for the enterprise semantic layer](https://atlan.com/know/ai-agent/semantic-layer/atscale-vs-cube-semantic-layer/), a narrower vendor decision than the one this page answers. **When to start with a governed context layer:** definitions already sit in multiple tools no single semantic model will absorb, an auditor is asking who approved a number, or agents on several platforms need the same metric with different trust bars, the same demand curve [open AI frontier vs semantic layer](https://atlan.com/know/open-ai-frontier-vs-semantic-layer/) tracks as agent adoption grows. **When to invest in both from day one:** greenfield AI-agent programs, where metric consistency and agent-trust signals are both needed before the first agent ships, the same threshold [how to implement an enterprise context layer for AI](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/) walks through. --- ## How Atlan approaches AtScale and the context layer Atlan's position is that a metric definition and the evidence around it should travel together, wherever that definition was authored. What breaks when a metric-governance tool and an estate-wide governance tool get treated as substitutes is specific: agents get a fast, confident answer from a semantic layer with no way to know it is disputed, stale, or unowned. AtScale itself does not claim to solve this. Its own language is that it is "not a data catalog nor a policy engine," so the gap is real and AtScale-acknowledged, not invented for this page. The [Enterprise Data Graph](https://atlan.com/know/enterprise-data-graph/) ingests semantic layer definitions from dbt's own metrics layer,[6] Cube, LookML, and AtScale, and binds ownership, certification, and column-level lineage to each one. The Context Development Lifecycle, trace, certify, promote, means this context compounds with every correction, unlike an aggregation engine that gets faster but not smarter. Atlan's MCP server delivers that full context stack, not one governed slice, and the [Context Lakehouse](https://atlan.com/know/context-catalog/) keeps it open across every warehouse, including the ones a single-vendor embedding does not reach. None of this replaces the modeling work AtScale does well. It sits above it. --- ## Real stories from real customers: one vocabulary, governed for agents "Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs." — Joe DosSantos, VP Enterprise Data & Analytics, Workday Watch Now → Workday's own words describe the second job in this comparison, not the first. Nothing here names AtScale, and no case study claims Workday runs it. The quote appears because it is the clearest public description of what a shared, governed vocabulary looks like once a semantic layer's definitions have somewhere to be certified, an owner to be recorded, and an MCP server to deliver both together. See the layer working on real definitions A live walkthrough of governed context reaching an agent: the definition, its owner, its lineage, and its trust status in one call. Watch the Live Demos --- ## What semantic layer embedding doesn't settle A well-modeled metric tells an agent what a number means and how it was computed. It cannot tell the agent that another team shipped a conflicting version last quarter, that the table underneath has not loaded since Tuesday, or that the person who owns the definition left the company in March. Embedding that same modeled metric inside Snowflake's own Semantic Views widens its reach; it does not add any of those three facts, because embedding is a distribution decision, not a governance one. That is the practical shape of governed versus ungoverned agent access, the same discipline [what is context engineering](https://atlan.com/know/what-is-context-engineering/) treats as a first-class job rather than an afterthought. Both AtScale and Atlan now ship an MCP server, so "can an agent reach this tool" is no longer the interesting question, and treating it as one repeats a framing that stopped being true the day AtScale's own MCP server shipped. What remains is what each server actually governs on the way out: one metric slice, computed precisely, or the metric plus the ownership, lineage, and freshness record that let an agent decide whether to act on it, the difference between a metric estate that is merely [AI-ready data](https://atlan.com/know/ai-readiness/ai-ready-data/) and one an agent can reason over. As more semantic layers get built into warehouse-native surfaces, that question moves. It does not disappear. Book a Demo --- ## FAQs about AtScale and context layer ### 1. What is a universal semantic layer? A universal semantic layer models business metrics and dimensions once and serves that same definition to every BI tool and warehouse a company runs, instead of letting each tool compute its own version. AtScale, Cube, and dbt's semantic layer all do this job, using different mechanisms to serve the definition out to consumers. ### 2. Is a semantic layer the same as a context layer? No. A semantic layer defines and computes what a metric means. A context layer is broader: it governs whether that metric, and everything else an agent touches, is owned, certified, current, and permitted. A semantic layer's output is one input into a context layer, not a substitute for it. ### 3. What is the difference between a semantic layer and a data catalog? A semantic layer models and computes metric logic for consumption by BI tools and agents. A data catalog inventories and governs assets across an estate, including lineage, ownership, and quality, independent of any one modeling layer. AtScale's own documentation describes it as neither a data catalog nor a policy engine. ### 4. Does AtScale replace my existing BI tools or data warehouse? No. AtScale sits between the warehouse and BI tools as a virtualization layer, modeling metrics once in its ACE engine and serving them to Power BI, Tableau, Excel, and similar tools without moving or duplicating the underlying data. ### 5. Can AtScale be used with Snowflake and Power BI? Yes. AtScale's ACE engine runs on Snowflake and several other warehouses, and serves modeled metrics natively to Power BI through XMLA. Since June 2026, that same engine also runs embedded inside Snowflake's own Semantic Views for customers in the Private Preview program. ### 6. Does AtScale have an MCP server for AI agents? Yes. AtScale ships its own MCP server so agents can query modeled metric definitions directly. It governs access to that one metric slice; it does not govern the rest of what an agent touches, including unstructured knowledge, column-level lineage, or an estate-wide catalog. ### 7. Is AtScale a data catalog? No, by its own description. AtScale enforces real row and column-level access control at query time within its own model, which is a genuine governance mechanism, but it does not provide estate-wide asset discovery, column-level lineage back to source systems, or unstructured knowledge, the jobs a data catalog and a governed context layer perform. ### 8. What are AtScale's limitations, according to reviewers? Public reviews are a thin sample, so treat this as directional rather than definitive. The recurring themes are a user interface reviewers say could be more modern, not enough separation from other analytics and BI tools in the buyer's mind, and enterprise pricing some reviewers flag as high. None of the recurring complaints are about the metric modeling itself. ### 9. Can you run AtScale and a governed context layer together? Yes, and that is the common enterprise pattern. AtScale models and computes the metric; a governed context layer records who owns it, whether it is certified, what columns it depends on, and whether the source data is current, then delivers all of it through an MCP server alongside the number. --- ## Sources 1. [Inside the AtScale and Snowflake Partnership: Why Snowflake Embedded AtScale in Semantic Views, AtScale](https://www.atscale.com/blog/snowflake-atscale-partnership-semantic-views/) 2. [Gartner Data & Analytics Summit 2026: Semantics, Agentic AI, and the Semantic Layer, Unwind Data](https://unwinddata.com/gartner-data-analytics-summit-2026) 3. [AtScale Taps Category Visionary Mark Palmer as CMSO to Define the "Deterministic Context" Era for Enterprise AI, AtScale](https://www.atscale.com/press/mark-palmer-joins-atscale-cmso/) 4. [Every Vendor Is Automating the Semantic Layer for AI Agents. Here's What They're Missing, Timbr.ai](https://timbr.ai/blog/every-vendor-is-automating-the-semantic-layer-for-ai-agents-heres-what-theyre-missing/) 5. [What Is Data Governance?, AtScale Glossary](https://www.atscale.com/glossary/data-governance/) 6. [Metrics Overview, dbt Labs Documentation](https://docs.getdbt.com/docs/build/metrics-overview) 7. [Semantic Layer vs Data Catalog: Why It Matters for AI, The Data Governance Playbook](https://thedatagovernanceplaybook.substack.com/p/semantic-layer-vs-data-catalog-why) 8. [Ep. 03: Is Semantic Layer = Context Layer?, Atlan WTF Is the Context Layer Series](https://atlan.com/wtf-context-layer/is-semantic-layer-context-layer/)