You're on Striim: It Streams Every Change in Real Time. Data Workers Owns Whether What Lands Downstream Is Right
Striim streams changes from your operational databases in real time and protects sensitive data in flight with Sentinel. Data Workers checks what lands downstream, traces it through dbt and BI, and gets the fix approved.
Your team runs Striim apps. Each app is a flow in Flow Designer: a CDC reader on the source (OJet for Oracle, MSJet for SQL Server, readers for PostgreSQL, MySQL, MongoDB and Salesforce), continuous queries (CQs) that reshape events in flight with streaming SQL, and a writer that lands them in BigQuery, Snowflake, Databricks, Microsoft Fabric, ClickHouse, Kafka or an Iceberg lake. Striim Cloud runs it as a service; Striim Platform runs it in your own environment. Since the 5.4.2 release you can also ask Clara, Striim's conversational AI agent, to inspect an app or draft a new one as a TQL plan you approve. And with AI Insights turned on, Sentinel masks or encrypts sensitive data inside the stream, before it reaches the target.
That is real work done in flight, and it is why Striim teams trust their targets. It also means a correct, deliberate change inside an app can change what a table means three systems later, with every app green and every row on time. Data Workers picks up there. It checks what Striim lands, traces it through your dbt project, dashboards and the business processes that read them, and gets the fix approved by the people who own each piece.
Key takeaways
- •Striim keeps its job. Apps, CDC readers, CQs, Sentinel policies, writers and reloads stay with your team. Data Workers works on what the apps land and everything built on it.
- •A correct change in the stream gets caught where it lands. When a masking policy, a CQ or a source DDL changes what a column means, Data Workers flags it on the target table and maps the damage across dbt, BI and the processes behind them.
- •Connected over Striim's REST API today. Data Workers reads the target tables natively in BigQuery, Snowflake or Databricks; your owner runs apps and reloads in Striim, with or without Clara.
- •Every fix goes through a named person. The governance lead, the Striim owner and the model owner each approve their part, and each step leaves a receipt.
- •Sensitive data stays protected. The proposed fix narrows a Sentinel rule to one key field, and protection stays on everywhere else.
Striim is the real-time stream. Data Workers is the owner of what it lands.
Striim's job is to read every change at the source, process it in flight exactly as the app says, and land it at the target in order, without loss. The job after the target is different: notice that a table now means something else, size the damage, hold what would act on it, get the cause fixed and prove the result. Here is one night at a freight brokerage that streams its transportation management system (TMS) on SQL Server into BigQuery with Striim Cloud. Times are Central. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Mon 17:30 | Striim Cloud | Driver mobile numbers keep turning up in free-text dispatch notes. The governance lead updates the Sentinel component in app tms_cdc so PHONE_NUMBER is set to Mask completely, and the app is redeployed. Exactly the right call for the notes |
| 17:31 | SQL Server | Dispatchers keep booking and updating loads. The MSJet reader captures every insert and update to dbo.shipments, as it has for two years |
| 17:31 | Striim Cloud + BigQuery | Sentinel acts on data identifiers by what a value looks like, wherever it sits. Many carriers use 10-digit PRO numbers, and those look like US phone numbers. In 9,860 changed rows, carrier_pro_id arrives in tms.shipments as xxxxxxxxxx. The BigQuery Writer merges every change on time. No error, no lag |
| Tue 05:00 | dbt Cloud | The nightly job builds fct_freight_audit, which matches carrier invoices from the EDI feed to shipments on carrier_pro_id. The match rate falls from 97% to 61%, and 1,240 invoices drop to the exceptions queue. The not_null test passes: xxxxxxxxxx is not null |
| 05:20 | Data Workers + BigQuery | run_quality_check on tms.shipments finds carrier_pro_id no longer unique: 9,860 rows share one value. The invoice match rate, a metric the team records with monitor_metrics, reads 61% against a baseline of 96 to 98%. Data Workers opens an incident |
| 05:31 | Data Workers | Every repeated value is ten x's, the signature of Sentinel's Mask completely action, and every affected row was modified after 17:30. The context graph, where the team recorded which app writes each table, ties tms.shipments to tms_cdc. diagnose_incident names the cause: a masking rule reaching a key. blast_radius_analysis maps what reads the column: fct_freight_audit, the carrier scorecard, the Looker "Freight Audit" Explore and its 07:00 exceptions delivery to 14 AP clerks, and the 10:00 carrier payment run, which releases matched invoices only |
| 05:35 | PagerDuty + Slack | Data Workers raises a PagerDuty incident for the data on-call and sends approval requests in Slack to three owners: the governance lead (Sentinel policy), the Striim owner (the app) and the freight audit model owner |
| 05:50 | Striim Cloud | The Striim owner opens Ask Clara, asks it to inspect tms_cdc, and confirms the Sentinel policy the incident points to |
| 06:10 | Spellbook | The owners review four proposals: an Actions on Fields rule of "No action" for carrier_pro_id on the Sentinel component, which Striim's docs recommend for key fields and which overrides the identifier rule for that field only; a reload of the shipments modified since 17:30; a dbt test that fails if carrier_pro_id is all x's; and a hold on the 07:00 delivery. Each owner approves their part |
| 06:20 | Looker | The Looker admin pauses the 07:00 exceptions delivery |
| 06:25 | Striim Cloud | The Striim owner adds the field rule and redeploys tms_cdc; driver numbers in the notes stay masked. She then runs a one-off Database Reader app with a labeled query for shipments modified since 17:30, into the same BigQuery Writer in MERGE mode. The real PRO numbers overwrite the masked ones by primary key. Nothing is deleted |
| 07:05 | GitHub | The model owner opens a pull request with the approved test diff; Data Workers posts the blast radius on it, and she merges |
| 07:10 | dbt Cloud | The team's scheduler queues the approved job, with the approval on Data Workers' record; the audit models rebuild by 07:30 |
| 07:40 | Data Workers + BigQuery | Data Workers verifies: carrier_pro_id is unique again, no value is all x's, dbt Cloud reports the new test passing and the match rate reads 97.2%, inside its baseline. remediate re-checks the quality assertions on the rebuilt models |
| 07:45 | PagerDuty | Data Workers resolves the incident with a link to the receipt: cause, approvals, the Striim and dbt changes, checks passed and the undo for each step |
| 08:00 | Looker | The admin resumes the delivery. The exceptions list holds 38 invoices, not 1,240 |
| 10:00 | AP | The payment run releases matched invoices on schedule, and carriers on quick-pay terms are paid on time |
Nothing in Striim misbehaved. Sentinel did what its docs promise: it acts on the type of a value, "not on its location in the input record." The app redeployed cleanly and the writer merged every change. Catching the problem took knowledge Striim was never meant to hold: that a column named for a carrier reference is a join key in a dbt model, and that a 10:00 payment run depends on the join.
| Job | What Striim does | What Data Workers does |
|---|---|---|
| The move | Reads every change with log-based CDC readers and lands it at the target in order, with MERGE or append-only writers | Reads what the apps land, natively in BigQuery, Snowflake or Databricks; connects to Striim over its REST API |
| In flight | Runs CQs, windows and caches, and Sentinel masks or encrypts sensitive data before it leaves the stream | Knows what each landed column means downstream, who owns it and what reads it |
| The signal | App monitoring, custom alerts, Foreseer anomaly detection and Validata dataset comparison | Checks the tables after the target: uniqueness, nulls, volume, and load lag and the team's own metrics against a baseline |
| The diagnosis | Clara inspects apps, components and monitoring data in conversation | Joins the masked key, the change window, lineage and owners into one cause, with the blast radius across dbt, Looker and the payment run |
| The fix | Applies the field rule, redeploys the app and runs the reload when the owner says so | Proposes the field rule, the reload, the dbt test and the hold to named owners, who approve and apply them |
| The proof | Keeps app and monitoring history | Re-checks the tables and writes a receipt: what changed, who approved it, how it was checked, how to undo it |
Why doesn't Striim just do this itself?
Because Striim is built to move and transform every change faithfully, in real time, exactly as each app is written. A stream that paused to second-guess a governance rule would be the wrong product: the point of Sentinel is that sensitive data never reaches the target, whatever field it hides in. Striim's quality work follows the same scope. Validata compares and verifies the datasets Striim moves, which is the right question for replication and migration. Clara helps your team build, inspect and operate apps: nothing it builds changes until you approve its TQL plan, and it runs lifecycle actions when the owner asks.
Whether a value that landed correctly breaks a dbt join, a Looker delivery and an accounts payable run is a question about every system after the target. Owning it takes a context graph of every table, model and consumer, blast-radius scoping, named approvers in three teams, a recorded undo and receipts an auditor can read. That is a different product, and it is Data Workers. More in is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
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 Striim apps already there.
| Stage | Data Workers | Striim | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | Flow Designer shows each app's sources, CQs and targets, and Sherlock tags sensitive fields. Data Workers keeps one governed context graph of what every table means, who owns it and what reads it. |
| Analytics & Insights | 8 | 3 | Striim runs streaming SQL and windows in flight; the reporting sits in BI. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 6 | Validata monitors, compares and verifies datasets at scale, a real strength for replication. Data Workers checks the tables built after the target: nulls, uniqueness, volume and team metrics, load lag included. |
| Observability & Incidents | 8.5 | 5 | App monitoring, custom alerts and Foreseer anomaly detection watch the stream. Data Workers diagnoses the incident when every app is running and the number is still wrong. |
| Pipelines & Ingestion | 8.5 | 9 | Striim's home stage: log-based CDC readers for Oracle, SQL Server, PostgreSQL, MySQL, MongoDB and Salesforce, CQs in flight and writers for every major warehouse and lake. Data Workers proposes reloads for the owner. |
| Schema & Migration | 8 | 6 | Writers propagate supported source DDL, and MSJet now captures DDL inside SQL Server transactions. Data Workers traces what a change does in dbt and BI and generates migrations with rollback SQL for the owner. |
| Governance & Access | 8.5 | 4 | Striim controls who manages apps, namespaces and API tokens. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 6 | Sentinel masks or encrypts sensitive data in flight and Sherlock discovers it in sources. Data Workers leaves a receipt on every data change and keeps classification next to lineage. |
| Cost / FinOps | 8 | 2 | Striim runs the stream; warehouse spend sits in the warehouse. Data Workers reads BigQuery spend from the Jobs API and traces Snowflake credits to the dbt model behind them. |
| MLOps & Models | 7.5 | 3 | Euclid writes vector embeddings in flight for AI apps. Data Workers keeps the data under models and agents healthy. |
How Striim and Data Workers work together
Data Workers connects to Striim over its REST API today. Most of what it needs already sits at the target: the tables each app writes, their keys and the modification times the source carries. Data Workers reads those natively in BigQuery, Snowflake and Databricks, and the context graph holds which app writes which table and who owns it. Apps, CQs, Sentinel and Sherlock settings, writers and reloads stay with your team: Data Workers never deploys, starts, stops or reloads a Striim app. When a fix needs fresh rows, it proposes the reload with the reason, the table and the window, and the owner runs it in Striim or with Clara. The rest of this incident runs on native connections: BigQuery, dbt Cloud, Looker (read), PagerDuty, Slack and GitHub, among 50+ connectors.
Striim doesn't publish an MCP server today, so the Data Workers agents sit in your coding agent or assistant on their own, and Clara stays in the Striim console. The setup follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry.
# Example: Data Workers agents in Claude Code, from a clone of the open-source repo
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents
claude mcp add --scope user dw-quality -- "$(pwd)/start-agent.sh" dw-quality
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-connectors -- "$(pwd)/start-agent.sh" dw-connectorsList the tools with your client's own command (/mcp in Claude Code). In this incident: run_quality_check (dw-quality) runs the uniqueness, null and volume checks on BigQuery; monitor_metrics (dw-incidents) tracks the match rate against its baseline; diagnose_incident names the cause; blast_radius_analysis and trace_cross_platform_lineage (dw-context-catalog) map what the masked key reached; the team's dbt Cloud scheduler runs the approved rebuild; remediate re-checks the quality assertions and escalates any failure to a person.
In production the agents run in your infrastructure and hold the warehouse credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only. Sensitive-data policy stays in Sentinel: Data Workers reads no values to classify columns, and any masking it suggests is a proposal a person applies. More in where does our data go.
One incident, L0 to L4, set per domain:
- •L0 manual. Carriers call AP on Wednesday about late quick-pay; an engineer finds the x's that afternoon.
- •L1 observe. Data Workers flags the repeated key and the match-rate drop at 05:20 with the cause and blast radius. Nothing changes.
- •L2 propose. Data Workers proposes the field rule, the reload, the test and the hold; nothing moves until each named owner approves, and an unanswered request expires and escalates, never auto-grants.
- •L3 act reversibly. For a class with a clean record, approved downstream rebuilds go straight onto the team's dbt Cloud schedule, and Data Workers sends any failed check to a person. Striim and its policies stay with their owners.
- •L4 autonomous. For a scoped domain, Data Workers checks each target table as changes land, so the owners' decision is waiting before the nightly build.
Who sets those levels: who owns the agents, how approvals work for AI data agents and autonomy levels L0 to L4 explained.
What changes for your team
- •Governance and data quality stop pulling against each other. A new Sentinel rule ships with a check on every key it might reach.
- •On-call starts from a cause. The PagerDuty incident carries the masked key, the change window, the damage, the proposed fixes and who owns each one.
- •Business processes get a guard. When a delivery or a payment run reads a table that just went wrong, the hold is proposed before it acts.
- •One record for the platform, governance and finance teams. Everyone sees the same incident and receipt in Spellbook Data Catalog (in preview), linked from the PagerDuty incident.
More: Data Workers integrations, what is an agentic data platform and the change data capture explained primer.
Keep Striim, or consolidate?
Keep Striim if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For Striim teams, keeping it is the norm: real-time CDC with processing in flight is what Striim is for. What teams consolidate is the checking around it: a custom alert in Striim, a dbt test suite, a monitor in a third tool and a wiki runbook, each seeing one hop. Data Workers puts the target tables, models, dashboards and the processes behind them on one incident record and one approval flow, whichever mover lands the data.
Running more than one mover? See you're on Debezium and you're on Estuary, and you're on dbt for the models downstream. Comparing CDC tools first? Start with the CDC tools comparison.
Weighing a build? Read build it ourselves with Claude Code and MCP servers: spotting ten x's is easy; the context graph, three owners' approvals, the undo and the receipts are the work.
The case for your CFO
The outcome. When a change inside the stream alters what a downstream number means, it is caught the same night and corrected before a payment run, a customer or a manager acts on it, with a record of how it was checked.
The risk story. At L0 and L1, agents only read. At L2 they propose and a named person approves; an unanswered request expires and escalates, never auto-grants. At L3 they act on reversible changes inside the domains you open; L4 is a later choice per domain. Striim and its policies stay with their owners. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. Every change carries a receipt: what changed, who approved it, the blast radius and the undo.
Why now. Every vendor in the data path now ships AI that acts: Striim's Sentinel and Clara among them, each working well inside its own product. The more changes happen in flight, the more you need one owner for what they do to the numbers after the target.
The first win. L1 on the Striim apps that feed finance and customer numbers: a broken key or a match-rate drop becomes a diagnosed incident before the nightly build finishes.
What stays the same. Nothing migrates for Data Workers: Striim, your sources, your warehouse, your dbt project, Looker and your on-call rota. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "Striim keeps our data real-time and protected; Data Workers makes sure what it lands is right, and gets it fixed with our approval when it isn't."
Getting started
Start with a pilot. Pick the Striim apps that feed the numbers finance and customers act on, give Data Workers read access to the target schemas and the dbt project, record the two or three metrics that matter, and run at L1 for a few weeks. Then turn on L2 for one domain, and open L3 for a narrow class once the receipts show the agents were right. The pilot path is on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to Striim? Over Striim's REST API today. Data Workers reads the tables your apps write natively in BigQuery, Snowflake or Databricks; your owner keeps running apps and reloads in Striim, directly or with Clara.
Will Data Workers change our Striim apps or Sentinel policies? No. Apps, CQs, Sentinel and Sherlock settings, writers and reloads stay with their owners. Data Workers proposes a change, such as a field rule or a reload, with the reason and the rows involved; the owner approves and applies it in Striim.
Our apps are green and nothing is lagging. Why would a number be wrong? Because a healthy stream can still change what a column means: a masking rule, a CQ edit, a source DDL the writer propagates. Striim lands each one faithfully. Data Workers checks the landed tables and the team's metrics, so a correct change that breaks a join still raises an incident.
We already use Validata. What does Data Workers add? Validata compares and verifies the datasets Striim moves, the right check for replication and migration. Data Workers owns what happens after the target: the models, dashboards and processes that read the tables, the fix across owners and the receipt.
How is this different from Clara? Clara is Striim's conversational agent for building, inspecting and operating Striim apps; it builds through a TQL plan you approve. Data Workers works across the whole estate: it traces a problem from the target through dbt, BI and on-call, and routes each fix to the owner of that system. In the incident above, the Striim owner used Clara and Data Workers side by side.
Does fixing a masking problem weaken our data protection? No. The fix in the example narrows a rule: a key field gets "No action" while every other phone number stays masked, which is the pattern Striim's own Sentinel docs recommend for key fields. The governance lead approves it, and the receipt records the change.
Sources
All checked Oct 3, 2026.
- •Striim homepage ("complete Change Data Capture and Streaming platform"; Striim Cloud, Striim Platform, Validata, per-target editions), https://www.striim.com/
- •Striim docs, What's new in Striim Cloud 5.4.2 (Clara AI agent, ClickHouse Writer, S3 Tables and GCP Lakehouse writers, Fast Snapshot Loading labeled queries, MSJet DDL capture, BigQuery Writer exactly-once in MERGE mode; last modified Sep 12, 2026), https://www.striim.com/docs/en/what-s-new-in-striim-cloud-5-4-2.html
- •Striim docs, Striim Clara AI Agent (inspect apps, lifecycle actions such as deploy and stop on request, build plans reviewed and approved before anything changes; no GA or preview label; last modified Sep 21, 2026), https://www.striim.com/docs/en/striim-clara-ai-agent.html
- •Striim blog, "How do you build a real-time CDC pipeline by talking to an AI agent?" (Sep 25, 2026), https://www.striim.com/blog/building-cdc-pipeline-with-ai/
- •Striim docs, AI Agents and features in Striim (Sentinel, Sherlock, Euclid, Foreseer, Clara; last modified Sep 18, 2026), https://www.striim.com/docs/en/ai-agents-and-features-in-striim.html
- •Striim docs, Sentinel AI: real-time sensitive data detection and protection (Actions on Data Identifiers and on Fields, Mask completely, "No action" for key fields; last modified Aug 27, 2026), https://www.striim.com/docs/en/sentinel-ai--real-time-sensitive-data-detection-and-protection.html
- •Striim docs, Sherlock AI: sensitive data discovery in sources, https://www.striim.com/docs/en/sherlock-ai--sensitive-data-discovery-in-sources.html
- •Striim docs, CREATE CQ (query), https://www.striim.com/docs/en/create-cq--query-.html
- •Striim docs, API Guide (Application Management REST API: deploy, start, stop, undeploy, drop, TQL, monitoring; last modified Mar 27, 2026), https://www.striim.com/docs/en/api-guide.html, and Managing API tokens in Striim Cloud (last modified Sep 3, 2026), https://www.striim.com/docs/en/managing-api-tokens-in-striim-cloud.html
- •No Striim MCP server found: not in the Striim docs, the 5.4.2 release notes or the Sep 25 Clara post, and no Striim MCP repository on GitHub or package on npm (checked Oct 3, 2026)
- •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community, and client setup guide, https://dataworkers.io/opensource-docs/client-setup/