You're on DataGalaxy: Keep Every Data and AI Product True, With Data Workers Doing the Operations Work

Your governance office runs on DataGalaxy, which now calls itself "The AI Context Engine". The catalog holds every BigQuery table and dbt model with its owner, steward and lineage, and the glossary says what "marketing consent" means. Data products and AI products sit in the Products module with their use case, output ports, domain and policies, and the ones you publish appear in the Marketplace, where a marketer can find "Marketing-eligible customers", see who owns it and request access without a ticket. The AI data steward drafts descriptions and suggests personal-data classifications for stewards to accept. Blink answers questions in plain language. And the DataGalaxy MCP server hands the same governed context to Claude, Cursor, Mistral Le Chat and Copilot Studio, and since the June product update it lets an agent update catalog attributes too.

DataGalaxy is where your data and AI products are governed and shared. Data Workers does the operations work that keeps them true, behind approvals. A published product is a promise about what the data means, who owns it and what it is fit for. When an upstream change quietly breaks that promise overnight, someone has to find it, fix the model, rebuild the product and prove it before anyone uses it again.

Key takeaways

• •DataGalaxy keeps its job. Catalog, glossary, lineage, data and AI products, the Marketplace, Blink and the MCP server stay as they are.
• •DataGalaxy's context starts the work. A comment or task on a product, with its output ports, lineage and owner, reaches Data Context Wizard over the DataGalaxy MCP server and becomes an incident with a traced cause.
• •The fix lands where the cause lives. Data Workers proposes the dbt diff, queues the rebuild through your orchestrator and records the owner's test results on the rebuilt product, with the named owner approving first.
• •The catalog stays the record. Data Workers drafts the comment and status change; the product owner posts them in DataGalaxy.
• •Start with a pilot. One domain with published products, read-only first, on the ladder from L0 manual to L4 autonomous.

DataGalaxy is the governed shelf for data and AI products. Data Workers is the control plane.

DataGalaxy holds what each product is, what it means, who owns it and who uses it. Data Workers handles what happens when the product stops matching the data underneath it: one context across the systems DataGalaxy describes, one approval flow and one audit trail, with Spellbook Data Catalog (in preview) as the place your team reviews it.

A Tuesday at a European home-goods retailer with an app, a web shop and a loyalty program, two days before a spring campaign. The stack: Didomi as the consent platform, a daily load in Managed Service for Apache Airflow, BigQuery, dbt Core, DataGalaxy as the catalog and product shelf, and Brevo for email and push. By design, each customer's consent is recorded in Didomi and turned into eligibility by a dbt model your team owns; Data Workers checks the data that results. This is an illustrative example.

DataGalaxy did its part exactly: a named owner, linked output port and AI consumer, and the right object to raise the problem against. The cause sat in a dbt model that reads a consent export, two places DataGalaxy describes and doesn't change. Without the trace, 4,212 people who had said no would have received Thursday's offer.

Why doesn't DataGalaxy just do this itself?

DataGalaxy is built to be where a company governs and shares its data and AI products, and it draws its write lines around that job. Its MCP server reads the catalog, glossary, lineage, comments and tasks; its writes stay inside the catalog: create_comment adds a comment and update_object changes an object's attributes, such as status, owners, stewards and tags. Every call runs under the token holder's roles and domains, and the server exposes metadata only, never rows. Blink is scoped more tightly still: it can add a comment, and DataGalaxy's documentation says it cannot update objects or create tasks. That design is right for a governance platform: it keeps DataGalaxy neutral across every warehouse it catalogs.

Keeping a consent-based audience true is a different promise: changing a dbt model DataGalaxy catalogs but doesn't own, scoping what that touches, getting the right approval, rebuilding, proving it and owning the rollback, with receipts for changes in tools DataGalaxy doesn't run. That product is Data Workers.

Every tool owns a slice. Data Workers covers the whole lifecycle

DataGalaxy owns one slice outright: governing and sharing data and AI products. 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 catalog you already run.

How DataGalaxy and Data Workers work together

People keep working in Claude, Cursor, Le Chat or Copilot Studio and DataGalaxy. Spellbook is where the data team reviews proposed changes with incident, blast radius, approver and rollback path; approval requests reach the named approver in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor runs each fix: detect, diagnose, fix, review, verify, remember.

What comes in from DataGalaxy. Data Workers connects to DataGalaxy over its MCP server or API today. Products, output ports, consumers and glossary terms come over search_objects, get_object and get_object_relations; comments and tasks over get_comments and get_tasks. Each fact keeps its source and stays yours. Context Wizard joins them to what the lineage points to: BigQuery job history, Airflow DAG runs, dbt manifests, through Data Workers' native BigQuery, dbt and Airflow connectors (including Managed Service for Apache Airflow). Didomi and Brevo connect over their APIs today.

Setup over MCP today. Your account manager enables the DataGalaxy MCP server for your company. Create a service user whose roles cover the pilot domain, copy its Personal Access Token from Profile, then Security, and copy the server URL from the DataGalaxy MCP Server tab. For Data Workers, clone the open-source repository and add start-agent.sh entries, as the client setup docs show.

// Example: .mcp.json for Claude Code
{
  "mcpServers": {
    "datagalaxy": {
      "type": "http",
      "url": "https://<instance>.api.datagalaxy.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${DATAGALAXY_PAT}",
        "X-API-Base-URL": "https://<instance>.api.datagalaxy.com/v2/",
        "X-Version-ID": "<version id>",
        "Accept": "application/json, text/event-stream"
      }
    },
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    },
    "dw-connectors": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-connectors"]
    },
    "dw-incidents": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-incidents"]
    }
  }
}

The version id is the second UUID in your DataGalaxy URLs. List the tools with /mcp. Because update_object writes under the token's roles, give the service user a role that reads the pilot domain and comments, and keep attribute edits with their owners. Then "why did customers who refused offers get one?" gets the product, owner and glossary term from DataGalaxy, lineage beyond the catalog from trace_cross_platform_lineage, what a fix touches from blast_radius_analysis, and the cause from get_root_cause, in one answer.

Where writes go. The dbt change is a diff for the owner to merge; the rebuild is queued through Airflow after approval. Didomi and Brevo stay with their owners, and catalog updates are drafted for the product owner to post. Approved facts land in the Context Wizard graph; DataGalaxy stays the system of record for its metadata, by design.

One request, L0 to L4. The autonomy ladder is set per domain.

• •L0 manual. Connected, not acting.
• •L1 observe. Each issue on a product arrives explained with cause, owner and blast radius.
• •L2 propose. Data Workers drafts the dbt diff, tests, rebuild plan and catalog comment; the owner approves in Spellbook.
• •L3 act reversibly. For proven classes, such as rebuilding a product after an approved fix, Data Workers acts and keeps the undo path.
• •L4 autonomous. For a scoped, trusted class, it fixes, verifies and posts the receipt.

An unanswered approval request expires and escalates; it never auto-grants. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. See is it safe to let AI agents change production data, how approvals work for AI data agents and autonomy levels L0 to L4 explained. The agents run in your infrastructure and hold your warehouse credentials and model key; your data stays in your systems, and the hosted Conductor sees workflow metadata only (where does our data go). For teams that work under GDPR, consent records and customer rows stay in your own BigQuery project, and the receipt is something your privacy office can read; how receipts relate to GDPR and the EU AI Act is in Data Workers and SOX, HIPAA, GDPR and the EU AI Act.

Sibling guides: Collibra, Microsoft Purview, Atlan, Data Workers vs a data catalog, bring your own context, the AI data catalog and the agentic data catalog.

What changes for your team

The governance office raises issues against products; the data team chases them across warehouses and pipelines. With Data Workers on top, those jobs run on autopilot at the level you set.

• •Incidents. A comment, task or alert on a Marketplace product arrives traced to its cause, with the owner and a proposed fix.
• •Data quality. New source values get a test and a fix, and the product is trusted again once the owner's tests pass.
• •Cloud spend. BigQuery spend is summed from the Jobs API; Snowflake credits are tied to the dbt model behind them.
• •Access. When a Marketplace request becomes a grant, Data Workers dry-runs it first: effective privileges, sensitive columns reached, policy conflicts and an expiry recommendation.
• •Audits. Every change carries the trigger, the approver, the diff and a rollback path.
• •Migrations. Schema moves are planned in approved waves, with rollback SQL for the owner to apply.

Keep DataGalaxy, or consolidate?

Keep DataGalaxy if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

For most DataGalaxy teams the answer is to keep it: your glossary, product definitions, ownership model and Portfolio live there, and your governance office runs its program from it. What teams consolidate is the tooling around it: the spreadsheet mapping products to dbt models and the runbook for rebuilding a product after a fix. Teams that later want one agentic catalog can move to Spellbook without a cutover weekend, because Data Workers has read DataGalaxy from the start. Weighing building this yourself on DataGalaxy's MCP server? Read build it ourselves with Claude Code and MCP servers: the connection is the easy part; cross-system context, approvals and rollback are the work.

The case for your CFO

The outcome: the products the company governs in DataGalaxy pay back in decisions nobody has to redo. Breaks that reach a published product get fixed at the source the same morning. Above, that is the difference between a clean spring campaign and an offer sent to 4,212 people who had said no.

The risk story is plain. Data Workers reads DataGalaxy with one scoped token. Every change shows its blast radius, goes to a named owner, lands through your existing dbt and Airflow workflows, is verified and leaves a receipt: trigger, diff, before and after checks, approver and undo path. Zero migration: DataGalaxy, BigQuery, dbt and Airflow stay where they are.

Why now: DataGalaxy already hands your context to AI agents over MCP, and those agents can now write to the catalog. The first win is one domain where every issue raised on a product arrives explained and owned. What stays the same: your glossary, products, Portfolio, roles and review process. For the numbers, see the ROI of agentic data operations. Start with a pilot (pricing); the pilot is credited in full against the first year.

The sentence to repeat upstairs: "DataGalaxy is where we govern and share our data and AI products; Data Workers keeps them true, with the owner approving every fix and a receipt for each one."

Getting started

Start with a pilot. Pick one domain with products published in the Marketplace, connect the DataGalaxy MCP server with a scoped service user next to Data Workers, and let Data Workers explain every issue raised on those products before you turn on the first fix class. Plans are on the pricing page, and the pilot is credited in full against the first year.

FAQ

The DataGalaxy MCP server can now update the catalog. Does Data Workers use that? Data Workers reads with it and drafts catalog changes for the owner, who posts them. DataGalaxy added write-back in its June product update (published July 17, 2026): agents can update descriptions, tags, statuses, owners, stewards and custom attributes under the token's roles. Keeping catalog edits with their owners keeps DataGalaxy the record your governance office trusts.

How is this different from Blink and the AI data steward? Both work inside the catalog: Blink answers questions and writes SQL against catalogued columns; the AI data steward drafts descriptions, classifications and links for stewards to accept. Data Workers works on the systems underneath: it traces the cause, proposes the change, gets it approved, runs it and verifies it.

Does Data Workers manage consent? By design, consent is recorded in your consent platform and turned into eligibility by models your team owns, so each person's choice has one source of truth. Data Workers checks the data that results: it traces a complaint to the model, records your dbt test results on the audience, proposes the fix and records every check.

Does Data Workers make us GDPR or EU AI Act compliant? No tool does that for you. Data Workers keeps products consistent with their sources and leaves a receipt for every change, with the approver named, in your own infrastructure. Your privacy office and counsel decide what the receipts are evidence for.

Can Data Workers handle Marketplace access requests? A request becomes a task for the object's owner. Where the owner grants through Data Workers, it dry-runs the grant first. Unity Catalog grants are applied after approval; on other platforms the grant is proposed for the platform owner to apply.

Sources

• •DataGalaxy, homepage ("DataGalaxy: The AI Context Engine"; Catalog, Portfolio, Marketplace), https://www.datagalaxy.com/en/ (checked Oct 3, 2026)
• •DataGalaxy, MCP Server product page (inherits roles, domains and access controls; exposes metadata only), https://www.datagalaxy.com/en/product/mcp-server/ (checked Oct 3, 2026)
• •DataGalaxy docs, DataGalaxy MCP Server Tools (updated Sep 21, 2026; read tools, create_comment, update_object), https://docs.datagalaxy.com/catalog/en/articles/1790096046-datagalaxy-mcp-server-tools (checked Oct 3, 2026)
• •DataGalaxy docs, Quick Start with MCP Server, https://docs.datagalaxy.com/catalog/en/articles/1790031970-quick-start-with-mcp-server (checked Oct 3, 2026)
• •DataGalaxy docs, How to Add DataGalaxy MCP Server to Cursor (headers, API base URL, version id), https://docs.datagalaxy.com/catalog/en/articles/1790076579-how-to-add-datagalaxy-mcp-server-to-cursor (checked Oct 3, 2026)
• •DataGalaxy, Product Update June (published Jul 17, 2026; MCP write-back), https://www.datagalaxy.com/en/blog/product-update-june/ (checked Oct 3, 2026)
• •DataGalaxy, Product Update September (Sep 24, 2026; Claude Desktop Extension, MCP field writability, pagination, dbt Snapshots), https://www.datagalaxy.com/en/blog/product-update-september/ (checked Oct 3, 2026)
• •DataGalaxy, AI data steward, https://www.datagalaxy.com/en/product/ai-data-steward/ (checked Oct 3, 2026)
• •DataGalaxy docs, Functional boundaries and limitations of Blink (Sep 21, 2026), https://docs.datagalaxy.com/catalog/en/articles/1790029896-functional-boundaries-and-limitations-of-blink (checked Oct 3, 2026)
• •DataGalaxy, Data products and Marketplace, https://www.datagalaxy.com/en/product/data-ai-product-management/ and https://www.datagalaxy.com/en/product/marketplace/ (checked Oct 3, 2026)
• •DataGalaxy docs, Products objects in detail (output ports, consumed by, request access tasks), https://docs.datagalaxy.com/catalog/en/articles/1790161462-products-objects-in-detail (checked Oct 3, 2026)
• •DataGalaxy, Data quality monitoring (Bigeye, Sifflet; alerts to Slack, Teams), https://www.datagalaxy.com/en/product/data-quality-monitoring/ (checked Oct 3, 2026)
• •DataGalaxy, Connectors (70+), https://www.datagalaxy.com/en/connectors/ (checked Oct 3, 2026)
• •Data Workers, Client setup, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
• •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)