Your Company Runs on Atlan. Now Let Data Workers Keep What It Shows True: A Guide for Data Leaders

Atlan is where your company finds, understands and governs its data. Data Workers is where the operations work behind it gets done: the fixes, the grants and the checks that keep every certificate honest. This guide is for the CDO or VP of data whose company standardized on Atlan.

Your organization already lives in Atlan. Every table, dbt model and dashboard is an asset with an owner and a certificate. The Business Graph glossary ties "net revenue" to the columns that compute it, domains and data products group assets by team, and classifications flow down lineage on their own. Data Quality Studio runs rules natively in Snowflake, Databricks and BigQuery. Governance workflows route access requests and metadata changes to the right approver, and the hosted Atlan MCP server hands all of that context to Claude, Cursor, ChatGPT and the rest of your AI tools.

Then the work starts. A rule fails and someone has to find the cause, fix the model and rerun the job. An access request is approved in Atlan and a Jira ticket waits for a platform engineer to run the grant. A steward approves a new definition of a metric and the dbt model keeps computing the old one. The same people handle the warehouse bill and the next audit request.

Your data platform has a control-plane problem, and the control plane is your team. Atlan made knowing your data cheap. The expensive part is the doing: the fixing, the granting, the checking and the record of what changed.

What Atlan solved, and what it didn't

Atlan solved knowing. One governed record covers what each asset is, what it means, who owns it and what it feeds, across more than 80 connectors. Its AI is aimed at that record and does it well. Context agents enrich it, Context Engineering Studio tests a context repository and deploys it to Databricks Genie or Snowflake Cortex Analyst, and since September its agents also read GitHub and Confluence as knowledge sources. The MCP server exposes 39 tools, and the ones that change anything in Atlan "return a preview of the change and wait for your approval before writing".

What Atlan doesn't do is repair or provision the systems it describes. Apart from publishing context to engines like Genie, its MCP write tools change Atlan metadata, and its SQL tool rejects "statements that modify data". The access management workflow grants access inside Atlan for exploring and previewing data, and for the warehouse itself it raises a Jira ticket or a ServiceNow request, or triggers a webhook, "for your team to grant or revoke data access" at the source. Nothing in Atlan owns the repair of a production table, the grant in Databricks, the check that the number is right again, or the receipt an auditor will ask for. That is the right focus for a catalog that has to stay neutral across every system it connects to.

Atlan is the inventory and context layer. Data Workers is the agentic data platform that does the operations work keeping what Atlan shows true, and runs the rest of your data back office.

Or, in one sentence for your team: Atlan tells us what our data is and who owns it; Data Workers does the work behind it, under the approvals our owners set.

What goes on autopilot

Each of these is a queue your team runs by hand today, behind signals Atlan already raises.

None of this requires replacing anything. Atlan connects over its API and MCP server today, used by your team's assistant side by side with Data Workers, which works inside the warehouse, dbt and orchestrator you already run, and leaves an auditable record of every change. Catalog updates are proposed for your stewards, who make them in Atlan under its own preview and approval. Atlan stays the system of record for its metadata, by design.

What changes for your organization

Here's what that looks like in a normal week. Spend and migrations follow the same pattern: the change is drafted for its owner, approved and recorded.

• •Access stops being a ticket queue. A request approved in Atlan arrives at the platform owner as a scoped grant with a dry run attached. Unity Catalog grants are applied on approval; on other platforms the drafted grant goes to the owner to run. Analysts start work the day they're approved, with exactly what they need.
• •Certificates keep meaning what they say. A failed Data Quality Studio rule arrives traced to its cause with a proposed fix, so a Verified asset is backed by a table that's right again before the business reads it.
• •Stewards curate instead of chasing. The forwarding and the owner hunts move to the agents, and stewards spend the week on definitions and domains.
• •The glossary and the code stay in step. Data Workers checks the definitions in your dbt code against the governed ones in its context graph and routes any conflict to the model's owner.
• •Audits get easier. Atlan records who approved a request or a metadata change. Data Workers records what changed in the platform, who applied it and how to undo it.

One request, start to finish

This is an illustration, not a customer case.

• •On Monday at 9 a.m., a new FP&A analyst requests access to three revenue tables in the Databricks finance catalog through Atlan, and the finance data owner approves it in the Atlan inbox.
• •Atlan's access workflow opens a Jira ticket for the platform team, where it joins the rest of the week's queue.
• •On Wednesday, an engineer clears the backlog by granting the analyst's group read access to the whole finance.revenue schema, payroll table included.
• •On Friday, quarter close starts with the analyst three days behind, and the auditor asks who approved access to payroll.

With Data Workers, the approved request reaches it over Atlan's API on Monday morning. It dry-runs the grant in Unity Catalog: the effective privileges after role inheritance, the sensitive columns it would reach, any policy conflicts, and a least-privilege recommendation of read on the three tables with a 90-day expiry. The Databricks platform owner approves the scoped grant, Data Workers applies it in Unity Catalog and records it with its expiry date, so the owner knows when to renew or remove it, and the engineer closes the Jira ticket with the receipt linked. The analyst starts on Monday afternoon, payroll stays out of reach, and the auditor's question has a one-line answer.

You choose how far and how fast

You don't have to jump to full autonomy. You choose the altitude, one domain at a time.

L0 manual is the work your team does by hand today. Every domain starts at L1 observe: each failed rule and access request gets a diagnosis or a dry run, and nothing changes. At L2 propose, agents draft the fix or the grant and a named owner approves it. At L3 act reversibly, change classes with a proven record, such as rerunning a partition after an approved upstream fix, run on their own with the undo written down first and a receipt left behind. At L4 autonomous, a domain that has earned it runs end to end on its own, and any domain can be dialled back at any time. An unanswered approval request expires and escalates, never auto-grants, and no agent can promote its own work.

The ladder in detail is in autonomy levels L0 to L4 explained, and how approvals work covers who signs off on what.

Why doesn't Atlan just do this itself?

Focus and risk. Atlan earns trust by describing every system neutrally, and its write lines follow from that: its tools change its own metadata, its SQL is read-only, and access to the warehouse ends as a ticket because the platform team owns grants in Databricks and Snowflake, not the catalog. Changing a dbt model, a Unity Catalog grant or an orchestrator run is a different promise: scope what else it touches, get the right owner to approve, apply it, prove the result and own the undo, across systems Atlan doesn't run. That is a different product with a different liability, and the product we built.

How it fits with Atlan

• •Atlan keeps its job. Assets, certificates, the glossary, context agents, Data Quality Studio, workflows and the MCP server stay where they are.
• •Atlan's permissions apply to what we read. Data Workers reads Atlan with a service token scoped to one persona, the way Atlan requires, and Atlan's read-only mode works because Data Workers only needs read tools.
• •Your platforms' permissions stay the lock. Data Workers works through the roles you grant in Databricks, Snowflake, dbt and your orchestrator, and holds no more access than you give it.
• •Your stewards keep the pen. Announcements, descriptions and certificate changes are drafted for the steward, who makes them in Atlan.
• •Your data stays in your systems. The agents run in your infrastructure and hold the warehouse credentials. Nothing is migrated, and the hosted orchestration service sees workflow metadata only. Our security and deployment guide has the detail.

When you don't need Data Workers

• •Atlan's access requests close the same day and quality failures are rare.
• •Your platform team has the time to work every ticket the catalog raises.
• •Nobody upstairs is asking what the catalog fixed this year.

If all three are true, keep your budget. If any of them isn't, the rest of this guide is about you.

The case for your CFO

The outcome. The company already pays for Atlan to know its data. Data Workers makes that investment pay back in work done: analysts get the right access the day it's approved, breaks Atlan detects are fixed at the source before the business reads the number, and every certificate stays backed by a table that's right. Engineers' hours go to new work instead of tickets.

The risk story. Autonomy is set per domain on the ladder above, and nothing changes at L2 until a named person approves. Every grant gets a dry run of the privileges and sensitive columns it would reach before anyone approves it. Every change carries a receipt: the trigger, the diff, who approved it, what it touched, how it was verified and how to undo it. An org-wide stop halts all autonomous dispatch. Our safety guide goes deeper, and who owns the agents covers accountability.

Why now. Atlan's MCP server already puts your context in every AI tool your people use, and those agents are starting to change things across the stack. The choice is one approval flow and one record, or each engineer's own wiring: see build it ourselves with Claude Code and MCP servers.

The first win. Read-only: every access request and failed rule in one domain, such as finance, arrives with a dry run or a diagnosis attached.

What stays the same. Atlan, your glossary, personas, governance workflows, warehouse permissions and dbt review. The path is a pilot, run on your own data before you commit. The ROI guide shows how to size it.

The sentence to repeat upstairs: Atlan tells us what our data is and who owns it; Data Workers keeps it true, under the approvals our owners set, with a receipt for every change.

Where to start

Pick one domain whose signals already live in Atlan and end the same way every time: the access requests for finance tables, the Data Quality Studio rules on the revenue models, or the Snowflake bill.

Start with a pilot. A forward-deployed engineer connects Data Workers to Atlan, your warehouse, dbt and your orchestrator, and runs the first domain alongside your team. See pricing for how the pilot works.

For the detail, send your architects you're on Atlan, the practitioner version of this guide with a worked quality incident, and Atlan vs Spellbook Data Catalog if a catalog choice is on the table. The category answer is how Data Workers is different from a data catalog, and the Collibra leaders guide covers the same move on Collibra. They cover the four products: the Autonomous Data-Conductor picks up Atlan's signals and runs each job from detection to a verified result, the Data-Agents Swarm does the work, Data Context Wizard keeps one governed graph of definitions, lineage and owners across every platform with Atlan as a first-class source, and Spellbook Data Catalog (in preview) is where your team approves, audits and rolls back. The thinking behind them is in our thesis.

Sources

• •Atlan, homepage ("The Context Layer for AI"; "80+ connectors"), checked Oct 3, 2026: https://atlan.com/
• •Atlan Docs, Context Engineering Studio index (deploy to Snowflake Cortex Analyst and Databricks Genie), checked Oct 3, 2026: https://docs.atlan.com/llms/platform/context-engineering-studio/llms.txt
• •Atlan Docs, Business Graph (Glossary) and classification propagation through lineage (docs index), checked Oct 3, 2026: https://docs.atlan.com/llms.txt
• •Atlan Docs, Set up Atlan MCP (hosted for all tenants; last modified Sep 4, 2026), checked Oct 3, 2026: https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/remote-mcp-overview
• •Atlan Docs, Atlan MCP tools (39 tools; writes preview and wait for approval; SQL rejects data-modifying statements; last modified Aug 12, 2026), checked Oct 3, 2026: https://docs.atlan.com/product/capabilities/atlan-ai/references/mcp-tools
• •Atlan Docs, Atlan MCP security (read-only mode, one persona per service token; last modified Aug 31, 2026), checked Oct 3, 2026: https://docs.atlan.com/product/capabilities/atlan-ai/references/mcp-security
• •Atlan Docs, Automate data governance (governance workflows; access management grants in Atlan or raises Jira, ServiceNow or webhook requests to grant at the source), checked Oct 3, 2026: https://docs.atlan.com/product/capabilities/governance/stewardship/how-tos/automate-data-governance
• •Atlan Docs, Understand context agents (existing values never overwritten; last modified Sep 24, 2026), checked Oct 3, 2026: https://docs.atlan.com/product/capabilities/governance/context-agents-studio/concepts/agents
• •Atlan Docs, Deploy to Databricks Genie from Context Engineering Studio (last modified Aug 25, 2026), checked Oct 3, 2026: https://docs.atlan.com/product/capabilities/governance/context-engineering-studio/how-tos/deploy-databricks
• •Atlan Docs, Data Quality Studio rule types and failed rows (last modified Aug 12, 2026), checked Oct 3, 2026: https://docs.atlan.com/product/capabilities/governance/data-quality/references/rule-types-and-failed-rows
• •Atlan, Product changelog (knowledge sources Sep 7; GitHub Sep 15; Confluence Sep 29, 2026), checked Oct 3, 2026: https://docs.atlan.com/product/changelog