You're on Qualytics: It Infers and Enforces the Checks. Data Workers Diagnoses, Fixes and Verifies Behind Approvals
Qualytics infers and enforces quality checks. Data Workers takes its anomalies from your team, with the Qualytics MCP server in the same client, fixes the cause behind approvals, verifies and keeps a receipt.
Your data quality team runs on Qualytics. Profiling learns how each table behaves and generates AI Managed checks (Qualytics renamed Inferred checks in release 2026.5.7), and stewards add Authored checks where the business has its own rule. Scans raise Shape and Record anomalies, write source records to an enrichment datastore you own and assign each anomaly to a person. Flows send the Slack message and open the Jira or ServiceNow ticket. AgentQ answers in plain language, drafts checks from a sentence or a regulation, and assesses whether a table can be trusted. Recipes take a table from duplicates to a golden set, reconcile a source against a target, and certify the data feeding a model as an AI Use Case with attestations a model risk reviewer can read. Qualytics calls the whole thing a Data Control Layer. Qualytics infers and enforces the checks. Data Workers diagnoses, fixes and verifies behind approvals.
A failed check says the data broke the standard. The cause usually sits upstream, in a CDC stream, a dbt model or a DAG run, and the repair has to land there. Data Workers finds it, proposes the change with its blast radius, runs the steps with one approval and proves the data meets the standard again.
Key takeaways
- •Qualytics keeps its job. Checks, anomalies, enrichment, recipes, AI Use Cases and AgentQ stay where they are.
- •Every anomaly arrives with a cause and a plan. The Qualytics anomaly reaches Data Workers through the on-call, whose assistant can use the Qualytics MCP server side by side with Data Workers; Data Workers traces it through BigQuery, dbt, Airflow and BI, and proposes the code change, the rebuild and the new test as one change set.
- •A named owner approves; Data Workers verifies. Data Workers drafts the rebuild for the owner to run in Airflow and checks volume and quality on every table the fix touched. Your team's MCP client posts the receipt link on the anomaly as a comment.
- •Attestations get evidence behind them. The attestation records that the data met its standard; the receipt records what changed to get it back there, who approved it and how to undo it.
- •One loop for the whole lifecycle. The same context graph and approval flow cover schema changes, access requests, cost and migrations.
Qualytics infers and enforces the checks. Data Workers diagnoses, fixes and verifies behind approvals.
Qualytics decides whether data meets the standard and tells the right person when it doesn't. Data Workers works the cause in the systems that produced the bad data and closes the loop. Here is a Monday at a mortgage lender, across a MySQL loan origination system, Datastream, BigQuery, dbt running in Managed Service for Apache Airflow (formerly Cloud Composer), Qualytics, Looker and Jira (times ET). This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Sun 23:40 | MySQL and Datastream | The loan origination database fails over to its replica during planned maintenance; the Datastream stream resumes from an earlier log position and replays 9,800 change events for loans.originations into the BigQuery landing table |
| Mon 02:00 | Managed Service for Apache Airflow and dbt | The nightly DAG run builds int_loan_originations, an incremental model with an append strategy; 3,412 loans now appear twice in fct_originations across three daily partitions |
| 06:45 | Qualytics | The scheduled scan fails the AI Managed uniqueness check on loan_id; Qualytics raises a Shape anomaly, writes source record examples to the BigQuery enrichment datastore and assigns it to the lending data owner. The container's quality score drops, and a trust assessment marks the table unfit for the underwriting assistant's AI Use Case |
| 06:47 | Qualytics Flow | The Flow posts to the #lending-data Slack channel and opens a Jira ticket linked to the anomaly |
| 06:50 | Data Workers | Reads the anomaly over the Qualytics MCP server, traces fct_originations back through int_loan_originations to the BigQuery landing table Datastream writes and finds the replay window in its source timestamps. Blast radius: three partitions, the Looker "Originations" Explore, the HMDA LAR staging table and the tables bound to the AI Use Case. get_incident_history finds no earlier replay |
| 07:05 | Data Workers | Proposes one change set: a dbt diff that switches the model to a merge on loan_id keeping the latest source event, a rebuild of the three affected partitions, and a dbt unique test on loan_id so the next replay fails in the DAG run instead of in a scan |
| 08:10 | Spellbook | The lending data owner reviews the diff, the blast radius and the undo, approves, and merges the dbt change |
| 08:15 | Managed Service for Apache Airflow | The owner triggers the run Data Workers drafted, rebuilding the three partitions with the corrected model |
| 08:50 | BigQuery | Data Workers verifies: one row per loan_id, row counts back in range for each partition, and the owner reports the new test green |
| 09:05 | Qualytics, Looker and Jira | The uniqueness check passes on the next scan; the owner's MCP client posts the receipt link on the anomaly as a comment, the owner resolves it, and Qualytics moves the linked Jira ticket with it. The Originations Explore reads correct counts before the 09:30 pipeline meeting |
Qualytics did its job well. Nobody wrote a uniqueness rule on loan_id; profiling learned it. The scan caught the duplicates before a regulatory file or an underwriting assistant used them, with the evidence in a table the team owns. An Entity Resolution recipe could have built a clean golden set, but the production table would have filled again on the next replay, because the dbt model still appended. What changed was everything after the anomaly: the cause, a blast radius reaching the HMDA staging table, one change set, an approved rebuild, verification and a test that moves the guard upstream.
| Job | What Qualytics does | What Data Workers does |
|---|---|---|
| The standard | Profiling infers AI Managed checks; stewards author their own; AgentQ drafts checks from a sentence or a regulation | Proposes the dbt test behind each fix and reads Qualytics' checks as part of its context |
| Detection | Scans raise Shape and Record anomalies with source records in your enrichment datastore | Watches freshness and volume itself, and catches schema changes in the dbt manifest and in review |
| Root cause | AI Explanations describe score changes; AgentQ investigates anomalies and their history | Joins the anomaly to CDC timestamps, dbt runs, DAG runs, lineage and incident history to find what changed upstream |
| Routing | Assigns the anomaly, posts through Flows, opens and syncs Jira or ServiceNow tickets | Routes the approval for the fix to a named owner in Slack or email; unanswered requests expire and escalate |
| The fix | Recipes build golden sets and reconciled keep sets in the enrichment destination; computed tables run in the source | Proposes the repair at the cause (code diff, ordered rebuilds, new tests) with blast radius as one change set |
| Verification | The check passes on its next scan | Checks quality and volume on every downstream table the fix touched |
| The record | Anomaly history, comments, the AgentQ audit and AI Use Case attestations | A receipt in Spellbook and the audit trail: the cause, the diff, who approved it, what it touched, how it was verified and how to undo it |
Why doesn't Qualytics just do this itself?
Because Qualytics chose a clear job. Its writes land in its own objects and the enrichment datastore: checks, anomalies, comments, computed assets, golden sets. The docs recommend keeping enrichment outputs "in a dedicated location, separate from the source data you govern". On its MCP server, "no tool returns rows or records in bulk, and masked fields stay masked," and AgentQ "runs its tools as the person chatting with it, so it never widens what that person can already reach." Those are the right decisions for a control layer: a model risk reviewer can trust that the system certifying the data is not also the system changing it.
Fixing a CDC replay, rewriting a dbt model and proving a Looker Explore and a regulatory staging table are right again is a different product with a different liability. It needs context about systems Qualytics does not run, a blast radius across them, a named approver, an undo written before anything runs and a receipt an auditor can follow. Keeping the certifier and the fixer separate is good governance. Data Workers is built for the fixing job.
Every tool owns a slice. Data Workers covers the whole lifecycle
Qualytics owns inferred quality checks and data control, with real depth in rule inference, reconciliation and AI use case certification. Each point tool adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | Qualytics | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Qualytics collects lineage from Snowflake, BigQuery and Databricks during Sync and links to your catalog. Data Workers keeps one governed context graph of definitions, owners, lineage, quality and usage across every platform. |
| Analytics & Insights | 8 | 3 | AgentQ answers questions about quality scores, anomalies and trends. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 9 | Qualytics' home stage: AI Managed checks inferred from profiling, Authored checks, Data Diff and recipes for duplicates and reconciliation. Data Workers writes and runs checks and adds the test behind each fix. |
| Observability & Incidents | 8.5 | 7 | Scans raise Shape and Record anomalies with source records, owners and assignees, and Flows notify and open tickets. Data Workers diagnoses across systems, fixes with approval and verifies the fix. |
| Pipelines & Ingestion | 8.5 | 3 | Computed tables, files and joins run inside your datastores, and enrichment writes findings back. Data Workers drafts reruns and backfills for your orchestrator, holds the approvals and verifies the result. |
| Schema & Migration | 8 | 3 | Profiling notices schema shifts on the tables it scans. Data Workers catches schema changes in the dbt manifest and in review, scores their blast radius and plans migrations in waves. |
| Governance & Access | 8.5 | 6 | AI Use Cases carry a certification state and immutable attestations, and AgentQ runs as the person chatting. Data Workers dry-runs each warehouse access request and proposes a time-bound grant for the owner to approve. |
| Security & Privacy | 8 | 4 | Masked fields stay masked, and no MCP tool returns rows in bulk. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 1 | Qualytics reports on data quality, and AgentQ's audit estimates model cost. Data Workers reads BigQuery spend from the Jobs API, attributes Snowflake spend to the dbt model and drafts warehouse setting changes for their owner. |
| MLOps & Models | 7.5 | 4 | Data Suitability certifies the data feeding a model or agent against its check set. Data Workers keeps the data under your models fresh and correct. |
Qualytics leads on data quality. For the category view, read Data Workers vs data observability, Bigeye, Anomalo, Sifflet and Soda vs Data Workers and beyond data observability: autonomous resolution.
How Qualytics and Data Workers work together
Qualytics stays where anomalies are caught. Spellbook Data Catalog (in preview) is where the data team reviews each proposed change and how to roll it back. Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with 20 specialized agents, and the Autonomous Data-Conductor runs each fix end to end.
Qualytics to Data Workers. Qualytics connects over its MCP server or API today, in your team's client next to Data Workers. The server lives at your instance's /mcp path and takes a Personal API Token as a Bearer header from a service account with Reporter permission. Your team's assistant reads anomalies, checks, quality scores and comments and brings a new anomaly to Data Workers. BigQuery, dbt, Managed Service for Apache Airflow and Slack are native Data Workers connectors, and Looker is read by design. A new anomaly starts a diagnosis: diagnose_incident and get_root_cause work the evidence, trace_cross_platform_lineage and blast_radius_analysis map everything downstream, the dbt manifest rules a model change in or out, and get_incident_history checks whether the table broke before. remediate proposes the change set: the dbt change arrives as a diff for the owner to merge, or as a pull request when your team turns on the GitHub pull-request target. run_quality_check and get_quality_score verify, and get_audit_trail reads back every step.
Back to Qualytics. The receipt lives in Spellbook and the audit trail. Your team's MCP client, holding both servers, posts its link on the anomaly through Qualytics' create_comment tool (writing comments needs Viewer permission). Your team resolves the anomaly, and Qualytics keeps the linked Jira ticket in step. Checks, AI Effort and Oversight settings, recipes and AI Use Case certifications stay with your Qualytics admins and stewards.
In your coding agent. Every Data Workers agent is an MCP server, so an engineer can ask Claude or Cursor about the anomaly with the Qualytics MCP server alongside. The client setup guide documents the path: clone the open-source repo and add one start-agent.sh entry per agent. Example mcp.json:
{
"mcpServers": {
"dw-context-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
"dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
"dw-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] }
}
}Ask "why does fct_originations have duplicate loans?" and the client returns the replay window, everything downstream and a proposed repair. For a shared endpoint, the Data Workers remote server takes an API key (bearer) or OAuth tokens from your identity provider, verified through JWKS.
One Qualytics anomaly, L0 to L4. The same anomaly at each level of the autonomy ladder, set per domain.
- •L0 manual. An engineer finds the replay, edits the model and reruns the DAG by hand.
- •L1 observe. Data Workers posts the diagnosis and blast radius. Nothing changes.
- •L2 propose. Data Workers proposes the dbt diff, the rebuild and the test; nothing runs until the owner approves.
- •L3 act reversibly. For proven change classes, such as rerunning a DAG after a merged fix, Data Workers starts the run, verifies it and records the receipt. On Airflow 2 Data Workers queues the run through Airflow's REST API; on Airflow 3, and for dated partition rebuilds like this one, the owner triggers the approved run.
- •L4 autonomous. In a scoped domain with a long clean record, Data Workers handles the repeatable steps end to end; code changes still go to their owner as a diff.
For the safety model, read is it safe to let AI agents change production data, how approvals work and how to roll back an agent's change. On where data lives: the agents run in your infrastructure on every tier, your data stays in your systems, and the hosted Conductor sees workflow metadata only.
What changes for your team
Qualytics gave the quality team a standard for every table. Data Workers gives the owner a fix path that runs to the cause.
- •Incidents. A Qualytics anomaly arrives with a diagnosis, a blast radius and a proposed fix, and closes with a receipt linked from the anomaly.
- •Data quality. Qualytics keeps inferring and enforcing checks; each fix brings the dbt test that would have stopped the break before the scan.
- •Cloud spend. Data Workers reads BigQuery spend from the Jobs API, drafts warehouse setting changes for their owner and records the model cost of each action.
- •Access. A warehouse access request is dry-run against role inheritance and sensitive columns and becomes a time-boxed grant proposed for the owner.
- •Audits. Attestations show the data met its standard; receipts show what changed to keep it there, who approved it and how to undo it.
- •Migrations. Platform moves run in approved waves, with parity checks planned and tracked and the completion gate held for the owner's sign-off.
The steward changes most: an anomaly assigned at 06:45 now means reviewing a ready change set, not a morning of chasing engineers. For the role view, read Data Workers for data governance leads and who owns the agents; for the lending context, the agentic data platform for financial services.
Keep Qualytics, or consolidate?
Keep Qualytics if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Teams that certify AI use cases and answer regulators usually keep Qualytics, because rule inference, reconciliation and attestations are its depth. What they consolidate is the work around it: a second monitor on the same break, runbooks in a wiki, spreadsheets of which fix went where. Building a fix layer on the Qualytics MCP server yourself? Read build it ourselves with Claude Code and MCP servers: the context graph, approvals and rollback are the work. Across the governance-suite tools, see you're on Ataccama, you're on DQLabs and you're on Collibra Data Quality, plus Data Workers with Airflow.
The case for your CFO
The outcome: you already pay Qualytics to catch the moment data isn't good. Data Workers turns each of those moments from a morning of tracing and rerunning into a complete fix with one approval, so origination counts, regulatory files and AI systems read correct data.
The risk story is plain. Autonomy is set per domain: L1 only reads; L2 changes nothing until a named person approves; L3 applies changes it can undo. Code goes to its owner as a diff. An unanswered approval request expires and escalates, never auto-grants. No agent can promote its own work. Every change carries a receipt, and an org-wide stop halts all autonomous dispatch. Zero migration: every system in the stack stays where it is.
Why now: every failed check on a certified AI Use Case has a model waiting on it, and the slow part is the fix and the proof. The first win is read-only: every Qualytics anomaly in one domain gets a cross-system diagnosis and a blast radius, while checks, certifications and code review stay the same. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Qualytics tells us whether our data meets the standard; Data Workers fixes the cause when it doesn't, with one approval, and hands the auditor the receipt."
Getting started
Start with a pilot. Pick one domain whose anomalies already live in Qualytics, such as lending, connect Data Workers to the Qualytics MCP server, BigQuery, dbt and Airflow, and run at L1 so every anomaly gets a diagnosis and a blast radius. Then turn on the first write class at L2, such as partition rebuilds after a merged dbt fix, with owner approval. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to Qualytics? Over the Qualytics MCP server or API today, with a Personal API Token for a service account. Your team's MCP client reads anomalies, checks, quality scores and comments, side by side with Data Workers, and posts the receipt link on the anomaly as a comment. BigQuery, dbt, Airflow and Slack are native Data Workers connectors.
AgentQ already investigates anomalies and drafts checks. Why add Data Workers? AgentQ works inside Qualytics, as the person chatting, on Qualytics objects and computed assets, a strong surface for a steward. Data Workers adds the fix at the cause in systems Qualytics does not run, with verification and a receipt.
Does Data Workers change our checks or AI Use Cases? No. Checks, AI Effort and Oversight settings, recipes and certifications stay with your Qualytics admins and stewards. Data Workers proposes tests in dbt next to the fix, and the receipt link reaches the anomaly as a comment.
Does Data Workers see the source records Qualytics stores? The agents run in your infrastructure and hold the warehouse credentials and model key, so your data stays in your systems. The hosted Conductor sees workflow metadata only, such as table names, proposals with diffs and run records.
How does this help with AI use case attestations? An attestation records quality scores, row counts, check outcomes, lineage and access controls at a point in time. When the data is repaired, the receipt records the cause, the change, the approver and the verification, so the next attestation has a documented reason the data is back in standard.
Sources
- •Qualytics homepage ("Data Control for Trusted Context", Data Control Layer, Recipes item dated 9/17/2026), https://qualytics.ai/ (checked Oct 3, 2026)
- •Qualytics User Guide, 2026 release notes (Inferred checks renamed AI Managed in 2026.5.7; AgentQ check and template assistants and managed LLM provider Beta in 2026.7.20; shared AgentQ and MCP action catalog in 2026.7.27; Entity Resolution recipe 2026.8.18; Data Reconciliation recipe and check_data_trust 2026.9.1; Data Suitability recipe, AI Use Cases, attestations, Sync lineage and ticket status sync 2026.9.21), https://userguide.qualytics.io/changelog/ (checked Oct 3, 2026)
- •Qualytics User Guide, MCP ("no tool returns rows or records in bulk, and masked fields stay masked"; streamable HTTP; Bearer token), https://userguide.qualytics.io/agentq/deep-dive/mcp/ (checked Oct 3, 2026)
- •Qualytics User Guide, AgentQ in Action (endpoint, Personal API Token, capabilities, Proposal Cards), https://userguide.qualytics.io/agentq/deep-dive/in-action/ (checked Oct 3, 2026)
- •Qualytics User Guide, AgentQ Permissions ("runs its tools as the person chatting with it"; team permissions per tool; writing comments needs Viewer; writes take effect with no built-in confirmation step), https://userguide.qualytics.io/agentq/deep-dive/permissions/ (checked Oct 3, 2026)
- •Qualytics User Guide, Tool Catalog (update_anomaly, create_comment, check_data_trust, send_notification, create_ticket), https://userguide.qualytics.io/agentq/deep-dive/tool-catalog/ (checked Oct 3, 2026)
- •Qualytics User Guide, AI Managed checks, https://userguide.qualytics.io/data-quality-checks/ai-managed/introduction/ (checked Oct 3, 2026)
- •Qualytics User Guide, Enrichment introduction, https://userguide.qualytics.io/source-datastore/enrichment-datastore/deep-dive/introduction/ (checked Oct 3, 2026)
- •Qualytics User Guide, Source Records, https://userguide.qualytics.io/anomalies/deep-dive/source-record/ (checked Oct 3, 2026)
- •Qualytics User Guide, Entity Resolution Scan and Remediate, https://userguide.qualytics.io/recipes/entity-resolution/deep-dive/scan-and-remediate/ (checked Oct 3, 2026)
- •Qualytics User Guide, AI Use Cases (certification states and attestations), https://userguide.qualytics.io/recipes/data-suitability/deep-dive/ai-use-cases/ (checked Oct 3, 2026)
- •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)