You're on Matillion: Your Team and Maia's Agents Build and Run the Pipelines. Data Workers Owns Whether What They Deliver Is Right
Matillion is where your team, and now Maia Team's agents, build and run ELT pipelines. Data Workers catches the run that succeeded with wrong values and gets the fix approved.
Your data engineers build in Designer. They drop components on the canvas, wire orchestration pipelines that load from 150+ connectors, shape the data in transformation pipelines that push down into Snowflake, Databricks, BigQuery or Redshift, and publish to schedules. That platform is now called Maia Foundation (formerly the Data Productivity Cloud). On top of it sits Maia Team, Matillion's agents that plan, build, test and fix pipelines: an engineer gives it a task in Mission Control, approves its tool permissions in chat and reviews what it commits. Context Engine knowledge graphs teach it your business terms; Mission Control and Context Engine have been generally available since July 29, 2026. When a scheduled run fails, Maia writes a root cause analysis, Impact stream shows what sits downstream, and Fix with Maia proposes the repair. Many teams still run Matillion ETL, which Matillion says is fully supported, with a migration path to Maia when they choose.
That covers building pipelines and fixing the ones that fail. The costly incidents on Matillion are the runs that succeed: every component green, every row loaded, and a number finance acts on is wrong because a source system changed shape. Data Workers checks what your pipelines deliver, catches the schema change the night it lands, traces it to the dashboards it reaches, proposes the fix to each owner and verifies the result after they approve.
Key takeaways
- •Matillion keeps its job. Designer, pipelines, schedules, Maia Team and Mission Control stay as they are. Data Workers works on what the pipelines deliver and the systems around them.
- •Successful runs get checked too. Schema changes, null spikes and the business totals your team records are checked after each load, so a run that succeeded with wrong values becomes a diagnosed incident the same night.
- •Maia's agents can build the fix. Data Workers hands over a diagnosis and a proposed change; your engineer turns it into a Maia Team task, reviews the result and publishes.
- •Connected over Matillion's API and MCP server today. Runs and steps sit beside native checks on the warehouse. Runs and publishes stay with your engineers, under Matillion's own roles.
- •Autonomy is set per domain. Start at L1 observe, move to L2 propose, and let a narrow class of work reach L3 act reversibly once the record supports it.
Matillion builds and runs the pipelines. Data Workers owns whether what they deliver is right.
Matillion loads, transforms and schedules, and Maia Team does a growing share of the building. Owning the outcome is different work: noticing a wrong value while every run is green, finding the change in another team's system, sizing the damage, getting each owner's approval and proving the number. Here is one night at a mid-size industrial manufacturer during month-end close. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Wed 18:20 | Coupa | For the new fiscal year, the procurement admin moves invoice coding to a segmented chart of accounts: account_segment_entity, account_segment_dept and account_segment_project. The single account_code field stops being filled on new invoice lines |
| Thu 01:30 | Matillion (Maia Foundation) | The orchestration pipeline coupa_invoices_load, built on a custom connector Maia Team made for Coupa's API, loads 2,940 new invoice lines worth $4.26M into BigQuery raw_coupa.invoice_lines. The three new columns land; account_code is empty on every new line. The run succeeds |
| 01:44 | Data Workers + BigQuery | run_quality_check on the BigQuery table finds account_code null on 61% of the day's rows, past the 1% null threshold the team set. An incident opens |
| 01:46 | Data Workers | The team's context-graph notes put account_code on the join in the transformation pipeline spend_gold to ref.gl_account_map. Blast radius: mart.fct_spend_vs_budget, the Omni "Spend vs budget" dashboard read at the 09:00 close review, and the accrual extract FP&A pulls at 10:00 |
| 01:47 | Slack | Data Workers sends the incident to the spend_gold owner and the Coupa admin, and tells the FP&A channel to hold spend-vs-budget numbers and the accrual extract until they are verified |
| 03:00 | Matillion (Maia Foundation) | spend_gold runs on schedule. Lines with no account_code fall to cost center UNALLOCATED. The run succeeds |
| 03:12 | Data Workers | Unallocated spend, a total the team records each night with monitor_metrics, jumps from $41K to $4.3M and breaks its baseline. The predicted damage is now in the mart |
| 07:30 | Spellbook | The pipeline owner and the Coupa admin review the proposal: in spend_gold, derive the legacy account from the three segments through finance's published segment map, keep the fallback for true gaps, and add an assertion that stops the pipeline when unallocated spend passes 1% of the day's total. The admin confirms the Coupa change is permanent. Both approve |
| 07:38 | Maia Team | The engineer creates a Mission Control task from the approved proposal. Maia Team asks permission to sample the raw table, she grants it, and it edits spend_gold and validates it |
| 08:05 | Matillion (Maia Foundation) | The engineer reviews the diff, commits and publishes, then runs spend_gold from her own Claude Code session with the Matillion MCP server's execute-pipeline. The run completes at 08:19 |
| 08:22 | Data Workers + BigQuery | Data Workers verifies: unallocated spend is back to $39K and the mart total matches the Coupa invoice total the team records each night. It writes the receipt and posts the resolution in Slack |
| 09:00 | Omni | The close review reads spend vs budget with every cost center charged correctly. The accrual goes out on time |
Every part of Matillion did its job, and so did procurement. The load succeeded because nothing failed; the transform succeeded because a fallback did what it was built to do. Maia's root cause analysis and Impact stream start from a failed run, and there was none. The break showed up as values, not errors. Data Workers caught it at 01:44, after the load and before the transform built the damage into the mart.
| Job | What Matillion does | What Data Workers does |
|---|---|---|
| Building | Designer, components, custom connectors, and Maia Team building and refactoring pipelines | Reads pipelines, runs and lineage into one context graph with the sources, the warehouse and BI |
| Testing | Test pipelines, Test Execution tools and its data quality framework's detect, reject and audit patterns | Checks schema, nulls and the totals your team records after every load |
| Running | Schedules, runners, and execution history with step-level detail | Reads run status and warns downstream readers while an incident is open |
| Diagnosing | Root cause analysis and Impact stream for failed runs; runtime anomaly flags | Diagnoses across systems: the Coupa change, the Matillion join, the BigQuery mart and the Omni dashboard |
| Fixing | Fix with Maia for failed scheduled runs; Maia Team tasks from Mission Control | Proposes the fix with its evidence; your engineer has Maia Team build it, publishes and runs it, and Data Workers verifies |
| The record | Git commits, publishes, audit events and task history | A receipt: cause, diff, approvers, run, verification and undo, in Spellbook and the audit trail |
Why doesn't Matillion just do this itself?
Because Matillion is built to make pipelines fast to build, faithful to run and easy to repair, and Maia follows the same scope on purpose. Maia Team builds, refactors, tests, explains and fixes Matillion pipelines, and its documented limits keep the risky steps with people: it can't schedule or publish pipelines, and its Git work stops at committing and pushing to a branch. Its troubleshooting starts from a failed run (it is good at tracing that failure back to a source schema change), its anomaly flags watch how long runs take, and Impact stream maps what a failure reaches. That is the right design for a pipeline platform: Maia should be excellent at Matillion's own objects, and the people who own production should approve what it changes.
The MCP server keeps the same line. It starts read-only by default (READ_ONLY_TOOLS is true), and Matillion's docs warn that write tools can be destructive and must be switched on deliberately. Even then, every tool acts on Matillion: executions, schedules, artifacts, environments and Maia Team tasks.
The incident above sits outside that scope by design: a field retired in Coupa, a run that succeeded, and damage in a BigQuery mart and an Omni dashboard Matillion does not own. Owning it means context across those systems, routing each fix to its owner, scoping blast radius, keeping an undo and answering for changes across tools. That is a different product with a different liability: Data Workers. How we keep that safe in production is in is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
Matillion owns building and running ELT pipelines, with more depth than a general platform would bring. 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 Matillion pipelines already there. For the category view, read what is an agentic data platform.
| Stage | Data Workers | Matillion | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Lineage inside Maia Foundation and Context Engine knowledge graphs (GA since July 29, 2026) that teach Maia Team your business terms. Data Workers keeps one governed context graph across the sources, the warehouse and BI. |
| Analytics & Insights | 8 | 3 | Maia Team can query the warehouse and chart results in chat while it builds. Data Workers answers data questions from governed definitions, with lineage behind every number. |
| Data Quality | 8 | 4 | Test pipelines, Test Execution tools and the detect, reject and audit patterns of its data quality framework. Data Workers checks nulls and volume on what each pipeline lands and holds lateness and the totals your team records to their baselines. |
| Observability & Incidents | 8.5 | 5 | Root cause analysis and Impact stream on failed runs, plus runtime anomaly flags. Data Workers diagnoses incidents across systems, including runs that succeeded with wrong values. |
| Pipelines & Ingestion | 8.5 | 9 | Matillion's home stage: 150+ connectors, custom connectors, the Designer canvas, orchestration and transformation pipelines, schedules, and Maia Team to build them. Data Workers works through the runs your engineers publish. |
| Schema & Migration | 8 | 7 | The Migration Agent converts legacy ETL pipelines, and Maia Team adjusts components to source changes. Data Workers catches the schema change as it lands and plans migrations in approved waves. |
| Governance & Access | 8.5 | 4 | Account, project and environment roles, plus tool permissions approved in chat. Data Workers routes every production change to a named approver. |
| Security & Privacy | 8 | 4 | Secret references and runners in your cloud protect the pipelines. 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 | 5 | Credit consumption by pipeline, readable over the MCP server. Data Workers attributes Snowflake credits down to the model, reads BigQuery spend from the Jobs API and drafts each fix for the owner. |
| MLOps & Models | 7.5 | 2 | Pipelines can call AI components; models are not watched. Data Workers keeps the data under your models fresh and correct. |
How Matillion and Data Workers work together
Data Workers connects to Matillion over its API and MCP server today. Matillion's pipeline executions and step status sit in one context graph with the warehouse tables the pipelines land, the sources underneath and the BI downstream. BigQuery connects natively (as do Snowflake and Databricks), so schema and null checks run straight against the landed tables; Coupa and Omni connect over their APIs. Matillion keeps the build and the run. Data Workers does not start, pause or rerun Matillion pipelines or ingestion loads; your engineers publish and run them under Matillion's account, project and environment roles, and Data Workers verifies the result.
Engineers can run both side by side in one client. Matillion's server answers "what ran, what failed, what did it cost"; Data Workers answers "what did that run do to the data, what does it reach, and what's the fix". Matillion's server runs locally with npx and your API client ID and secret; the Data Workers side follows the documented client setup.
# Example: Matillion MCP server plus Data Workers agents in Claude Code
# Matillion MCP server is read-only by default; add --env READ_ONLY_TOOLS=false
# only for engineers who run pipelines or manage Maia Team tasks
claude mcp add matillion \
--env MATILLION_CLIENT_ID="<your-client-id>" \
--env MATILLION_CLIENT_SECRET="<your-client-secret>" \
--env MATILLION_REGION="us" \
-- npx -y @matillion/mcp-server
# Data Workers agents, from a clone of the open-source repo
claude mcp add dw-schema -- /path/to/dataworkers-claw-community/start-agent.sh dw-schema
claude mcp add dw-quality -- /path/to/dataworkers-claw-community/start-agent.sh dw-quality
claude mcp add dw-incidents -- /path/to/dataworkers-claw-community/start-agent.sh dw-incidents
claude mcp add dw-context-catalog -- /path/to/dataworkers-claw-community/start-agent.sh dw-context-catalog
claude mcp add dw-connectors -- /path/to/dataworkers-claw-community/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) finds the null spike; monitor_metrics (dw-incidents) watches unallocated spend and the Coupa invoice total; diagnose_incident classifies the incident; trace_cross_platform_lineage and blast_radius_analysis (dw-context-catalog) map what it reached; send_slack_alert (dw-connectors) tells FP&A to hold; create-agent-task and execute-pipeline on Matillion's server hand the work to Maia Team and run the fix under the engineer's own credentials; 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. More in where does our data go.
One incident, L0 to L4, set per domain:
- •L0 manual. A controller notices at the close review that $4.3M of spend has no cost center, after the accrual has gone out.
- •L1 observe. Data Workers flags the schema change and the null spike at 01:44 with the blast radius. Nothing changes; the morning starts from the answer.
- •L2 propose. Data Workers proposes the pipeline change and the assertion with their evidence. Nothing reaches production until the named owners approve; an unanswered request expires and escalates, never auto-grants.
- •L3 act reversibly. For a class with a clean record, such as telling FP&A to hold a dashboard while an incident is open, Data Workers acts under the standing approval your team set and sends anything outside it to a person.
- •L4 autonomous. For a scoped domain, Data Workers flags every downstream reader the moment a source changes shape, before the owners' fix lands.
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
Matillion and Maia Team give your engineers a fast way to build and repair pipelines. Data Workers takes the outcome work around them.
- •On-call starts from evidence. The schema change, the blast radius and a proposed fix sit in one place, ready to become a Maia Team task.
- •Other teams' changes stop being silent. A retired field in Coupa or a new value in an ERP shows up as a data effect, tied to the pipelines it touched.
- •Engineering, finance and the source owners share one record. Everyone sees the same incident and receipt in Spellbook Data Catalog (in preview).
For the schema side, see the Schema Evolution agent and how a BigQuery schema change reaches downstream dashboards. For on-call, see reducing data on-call burden with AI agents.
Keep Matillion, or consolidate?
Keep Matillion if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most Matillion teams the answer is keep it. What teams consolidate is the tooling around the pipelines: separate warehouse monitors, alert scripts, and runbooks that say "rerun the load and check the dashboard". If you are still on Matillion ETL, Matillion's migration path moves the jobs; Data Workers plans each wave with its parity checks, tracks them and holds the completion gate for your sign-off. If part of your estate lands through other tools, see you're on Fivetran and you're on Airbyte; for transformations in Coalesce, see you're on Coalesce. Native connectors are on the integrations page.
Weighing a build of your own on Matillion's MCP server? Read build it ourselves with Claude Code and MCP servers: connecting servers is the easy part.
The case for your CFO
The outcome. The numbers your Matillion pipelines deliver are right more often, and when a source change makes them wrong, it is caught the same night and corrected before the business acts. Above, that is the difference between a clean close and an accrual built on $4.3M of spend nobody could place.
The risk story. At L0 and L1, agents only read. At L2 they propose and a named person approves. At L3 they act on reversible changes inside the domains you open; L4 is a later choice per domain. Pipeline runs and publishes stay with your engineers. 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 how to undo it.
Why now. Maia Team means more pipelines built faster while every source keeps changing, so more runs succeed with wrong values.
What stays the same. Matillion, your pipelines, schedules, Maia Team, your warehouse and your on-call rota. Zero migration. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "Matillion and its agents build and run our pipelines; Data Workers checks what they deliver every night and gets the fix approved when a source system changes underneath them, so finance closes on the right number."
Getting started
Start with a pilot. Pick the Matillion pipelines that feed the numbers leaders act on, give Data Workers read access to the warehouse tables those pipelines land, record the totals that matter, and run at L1 for a few weeks. Then turn on L2 for one domain, and move a narrow class of actions to L3 once the receipts support it. 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 Matillion? Over Matillion's API and MCP server today, for pipeline executions and step status, plus native connections to the warehouse tables those pipelines land. Matillion, the warehouse, the sources and BI join one context graph.
Will Data Workers change our pipelines or run them? No. Fixes arrive as a proposal for the pipeline owner. Your engineer builds the change, often as a Maia Team task, then commits, publishes and runs it in Matillion. Data Workers never starts, pauses or reruns a Matillion pipeline or load; it verifies the result.
Maia already does root cause analysis. What does Data Workers add? Maia's root cause analysis, Fix with Maia and Impact stream are built for runs that fail, and they are good at it, including tracing a failure back to a source schema change. Data Workers covers runs that succeed with wrong values, traces the effect into the warehouse and BI, routes the fix to each owner and verifies the numbers afterwards.
Do Maia Team and Data Workers step on each other? No. Maia Team builds and fixes Matillion pipelines under your engineers' review. Data Workers decides whether what those pipelines deliver is right, and its proposals can become Maia Team tasks.
We still run Matillion ETL. Does this work? Yes. Matillion says Matillion ETL is fully supported, and Data Workers checks what its jobs land in the warehouse the same way. When you move to Maia, Data Workers plans the waves and holds the completion gate for your sign-off.
Where does our data go? The agents run in your infrastructure with your warehouse credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only.
Sources
- •Matillion homepage (Maia, Maia Foundation formerly Data Productivity Cloud, Matillion ETL "fully supported, actively maintained"), https://www.matillion.com/ (checked Oct 3, 2026)
- •Maia homepage (Mission Control, Context Engine, Foundation), https://www.maia.ai/ (checked Oct 3, 2026)
- •Maia docs, Maia product overview, https://docs.maia.ai/docs/guides/maia-overview.md (checked Oct 3, 2026)
- •Maia docs, Maia Team overview (capabilities and limitations), https://docs.maia.ai/docs/guides/maia-team-overview.md (checked Oct 3, 2026)
- •Maia docs, Mission Control overview, https://docs.maia.ai/docs/guides/mission-control.md (checked Oct 3, 2026)
- •Maia docs, Context Engine, https://docs.maia.ai/docs/guides/context-engine.md (checked Oct 3, 2026)
- •Maia docs, Troubleshoot pipelines with Maia Team, https://docs.maia.ai/docs/guides/troubleshoot-pipelines-with-maia-team.md (checked Oct 3, 2026)
- •Maia docs, Impact stream, https://docs.maia.ai/docs/guides/impact-stream.md (checked Oct 3, 2026)
- •Maia docs, Matillion data quality framework, https://docs.maia.ai/docs/guides/data-quality-framework.md (checked Oct 3, 2026)
- •Maia docs, Migrating from Matillion ETL to Maia, https://docs.maia.ai/docs/guides/migrating-from-matillion-etl.md (checked Oct 3, 2026)
- •Maia docs, Matillion's MCP server (tools, read-only default), https://docs.maia.ai/docs/api-reference/mcp-server.md (checked Oct 3, 2026)
- •Maia docs, 2026 changelog (Context Engine and Mission Control public preview May 28 and GA July 29, 2026; AI Agents MCP tools May 15, 2026; Test Execution tools June 10, 2026), https://docs.maia.ai/docs/changelog/2026-changelog.md (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)