Onboarding with zero migration
Most platform rollouts begin with a data copy, a new warehouse or a quarter of integration work. Data Workers connects read-only to the stack you already run, spends the first week watching and suggesting, and widens only when your owners say so. Nothing migrates.
Before and after
| Today | With Data Workers |
|---|---|
| A migration or integration project before the first benefit | Agents connect to the warehouse, catalog, orchestrator and BI tools you already run |
| Data copied into a new platform for the pilot | Nothing leaves your stack; agents work where the data lives |
| A security review of an agent that can write | Read-only credentials first, so the review covers access that cannot change anything |
| Missing grants found one failed attempt at a time | Each connection tested, with exactly what is missing listed |
| Value promised after a long rollout | A first week of watching and suggesting, so the team sees the findings before anything changes |
Most platform projects stall before they start: the vendor needs a data copy, the security review waits on write access, and the team that owns the stack is asked to rebuild it first. Starting read-only removes all three. The access model is covered in read-only roles for AI data agents, and the systems the agents connect to are listed in what integrations Data Workers supports.
How it works
1. Connect read-only to what you run
You give the agents read-only credentials for the warehouse, dbt, orchestrator, catalog and BI tools you already use, 50+ connectors in all. The Connectors Agent (get_connector_status) tests each connection and says exactly what is missing, so gaps surface before the pilot rather than as failed attempts later. Single sign-on and user provisioning (SAML and SCIM) are supported for enterprise rollout. See Inside the Connectors Agent, and for Snowflake the production setup guide.
2. Watch and learn the estate
The Data Context & Catalog Agent (explain_table, check_freshness) works out what each table means, who owns it and whether it is fresh. The Quality Monitoring Agent (run_quality_check) learns each table's normal behaviour. A week-one baseline records where you started, so progress is measured against it, not against memory.
3. Suggest, then widen on evidence
Findings arrive as proposals for a named approver through request_governance_review, each showing the full change, what it would affect and how to undo it. Nothing runs without approval. Owners raise a domain's autonomy only when its own review record supports it, then bring in the next domain. The rails are the ones in data agent production safety.
The impact metrics we move
- •Connections checked, missing access listed: from about 1 day to 1 h
- •One domain mapped (tables, owners, lineage): from about 2 weeks to 8 h
- •Baseline on key tables: from about 1 week to 4 h
Where teams start
- •One warehouse, one domain. Snowflake, Databricks, BigQuery or Redshift, starting with the domain whose incidents cost the most.
- •dbt and the orchestrator. Airflow, Dagster, Prefect or dbt Cloud runs and tests read first, so failures are seen in context.
- •The catalog you already run. DataHub, OpenMetadata or Unity Catalog stay in place; the agents read alongside them.
- •BI dashboards. Looker or Tableau connected to show which dashboards a change would touch.
- •Alerts where the team already works. Findings and status sent to Slack, PagerDuty or ServiceNow.
What powers it
The Connectors Agent tests each connection, the Data Context & Catalog Agent and the Data Context Wizard supply what every table means and which source is trusted, and the Quality Monitoring Agent learns normal behaviour. The Data Access & Governance Agent routes every proposal to its approver. Autopilot Routines then keep the upkeep running on a schedule, and the Autonomous Data-Conductor shows what every agent is doing and what waits for approval. The Spellbook Data Catalog (in preview) works alongside the catalog you run. This shows up in AI-ready data teams, in audit logging and as the start of agents in your data warehouse.
The climb: from assisted to autonomous to agentic
Agents start by watching and suggesting, and each domain moves up only on its own track record. L0 to L2 run today; L3 and L4 are where a domain can go on evidence. See our thesis.
The pilot
- •Scope. One domain on the stack you already run, in a 6 to 12 week pilot.
- •First week. Agents start by watching and suggesting: they test the connections, learn the domain and show what they would propose, with a week-one baseline. Nothing changes.
- •By week two. Routine upkeep runs on its own schedule; anything sensitive stays with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Connections checked, missing access listed: from about 1 day to 1 h
- •One domain mapped (tables, owners, lineage): from about 2 weeks to 8 h
- •Baseline on key tables: from about 1 week to 4 h
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Do we have to move or copy our data? No. The agents connect to the systems you already run and work where the data lives.
What access do the agents need? Read-only credentials to start. They test each connection and list exactly what is missing; write access comes later, per domain, through an approval path.
What if an agent is wrong? Every proposal shows the full change, what it affects and how to undo it, and a named approver decides. If people start reverting an agent's changes, that domain pauses itself.
Can we try it before a full contract? Yes. The pilot is the trial: one domain, read-only access first, and the impact metrics reviewed against your own baseline at day 30.
What stays with our team? Which domain to start with, the access grants and every approval. The agents take the checking, mapping and drafting.