You're on Hightouch: Hightouch Activates Your Warehouse Data. Data Workers Owns Whether What It Sends Is Right
Hightouch sends warehouse data to 300+ customer tools. Data Workers owns whether what it sends is right: checks, diagnosis and fixes before the sync runs, behind approvals.
Your team thinks in models, syncs, audiences and destinations. The data team publishes models on the warehouse, marketing builds audiences on them in Customer Studio, and syncs carry each audience and trait to Iterable, Braze, Salesforce, the ad platforms and the rest of 300+ tools on a schedule or after a dbt job. Since February 2026 Hightouch calls itself the Agentic Marketing Platform: an Agent drafts audiences from plain language, AI Decisioning picks the message, channel and timing for each person, and Lifecycle Studio and Ad Studio generate the campaigns. Hightouch activates your warehouse data in every customer tool. Data Workers owns whether what it sends is right: it checks the models behind your syncs, diagnoses what changed upstream, proposes the fix to a named owner and verifies it before the next sync runs.
A sync that completes tells you the rows arrived in the destination. It can't tell you whether the rows were right when they left the warehouse.
Key takeaways
- •Hightouch keeps its job. Models, syncs, Customer Studio audiences, journeys, AI Decisioning and the creative studios stay with the teams that run them today.
- •Data Workers owns what the syncs read. It checks the tables and dbt models behind each sync for nulls, duplicates and volume on Snowflake and BigQuery, and baselines the metrics your team names.
- •It sees the whole chain. One context graph joins source events, the warehouse, dbt and the Hightouch syncs that read them, so a broken input is traced to every destination before the sync runs.
- •Syncs stay in your team's hands. Data Workers connects to Hightouch over its REST API or the Hightouch MCP server today. It proposes holding a sync with the reason and the audience at risk; the sync owner acts in Hightouch.
- •One approval, one receipt. A named owner approves in Spellbook, and the receipt records the cause, the fix, the approver, the checks and the undo.
Hightouch is the activation layer. Data Workers is the owner of what it sends.
Hightouch makes the warehouse useful to marketing; Data Workers makes sure it tells marketing the truth. Here is a Thursday morning at an online apparel retailer, an illustration rather than a customer case. The storefront sends events to Google Analytics 4, and the GA4 daily export lands them in BigQuery. A marketing_daily DAG on Managed Service for Apache Airflow runs dbt at 06:00, building stg_ga4__product_views and then dim_customers, which carries each customer's last_browsed_category. dim_customers is the parent model in Customer Studio, and the "Browse abandoners" audience built on it syncs to an Iterable static list at 09:00; the CRM team's browse-recovery campaign sends to that list at 10:00. Because the parent model is a dbt model, Hightouch's exposure sync writes that sync into the dbt project as an exposure, and the team has recorded it in the context graph. Data Workers runs at L2 propose for the marketing data domain.
| Time | System | What happens |
|---|---|---|
| Wed 16:40 | Storefront and GA4 | A new product page template ships. It sends the product category inside GA4's items array as item_category and stops sending the custom product_category event parameter the dbt model reads |
| Thu 05:10 | GA4 and BigQuery | The daily export table for Wednesday lands. Its schema is unchanged: event parameters are key and value pairs, so a missing key adds no column and removes none |
| 06:00 | Managed Airflow and dbt | marketing_daily runs dbt build. Every product view after 16:40 has a null category. dim_customers keeps the last non-null category, so 23,900 customers who browsed outerwear on Wednesday now show whatever they browsed weeks ago. All dbt tests pass |
| 06:25 | Data Workers and BigQuery | The checks the team schedules after each dbt run flag stg_ga4__product_views: run_quality_check reads a null rate of 38% on product_category against a 30-day norm under 1%. The owner confirms the export's schema is unchanged, which rules out the export |
| 06:34 | Data Workers | diagnose_incident finds that every null comes from the new template's pages after 16:40, and that those same events carry the category in items.item_category. trace_cross_platform_lineage and blast_radius_analysis follow dim_customers to the recorded Hightouch sync: the 09:00 sync would move 23,900 customers into the wrong category segments of the Iterable list before the 10:00 send. The audience size is normal, so no size alert fires |
| 06:40 | Slack and Spellbook | The approval request reaches the analytics engineer who owns the model and the marketing ops owner of the sync, with one proposal: hold the Browse abandoners sync until the fix is verified; a diff to stg_ga4__product_views that reads items.item_category when the parameter is missing; a dbt not_null test on product views from the new template; a note to the web team |
| 07:05 | Hightouch | The marketing ops owner turns the sync off in Hightouch. The Iterable list keeps Wednesday morning's members |
| 07:20 | Spellbook and GitHub | The analytics engineer reviews the evidence and approves. Her coding agent opens the pull request from the approved diff, Data Workers posts the blast radius on it, CI passes and she merges at 07:35 |
| 07:50 | Managed Airflow | She clears the dbt task in marketing_daily, and the models rebuild on the fixed staging model; the new test passes |
| 08:15 | Data Workers and BigQuery | Data Workers re-runs the null check, compares Wednesday's category mix with the baseline the team records with monitor_metrics, confirms dim_customers rebuilt and writes the receipt |
| 08:40 | Hightouch and BigQuery | The marketing ops owner reads the receipt, previews the audience in Customer Studio and turns the sync back on. Data Workers reads the run in Hightouch's Warehouse Sync Logs in BigQuery: completed, no failed rows |
| 10:00 | Iterable | The browse-recovery campaign sends to the right list. Nobody who looked at winter coats gets a swimwear email |
Nothing in Hightouch misbehaved. The model returned the usual row count, the sync would have succeeded, and approval flows had nothing to review because nobody edited the model or the sync. The problem started on a product page and crossed GA4, BigQuery and dbt without changing a schema. Data Workers saw the events, the dbt project and the sync as one chain and put the decision in front of its two owners before 09:00.
| Job | What Hightouch does | What Data Workers does |
|---|---|---|
| Sending data out | Reverse ETL syncs from the warehouse to 300+ destinations, on a schedule or after a dbt Cloud or Fivetran job | Leaves syncs with your team and checks what each one is about to read |
| Building audiences | Customer Studio, the audience builder Agent, journeys, Insights | Keeps the parent model and its related models right, so an audience means what marketing thinks it means |
| Deciding per person | AI Decisioning agents choose message, channel and timing within your guardrails | Keeps the audience and outcome data those agents learn from fresh and correct |
| Guarding changes | Approval flows for model and sync edits, roles, subsets, audit logs | Puts every change to the data behind a sync through one approval flow with a receipt |
| Watching syncs | Sync alerts on fatal errors, rejected rows, throughput, model size and duration; Warehouse Sync Logs | Diagnoses the incident upstream of the sync, across the source, warehouse and dbt, with diagnose_incident |
| The record | Audit logs of in-app actions and row-level sync logs | A receipt: cause, fix, approver, checks and undo, in Spellbook and the audit trail |
Why doesn't Hightouch just do this itself?
Because Hightouch's promise is faithful activation, and that is why marketing trusts it. A sync sends what the model returns, quickly and completely. A reverse ETL tool that held rows it suspected were wrong would be a worse reverse ETL tool.
Hightouch's guards follow the same sensible scope. Approval flows stage a change to a model's query or a sync's configuration until an approver publishes it. Sync alerts watch the sync itself: fatal errors, rejected rows, stalled throughput and a model that returns too few rows. The audience builder Agent drafts conditions for a person to review, and AI Decisioning agents operate within the rules you define. Each keeps Hightouch's own work correct.
The Thursday fix sat outside all of them: it crossed a storefront release, GA4, a BigQuery export, an Airflow DAG, a dbt model and a sync owned by marketing. It needed a check on values inside the warehouse, a diagnosis that read GA4's export structure, a blast radius that ended at an Iterable list, a named approver and a receipt. Taking on liability for changes across tools Hightouch doesn't run is a different product category. That product is Data Workers, and it builds on Hightouch.
Every tool owns a slice. Data Workers covers the whole lifecycle
Hightouch owns activation, and it is excellent at it. 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, with Hightouch at the outbound edge of the warehouse.
| Stage | Data Workers | Hightouch | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4 | Customer Studio's schema maps parent models, related models, events and traits for marketers and agents. Data Workers keeps one governed context graph across sources, the warehouse, dbt and every consumer, with owners and usage. |
| Analytics & Insights | 8 | 6 | Intelligence and Customer Studio Insights give marketers analysis of audiences and campaigns on warehouse data. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 4 | Sync alerts catch rejected rows and a model that returns too few rows. Data Workers checks the tables and models behind each sync for nulls, duplicates and volume, and baselines the values your team names. |
| Observability & Incidents | 8.5 | 5 | Sync alerts routed to email, Slack, PagerDuty, SMS or a webhook, plus row-level Warehouse Sync Logs. Data Workers diagnoses the incident across the source, warehouse and dbt, including the ones where every sync succeeds. |
| Pipelines & Ingestion | 8.5 | 9 | Hightouch's home stage: reverse ETL to 300+ destinations, warehouse-side change data capture, dbt and Fivetran triggers, Git sync. Data Workers leaves syncs with your team and makes sure what they read is right. |
| Schema & Migration | 8 | 2 | Hightouch reads models as the warehouse defines them, and its dbt CI checks flag pull requests that remove a model a sync uses. Data Workers classifies schema changes as breaking or safe and plans migrations in approved waves. |
| Governance & Access | 8.5 | 6 | Roles, subsets, Spaces, environments, approval flows for models and syncs, and audit logs. Data Workers drafts each warehouse access request as a scoped grant with an expiry for a named owner to approve. |
| Security & Privacy | 8 | 5 | The composable design keeps customer data in your warehouse, and subsets limit which rows each user sees. 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 | 3 | Hightouch runs sync compute in your warehouse with the Lightning engine. Data Workers attributes Snowflake credits to dbt models, totals BigQuery spend from the Jobs API and drafts fixes for the owner. |
| MLOps & Models | 7.5 | 5 | AI Decisioning runs reinforcement learning agents per campaign, with agent health and alerting. Data Workers keeps the audience and outcome data under those models fresh and correct. |
Hightouch leads on its home stage, as it should. For the category, read what is an agentic data platform, how Data Workers differs from data observability and Data Workers vs a data catalog.
How Hightouch and Data Workers work together
Hightouch stays where your teams run models, audiences and syncs, in the app or through the Hightouch MCP server. Spellbook Data Catalog (in preview) is where the data team reviews, approves and rolls back. Data Context Wizard joins the source events, the warehouse, the dbt project and Hightouch's syncs in one governed context graph, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor carries each fix from detection to verification.
Exactly what Data Workers reads, runs and proposes around Hightouch.
| What it covers | How | |
|---|---|---|
| Reads | The tables and models every sync reads, their null, uniqueness and row-count checks, and Hightouch's Warehouse Sync Logs in the hightouch_audit schema | Native connections to Snowflake, BigQuery, Databricks and PostgreSQL |
| Reads | The dbt manifest's models and lineage; pull-request review's lineage diff also reads the exposures Hightouch's exposure sync writes | Native dbt connection |
| Reads | Syncs, models, schedules and destinations in Hightouch's own terms | Over Hightouch's REST API with a key scoped to a group with the Workspace viewer role, or the Hightouch MCP server in the same client |
| Runs | Checks after each dbt run and before the sync windows your team names | run_quality_check on the warehouse for volume, nulls and uniqueness, each result in the audit trail |
| Proposes | Model fixes, tests and sync holds | A diff for the owner to merge; holds with their reason and the audience at risk, for the sync owner to apply in Hightouch |
Hightouch objects stay with your team, by design. Data Workers reviews your dbt pull requests with a blast-radius comment that reaches the Hightouch exposures, next to Hightouch's own dbt CI check. Managed Airflow and dbt Cloud connect natively; GA4 and Iterable connect over their APIs today.
Setup in your coding agent. Every Data Workers agent is an MCP server, set up by the documented path in the client setup guide: clone the open-source repo and add one start-agent.sh entry per agent. The Hightouch MCP server goes in the same client once Hightouch enables it for your workspace. Example for Claude Desktop or Cursor:
{
"mcpServers": {
"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"] },
"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"] }
}
}Ask "is anything feeding this morning's Hightouch syncs wrong?" and Data Workers returns each flagged table, the cause, the syncs it reaches and any proposal awaiting approval. The Hightouch MCP server answers in Hightouch's terms. List the tools with your client's own command, such as /mcp. For a shared endpoint, the Data Workers remote server serves /mcp with an API key (bearer) or OAuth tokens from your identity provider, verified through JWKS.
One Hightouch incident, L0 to L4, with the ladder set per domain.
- •L0 manual. A customer replies to a swimwear email in October, and someone finds the template change by the afternoon.
- •L1 observe. Data Workers posts the 06:34 diagnosis: the template change, the null rate and the sync and Iterable list at risk. Nothing changes.
- •L2 propose. Data Workers proposes the hold, the staging diff and the test. Nothing changes until the owners approve and act.
- •L3 act reversibly. For change classes with a proven record, such as re-running the checks after an approved fix merges and posting the result to the sync owner, Data Workers runs the step and writes the receipt.
- •L4 autonomous. For a scoped domain with a long clean record, Data Workers runs the repeatable steps end to end; Hightouch changes still go through your team.
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 and hold the warehouse credentials and model key, your data stays in your systems, and the hosted Conductor sees workflow metadata only.
What changes for your team
Hightouch took the CSV uploads off your team's plate. Data Workers takes the next job: making sure the warehouse is right before a sync carries it to a customer.
- •Incidents. A source change headed for customers through a sync gets a diagnosis, a blast radius and a fix proposal before the sync window.
- •Data quality. The models behind your highest-reach syncs are checked for nulls, duplicates and volume after every dbt run, and the values marketing depends on get baselines.
- •Cloud spend. BigQuery spend is read from the Jobs API, Snowflake credits are traced to the dbt models behind them, and fixes reach their owners drafted.
- •Access. A request for the tables behind Customer Studio becomes a scoped, time-boxed grant the data owner approves.
- •Audits. Every fix to the data Hightouch sends carries a receipt: cause, change, approver, checks and undo.
- •Migrations. A warehouse move runs in approved waves with parity checks planned and tracked per wave, and syncs move after the owner signs off.
The marketing ops lead changes most: a bad input arrives as one proposal with its evidence and its undo, hours before the send, instead of as a complaint after it. On who answers for each agent, read who owns the agents.
Keep Hightouch, or consolidate?
Keep Hightouch if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For Hightouch, keeping it is the norm: Hightouch's syncs, audiences and AI Decisioning agents are where your activation lives. What teams consolidate is the checking around it: a monitor that only sees the warehouse, row-count alerts set per sync, a runbook for tracking changes nobody reads. Most estates run more than one mover and want one operating layer across all of them; the same pattern runs through you're on Census, you're on Segment, you're on Fivetran and you're on dbt. Hightouch also appears in you're on Monte Carlo and the agentic data platform for retail and e-commerce. Building the checks yourself? Read build it ourselves with Claude Code and MCP servers. Connections are listed on Data Workers integrations and the dbt wiring in Data Workers + dbt.
The case for your CFO
The outcome: the audiences, traits and scores Hightouch sends become emails, ads, sales calls and offers. Data Workers makes sure the data behind them is right before the sync runs, so a change on a product page becomes a scoped fix at breakfast instead of a campaign sent to the wrong customers.
The risk story: at L1 Data Workers only reads; at L2 it changes nothing until a named person approves; at L3 it acts only on steps it can undo. An unanswered request expires and escalates, never auto-grants. No agent can promote its own work. An org-wide stop halts all autonomous dispatch. Zero migration: Hightouch, GA4, BigQuery, Airflow, dbt and Iterable stay put.
Why now: marketing now runs agents that build audiences, choose messages and generate creative from warehouse data, and the Hightouch MCP server lets an assistant build audiences and manage syncs in conversation. A wrong value reaches a customer faster than it reaches a dashboard. You want one approval flow and one audit trail on that data. For the numbers, see the ROI of agentic data operations.
The first win is read-only: checks on the models behind your three largest syncs, each finding traced to the destinations it would reach. What stays the same: your models, syncs, audiences and schedules.
The sentence to repeat upstairs: "Hightouch sends our data to customers; Data Workers makes sure it's right before it leaves, and shows us the receipt."
Getting started
Start with a pilot. Pick the Hightouch syncs that reach the most customers, connect Data Workers read-only to the models they read and the dbt project with Hightouch's exposures, and run at L1 so every flagged input gets a diagnosis, a blast radius and a proposed fix. Then move that domain to L2 so fixes arrive in Spellbook for a named owner. 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 Hightouch? Over Hightouch's REST API or the Hightouch MCP server today. A key scoped to a group with the Workspace viewer role reads syncs, models and sources and changes nothing. The heavy lifting runs where the syncs read: native connections to your warehouse and your dbt project, where Hightouch's exposure sync records the syncs built on dbt models.
Does Data Workers pause or edit our syncs? No. Data Workers proposes a hold with the reason and the audience at risk; the sync owner acts in Hightouch.
We already use approval flows. What does this add? Approval flows review edits to a model's query or a sync's configuration; keep them. A bad send can also come from data that changed under an unedited model, as in the Thursday example. Data Workers checks that data and puts its fix through an approval with a receipt.
Hightouch sync alerts already watch our syncs. Isn't that enough? Sync alerts catch failed runs, rejected rows, stalled syncs and a model that returns too few rows. A model can return the usual row count with wrong values. Data Workers checks the values and traces the cause upstream.
Does it work with AI Decisioning and the audience builder Agent? Yes, on the data side. Both work from your Customer Studio schema and the warehouse behind it. Data Workers keeps those models and outcome events fresh and correct; what the agents decide stays inside Hightouch's guardrails.
How is this different from the Hightouch MCP server? The Hightouch MCP server lets an assistant build audiences, manage syncs and analyze campaigns inside your Hightouch workspace. Data Workers works on the warehouse, dbt and source systems behind it. Teams run both in the same client.
Sources
- •Hightouch homepage (Agentic Marketing Platform; Composable Customer Data Platform), https://hightouch.com/ (checked Oct 3, 2026)
- •Hightouch Reverse ETL (300+ destinations; warehouse change data capture; Git; dbt models, exposures and triggers), https://hightouch.com/platform/reverse-etl (checked Oct 3, 2026)
- •Hightouch blog, "Introducing the Agentic Marketing Platform" (Feb 3, 2026), https://hightouch.com/blog/agentic-marketing-platform (checked Oct 3, 2026)
- •Hightouch blog, "Introducing Lifecycle Studio" (Jun 24, 2026), https://hightouch.com/blog/introducing-lifecycle-studio (checked Oct 3, 2026)
- •Hightouch docs, Hightouch MCP (enabled by Hightouch; read and act; scoped to the workspace and its roles), https://hightouch.com/docs/ai-integrations/mcp (checked Oct 3, 2026)
- •Hightouch docs, API overview (REST API; keys scoped to a user group; viewer keys for AI tools), https://hightouch.com/docs/developer-tools/api-guide (checked Oct 3, 2026)
- •Hightouch docs, Customer Studio overview, https://hightouch.com/docs/customer-studio/overview (checked Oct 3, 2026)
- •Hightouch docs, Audience builder prompting guide (the Agent), https://hightouch.com/docs/customer-studio/agents (checked Oct 3, 2026)
- •Hightouch docs, AI Decisioning overview, https://hightouch.com/docs/ai-decisioning/overview (checked Oct 3, 2026)
- •Hightouch docs, Approval flows (models and syncs; audiences publish immediately), https://hightouch.com/docs/workspace-management/approval-flows (checked Oct 3, 2026)
- •Hightouch docs, Configure sync alerts (fatal errors, rejected rows, throughput, model or audience size, duration), https://hightouch.com/docs/syncs/alerting (checked Oct 3, 2026)
- •Hightouch docs, Warehouse Sync Logs (
hightouch_auditchangelog, snapshot and sync runs; BigQuery supported), https://hightouch.com/docs/syncs/warehouse-sync-logs (checked Oct 3, 2026) - •Hightouch docs, dbt observability layer (dbt CI checks; exposure sync), https://hightouch.com/docs/extensions/dbt-observability (checked Oct 3, 2026)
- •Hightouch docs, Iterable destination (static lists), https://hightouch.com/docs/destinations/iterable (checked Oct 3, 2026)
- •Google Analytics Help, GA4 BigQuery Export schema (
events_YYYYMMDD,event_params,items.item_category), https://support.google.com/analytics/answer/7029846 (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)