You're on Sifflet: Sage Finds the Cause and Forge Routes It. Data Workers Fixes It and Proves It

Your data team runs on Sifflet. The catalog holds your assets and data products, field-level lineage runs from BigQuery or Snowflake through dbt to every Looker dashboard, and monitors watch freshness, volume, distributions and schema. When a monitor or a dbt test fails, Sifflet groups the related failures into one incident, counts the compromised dashboards and opens a Jira or ServiceNow issue. Three AI agents carry the rest. Sentinel, in beta, suggests the monitors each asset or data product should have. Sage writes the incident's summary, likely root causes, impacted assets and "next steps or remediation ideas" from metadata and dbt run logs. Forge recommends next steps, routes the incident "to the right owner" and guides the team through resolution. Sifflet is the smoke alarm, with a very good map of the building. Data Workers is the crew.

Forge gets the incident to the analytics engineer who owns the model. That engineer still has to change the dbt model, rerun the Airflow DAG, check every compromised Looker tile and prove the numbers before the trading review. Data Workers does that work behind approvals and leaves a receipt.

Key takeaways

• •Sifflet keeps its job. Monitors, Sentinel, incidents, Sage, Forge, field-level lineage and the catalog stay exactly where they are.
• •The routed incident arrives with a finished fix. The Sifflet incident reaches Data Workers through the on-call, whose assistant can use Sifflet's MCP server side by side with Data Workers; Data Workers traces the cause across Shopify, Fivetran, BigQuery, dbt, Airflow and Looker, and proposes the dbt change, rerun and new test as one change set.
• •A named owner approves; Data Workers verifies. The owner approves in Spellbook, Data Workers queues the rerun through Airflow, checks quality and totals, and records a receipt.
• •Two MCP servers in one client. Run the Sifflet MCP server beside Data Workers in Cursor or Claude: Sifflet answers what broke and what it touches, Data Workers fixes it.
• •Autonomy per domain. Each data domain climbs from L0 manual to L4 autonomous at the pace your team sets.

Sifflet is the smoke alarm. Data Workers is the crew.

Sifflet observes, and its agents suggest: Sentinel suggests monitors, Sage suggests causes and next steps, Forge recommends and routes. Data Workers diagnoses across systems, fixes behind approvals and verifies. Here is a Monday at a European fashion retailer across Shopify, Fivetran, BigQuery, dbt run by Airflow, and Looker (times CEST). This is an illustrative example.

Sifflet did its job: field-level lineage pointed at the right column, grouping turned two failures into one incident, Sage explained it and Forge found the owner. What changed is everything after the routing: a diagnosis that reached past the staging model to the upstream field change, a blast radius that included the scheduled deliveries, one change set to approve, a queued rerun, totals checked against source and a record of what changed.

Why doesn't Sifflet just do this itself?

Because Sifflet made a clear, sensible choice about where its product ends. Sentinel suggests monitors and a person ticks the ones they want and clicks "Create monitors". Sage generates summaries and "next steps or remediation ideas" from metadata and incident context, and its docs stress that "no raw data rows are required or sent". Forge recommends, routes and guides. The Sifflet MCP server explores assets, monitors, incidents and impact, and when you ask it for a new monitor it returns Monitor-as-Code YAML for you to "adapt and commit". Its AI runs on metadata, with data samples off by default.

That is the right line for an observability product. Sifflet can watch every table, column and dashboard because nobody worries it will change one, and its agents switch on without a security review of write access to BigQuery. Changing a dbt model, rerunning an Airflow DAG and confirming totals in production is a different product with a different liability: check the change against everything downstream, get the owner's approval, have an undo before it runs, prove the numbers and keep the record, in dbt, Airflow and BigQuery, systems Sifflet observes but does not run. Data Workers is built for exactly that job.

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

Sifflet owns catalog, monitoring and root cause, and its field-level lineage is an excellent map of a data estate. 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.

Sifflet leads on observability and ties on data quality. For the category view, read Bigeye, Anomalo, Sifflet and Soda vs Data Workers and Data Workers vs data observability. For the idea behind this page, see beyond data observability: autonomous resolution and what is data observability.

How Sifflet and Data Workers work together

Sifflet stays on top, where monitors fire, Sage explains and Forge routes. Spellbook Data Catalog (in preview) is where the data team reviews each proposed change and how to roll it back. Between them, 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: detect, diagnose, fix, review, verify, remember.

Sifflet to Data Workers. Sifflet connects over its API or MCP server today: your team's assistant reads incidents, impacted assets, owners and impact analysis side by side with Data Workers, whose own checks rest on BigQuery, dbt and Airflow. BigQuery, dbt, Airflow (including Managed Service for Apache Airflow) and Looker are native connectors, with Looker read by design; Shopify and Fivetran connect over their APIs, and Fivetran keeps running its own syncs. A new Sifflet incident starts a diagnosis: diagnose_incident and get_root_cause work the evidence, trace_cross_platform_lineage and blast_radius_analysis map everything downstream, the Sifflet incident's lineage confirms the upstream field change, and get_incident_history checks for repeats. remediate proposes the change set for the owner; the dbt change arrives as a diff for the owner to merge, and reruns are queued through Airflow. run_quality_check and get_quality_score verify, and get_audit_trail reads back every step.

Data Workers to your team. The receipt lives in Spellbook. Sifflet's Jira integration moves an incident to Closed (Fixed) when its linked Jira issue moves to Done, so the owner closes the issue with the receipt link and Sifflet's history stays complete. Monitors, Sentinel and incident settings stay with your Sifflet admins.

Side by side in one client. Sifflet's MCP server runs locally through uvx with an access token (Viewer is enough for most tools; generating monitor YAML needs Editor) and your tenant's backend URL. Every Data Workers agent is an MCP server; the client setup guide documents the path: clone the open-source repo and add one start-agent.sh entry per agent. Example mcp.json for Cursor, with the Sifflet entry as its repository documents it:

{
  "mcpServers": {
    "mcp_server_sifflet": {
      "command": "uvx",
      "args": ["sifflet-mcp@latest"],
      "env": {
        "SIFFLET_API_TOKEN": "<access_token>",
        "SIFFLET_BACKEND_URL": "https://<tenant_name>.siffletdata.com/api/"
      }
    },
    "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"] },
    "dw-schema": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-schema"] }
  }
}

Ask "why is German net sales high this morning, and what does the fix touch?" and the client calls both: Sifflet returns the incident, impacted dashboards and owner; Data Workers returns the upstream field change, everything downstream and a proposed repair. Sifflet's token scopes what the client can see in Sifflet; Data Workers' guardrail decides whether a change may run in that domain. 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 Sifflet incident, L0 to L4. The same net sales incident, at each level of the autonomy ladder, set per domain.

• •L0 manual. The engineer reads Sage's summary, 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 rerun and the new test; nothing runs until the commerce data owner approves.
• •L3 act reversibly. For proven change classes, such as rerunning a partition after a merged fix, Data Workers queues the step through Airflow, verifies it and records the receipt.
• •L4 autonomous. In a scoped domain with a long clean record, Data Workers handles the repeatable steps end to end; model 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 autonomy levels L0 to L4. On where data lives: the agents run in your infrastructure, your data stays in your systems, and the hosted Conductor sees workflow metadata only.

What changes for your team

Sifflet made every broken dashboard visible and routable. Data Workers gives the owner a crew.

• •Incidents. A Sifflet incident arrives with a diagnosis, a blast radius and a proposed fix, and closes with a receipt.
• •Data quality. Each fix comes with a proposed dbt test on the model that broke, so the repeat is caught upstream, and Sentinel keeps suggesting coverage on the Sifflet side.
• •Cloud spend. BigQuery spend is read from the Jobs API as an account total, and warehouse setting changes go to their owner drafted.
• •Access. A warehouse access request is dry-run and becomes a scoped, time-boxed grant proposed for the data owner.
• •Audits. Sifflet records the incident; Data Workers records what changed, who approved it and how to undo it.
• •Migrations. A platform move runs in approved waves, with parity checks planned and tracked for each wave.

The on-call changes most: Forge's routing now lands on a ready change set to review and approve. See the data incident response playbook, data quality for AI agents and who owns the agents.

Keep Sifflet, or consolidate?

Keep Sifflet if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

Teams usually keep Sifflet where business users rely on its catalog, data products and dashboard-level impact. What they consolidate is the stack around it: a second monitoring tool alerting on the same break, hand-written runbooks, ad hoc rerun scripts. Weighing a fix layer of your own on the Sifflet MCP server and a coding agent? Read build it ourselves with Claude Code and MCP servers: the MCP calls are the easy part; the context graph, approvals and rollback are the work. Across the category, see you're on Monte Carlo, you're on Bigeye and you're on Soda, plus Data Workers integrations and what is an agentic data platform.

The case for your CFO

The outcome: you already pay Sifflet to see bad data before the business does and route each incident to the right person. Data Workers turns that routed incident from a morning of tracing, editing and rerunning into a diagnosis on arrival and a complete fix with one approval, so trading, merchandising and finance read correct numbers at their first meeting.

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. Model changes always go to their owner as a diff to merge. An unanswered approval request expires and escalates, never auto-grants. No agent can promote its own work. Every change carries a receipt: the cause, the diff, who approved it, what it touched, how it was verified and how to undo it. An org-wide stop halts all autonomous dispatch. Zero migration: Sifflet, Shopify, Fivetran, BigQuery, dbt, Airflow and Looker stay where they are.

Why now: Sage explains the cause and Forge finds the owner, so the slow part is the change, the rerun and the proof. The first win is read-only: every Sifflet incident in one domain gets a diagnosis and a blast radius, while monitors, permissions and dbt review stay the same. For the numbers, see the ROI of agentic data operations.

The sentence to repeat upstairs: "Sifflet tells us what broke and who owns it; Data Workers hands that owner a safe fix, runs it with one approval and proves it held."

Getting started

Start with a pilot. Pick one domain whose incidents already live in Sifflet, such as the commerce models, connect Data Workers to Sifflet, BigQuery, dbt and Airflow, and run at L1 so every incident gets a diagnosis and a blast radius. Then turn on the first write class at L2, such as partition reruns after a merged 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 Sifflet? Over Sifflet's API or MCP server today, reading incidents, impacted assets, owners and impact analysis. You can also run Sifflet's MCP server beside the Data Workers agents in Cursor or Claude.

Sage already suggests next steps and Forge routes the incident. Why add Data Workers? Sage and Forge explain and route, by design, from metadata. Data Workers adds the work after the routing: the cross-system diagnosis, the change set with its blast radius, a named approver, the queued rerun, verification against source and the receipt.

Does Data Workers change anything in Sifflet? No. Monitors, Sentinel suggestions, incidents and settings stay with your Sifflet admins. The receipt lives in Spellbook and the audit trail; the owner closes the linked Jira issue, and Sifflet closes the incident from it.

Does Data Workers merge dbt changes or edit our warehouse directly? Model changes arrive as a diff for the owner to merge, or as a pull request when your team turns on the GitHub pull-request target. Data cleanups are proposed for the owner to approve and apply. Data Workers then queues the reruns through your orchestrator and verifies the result.

Does Data Workers use Sifflet's field-level lineage? Yes. It reads Sifflet's impact analysis and joins it to Fivetran, dbt, Airflow runs and incident history in one context graph, so an upstream column change is tied to every model, dashboard and delivery it affects.

Our Sifflet AI features run on metadata only. What does Data Workers see? The agents run in your infrastructure and hold the warehouse credentials, so your data stays in your systems. The hosted Conductor sees workflow metadata only: goals, table names, proposals with diffs, run records, approval handles.

Sources

• •Sifflet, homepage (site title "The Control Plane for Data and AI"), https://www.siffletdata.com/ (checked Oct 2, 2026)
• •Sifflet, AI agents product page (Sentinel, Sage, Forge), https://www.siffletdata.com/product-agents (checked Oct 2, 2026)
• •Sifflet Docs, Auto-Monitoring (Sentinel) beta (updated Oct 1, 2026), https://docs.siffletdata.com/docs/sentinel-monitor-recommendations (checked Oct 2, 2026)
• •Sifflet Docs, Root Cause Analysis (Sage) (updated Oct 1, 2026), https://docs.siffletdata.com/docs/root-cause-analysis-sage (checked Oct 2, 2026)
• •Sifflet Docs, AI Features Overview (updated Oct 1, 2026), https://docs.siffletdata.com/docs/ai-features-overview (checked Oct 2, 2026)
• •Sifflet Docs, Sifflet AI Chat beta (updated Oct 1, 2026), https://docs.siffletdata.com/docs/sifflet-ai-chatbeta-1 (checked Oct 2, 2026)
• •Sifflet Docs, Incidents (updated Oct 1, 2026), https://docs.siffletdata.com/docs/incidents (checked Oct 2, 2026)
• •Sifflet Docs, Jira integration (issue creation; incident moves to Closed (Fixed) when the linked Jira issue moves to Done; updated Oct 1, 2026), https://docs.siffletdata.com/docs/jira (checked Oct 3, 2026)
• •Sifflet Docs, Field-Level Lineage (updated Oct 1, 2026), https://docs.siffletdata.com/docs/field-level-lineage (checked Oct 2, 2026)
• •Sifflet Docs, Looker integration, https://docs.siffletdata.com/docs/looker (checked Oct 2, 2026)
• •Sifflet Docs, changelog (Smarter Incident Grouping GA; Operations Dashboard beta; incident-centric notifications in private preview, GA mid-October 2026), https://docs.siffletdata.com/llms.txt (checked Oct 2, 2026)
• •Sifflet Docs, Sifflet MCP Server (updated Oct 1, 2026), https://docs.siffletdata.com/docs/sifflet-mcp-server (checked Oct 2, 2026)
• •Sifflet MCP server repository (tools, Cursor config, token roles; MIT), https://github.com/siffletdata/sifflet-mcp (checked Oct 2, 2026)
• •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)
• •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)