You're on Teradata: It Runs Your Enterprise's Most Demanding Analytics. Data Workers Owns Whether What It Serves Is Right, in Place or Through a Move
Teradata runs the heaviest enterprise analytics and is building Tera for its estate. Data Workers keeps what Teradata serves right across feeds, schedulers and reports, behind approvals.
Your enterprise's heaviest numbers come out of Teradata. AMPs spread each table across the system, workload management keeps the morning reports ahead of ad hoc queries, and decades of BTEQ scripts and TPT jobs load the data every night. Teradata now sells this as the Teradata Autonomous Knowledge Platform, generally available since July 15, 2026: Teradata Cloud, its cloud deployment, with Active Compute and Elastic Compute; Teradata Factory on premises; and AI Studio, which since May 2026 includes ClearScape Analytics, alongside Enterprise Vector Store. DBAs live in DBQL and workload rules, developers in BTEQ and the scheduler, analysts in Tableau, MicroStrategy or Power BI.
The incidents that cost the most on Teradata finish with return code 0: the load succeeds, the script ends clean, and the number is still wrong because something upstream changed what a field means. Teradata runs the workload. Data Workers owns whether what it serves is right: it watches the metrics each load records, traces a bad number to its cause across the systems around Teradata, and hands the owner a fix and a run plan, whether the table stays on Teradata or is moving off it.
Key takeaways
- •Teradata keeps its job. The engine, workload rules, BTEQ and TPT jobs, AI Studio models and DBA controls stay as they are.
- •Return code 0 gets checked too. Your load jobs record the metrics that define "right", so a clean run with wrong data becomes a diagnosed incident before the morning reports.
- •Built on what surrounds Teradata. Airflow, Tableau, ServiceNow, Slack and Snowflake connect natively. Teradata itself connects over its API today, and your team's assistant can query it through the Teradata MCP Server next to Data Workers.
- •Changes go to a named owner. Script fixes arrive as a diff, cleanups as a statement the owner runs, reruns queue through your orchestrator after approval, and every step leaves a receipt.
- •The same loop runs a move. If part of the estate is moving to Snowflake, Data Workers translates Teradata SQL for review, plans each wave with its parity checks and holds the completion gate for the owner's sign-off.
Teradata runs the enterprise's most demanding analytics. Data Workers owns whether what it serves is right.
Teradata answers the query it is given, at scale, on schedule. Wrong data is a different job: notice it, connect it to a change Teradata never sees, size the damage, hold what would act on it, fix the cause, rerun and prove the result. Here is one night at an airline's operations data team. This is an illustration, not a customer case.
The stack: the departure control system (DCS) writes a nightly flight-leg extract; an Airflow 2 DAG, ops_flight_leg_nightly, loads it with TPT into Teradata Cloud and runs the BTEQ script bld_flight_daily.btq, which derives each leg's service date and builds OPS.FLIGHT_DAILY. Its last task records departures per service date and legs dated after the run date with monitor_metrics, a step the team added during the pilot. A second DAG scores a no-show model in-database into RM.NOSHOW_FCST; a 05:00 extract feeds the revenue management system, which sets overbooking limits. Tableau's "Network operations" workbook serves the 06:30 operations call. The DAGs send OpenLineage events to Marquez; incidents live in ServiceNow; approvals reach people in Slack.
| Time | System | What happens |
|---|---|---|
| Mon 23:30 | DCS | A vendor upgrade changes the extract: ACT_DEP_TS and ACT_ARR_TS now carry UTC with a Z suffix instead of station local time. Same names, same type. The release note went to the airport systems team |
| Tue 01:10 | Airflow + TPT | The DAG starts when the file lands. TPT loads Monday's 1,184 legs into OPS.FLIGHT_LEG_STG. Success |
| 01:40 | Airflow + Teradata | The BTEQ task casts ACT_DEP_TS to a date as the service date. Every leg departing after 17:00 Pacific or 20:00 Eastern now lands on Tuesday. Return code 0 |
| 01:55 | Data Workers | The metrics task records Monday departures at 921 against a baseline of 1,150 to 1,200, and 263 legs dated after the run date against a usual 0. Both are flagged and Data Workers opens an incident |
| 02:00 | Data Workers + Airflow | Data Workers reads the DAG run: every task green, the TPT row count normal. diagnose_incident points away from a lost load and toward a change in how dates are derived from the feed; get_incident_history finds no earlier case. blast_radius_analysis walks the context graph and Tableau: OPS.FLIGHT_DAILY feeds the 03:30 scoring DAG, RM.NOSHOW_FCST, the 05:00 extract job and the network operations workbook |
| 02:06 | ServiceNow + Slack | Data Workers opens a ServiceNow incident with the diagnosis and recommends pausing scoring and holding the extract. The approval request goes to the operations data owner in Slack, with the revenue management analyst and the airport systems owner copied |
| 02:12 | Teradata MCP Server | The engineer on call asks her assistant to compare staging with last Monday over the Teradata MCP Server (read-only profile). Departure hours have shifted by four to seven hours by station, and the raw values end in Z. The airport systems owner confirms the upgrade |
| 02:18 | Airflow + revenue management | The engineer pauses the scoring DAG; the analyst holds the extract |
| 02:30 | Spellbook | The owner reviews the proposal: a diff for bld_flight_daily.btq that converts each timestamp to station local time from REF.STATION before deriving the date, with a guard that stops the task on an offset mismatch; a cleanup statement that removes the 263 misdated rows by load ID; and a run plan. She approves |
| 02:44 | Git + Teradata | The engineer commits the script change and runs the approved cleanup in BTEQ |
| 02:50 | Data Workers + Airflow | Data Workers queues the approved rerun of ops_flight_leg_nightly with trigger_airflow_dag and reads the run's status |
| 03:25 | Data Workers | The run succeeds. The metrics task records 1,184 Monday departures, inside the band, and 0 legs dated after the run date |
| 03:35 | Airflow | The on-call unpauses scoring; RM.NOSHOW_FCST rebuilds by 04:10 |
| 04:15 | Spellbook + ServiceNow | Data Workers writes the receipt (cause, approvals, diff, cleanup and who ran it, rerun, checks, undo), linked from the ServiceNow incident, which the service desk resolves. The approved fact "DCS leg times are UTC" lands in the Context Wizard graph |
| 05:00 | Revenue management + Tableau | The analyst releases the extract on corrected forecasts. The 06:30 call sees every Monday departure |
Every system did its job. Catching the problem took knowledge no engine was built to hold: how many legs a Monday normally has, and which forecast turns those legs into overbooking limits before dawn.
| Job | What Teradata does | What Data Workers does |
|---|---|---|
| The run | Loads with TPT, transforms with BTEQ, scores models in-database, answers queries under workload management | Reads the scheduler's runs and the metrics each load records |
| The signal | DBQL, workload rules and system health tell the DBA how the engine is doing | Metrics the team defines, checked against their baselines after every load, tell the owner whether the data is right |
| The diagnosis | Query logs show what ran and how long it took | Joins the metric, the DAG run and the lineage into one cause, with the blast radius across models, extracts and reports |
| The fix | Runs whatever scripts and statements the team deploys | Proposes the script change as a diff and the cleanup as a statement for the owner to approve and run |
| The rerun | Executes the jobs the scheduler sends | Queues the approved rerun through Airflow and reads its status |
| The proof | DBQL keeps the query history, with the MCP server's query band on every call | Re-checks the load metrics and writes a receipt: what changed, who approved it, how it was checked, how to undo it |
Why doesn't Teradata just do this itself?
Because Teradata is built to run the most demanding workload fast, governed and at a predictable cost, and it does that exceptionally well. Its unit is the query and the workload. It knows bld_flight_daily.btq finished at 01:40 with return code 0; it does not know that a Monday should have about 1,180 departures.
Teradata's AI is ambitious. AI Studio brings in-database analytics, ModelOps, Enterprise Vector Store and Enterprise MCP, which connects agents to Teradata databases with governance, monitoring and access control. The open-source Teradata MCP Server ships tool profiles, query banding and DBQL tracing on every call, and a Guard Mode that confirms destructive backup and security operations. On September 22, 2026, Teradata announced Tera as an "agentic coworker for enterprise data work": Platform Agents for workload tuning, compute sizing, telemetry and FinOps, Analytics Agents for SQL, Python and query optimization, and a Tera Context Engine that Teradata describes as vendor-neutral and not limited to Teradata-managed data. Teradata says the Context Engine, Tera Harness and Agent Skills will be available in Q4 2026. It is a serious plan, centred on the Teradata platform.
Owning whether a number is right across a DCS feed, Airflow, Teradata, a model, an extract and Tableau is a specific job: metrics that define "right", blast-radius scoping, approvals that name a person, a recorded undo and receipts an auditor can read, running today across every system around the engine. An engine vendor that rewrote other teams' scripts or changed data feeding another vendor's system would take on liability it was never designed to carry, and a team moving off Teradata wants an operating layer that sits with neither engine. That 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
Teradata owns running the enterprise's heaviest analytics. 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 Teradata estate already there.
| Stage | Data Workers | Teradata | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 6 | The data dictionary, DBQL and the MCP server's semantic layer describe what lives in Teradata. Data Workers keeps one governed context graph across Teradata and every system around it. |
| Analytics & Insights | 8 | 9 | Teradata's home stage: massively parallel SQL, workload management and in-database analytics for the enterprise's most demanding queries. Data Workers answers data questions from governed definitions on top. |
| Data Quality | 8 | 5 | In-database functions and the MCP server's quality tools profile a table on request. Data Workers checks the metrics your loads record against their baselines after every run and opens the incident. |
| Observability & Incidents | 8.5 | 4 | DBQL and workload management watch the engine, not the business number. Data Workers diagnoses the data incident across the feed, the scheduler and the reports, and verifies the fix. |
| Pipelines & Ingestion | 8.5 | 5 | TPT and BTEQ load and transform data, and Elastic Compute reads Iceberg and Delta tables; the schedule usually lives in Airflow or Control-M. Data Workers queues the approved rerun through the orchestrator. |
| Schema & Migration | 8 | 4 | Teradata runs the schema it is given, and moving off it is not its job. Data Workers translates Teradata SQL for Snowflake and plans moves off Teradata in approved waves. |
| Governance & Access | 8.5 | 6 | Roles, access rights and row-level security govern who reads what inside Teradata. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 7 | Mature engine security: encryption, identity integration, query banding and DBQL audit. Data Workers leaves a receipt on every data change across systems. |
| Cost / FinOps | 8 | 5 | Fixed plus Flex pricing and workload management shape spend on Teradata Cloud. Data Workers traces Snowflake credits to the dbt model on the side of the estate that moved. |
| MLOps & Models | 7.5 | 6 | AI Studio brings in-database ModelOps, the Enterprise Feature Store and Enterprise Vector Store. Data Workers keeps the data under those models healthy. |
How Teradata and Data Workers work together
Data Workers doesn't need to sit inside Teradata to own this job. It reads the systems around it natively: Airflow (DAG runs and task instances), Tableau (read), ServiceNow, Slack, GitHub pull request review and Snowflake; the full list is on Data Workers integrations. Your load jobs record the metrics that define "right" with monitor_metrics, computed by your own SQL inside Teradata, and Teradata connects over its API today where you want more. Scripts, statements and workload rules stay with your team. For agent access, see read-only warehouse access for LLM agents.
Analysts and DBAs can run the Teradata MCP Server and the Data Workers agents side by side in one assistant: Teradata's server answers "profile this table"; Data Workers answers "what did last night's load do to the numbers, and what's the fix". The eda profile leaves out the write-query tools, every call carries a query band and DBQL records it, so your DBAs see exactly what the assistant asked. The Data Workers side follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry to your client.
// Example: Teradata MCP Server (read profile) plus Data Workers agents in one client config
// (Claude Desktop-style mcpServers block; Teradata settings follow the teradata-mcp-server README)
{
"mcpServers": {
"teradata": {
"command": "uvx",
"args": ["teradata-mcp-server", "--profile", "eda"],
"env": { "DATABASE_URI": "teradata://<READONLY_USER>:<PASSWORD>@<HOST_URL>:1025/<READONLY_USER>" }
},
"dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
"dw-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"] },
"dw-connectors": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-connectors"] }
}
}List the tools with your client's own command (for example /mcp in Claude Code). In this incident: monitor_metrics, diagnose_incident and get_incident_history (dw-incidents); blast_radius_analysis and trace_cross_platform_lineage (dw-context-catalog); and trigger_airflow_dag and create_servicenow_ticket (dw-connectors).
Through a move. Many Teradata estates run next to Snowflake during a long migration. The Data Migration agent translates Teradata SQL from BTEQ scripts and views into Snowflake SQL for review, annotating low-confidence constructs. It plans each wave with its parity checks from the object inventory your team exports, proposes the comparison queries your team runs, tracks the results and holds the completion gate for the owner's sign-off, reading Snowflake natively. See Data Workers on Snowflake and tools that automate Teradata and Informatica migrations.
In production the agents run in your infrastructure and hold the 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. Revenue management asks at 09:00 why evening flights oversold; two teams spend the morning on it.
- •L1 observe. Data Workers flags the departure count at 01:55 with the likely cause and blast radius. Nothing changes.
- •L2 propose. Data Workers proposes the diff, cleanup, run plan and holds. Nothing reaches production until the named owner approves.
- •L3 act reversibly. For a class with a clean record, Data Workers carries out reversible steps such as queuing the rerun, verifies them and sends any failed check to a person.
- •L4 autonomous. For a scoped domain, the fix is waiting for the owner before the first downstream job reads the table.
More in who owns the agents, how approvals work and autonomy levels L0 to L4.
What changes for your team
- •The DBA stops being the first suspect. A clean run with a wrong number arrives with its upstream cause, so nobody asks the DBAs to prove the engine innocent.
- •Forecasts and extracts get a guard. When a model, extract or regulatory feed reads a table that just went wrong, the hold is recommended before it runs.
- •Operations, platform and business owners share one record. Everyone sees the same receipt in Spellbook Data Catalog (in preview), linked from the ServiceNow incident.
Keep Teradata, or consolidate?
Keep Teradata if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
The engine is your platform decision, and Data Workers supports it either way. Teams that keep Teradata consolidate the tooling around it: a separate observability product, check scripts copied into every BTEQ job, runbooks that say "rerun and ask the business". Teams moving to Snowflake run each wave through Data Workers. Where Airflow, Control-M or Informatica schedule and load Teradata, see you're on Airflow, you're on Control-M and you're on Informatica PowerCenter; for the system of record upstream, see you're on Oracle.
Weighing a build on the Teradata MCP Server and a coding agent? Running SQL is the easy part; context across systems, approvals, undo and receipts are the work. See build it ourselves with Claude Code and MCP servers.
The case for your CFO
The outcome. When a Teradata load delivers a wrong number to a forecast, a regulatory report or the morning call, it is caught the same night and corrected before anyone acts on it.
The risk story. At L0 and L1, agents only read. At L2 a named person approves each proposal; an unanswered request expires and escalates, never auto-grants. L3 acts on reversible changes inside the domains you open; L4 is a later choice. Cleanups stay with the owner. 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. Every engine is inviting agents in through MCP and its own assistant, and most Teradata estates now sit next to a cloud warehouse. More engines and agents mean more nights that end with return code 0 and wrong data.
The first win. L1 on the BTEQ jobs that feed revenue, risk or operations reporting: a changed feed becomes a diagnosed incident before the first downstream job runs.
What stays the same. Teradata, your workload rules, BTEQ and TPT jobs, AI Studio models, scheduler, BI and on-call rota. Zero migration to start; a move you choose runs in approved waves with a design target of 4 to 8 weeks per migration instead of 6 to 12 months. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "Teradata keeps running our heaviest analytics; Data Workers makes sure the numbers it serves are right and gets problems fixed with our approval, whether a table stays on Teradata or moves."
Getting started
Start with a pilot. Pick the BTEQ jobs behind the numbers leaders and regulators read, give Data Workers read access to their scheduler and lineage, add a metrics step for the two or three values that define "right", and run at L1 for a few weeks. Then turn on L2 for one domain, and 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 Teradata? Data Workers works from the systems around Teradata, which it reads natively: the scheduler, lineage, BI, ITSM and the metrics your load jobs record. Teradata itself connects over its API today. For ad hoc questions inside Teradata, your team's assistant uses the Teradata MCP Server with a read-only profile, next to Data Workers.
Teradata announced Tera. Why add Data Workers? Tera is built to make the Teradata platform and the work around it more productive, and Teradata says its Context Engine, Harness and Agent Skills will be available in Q4 2026. Data Workers runs the operations job across the whole estate today: whether a load is right, what it reached, the fix, the approval and the receipt. Teams can use both.
Will Data Workers write to our Teradata system? No. Script changes arrive as a diff for the owner to merge, data cleanups arrive as a statement the owner approves and runs, and reruns queue through your orchestrator after approval. Your DBAs keep every grant.
Our BTEQ jobs return 0. How would Data Workers know the data is wrong? Your jobs record the metrics that define "right" after each load with monitor_metrics, such as departures per station, rows per business date or the share of a key category. A value outside its baseline opens an incident even when every job is green. Row-level business rules stay in your own tests.
We're moving part of Teradata to Snowflake. What does Data Workers do in the move? It translates Teradata SQL into Snowflake SQL for review, plans each wave with its parity checks and holds the completion gate until the owner signs off. Migration time of 4 to 8 weeks instead of 6 to 12 months is a design target.
Does our data leave our environment? Your data stays in your systems. The agents run in your infrastructure with your credentials and model key; the hosted Conductor sees workflow metadata only.
Sources
- •Teradata, "Teradata Transforms Tera into an Agentic Coworker; Introduces Tera Context Engine and Tera Harness" (Sep 22, 2026; Context Engine, Harness and Agent Skills "will be available in Q4 2026"), https://www.teradata.com/press-releases/2026/tera-an-agentic-coworker (checked Oct 3, 2026)
- •Teradata, "Teradata Autonomous Knowledge Platform Reaches General Availability Across Cloud and On-Premises" (Jul 15, 2026), https://www.teradata.com/press-releases/2026/teradata-autonomous-knowledge-platform-availability (checked Oct 3, 2026)
- •Teradata, Cloud ("Teradata Cloud, the cloud deployment of the Teradata Autonomous Knowledge Platform"; Active and Elastic Compute; Iceberg and Delta), https://www.teradata.com/platform/vantagecloud (checked Oct 3, 2026)
- •Teradata, analytics capabilities ("As of May 2026, ClearScape Analytics is now part of AI Studio"), https://www.teradata.com/platform/clearscape-analytics (checked Oct 3, 2026)
- •Teradata, AI Studio (Enterprise MCP, Tera, Enterprise Vector Store), https://www.teradata.com/platform/ai-studio (checked Oct 3, 2026)
- •Teradata, Enterprise Vector Store, https://www.teradata.com/platform/enterprise-vector-store (checked Oct 3, 2026)
- •Teradata MCP Server (README, profiles incl.
eda, Guard Mode, query banding and DBQL in the security guide; v0.2.8 released Sep 13, 2026), https://github.com/Teradata/teradata-mcp-server (checked Oct 3, 2026) - •Data Workers open-source repository (tool registrations in dw-incidents, dw-context-catalog, dw-connectors), 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)