You're on Cube: Let Agents Edit the Semantic Model, With Every Change Checked Against the Data Under It

Your team defines its metrics in Cube. Cubes and views sit in a Git-backed data model, measures compile to SQL against Snowflake, Databricks or BigQuery, and pre-aggregations keep busy queries fast. Your dbt models arrive as generated cubes on a review branch, and your analytics engineers write the customization layer on top. People ask Analytics Chat, build Workbooks and Dashboards with their agents, and embed the same numbers in your product. Engineers connect Claude or Cursor to the Cube MCP server, which can search the model, run queries and, for roles that can edit the model, write model files, commit them and merge to the default branch. Cube is where your metrics are defined and served. Data Workers keeps the model true to the data under it: Data Context Wizard brings the Cube model in as context with provenance, checks every change against the warehouse tables and dbt models underneath, and routes every model change, whoever proposed it, through one approval flow with a receipt.

A year ago, a model change came from an analytics engineer. Today it can also come from a dbt pull or an agent. Each path is well built. This guide answers the question between them: is the change still right for the data underneath, and who signed off?

Key takeaways

• •Cube keeps its job. The data model, Analytics Chat, Workbooks, Dashboards, pre-aggregations and embedded analytics stay where they are.
• •The Cube model becomes governed context. Data Context Wizard reads the model from its Git repository (your team's assistant can check the deployed model over the Cube MCP server alongside it), and ties each measure to the dbt model and warehouse table it reads, with lineage, quality and a named owner.
• •Every change is checked against the data. A dbt rename, a regenerated cube or an agent's edit on a dev branch is compared with Snowflake and dbt before it merges, with the numbers it would move.
• •One approval flow for every proposer. Changes from people, dbt pull and agents land in one Spellbook queue with their blast radius. Cube's own merge publishes the approved version.
• •Start with a pilot. One Cube deployment, read-only, with every model change checked; then one fix class in one domain, on the ladder from L0 manual to L4 autonomous.

Cube is where your metrics are defined and served. Data Workers keeps the model true to the data under it.

Cube calls itself "the agentic analytics platform built on a semantic layer". It announced its agentic platform as D3 in June 2025; today the work happens in Analytics Chat, the Workbook Agent, the Dashboard Agent and the Slack agent, all reading one data model, and since September Analytics Chat keeps model changes on their own branch per chat. The Cube MCP server, launched in January 2026 and available on all plans, exposes about 30 tools: searchDataModel and runQuery for discovery and queries, dashboard authoring, and, for roles that can edit the model, an edit flow from startDataModelEdit through writeDataModelFile, commitDataModelChanges and mergeToDefaultBranch. Content Validator flags reports that reference removed members, and Cube Evals scores the agent against known-correct answers.

Underneath every measure sits work Cube does not run: the dbt models that build the tables, the warehouse that holds them, and the people who decide what "revenue" means. Data Workers covers that side.

Here is a morning with Data Workers next to a Cube deployment. This is an illustration, not a customer case.

Every tool did its job. dbt pull regenerated the base layer on a review branch, and the agent's edit passed Cube's role check and the client's confirmation prompt. No single tool saw that the hand-written layer still read the old column, or that the agent's working fix changed what revenue means. Data Workers caught both, and one named person decided.

Why doesn't Cube just do this itself?

Cube built its product around the hardest part of its job: one semantic model every person, agent and application can query fast and consistently. Its guardrails fit that job. Model editing tools register only for roles that can edit the model, nine destructive tools are annotated so clients like Claude ask before running them, and edits flow through dev branches, commits and a merge. That is how a semantic layer should treat its own model.

Whether a change is right for the business is a different question, and most of the answer lives outside Cube: the dbt pull request that renamed the column, the warehouse table and its freshness this morning, the dbt metric finance signed off, and the readers in other tools. Acting on that means proposing changes in repositories Cube doesn't own, holding a business owner's approval, and keeping rollback and liability across vendors. That is a product with a very different risk profile. That cross-system context, approval and record is the product Data Workers is.

Every tool owns a slice. Data Workers covers the whole lifecycle

Cube owns one slice of the lifecycle outright: defining metrics once and serving them to every tool, agent and app. 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 Cube model you already run.

How Cube and Data Workers work together

Your people and agents stay where they are: Analytics Chat and Workbooks for business questions, Claude or Cursor for engineers. Spellbook Data Catalog (in preview) is where the data team looks: each proposed model change, its blast radius, approver and rollback. Between them, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.

What Context Wizard does with your Cube model. It reads cubes, views, measures and joins from the model's Git repository, and records each with its source file, expression, grain and owner. Your dbt project comes in directly through an importer ported from Cube's open-source cube_dbt, with the same dimension typing and primary-key inference, so the generated and hand-written layers can be compared line by line. Every measure joins to warehouse lineage, so revenue.total_revenue traces back through fct_orders and the dbt model to its sources. Trust is scored with quality, freshness, usage and ownership, and when a Cube measure disagrees with the dbt metric of the same name, the conflict goes to its named owner.

Setup over MCP today. Data Workers connects to Cube over the Cube MCP server today, alongside its own agents in the same client. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show. Sign in to Cube with a Viewer role for this work: searchDataModel and runQuery are available, and the model editing tools never register. Model files and branches are read from the Git repository that backs your deployment.

// Example: .mcp.json for Claude Code (Cursor uses the same mcpServers shape)
{
  "mcpServers": {
    "cube": {
      "type": "http",
      "url": "https://cubecloud.dev/mcp"
    },
    "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"]
    }
  }
}

Cube's server signs you in with OAuth on first use; list the tools with your client's own command (for example /mcp in Claude Code). An engineer can then ask "which Cube measures read fct_orders, and is it healthy today?" and get the measures from searchDataModel, the lineage from trace_cross_platform_lineage, the latest run_quality_check results on the table and the readers from blast_radius_analysis, in one answer. When a metric name is ambiguous, resolve_metric returns every candidate definition with its source.

Where writes go. Approved changes land where your team already reviews them: a branch on the Cube model repository, merged by its owner through Cube, or a dbt diff for its owner to merge when the fix belongs upstream. When Cube's own agents commit a change to a branch, Data Workers checks it the same way and puts it in the owner's queue before the merge. Every decision is recorded with its receipt in Spellbook.

One request, L0 to L4. The autonomy ladder is set per domain.

• •L0 manual. Data Workers is connected but not acting. Your engineer checks model changes by hand.
• •L1 observe. Data Workers checks every model change against Snowflake and dbt and reports what it would move. Nothing changes.
• •L2 propose. Data Workers drafts the Cube change or the dbt diff with its blast radius. The metric owner approves in Spellbook before anything merges.
• •L3 act reversibly. For proven change classes, such as remapping a measure after an approved column rename, Data Workers applies the change on a branch, verifies the numbers and can roll it back.
• •L4 autonomous. For a scoped class like description updates in one domain, Data Workers fixes and verifies on its own and posts the receipt.

For the safety model behind each step, read is it safe to let AI agents change production data, and for where data and credentials live, read where does our data go.

If you run more than one semantic layer, Data Workers + Cube, AtScale, MetricFlow and Ossie shows how one metric defined three ways gets one approved version. See also the hub, bring your own context, and the guides for the dbt Semantic Layer, AtScale and Ossie YAML semantics. For a side-by-side, see Cube vs Data Workers and semantic layer tools compared.

What changes for your team

Semantic model owners spend much of the week on work that isn't modeling: chasing a measure that broke after a dbt change, checking whether a regenerated branch is safe to merge, reviewing an agent's edit without the numbers. With Data Workers next to Cube, those jobs run on autopilot at the level you set.

• •Incidents. An upstream rename that would break a hand-written measure is caught and fixed before the model merges.
• •Data quality. Every table under a board measure gets freshness and quality checks before Cube serves it.
• •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 restricted view arrives as a time-boxed grant proposal for its owner.
• •Audits. Every model change carries an approver, a diff, the verification and a rollback path.
• •Migrations. When the warehouse under Cube moves, tables move in parity-checked waves while Cube keeps serving the same numbers.

The analytics engineering team gets its week back for the modeling work only it can do.

Keep Cube, or consolidate?

Keep Cube 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 answer is to keep Cube: the data model, the pre-aggregations, the embedded analytics and the agents your business users trust belong there. What teams consolidate is the tooling around the model: a separate data-quality tool for the tables under it, a script that diffs generated cubes against dbt, a spreadsheet that maps measures to owners. If you are weighing building this layer yourself on the Cube MCP server, read build it ourselves with Claude Code and MCP servers: connecting the servers is the easy part; cross-system context, approvals and rollback are the work.

The case for your CFO

The outcome: the numbers Cube serves to the board, to customers and to every agent stay right as the model changes, and every change has a named approver.

The risk story: agents now edit semantic models. With Data Workers, every change to the Cube model, from a person, a dbt pull or an agent, is checked against the warehouse and the approved definition, shows the numbers it would move, and goes to the metric's named owner before it merges. Data Workers reads Cube with a Viewer role; Cube's own branch and merge flow publishes the approved version. Every change is verified after the merge 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. There is zero migration.

Why now: Cube's agents and MCP server can already write to the model, and dbt pull regenerates it on every push. The first win is one Cube deployment read-only, with every model change checked before it merges. What stays the same: your data model, your roles and access policies, your Cube plan, your dbt project and your review process. For the numbers, see the ROI of agentic data operations.

The sentence to repeat upstairs: "Cube keeps defining and serving our metrics; Data Workers checks every model change against the data underneath, and a named owner approves it with a receipt."

Getting started

Start with a pilot. Pick one Cube deployment that serves numbers people act on, such as the board dashboard, connect the Cube MCP server with a Viewer role next to Data Workers, and let Data Workers check every model change 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 write to our Cube data model? No. It reads Cube with a Viewer role, so the editing tools never register. Approved changes land as a diff for your model repository or for dbt, and your model owner merges through Cube.

Cube's agents can already edit and commit the model. Why add an approval? Cube's role gates and the confirmation prompts on its destructive tools decide who may change the model. Data Workers adds what the change would do to the numbers and a named business owner's sign-off, in one queue for every proposer.

We use Cube's dbt integration. Does that change anything? It makes the check more useful. dbt pull regenerates the base layer on a review branch, and Data Workers checks the hand-written layer and every reader against the dbt change before that branch merges.

Does this replace Content Validator or Cube Evals? No. Content Validator keeps reports pointing at members that exist, and Cube Evals measures the agent's accuracy. Data Workers checks the data and definitions under the model, across systems.

How does lineage reach from a Cube measure to the source? Context Wizard records which table and column each measure reads, and joins that to lineage across dbt, ingestion and the sources. trace_cross_platform_lineage follows the table under a measure back to the source field.

Does this affect pre-aggregations? Cube keeps building them. After an approved change merges and the rollups rebuild, Data Workers verifies the served numbers against the warehouse.

Sources

• •Cube, homepage (agentic analytics platform, Analytics Chat, Workbook Agent, Dashboard Agent, MCP server), https://cube.dev/ (checked Oct 2, 2026)
• •Cube, Announcing Cube D3 (June 2, 2025), https://cube.dev/blog/announcing-cube-d3 (checked Oct 2, 2026)
• •Cube, MCP server documentation (30 tools, Viewer role or higher, editing tools for Admin and Developer roles by default, nine destructive tools that clients such as Claude confirm, edit workflow, all plans), https://docs.cube.dev/docs/integrations/mcp-server (checked Oct 2, 2026)
• •Cube, dbt integration documentation (dbt pull, review branch, generated files), https://docs.cube.dev/docs/integrations/dbt (checked Oct 2, 2026)
• •Cube, changelog (MCP Server Jan 30, 2026; Data Masking Mar 20; Dashboard Agent May 29; Cube Evals Jun 26; Content Validator Jul 3; dbt Integration Jul 17; Python Analysis Jul 31; Chat Artifacts Sep 11, 2026; entries to Sep 25, 2026), https://cube.dev/changelog (checked Oct 2, 2026)
• •Cube, REST API reference (/v1/meta, /v1/load), https://docs.cube.dev/reference/core-data-apis/rest-api/reference (checked Oct 2, 2026)
• •cube-js/cube_dbt (MIT), the dbt-to-Cube conversion our importer is ported from, https://github.com/cube-js/cube_dbt (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)