You're on Rill: Your Metrics Views Answer in Milliseconds. Data Workers Makes Sure the Data Feeding Them Is Right
Already on Rill? Data Workers checks the data under every metrics view, traces a wrong number to the release, sync or model behind it and fixes it behind a named approval, with a receipt.
Your team runs on Rill. Engineers build the project in Rill Developer as SQL and YAML in a GitHub repository: connectors, models, metrics views and alerts, all as code. Ad ops, sales and finance work in Rill Cloud: explore dashboards for slicing and drilling, canvas dashboards for the views leadership reads, bookmarks, scheduled reports and Slack alerts. Underneath sits a fast engine: DuckDB by default, or a live connector to Druid, ClickHouse, Pinot, StarRocks, Snowflake, BigQuery or Databricks. People ask AI Chat why a measure spiked, and analysts in Claude Code reach the same metrics through the Rill MCP server. Rill serves fast operational dashboards from metrics you define in code. Data Workers makes sure the data feeding those metrics is right: it checks the tables after every build, traces a wrong number to the change that caused it, proposes the fix behind a named approval and verifies it with a receipt.
Key takeaways
- •Rill keeps its job. Metrics views, explore and canvas dashboards, alerts, reports, AI Chat and the MCP server stay with the people who own them today.
- •Fast makes a wrong number travel fast. A metrics view answers in milliseconds for every dashboard, alert and AI answer at once, so a broken field reaches ad ops before anyone opens the pipeline.
- •The fix lands where the cause is. Data Workers proposes the upstream change as a diff for its owner, routes it to a named approver and queues the rerun.
- •Data Workers changes nothing in Rill or your OLAP engine. It works natively on Snowflake, Kafka Connect, dbt and Airflow; your team's own client reaches Rill through its MCP server.
- •Start with one dashboard people act on, then climb from L0 manual to L4 autonomous per domain.
Rill serves fast operational dashboards from metrics you define in code. Data Workers makes sure the data feeding those metrics is right.
Rill's promise is one answer, fast. Its docs say MCP responses are "guaranteed to be as accurate and consistent as the metrics displayed in your Rill dashboards", and they are: the AI, the alert and the dashboard all read the same metrics view. That consistency is why the data under the metrics view matters: if a field upstream stops arriving, every surface agrees on the same wrong number, instantly.
Here is a Tuesday afternoon at an audio ad network with Data Workers next to Rill on a Druid and Snowflake stack. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Tue 13:30 | GitHub | The ad-server team merges "SDK v5 event envelope" for the new host-read podcast format. The new envelope writes the line item as lineItemId; the other formats still send line_item_id |
| 13:45 | Ad server, Apache Kafka | The release deploys. About 31% of events on the ad_impressions JSON topic, all host-read, now carry the camelCase key |
| 13:46 | Apache Druid | The Kafka supervisor ingests as usual. Its ingestion spec reads line_item_id, finds nothing on host-read events and stores the line item as null; minute rollup merges those rows per campaign and publisher. Ingestion is healthy and lag is normal |
| 13:46 | Kafka Connect, Snowflake | The Snowflake sink connector lands the raw JSON in RAW.AD_IMPRESSIONS as before. The record still holds the line item, under the new key |
| 14:00 | Airflow 2, dbt Core | The ads_hourly DAG run builds stg_ad_impressions and fct_line_item_delivery, the table advertiser invoices come from. Staging reads record_content:line_item_id. The run is green |
| 14:10 | Data Workers | The post-run run_quality_check on stg_ad_impressions fails: line_item_id is null on 31% of rows, over the team's threshold (it usually runs near 0.2%). Row counts are above the minimum, and get_connector_status shows the sink connector running, so nothing stopped. The hourly delivered-impressions value the team records for host-read line items with monitor_metrics is flagged too |
| 14:12 | Data Workers, Slack | The dbt manifest shows no model changed since the last good run, so diagnose_incident points upstream. trace_cross_platform_lineage follows stg_ad_impressions back to RAW.AD_IMPRESSIONS and forward to fct_line_item_delivery; blast_radius_analysis lists the downstream models and two notes the team recorded in the context graph: the advertiser invoice export reads fct_line_item_delivery, and the Rill pacing metrics view reads the same topic through Druid. send_slack_alert posts to #ads-data-oncall with the evidence and a check to run |
| 14:20 | Snowflake | The data engineer runs the check: SELECT record_content:lineItemId IS NOT NULL AS new_key, count(*) FROM raw.ad_impressions WHERE record_metadata:CreateTime >= DATE_PART(epoch_millisecond, '2026-09-29 13:30'::timestamp) GROUP BY 1; It returns 1.9M events with the new key, all host-read, all since 13:45. Cause confirmed. She posts the incident link in #ad-ops |
| 14:25 | Data Workers | Proposes the fix as a diff for the owner to merge: staging reads coalesce(record_content:line_item_id, record_content:lineItemId), and a not_null test on line_item_id makes the next renamed key fail the run. With it: the blast radius, the rerun plan and the undo (revert the diff). The incident notes two changes for their owners: the ad server should send the old key again, and the Druid ingestion spec needs to read the new key too, plus a reindex from 13:45. The approval request reaches the ads data lead in Slack |
| 14:40 | Spellbook | The ads data lead approves in Spellbook; the analytics engineer merges the diff |
| 14:45 | Airflow 2 | Data Workers queues the approved ads_hourly rerun with trigger_airflow_dag |
| 15:00 | Rill Cloud, Slack | Rill's hourly pacing alert, a metrics_sql query over the pacing metrics view, fires to #ad-ops: 37 host-read line items under 80% of pace. The explore dashboard shows a null line item holding a third of host-read impressions |
| 15:05 | Rill Cloud AI Chat | A trader opens AI Chat from the explore dashboard and asks why these line items are under-delivering. The answer: delivery shifted from 37 line items to an unattributed bucket starting 13:45, concentrated on two podcast publishers, with links to the filtered dashboard. It is faithful to the metrics view; the ads ran. The incident link in the channel stops the bid changes |
| 15:20 | Ad server | The ad-server team ships a hotfix that writes both keys |
| 15:30 | Data Workers | The rerun finishes. run_quality_check passes with line_item_id null on 0.2% of rows, and monitor_metrics records host-read delivery back on its baseline. fct_line_item_delivery is right a day before month-end invoicing |
| 16:40 | Apache Druid | The Druid owner updates the ingestion spec and reindexes 13:45 to 15:20 from the topic |
| 16:55 | Rill Cloud | The trader checks the pacing explore: 37 line items on pace. The alert's recovery notice posts to #ad-ops. Data Workers writes the receipt (cause, diff, approver, rerun, checks, undo) and a graph note that ad_impressions producers must keep line_item_id |
Every tool did its job. Rill alerted on the metric and explained the chart in seconds. The cause sat in an SDK release; the evidence sat in Snowflake. Data Workers caught it before the pacing alert fired, a named person approved the fix, and no bid or invoice went out wrong.
| Job | What Rill does | What Data Workers does |
|---|---|---|
| The metric | Metrics views define measures and dimensions once in YAML, and every dashboard, alert and AI answer reads them | Keeps the tables and dbt models under those metrics right |
| The speed | Queries Druid, ClickHouse, DuckDB or your warehouse live, with rollups for common grains | Checks the tables after every build and holds the values your team records to a baseline |
| The break | Alerts when a metric crosses a threshold; AI Chat explains what moved in the chart | Traces the movement to the release, sync or model behind it and lists every model and recorded dashboard it reaches |
| The fix | Owners edit metrics views and alerts in Git; engine owners reindex | Proposes the upstream fix as a diff for its owner, routes it to a named approver and queues the approved rerun |
| The proof | The dashboard and alert recover on the next query | Re-checks the tables, compares the recorded values and writes a receipt with cause, diff, approver and undo |
Why doesn't Rill just do this itself?
Rill made a clear bet: BI as code on the fastest engine you have, with one metrics layer for people and agents. Its safeguards fit that job. Projects live in Git, with branch deployments for review. Data quality tests run whenever a Rill model refreshes. Alerts as code check a query on a cron, notify Slack or email and confirm recovery. The MCP server is "designed primarily for data analysts, not data engineers" and built for consuming metrics views rather than creating them, and AI Chat "only queries metrics views you've already defined".
Rill also draws its own line. On live connectors, its docs say, "alerts are your primary tool for data quality monitoring. Since live connectors don't create local models, data quality tests won't run", and Rill does not model on Druid at all. That is a sensible scope: the Druid cluster, the Kafka topic, the ad server and the dbt project belong to other teams. This incident took a check query in Snowflake, a dbt change, a named approval, an orchestrator rerun, an ad-server hotfix and a Druid reindex. Coordinating changes in systems Rill doesn't own, with blast-radius scoping, approvals, rollback and receipts, is a different product with different liability. That product is Data Workers, and it builds on the Rill your operators already trust.
Every tool owns a slice. Data Workers covers the whole lifecycle
Rill owns one slice outright: fast operational dashboards from a code-defined metrics layer. 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 Rill you already run.
| Stage | Data Workers | Rill | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 6 | Metrics views define dimensions and measures once in YAML, with ai_instructions and project skills for agents. Data Workers keeps one governed context graph across every platform, joined to lineage, quality and owners. |
| Analytics & Insights | 8 | 9 | Rill's home stage: explore and canvas dashboards on fast OLAP engines, AI Chat and the AI agent that finds the why behind a number, all from the same metrics. Data Workers makes sure the data under them is right. |
| Data Quality | 8 | 4 | Data quality tests run when Rill models refresh; on live connectors such as Druid, alerts are the check. Data Workers tests the tables underneath for nulls, duplicate ids and row counts, and holds recorded values to a baseline. |
| Observability & Incidents | 8.5 | 5 | Alerts as code watch a metric on a schedule and notify Slack or email, with recovery notices. Data Workers traces a wrong number to the release, sync or model behind it, proposes the fix and verifies it. |
| Pipelines & Ingestion | 8.5 | 4 | Source and incremental models load data into the default DuckDB engine on a refresh schedule. Data Workers queues approved reruns through the orchestrator for the pipelines under Rill. |
| Schema & Migration | 8 | 3 | Projects live in Git, with branch deployments for review. Data Workers reviews dbt pull requests with a lineage diff that reads exposures, and scopes the blast radius across models and recorded dashboards. |
| Governance & Access | 8.5 | 4 | Roles, user groups and row-level access policies govern who sees which metrics. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 4 | Access tokens, OAuth for the MCP server and View As for testing policies protect Rill itself. Data Workers leaves a receipt on every data change and proposes masking for the owner to apply. |
| Cost / FinOps | 8 | 3 | Rollups route queries to pre-aggregated tables and query attributes tag engine cost. Data Workers attributes Snowflake spend per query and per dbt model through query tags. |
| MLOps & Models | 7.5 | 2 | Rill serves analytics, not models. Data Workers keeps the data under models and agents healthy. |
How Rill and Data Workers work together
Your people stay in Rill Cloud, AI Chat, Claude Code or Cursor, and Slack. Spellbook Data Catalog (in preview) is where the data team reviews each proposed fix, its blast radius, approver and rollback. Underneath, 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.
Where Data Workers works. Data Workers works natively on the systems around Rill: Snowflake, Kafka Connect, the dbt project and Airflow, Dagster or Prefect. Rill connects over its API or MCP server today, and Druid over its API; Data Workers' agents call neither. Metrics views and dashboards enter the blast radius when your team records them in the context graph, with notes such as "the pacing view reads ad_impressions through Druid"; when a fix goes through a pull request, change review's lineage diff also reads the dbt exposures. Data Workers writes nothing to Rill or your OLAP engine; Rill's owners stay its editors.
What Data Workers checks under each metrics view. run_quality_check runs nulls, uniqueness on id columns and a minimum row count on Snowflake and Postgres tables (BigQuery with a service-account key); get_quality_score rolls them up. monitor_metrics holds the values your team records, such as hourly delivered impressions, to a baseline, so a change on an engine Data Workers doesn't read still opens an incident. trace_cross_platform_lineage and blast_radius_analysis follow a table back to its source and forward to every model and recorded dashboard; explain_table gives its definition, lineage, documentation and trust score; diagnose_incident, remediate and get_incident_history run and record the incident. Your data stays in your systems: the agents, warehouse credentials and model key run in your infrastructure, and the hosted Conductor sees workflow metadata only.
Setup over MCP today. Clone the open-source repository and add start-agent.sh entries to your client's MCP config, as the client setup docs show. The Rill MCP server can sit next to Data Workers in the same client; Data Workers' agents never call it. Rill's server is consumption-only by design (list, read and query metrics views, load project skills); Claude Code connects over OAuth with claude mcp add --transport http and the project's MCP URL.
// Example: .mcp.json for Claude Code. The rill entry is your team's own connection
// to the Rill MCP server (OAuth on first connect via /mcp); Data Workers does not call it.
{
"mcpServers": {
"rill": {
"type": "http",
"url": "https://api.rilldata.com/v1/orgs/your-org/projects/ad-pacing/runtime/mcp"
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
}
}
}List the tools with /mcp. An analyst can ask "is everything under the pacing dashboard healthy?" and get the metrics view and current numbers from Rill's server and the lineage, checks and open incidents from Data Workers in one answer. Teams that build Rill projects with the Rill Agent Skills from rill init --agent keep doing so in the same client.
Where fixes go. Data Workers proposes the change as a diff for the owner to merge, usually a dbt model, test or source mapping, with its blast radius and undo step. It opens the pull request itself only when your team turns on the dbt GitHub pull-request target. After approval it queues the rerun through Airflow, Dagster or Prefect.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Data Workers is connected and not acting. A trader notices a pacing drop and asks around.
- •L1 observe. Data Workers checks every table under your key metrics views and logs what it would do.
- •L2 propose. Data Workers drafts the upstream fix with its blast radius. A named owner approves in Spellbook before anything runs.
- •L3 act reversibly. For proven classes, such as rerunning the hourly DAG after an approved staging fix, Data Workers acts, verifies and records the undo.
- •L4 autonomous. For a narrow class in one domain, Data Workers fixes and verifies on its own and posts the receipt.
Approvals go to a named person; a request nobody answers expires and escalates, and never grants itself. No agent can promote its own work. Read is it safe to let AI agents change production data, how approvals work for AI data agents and where does our data go for the full safety model.
If Rill sits on ClickHouse instead of Druid, You're on ClickHouse shows the loop on that engine. For the systems in this example, see You're on Apache Kafka and You're on Airflow; running a second BI tool, see You're on Metabase.
What changes for your team
Teams on Rill run operational data: impressions, auctions, listens, sensor readings, refreshed by the minute and acted on by the hour. With Data Workers, these jobs run on autopilot at the level you set.
- •Incidents. A pacing drop that is really a pipeline bug arrives with the cause, the blast radius and a fix ready to approve.
- •Data quality. The tables under your metrics views are checked after each build, and the numbers you record hold to a baseline.
- •Cloud spend. Snowflake spend is attributed down to the dbt model, with warehouse settings drafted for the owner.
- •Access. A request for a restricted table becomes a scoped, time-boxed grant proposal the data owner approves.
- •Audits. Every data change behind a Rill metric carries the approver, the diff, the checks and the undo step.
- •Migrations. When the warehouse under your billing tables moves, tables move in approved waves with parity checks tracked per wave.
Keep Rill, or consolidate?
Keep Rill 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 Rill: the metrics views, the speed, the dashboards and AI Chat belong there. What teams consolidate is the tooling around it: a separate data-quality tool, threshold alerts that each guess at a cause, and a wiki page listing which topic feeds which metrics view. Weighing a build on the Rill MCP server and a coding agent? Read build it ourselves with Claude Code and MCP servers: connecting servers is the easy part; cross-system context, approvals and rollback are the work. For what Data Workers reads and changes on each system, see Data Workers integrations, and for how this differs from monitoring alone, Data Workers vs data observability.
The case for your CFO
The outcome: the numbers people act on every hour in Rill (delivery, pacing, revenue) stay right, and when an upstream release changes what arrives, the fix is approved before anyone acts on a false signal or sends a wrong invoice.
The risk story: Data Workers changes nothing in Rill or the engine under it. It checks the tables and dbt models feeding each metrics view, proposes upstream fixes as diffs, and nothing runs until the named owner approves. Every change leaves a receipt: what broke, what changed, who approved it and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous, and an org-wide stop halts all autonomous dispatch. There is zero migration.
Why now: Rill's AI agent and MCP server put the same metrics in front of every operator and assistant in seconds, so a broken field upstream becomes a confident answer, a bid change or an invoice line before a person looks at the pipeline.
The first win: one dashboard people act on, with every table under it checked after each build and its headline numbers held to a baseline. What stays the same: your Rill project, OLAP engine, Kafka, warehouse, dbt project, orchestrator and review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Rill keeps giving everyone the number in milliseconds; Data Workers makes sure the number is true, and a named owner approves every fix with a receipt."
Getting started
Start with a pilot. Pick the Rill dashboard behind a number people act on, connect Data Workers read-only to the warehouse, Kafka Connect, dbt and the orchestrator under it, record the headline values, and let it check every table that dashboard depends on for a few weeks before turning on 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 edit our metrics views, alerts or dashboards? No. Metrics views, alerts, explore and canvas dashboards stay with their owners in your Rill project. When a definition should change, Data Workers says which one and why, and the owner changes it in Git like any other Rill change.
Our dashboards run on Druid through a live connector. What can Data Workers check? Data Workers works natively on the systems around the engine: the warehouse copy, Kafka Connect, dbt and the orchestrator. For Druid itself, your team records the values that matter, such as hourly impressions, with monitor_metrics, and Data Workers holds them to a baseline. A recorded graph note puts the Druid-backed metrics view in the blast radius.
AI Chat explained the drop. Why did we still need Data Workers? AI Chat answered correctly from the metrics view: delivery moved to a null line item. Data Workers' agents never call AI Chat or the Rill MCP server; they trace the tables back to the release, sync or model that moved, propose the fix and record it in a receipt.
Does Data Workers reindex Druid or refresh Rill models? No. Druid reindexes, ClickHouse view rebuilds and Rill model refreshes stay with their owners and run on their schedule or by their hand. Data Workers re-checks the tables after the approved rerun and records the result.
Does Data Workers work with Rill on DuckDB, ClickHouse or Snowflake? Yes. The engine doesn't change the loop. Among 50+ connectors, table checks run natively on Snowflake and Postgres (BigQuery with a service-account key); DuckDB and ClickHouse connect over their API today, with your recorded values held to a baseline.
Sources
- •Rill, homepage ("The fastest business intelligence tool for humans and agents"; AI agent; BI-as-code; solutions), https://www.rilldata.com/ (checked Oct 3, 2026)
- •Rill, Rill MCP Server (consumption-only scope, supported tools, OAuth URLs, branch deployments, ai_instructions and skills), https://docs.rilldata.com/guide/ai/mcp (checked Oct 3, 2026)
- •Rill, Contextual AI Chat (powered by MCP, queries defined metrics views, dashboard context and links), https://docs.rilldata.com/guide/ai/ai-chat (checked Oct 3, 2026)
- •Rill, Alerts (alerts as code, metrics_sql, Slack and email, recovery; live connectors and data quality tests), https://docs.rilldata.com/developers/build/alerts (checked Oct 3, 2026)
- •Rill, Druid connector (live connector, Druid v28.0 or newer, no modeling with Druid), https://docs.rilldata.com/developers/build/connectors/olap/druid (checked Oct 3, 2026)
- •Rill, Rollups (pre-aggregated tables for metrics views), https://docs.rilldata.com/developers/build/metrics-view/rollups (checked Oct 3, 2026)
- •Rill, Data Quality Tests, https://docs.rilldata.com/developers/build/models/data-quality-tests (checked Oct 3, 2026)
- •Rill, Rill Cloud vs Rill Developer, https://docs.rilldata.com/developers/deploy/cloud-vs-developer (checked Oct 3, 2026)
- •Rill, docs index (OLAP engines, metrics views, Agent Skills and
rill init --agent), https://docs.rilldata.com/llms.txt (checked Oct 3, 2026) - •Rill, GitHub releases (v0.90.2 on Sep 25, 2026; v0.90.0 on Sep 24, 2026), https://github.com/rilldata/rill/releases (checked Oct 3, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers, client setup, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers, pricing, https://dataworkers.io/pricing/ (checked Oct 3, 2026)