You're on Hex: Your Analysts and Data Scientists Answer There. Data Workers Owns Whether the Data Behind Every Answer Is Right
Already on Hex? Data Workers checks the tables under every published app and Thread, traces a wrong chart to its cause, proposes the fix behind a named approval and verifies the number, with a receipt.
Your analysts and data scientists live in Hex. They write SQL and Python side by side in projects, publish the good ones as apps the leadership team opens every Monday, and let the Notebook Agent draft cells they review. Business users ask questions in Threads, in Hex or straight from Slack, and Threads answer from semantic models built in the Modeling Workbench or synced from dbt MetricFlow, Cube or Snowflake Semantic Views. Endorsed data marks what to trust, Context Studio shows how the agents are used, and engineers connect Claude Code or Cursor to the Hex MCP server (beta). Hex is where your analysts and data scientists explore and share answers. Data Workers owns whether the data behind those answers is right: it checks the tables under every app and Thread, traces a wrong chart to the release, sync or model that caused it, proposes the fix behind a named approval and verifies the number with a receipt.
Key takeaways
- •Hex keeps its job. Projects, published apps, Threads, semantic models and the Notebook Agent stay with the people who own them today.
- •Endorsed data says which table to use. Data Workers checks whether last night's load left it right. It checks the tables under every published app after each load and holds headline values to a baseline.
- •The fix lands where the cause is. A wrong Hex chart usually starts in an app release, an ingestion sync or a dbt model. Data Workers proposes the fix there as a diff, behind a named approval, and queues the rerun.
- •Nothing written to Hex, by design. Data Workers connects to Hex over its API or MCP server today and changes nothing in it; its agents never call the Hex MCP server. App reruns, cache choices and model syncs stay with Hex's owners.
- •Start with one app. Check every table under the app your leadership reads, then climb from L0 manual to L4 autonomous per domain.
Hex is where analysts and data scientists explore and share answers. Data Workers owns whether the data behind them is right.
A Hex app is only as good as the last load under it, and Threads make that sharper. Hex's docs say the Threads agent "heavily prioritizes semantic models and endorsed data sources," so a business user gets a fluent answer from the table your team trusts most. When that table is wrong, the answer is fluent and wrong.
Here is a Wednesday at a B2B software company running Hex on Snowflake, with the product's PostgreSQL database replicated by an Airbyte CDC connection and dbt Core run by Prefect (times ET). This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Tue Sep 29, 14:05 | PostgreSQL (app), GitHub | The product team ships seats-v2. Seat ownership moves from seats.account_id to a new seat_assignments table. New rows in seats now carry a null account_id; the app reads ownership from the new table and works fine. |
| Tue 15:00 to Wed 01:00 | Airbyte, Snowflake | The hourly Postgres CDC connection syncs seats into RAW_APP. It syncs the streams the platform team selected, and seat_assignments is new, so it is not one of them. 172 new seats land with no account. |
| Wed 02:00 | Prefect, dbt Core, Snowflake | The nightly_dbt flow builds fct_seats, which left-joins dim_accounts for each seat's plan_tier. The 172 new seats build with no tier. The paid_seats metric in MetricFlow filters plan_tier <> 'free', and a null tier fails that filter, so they fall out of the count. Every model builds; the flow run is green. |
| 02:20 | Data Workers | The null check the team registered on stg_app__seats.account_id fails in run_quality_check: 172 nulls, against zero in every earlier run. monitor_metrics shows Tuesday's new paid seats, a value the team records after each build, at 118 against a baseline near 290. |
| 02:22 | Data Workers, Slack | blast_radius_analysis follows fct_seats to the paid_seats metric in dbt MetricFlow and to two Hex consumers the team recorded in the context graph: the Weekly Business Review app and the Seats semantic model Hex syncs from MetricFlow. Another note adds the data science team's seat forecast project. Data Workers opens an incident and posts it to #data-incidents with send_slack_alert. |
| 06:00 | Prefect, Hex | The wbr_refresh flow runs the Weekly Business Review project through Hex's API with published results updated. The app now shows 40,864 paid seats and a Tuesday dip. |
| 07:40 | Hex Threads in Slack | The VP of Finance asks the Hex agent in Slack why new seats fell on Tuesday. The Thread answers from the Seats semantic model: 118 new seats, 59% below average, and offers a reasonable-sounding theory about a pricing page test. The analytics lead replies in the thread with the incident link. |
| 08:05 | Data Workers | diagnose_incident with trace_cross_platform_lineage walks fct_seats back through stg_app__seats to RAW_APP.SEATS; the dbt manifest, read natively, shows the left join and the metric filter that a null tier fails. A native catalog read of the app's PostgreSQL database finds the new seat_assignments table. get_incident_history finds no earlier case on this table. |
| 08:20 | Slack | The app engineer confirms the seats-v2 change and that seats.account_id is now empty for new rows. The platform engineer confirms seat_assignments is not selected in the Airbyte connection. |
| 08:35 | Data Workers, Spellbook | One plan with three owners. For the platform engineer: add the seat_assignments stream to the Airbyte connection and sync it. For analytics engineering: a diff that adds the new source, takes account_id from seat_assignments when seats has none, and adds a not_null test on fct_seats.account_id; then a Prefect rerun of nightly_dbt for fct_seats and everything downstream. For the app owner: rerun the Weekly Business Review with fresh SQL results. The blast radius and the undo (revert the merge, rerun) travel with it. The approval request reaches the analytics engineering lead in Slack. |
| 09:05 to 09:25 | Airbyte | The platform engineer adds the stream and runs the sync. Data Workers never starts syncs; the connection's owner does. |
| 09:30 | Spellbook, GitHub | The lead reviews the diff and blast radius in Spellbook and approves; the dbt owner merges. |
| 09:32 | Prefect | Data Workers queues the approved flow run through Prefect and reads its state until it completes. |
| 09:58 | Snowflake | run_quality_check finds no null account_id in stg_app__seats or fct_seats. Tuesday's new paid seats read 290, inside the baseline. Data Workers records 41,036 paid seats as the agreed source value. |
| 10:05 | Hex | The app owner reruns the Weekly Business Review through Hex's API with updatePublishedResults on and useCachedSqlResults off. The 06:00 flow's call kept Hex's default, which lets SQL cells reuse cached results, so the owner chose fresh results on purpose. The app shows 41,036. |
| 10:15 | Hex Threads in Slack | The VP of Finance asks again. The Thread answers 41,036 paid seats and 290 new on Tuesday. Data Workers closes the incident with the receipt (cause, diff, approver, rerun, checks) and a graph note that every seat metric depends on seat_assignments. |
No tool failed. The release was right for the app, Airbyte synced the streams it was given, dbt built what the model said, and Hex showed and explained what Snowflake returned. The break sat in the handoffs: a new table nobody told the pipeline about, and a filter that reads an empty tier as "not paid". Data Workers flagged it hours before the app refreshed, a named person approved the fix, and the Thread's second answer matched the source.
| Job | What Hex does | What Data Workers does |
|---|---|---|
| The question | Projects, published apps, Threads and the Notebook Agent let analysts, data scientists and business users ask and answer | Gives the agents your team uses one governed view of each table: definition, lineage, owners and trust score |
| The metric | Semantic models built in Hex or synced from dbt MetricFlow, Cube and Snowflake Semantic Views ground every Thread | Holds the tables under those models to the checks your team registers and the headline values it records |
| The break | Shows and explains whatever the warehouse returns, faithfully | Catches the null, duplicate key or missing rows after the load, traces them to the release, sync or model, and lists every app the change reaches |
| The fix | Owners edit cells, rerun apps and choose when results refresh | Proposes the upstream fix as a diff for its owner, routes it to a named approver and queues the approved rerun |
| The proof | The rerun app and the next Thread show the new number | Re-checks the tables, compares the recorded value and writes a receipt with cause, diff, approver and undo |
Why doesn't Hex just do this itself?
Hex made a clear bet: one workspace for analysts, data scientists and business users, with every answer fast, shareable and grounded in trusted context. Its guardrails fit that job. The Notebook Agent is "intended to be used by technical users who can audit the SQL and code that the agent suggests." Hex MCP edits "always apply to a project's draft version," and publishing happens in the Hex app. Endorsed Mode limits Threads to endorsed data. Admins can mark a data connection sensitive, which the MCP server does not query by default. Since September 15, Skip approvals mode lets the Hex Agent work straight through a task, while anything that expands access still waits for a person and the last agent turn can be undone.
All of that protects the workspace. Wednesday's break never touched Hex. It came through a product release, an ingestion connection and a dbt model, and the fix meant an Airbyte stream, a dbt change, an approval and a Prefect rerun. That is a different product with different liability: cross-system context, blast radius, approvals, rollback and receipts across vendors. It is the product Data Workers is, built on the Hex workspace your teams already use.
Every tool owns a slice. Data Workers covers the whole lifecycle
Hex owns one slice outright: exploring data and sharing answers through projects, apps and Threads. 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.
| Stage | Data Workers | Hex | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 6 | Semantic models (built in the Modeling Workbench or synced from dbt MetricFlow, Cube and Snowflake Semantic Views), endorsed data and Context Studio give Hex's agents trusted context. Data Workers keeps one governed context graph across every platform, joined to lineage, quality and owners. |
| Analytics & Insights | 8 | 9 | Hex's home stage: SQL and Python projects, published apps, Threads (GA, also in Slack) and the Notebook Agent put analysts, data scientists and business users on the same answers. Data Workers answers through governed definitions and makes sure the tables under them are right. |
| Data Quality | 8 | 4 | Analysts can check results in cells, and Threads favour endorsed data. Data Workers checks the tables under every app after each load for nulls, duplicate keys and row counts, and holds headline values to a baseline. |
| Observability & Incidents | 8.5 | 3 | Scheduled runs and alerts tell a project's owner when a value or run changes. Data Workers traces a wrong chart back to the release, sync or model that caused it, proposes the fix and verifies it. |
| Pipelines & Ingestion | 8.5 | 4 | Hex runs projects on a schedule or through its API, and Airflow and Dagster can trigger them. Data Workers queues approved dbt and orchestrator reruns for the pipelines that feed the warehouse. |
| Schema & Migration | 8 | 3 | Semantic projects move through the CLI and the ingest API into version control. Data Workers reviews dbt changes and their manifest diff and scopes the blast radius across models and declared apps before merge. |
| Governance & Access | 8.5 | 5 | Workspace roles, project permissions and Endorsed Mode govern who sees and edits what in Hex. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 5 | SSO, audit logs, BYOK for model providers and sensitive data connections (blocked from MCP by default) protect Hex itself. Data Workers leaves a receipt on every data change and proposes masking for the owner to apply. |
| Cost / FinOps | 8 | 3 | Shared result caching cuts repeat warehouse queries from Hex. Data Workers reads Snowflake spend down to the dbt model and BigQuery spend as an account total from the Jobs API. |
| MLOps & Models | 7.5 | 6 | Data scientists build and test models in Python notebooks next to the SQL. Data Workers checks the training and feature tables those notebooks read; their owners retrain. |
How Hex and Data Workers work together
Your people stay where they are: projects and apps for analysts, Threads in Hex and Slack for the business, Claude Code or Cursor for engineers, Slack for alerts and approval requests. Spellbook Data Catalog (in preview) is where the data team looks: 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, and the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember).
How Hex enters the picture. Data Workers connects to Hex over its API or MCP server today. Apps and semantic models enter the blast radius as notes your team records in the context graph, like the forecast project above; when a fix goes through a pull request, change review's lineage diff also reads any dbt exposures you declare. Data Workers writes nothing to Hex: cell edits, app reruns, cache choices and semantic model syncs stay with Hex's owners. Data Workers + Hex and ThoughtSpot walks through a second incident with both tools side by side.
What Data Workers checks under each app. run_quality_check runs nulls, uniqueness on id columns and minimum row counts on Snowflake and Postgres, and on BigQuery with a service-account key; get_quality_score rolls them up. monitor_metrics holds the values your team records, such as paid seats from fct_seats or rows landed per hour, against their baseline. explain_table returns a table's definition, lineage, documentation and trust score. trace_cross_platform_lineage and blast_radius_analysis follow a table to its source and to every model and declared app; 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. On BigQuery, give Data Workers a service-account key for the project so the table checks run live. The Hex MCP server can sit next to Data Workers in the same client for your own work; Data Workers' agents never call it. For users who should only ask and read, the Explorer role reaches its knowledge tools, not the project editing tools.
// Example: .mcp.json for Claude Code. The hex entry is your team's own
// connection to the Hex MCP server (beta); Data Workers does not call it.
{
"mcpServers": {
"hex": {
"type": "http",
"url": "https://app.hex.tech/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 your client's own command (for example /mcp in Claude Code). A data scientist can then ask whether everything under the seat forecast is healthy and get its cells from Hex and the lineage, checks and open incidents from Data Workers in one answer.
Where fixes go. Data Workers proposes the change as a diff for the owner to merge, usually a dbt model 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; ingestion syncs and Hex app reruns stay with their owners.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Connected, not acting. Analysts chase wrong charts by hand.
- •L1 observe. Data Workers checks the tables under your apps 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 queuing the downstream dbt rerun 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 how approvals work for AI data agents, autonomy levels L0 to L4 explained, is it safe to let AI agents change production data and where does our data go.
For the layers around Hex, see You're on the dbt Semantic Layer, You're on Prefect, You're on Airbyte and, for a BI suite next to Hex, You're on Looker. Background: ground LLM analytics in a semantic layer.
What changes for your team
Hex teams lose real time asking whether a moved chart is the query, the metric or the data. With Data Workers next to Hex, these jobs run on autopilot at the level you set.
- •Incidents. A chart that moved overnight arrives with the cause, the blast radius and a fix ready to approve.
- •Data quality. The tables under every published app are checked after each load for nulls, duplicate keys and row counts.
- •Cloud spend. Snowflake spend is read down to the dbt model and BigQuery spend as an account total, with warehouse settings drafted for the owner to apply.
- •Access. A request for a restricted table becomes a scoped, time-boxed grant proposal the data owner approves.
- •Audits. Every data change behind a Hex number carries the approver, the diff, the checks and the undo step.
- •Migrations. When the warehouse under Hex moves, tables move in approved waves with parity checks tracked.
Fewer "is this right?" messages reach your analysts, and the ones that do arrive with an incident link and a cause.
Keep Hex, or consolidate?
Keep Hex 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 Hex: the projects, the apps your leadership reads and the Threads your business asks first belong there, and Hex fits existing buying paths (it is offered on the Snowflake and AWS marketplaces). What teams consolidate is the tooling around it: a separate data-quality tool, a "sanity check" notebook nobody owns, and a spreadsheet of which app reads which table. If you are weighing building this yourself on the Hex MCP server and your warehouse's, 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. What is an agentic data platform covers where that work sits.
The case for your CFO
The outcome: the numbers leadership reads in Hex apps and hears from Threads stay right, and when something upstream breaks, the fix is approved before the review meeting.
The risk story: Data Workers changes nothing in Hex. It checks the tables under each app and proposes upstream fixes as diffs; nothing runs until the named owner approves. Every change is verified and 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: Threads turned your semantic models into an answer desk for the whole company, in Slack. A broken table now reaches a VP as a confident explanation before any analyst sees the chart.
The first win: the app your leadership reads every week, every table under it checked after each load and its headline numbers recorded. What stays the same: your Hex projects, apps and semantic models, your Airbyte, dbt and Prefect, and your review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Hex stays where our analysts answer questions; Data Workers makes sure the data behind every answer is right, and a named owner approves every fix with a receipt."
Getting started
Start with a pilot. Pick the Hex app behind a number people act on, such as the weekly business review, connect Data Workers read-only to the warehouse (a service-account key on BigQuery), dbt and your orchestrator, record the app in the context graph, and let Data Workers check every table under it for a few weeks before 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 Hex projects or rerun our apps? No. It writes nothing to Hex. Cell edits, app reruns and the choice between cached and fresh results stay with your Hex owners.
We use endorsed data and semantic models. Why add this? Keep them. They tell Threads which table and definition to use. Data Workers checks whether last night's load left that table right, traces a failure to its cause and carries the fix through approval and verification.
A Thread gave a wrong answer. Can Data Workers tell why? Usually the Thread was faithful to the semantic model and the data underneath was wrong. Data Workers traces the model's tables back to the release, sync or dbt model that changed, and the receipt records cause and fix.
Do Data Workers' agents use the Hex MCP server? No. Your team can run it side by side in the same client. Data Workers relies on its own warehouse, dbt and orchestrator connections.
What about our data scientists' Python notebooks? The checks protect the tables those notebooks read. A forecast project recorded in the context graph shows up in the blast radius of any change to its tables, and its owner hears about the incident.
Which warehouses does this cover? The table checks run natively on Snowflake and Postgres, and on BigQuery with a service-account key. Across 50+ connectors, Data Workers also works natively with dbt, Airflow, Dagster and Prefect; what integrations Data Workers supports lists what each one reads and changes.
Sources
- •Hex, AI overview (Notebook Agent, Threads, Chat With App Agent, Modeling Agent and Context Studio GA; Generative Apps Beta; features formerly named under an older product name; Notebook Agent intended for technical users who audit its code), https://learn.hex.tech/docs/getting-started/ai-overview (checked Oct 3, 2026)
- •Hex, Threads (semantic models and endorsed data prioritized; Endorsed Mode; Explorer role; Slack integration), https://learn.hex.tech/docs/explore-data/threads (checked Oct 3, 2026)
- •Hex, Introduction to semantic models (Modeling Workbench; import from Cube, dbt MetricFlow, Snowflake Semantic Views), https://learn.hex.tech/docs/connect-to-data/semantic-models/intro-to-semantic-models (checked Oct 3, 2026)
- •Hex, MCP server (beta; Team and Enterprise;
https://app.hex.tech/mcp; knowledge tools for Explorer and project editing tools for Editor; edits apply to the draft version; sensitive connections blocked from MCP by default), https://learn.hex.tech/docs/administration/mcp-server (checked Oct 3, 2026) - •Hex, API reference (RunProject
updatePublishedResultsdefault false anduseCachedSqlResultsdefault true; GetProjectRuns; semantic project ingest), https://learn.hex.tech/docs/api/api-reference (checked Oct 3, 2026) - •Hex, Changelog (Sep 15, 2026: agent without approval pauses, chat agents build Hex projects over MCP, eval suites from the CLI; Sep 23: chat with Generative Apps; Sep 29: agent activity classifications in Context Studio; Aug 18: semantic projects via CLI), https://learn.hex.tech/changelog (checked Oct 3, 2026)
- •Hex, Pricing (Airflow, Dagster and dbt integrations; REST APIs; AWS Marketplace and Snowflake Marketplace offerings), https://hex.tech/pricing/ (checked Oct 3, 2026)
- •Hex, Snowflake integration (purchase through the Snowflake Marketplace with Snowflake credits; Semantic Views sync), https://hex.tech/integrations/snowflake/ (checked Oct 3, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (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)