You're on AtScale: Keep One Semantic Model True for Excel, Power BI, Tableau and Every Agent
Already on AtScale? Data Workers brings your SML model in as governed context, catches source changes that would shift its numbers, and fixes them through one approval flow.
Your finance and sales teams agree on what "net revenue", "bookings" and "gross margin" mean, because AtScale defines them once. The model lives in SML, the YAML-based Semantic Modeling Language, in Git: datasets point at warehouse tables, dimensions and hierarchies sit on top, metrics and calculations sit on those. Design Center is where modelers work. Excel users build PivotTables over MDX, Power BI reports query through DAX, Tableau and the rest connect over SQL, notebooks use Python, and agents in Claude, ChatGPT or Gemini read the same model through AtScale's MCP server, generally available since release C2026.7. AtScale's AI Computation Engine computes a metric "identically whether the question comes from Claude, Cursor, Power BI, Excel, or Tableau", and its aggregates keep those answers fast on Snowflake, Databricks, BigQuery or Redshift. AtScale is where your metrics are defined once and served everywhere. Data Workers keeps that model true: Data Context Wizard brings your SML in as context with provenance and joins it to the lineage, quality and usage underneath, and when a source change would shift or break the model, Data Workers proposes the fix through one approval flow and leaves a receipt.
The model is only as right as the tables it points at. A renamed dbt column, a late Fivetran sync or a new code in a source system all reach AtScale through the warehouse, and every workbook, report and agent that asks gets the result. That seam is the job this guide covers.
Key takeaways
- •AtScale keeps its job. SML, Design Center, the query engine, aggregates and every BI connection stay as they are. Data Workers works next to them from day one.
- •Your model becomes governed context. Context Wizard reads the SML in Git (your team's assistant can check the deployed model over AtScale's MCP server alongside it), then ties each dataset column to the dbt models, ingestion jobs and source fields behind it.
- •Source changes are caught before the business sees them. A new code in a source system, a rename, or a grain change that would shift a hierarchy or a metric is flagged with every affected dataset, metric and query pattern named.
- •One approval flow, one receipt. Fixes go to a named owner in Spellbook as diffs for the dbt or SML repository, for the owner to merge, and Data Workers verifies the answer through AtScale afterwards.
- •Start with a pilot. One model, read-only, with its source columns watched; then one fix class in one domain, on the ladder from L0 manual to L4 autonomous.
AtScale is the semantic layer. Data Workers is the operations layer that keeps it true.
AtScale does one job very well: one definition of every metric, served to every tool, computed the same way. Its MCP server exposes that model to agents through six read-only tools: list_models, explore_columns and focus_columns to discover the model, run_query for governed SELECT queries, get_outbound_queries to see the SQL AtScale sent to the warehouse, and get_sml_skills for semantic-layer guidance. SML is open source under Apache 2.0, now at version 1.8, with converters to and from Snowflake Cortex semantic models, Databricks UC metrics and Power BI.
Underneath the model sits everything that decides whether its answers are right: source systems, ingestion, dbt, the orchestrator and the warehouse. Data Workers covers that side, and reads the model so it knows exactly which columns the business depends on.
Here is one afternoon with Data Workers next to a finance model on AtScale. This is an illustration, not a customer case. Nothing in it fails loudly: every query keeps running, and the numbers move.
| Time | System | What happens |
|---|---|---|
| 15:00 | Salesforce | Sales operations splits the EMEA value in the account Region picklist into EU and MEA as part of a territory change |
| 15:30 | Fivetran | The next sync lands the new values in salesforce.account. No column changed, so the sync succeeds |
| 15:45 | dbt + Snowflake | The hourly job rebuilds dim_account. The region_theater_map seed that rolls Region up to Theater has no rows for EU or MEA, and the build passes |
| 15:50 | Data Workers | run_quality_check on the columns the finance model maps to flags a distribution change in dim_account.region: two values it has never held, and no EMEA rows |
| 15:55 | AtScale | Data Workers reads the SML from Git: the Geography hierarchy runs Theater, Region, Country on dim_account. A run_query for bookings by Theater shows International down by a third, with the difference sitting in an unassigned member |
| 16:05 | Snowflake | get_outbound_queries and query history show the finance model groups by theater about 1,200 times a day, including the board's bookings PivotTable and two Power BI reports |
| 16:20 | GitHub (dbt repo) | Data Workers proposes a diff that adds EU and MEA to the seed under International, plus an accepted-values test on region, with the blast radius: one seed, one dimension table, one hierarchy, five metrics that slice by theater |
| 17:00 | Spellbook | The sales operations lead confirms the mapping and the finance model owner approves |
| 17:10 | dbt + Snowflake | The change merges and the job rebuilds dim_account |
| 17:30 | AtScale | Data Workers runs the same bookings-by-Theater query through run_query, confirms International matches the morning's total plus the afternoon's new bookings, and writes the receipt |
| 08:15 | Excel, Power BI | The CFO's PivotTable refreshes by theater; International is whole |
Every system did its job. Salesforce took a valid territory change, Fivetran synced it, dbt built cleanly, and AtScale computed exactly what its model asked for. Without the check at 15:50, the first sign would have been a regional VP asking at the forecast call why International bookings dropped overnight. The SML never needed to change: the fix belonged in a dbt seed, approved by two named owners.
| Job | What AtScale does | What Data Workers does |
|---|---|---|
| The model | Defines metrics, dimensions, hierarchies and calculations once in SML | Reads the model as context and joins each dataset column to lineage, quality, usage and owners |
| The answers | Serves Excel, Power BI, Tableau, Python and agents from one model, fast, through aggregates | Makes sure the tables and values behind those answers are correct and current |
| The source | Queries the warehouse tables each dataset names | Watches those tables for schema, value, grain and freshness changes before they shift the model |
| The fix | Deploys the model changes its owner approves | Proposes changes in dbt or SML with the blast radius and routes them to a named owner |
| The proof | Stores inbound requests and the queries it executes | Verifies the answer through AtScale and writes a receipt with the cause, diff, approver and rollback |
| The meaning | Holds the authoritative definition for every query through AtScale | Keeps that definition consistent with dbt, warehouse semantic objects and the catalog, with conflicts routed to an owner |
Why doesn't AtScale just do this itself?
Because AtScale built a semantic layer, and its design is right for that job. The model is authoritative for every query through it, and AtScale guards it carefully: every tool on its MCP server declares itself read-only, and the server parses each statement and rejects anything that is not a SELECT before it reaches the warehouse. Modelers change the model in Design Center or SML and deploy it on purpose. That is exactly what you want from the system every finance workbook trusts.
The changes this guide is about start outside the model, in systems AtScale doesn't run: the CRM, the Fivetran connector, the dbt project, the Airflow DAG. Changing those means writing to other vendors' systems and to production data, with a blast radius, an approval, a rollback path and accountability for the result. For a semantic layer, taking that on would mean reaching into your pipelines from the place your metrics are served, which is a sensible thing to keep separate. That cross-system, write-with-approval work is the product Data Workers is.
Every tool owns a slice. Data Workers covers the whole lifecycle
AtScale owns one slice of the data lifecycle outright: defining metrics once and serving them to every BI tool and agent. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the semantic layer you already run.
| Stage | Data Workers | AtScale | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 9.5 | AtScale's home stage: metrics, dimensions, hierarchies and calculations defined once in SML and served over SQL, MDX, DAX, Python, REST and MCP. Data Workers brings that model in as context, next to lineage, quality and usage. |
| Analytics & Insights | 8 | 9.5 | AtScale's other home stage: Excel, Power BI and Tableau users query live warehouse data through one model, with aggregates that keep answers fast. Data Workers' Insights agent answers through governed metric definitions. |
| Data Quality | 8 | 3 | AtScale computes each metric the same way for every tool; testing the source tables is a different job. Data Workers checks the tables and columns the model reads and repairs breaks before the next build. |
| Observability & Incidents | 8.5 | 3 | AtScale stores inbound requests and the queries it runs. Data Workers detects a source change, traces it to every model and report, fixes it and verifies the result. |
| Pipelines & Ingestion | 8.5 | 3 | Query-based datasets can be materialized as AtScale-managed tables (public preview). Data Workers builds, reruns and backfills the pipelines that feed the model, with approvals. |
| Schema & Migration | 8 | 4 | Versioned SML in Git, with converters for Snowflake Cortex, Databricks UC metrics and Power BI. Data Workers detects upstream schema changes and assesses their impact on every dataset before they land. |
| Governance & Access | 8.5 | 6.5 | Strong over its own model: row security, access rules and auditable query history. Data Workers proposes and applies grants across your data platforms by policy. |
| Security & Privacy | 8 | 5 | Strong for its own queries: governed access and traceable answers. Data Workers flags sensitive column names in pull request review and proposes masking for the owner. |
| Cost / FinOps | 8 | 5 | Aggregates cut full-table scans for BI and AI queries. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 3 | A Python interface serves governed metrics to notebooks. Data Workers keeps the data under your models healthy and connects to MLflow and W&B. |
How AtScale and Data Workers work together
Your people and agents stay where they are: Excel, Power BI and Tableau for analysis, Claude Code or Cursor for engineering, Design Center for modeling. Spellbook Data Catalog (in preview) is where the data team reviews each proposed change, its blast radius, approver and rollback. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm's 20+ specialist agents do the work, and the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember) under per-domain guardrails.
What Context Wizard does with your model. It reads the SML files from Git and records each definition with provenance: file, commit, read time and owner. Your team's assistant confirms the deployed model over AtScale's MCP server with list_models and explore_columns, and Data Workers joins every dataset column to warehouse lineage, so the Theater level traces back through dim_account and the seed under it to the Salesforce field it came from. It serves one governed view to every agent through tools like explain_table and trace_cross_platform_lineage, and when AtScale's "net revenue" disagrees with the dbt Semantic Layer's, the conflict goes to a named owner.
Setup over MCP today. Data Workers connects to AtScale over its MCP server today, in the same client as its own agents. Your AtScale admin enables the server with atscale-mcp: enabled: true in the Helm values, and you authenticate with the atscale-mcp OAuth client or an API token from Design Center, issued to a user with read access to the models you want covered. Data Workers' agents are MCP servers from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show.
// Example: .mcp.json for Claude Code (Cursor uses the same mcpServers shape)
{
"mcpServers": {
"atscale": {
"command": "npx",
"args": ["mcp-remote", "https://<your-atscale-host>/mcp",
"--header", "Authorization: Bearer ${AUTH_TOKEN}"],
"env": { "AUTH_TOKEN": "<AtScale API token from your secret store>" }
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-schema": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-schema"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
}
}
}List the tools with your client's own command (for example /mcp in Claude Code). An engineer can then ask "what feeds the Theater level in the finance model, and is it safe to rename dim_account.region?" and get the model's columns from AtScale, lineage from trace_cross_platform_lineage, impact from assess_impact and check_compatibility, and the latest run_quality_check results, in one answer.
Where writes go. Fixes land where your team already reviews change: a dbt diff for the tables and an SML diff for the model, each for its owner to merge. The model owner deploys from Design Center or CI, as today.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Data Workers is connected but not acting. Your modeler traces the change by hand.
- •L1 observe. Data Workers watches every column the model maps to, flags changes with lineage and owners, and changes nothing.
- •L2 propose. Data Workers drafts the dbt or SML diff with its blast radius. The owner approves in Spellbook before anything merges.
- •L3 act reversibly. For change classes with a proven record, such as rerunning a late partition the model reads, Data Workers applies the change, verifies through AtScale and can roll it back.
- •L4 autonomous. For a scoped, trusted class like late feeds into one model's source tables, Data Workers fixes and verifies on its own and posts the receipt.
For the safety model, read is it safe to let AI agents change production data; for where data and credentials live, where does our data go.
If you run more than one semantic layer, Data Workers + Cube, AtScale, MetricFlow and Ossie shows how Context Wizard compares definitions across all of them. See the hub, bring your own context, and the guides for teams on Cube, the dbt Semantic Layer and Apache Ossie (formerly Open Semantic Interchange). For the wider category, semantic layer tools compared and why a semantic layer is not enough for AI cover the tradeoffs.
What changes for your team
Semantic layer teams spend much of the week on work that isn't modeling: chasing a shifted total, explaining why an Excel number moved, rebuilding after a late load. With Data Workers next to AtScale, those jobs run on autopilot at the level you set.
- •Incidents. A source change that would break a dimension or shift a metric is caught, traced and fixed before it reaches Excel or Power BI.
- •Data quality. Every column a dataset maps to gets null, range, distribution and freshness checks in the warehouse.
- •Cloud spend. Snowflake credits are traced to the query and dbt model behind them, and each fix goes to its owner drafted.
- •Access. A request for a sensitive measure, such as margin by customer, arrives as a time-boxed grant proposal for its owner.
- •Audits. Every change to a dataset, source table or definition carries an approver, a diff and a rollback path.
- •Migrations. When the warehouse under the model moves, the source tables move in parity-checked waves while AtScale keeps answering.
The modeling team gets its week back for new subject areas, new metrics and the business conversations only it can have.
Keep AtScale, or consolidate?
Keep AtScale if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most teams, the SML model, the DAX and MDX support Excel and Power BI depend on, and the aggregates belong right where they are. What teams consolidate is the tooling around the model: a separate quality tool for the source tables, a spreadsheet mapping dataset columns to dbt models, a script that compares yesterday's totals, a Slack thread as the change log. If you are weighing building this layer yourself on AtScale's MCP server, read build it ourselves with Claude Code and MCP servers: the connection is the easy part; the cross-system context, approvals and rollback are where the work is.
The case for your CFO
The outcome: the numbers finance, sales and the board read in Excel and Power BI stay right every morning, and every agent that asks gets the same answer. AtScale already makes the definition consistent; Data Workers keeps the data under it correct as the business changes.
The risk story is plain. Data Workers reads SML from Git; your team's assistant uses AtScale's read-only MCP server side by side with it. Every change it proposes shows its blast radius, goes to a named approver as a diff your team already reviews and merges, is verified through AtScale and leaves a receipt: who approved it, what it touched and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous and can be dialled back at any time. Zero migration: AtScale, the warehouse, dbt and your BI tools stay put.
Why now: agents read the model directly over MCP, next to every Excel and Power BI user, so one unnoticed source change reaches more people faster. The first win is one model with its source columns watched, read-only, so the next territory change is caught the afternoon it happens. What stays the same: your SML, Design Center workflow, AtScale deployment, warehouse permissions and review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "AtScale gives us one definition of every number; Data Workers keeps the data under it right, and fixes breaks with an owner's approval and a receipt."
Getting started
Start with a pilot. Pick the AtScale model your finance leaders read most, connect AtScale's MCP server and the SML repository read-only, and let Data Workers watch the model's source columns for a few weeks before enabling the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers change our AtScale model? Only through its owner. Data Workers proposes SML changes as diffs for your model repository; the owner approves in Spellbook and deploys from Design Center or CI. AtScale's MCP server stays read-only.
How does Data Workers read AtScale today? From the SML files in your Git repository, recorded in Context Wizard with source, commit and owner, and over AtScale's MCP server to confirm the deployed model and run governed SELECT queries for verification.
Does this replace AtScale's aggregates or query engine? No. AtScale keeps serving every tool with its own aggregates. Data Workers keeps the tables those queries read healthy and current.
What happens when AtScale and dbt define a metric differently? Context Wizard routes the conflict to a named owner, and agents that ask Data Workers see both definitions with their sources until the owner decides. The multi-layer wiring guide walks through a full run.
Our modelers work in Design Center, not Git. Does that matter? Your team's assistant can check the deployed model over AtScale's MCP server either way. SML in Git adds commit-level provenance and lets Data Workers propose model changes as diffs for the owner to merge.
Sources
- •AtScale, homepage (components, interfaces), https://www.atscale.com/ (checked Oct 2, 2026)
- •AtScale, Platform (BI tools, data platforms, deployment, aggregates, auditable execution), https://www.atscale.com/product/ (checked Oct 2, 2026)
- •AtScale, Semantic context for AI with MCP (SQL, MDX, DAX, Python, REST and MCP), https://www.atscale.com/use-cases/semantic-context-ai-mcp/ (checked Oct 2, 2026)
- •AtScale, Microsoft joins open semantic standard (Sep 29, 2026; AI Computation Engine, Apache Ossie), https://www.atscale.com/blog/microsoft-joins-open-semantic-standard/ (checked Oct 2, 2026)
- •AtScale, MCP Server Tools Reference (six read-only tools, SELECT only), https://documentation.atscale.com/container/connect-integrate/connecting-with-ai/mcp-tools-reference (checked Oct 2, 2026)
- •AtScale, C2026.7 release notes (MCP Server GA, read-only enforced), https://documentation.atscale.com/container/release-notes/C2026.7/new-features-and-improvements (checked Oct 2, 2026)
- •AtScale, Connecting with AI applications (ChatGPT, Claude, Gemini), https://documentation.atscale.com/container/connect-integrate/connecting-with-ai/connect-ai-applications (checked Oct 2, 2026)
- •AtScale, Enable the MCP Server (Helm values), https://documentation.atscale.com/container/connect-integrate/connecting-with-ai/manage-mcp-server/enable-mcp-server (checked Oct 2, 2026)
- •AtScale, MCP development environment setup (endpoint, OAuth client, API token), https://documentation.atscale.com/container/connect-integrate/connecting-with-ai/manage-mcp-server/development-environment (checked Oct 2, 2026)
- •AtScale, C2026.8 new features and improvements (query-based dataset materialization, public preview), https://documentation.atscale.com/container/release-notes/C2026.8/new-features-and-improvements (checked Oct 2, 2026)
- •Semantic Modeling Language (SML), Apache 2.0, version 1.8, object types and converters, https://github.com/semanticdatalayer/SML (checked Oct 2, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)