You're on Secoda: Keep Every Answer True, With Data Workers Doing the Operations Work

Your team runs on Secoda. Every Snowflake table, dbt model and Metabase question is searchable, with column lineage, an owner and a description. The glossary says what "completed session" and "active tutor" mean. People open a Question instead of pinging the data channel, and the best answer gets a green check and lands in search. Monitors watch row counts, freshness and custom SQL, and their incidents show what sits downstream. Secoda AI answers in plain language, runs SQL against the warehouse and turns a good prompt into a scheduled agent. Its MCP server hands the same catalog, lineage and glossary to Claude and Cursor. Since December 2025, Secoda has been part of Atlassian, with Atlassian saying Secoda's expertise will strengthen Rovo and Secoda telling customers their experience will not change.

Secoda is where your team searches, documents and asks questions about data. Data Workers does the operations work that keeps the answers true, behind approvals. An answer in Secoda is only as good as the table under it. When a new value slips past a dbt filter at 3 a.m., someone has to find it, change the model, rerun the flow and prove the number before money moves.

Key takeaways

• •Secoda keeps its job. Catalog, glossary, Questions, Monitors, Secoda AI and the MCP server stay as they are.
• •Secoda's signals start the work. A monitor incident, its downstream resources and the owner reach Data Context Wizard over Secoda's API and MCP server and become an incident with a traced cause.
• •The fix lands where the cause lives. Data Workers proposes the dbt diff, queues the rerun through your orchestrator and verifies the result, with a named owner approving first.
• •Answers stay current. Data Workers drafts the glossary update and the answer to the open Question; the owner posts them in Secoda.
• •Start with a pilot. One domain where Secoda Monitors already run, read-only first.

Secoda is the answer desk. Data Workers is the control plane behind it.

Secoda holds what your data is, what it means and what people have asked about it. Data Workers holds what happens when the answer stops matching the data: one context across the systems Secoda describes, one approval flow and one audit trail, with Spellbook Data Catalog (in preview) as the place your team reviews it.

A Thursday at a Series B online tutoring marketplace, two days before tutors are paid. The stack: a PostgreSQL bookings app, dlt pipelines run in Prefect, Snowflake, dbt Core in Prefect, Secoda as the catalog and Metabase for the finance dashboards. This is an illustrative example.

Secoda did its part: the monitor caught the drop, the incident showed the payout export downstream, and the Question reached the right team. The cause sat in an app release and a dbt filter, two places Secoda describes and doesn't change. Without the trace, about 600 tutors would have been underpaid by $36,300 on Friday, and Secoda AI would have kept quoting a definition the business no longer used.

Why doesn't Secoda just do this itself?

Secoda is built to be the one trusted place a lean data team points everyone to, and it draws its write lines with that in mind. Its MCP server searches, retrieves entities, walks lineage, reads the glossary and runs SQL, and "all operations respect your existing data governance and access controls"; no tool in it edits a dbt model or a pipeline. Secoda AI's documented scope leaves out live monitor changes, access requests and audit logs. Its agents are saved prompts that run on a schedule, and the docs say plainly that they are read-only. When Secoda touches code, it does so carefully: the GitHub extension comments on dbt pull requests, and the metadata sync opens a pull request for a person to review. That design is right for an answer desk: it keeps Secoda neutral and its security review simple.

Fixing the tutor payouts is a different promise: changing a dbt model Secoda catalogs but doesn't own, scoping what it touches, getting the right approval, rerunning the flow, proving the total and owning the rollback. That needs blast radius across systems, approvals per domain and receipts for changes in tools Secoda doesn't run. That product is Data Workers.

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

Secoda owns one slice outright: the answer desk for data, where search, documentation, lineage and Questions meet. 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 Secoda and Data Workers work together

People keep working where they work: Claude Code or Cursor for SQL and dbt, Secoda for search and Questions, Metabase for dashboards. Spellbook is where the data team reviews each change with its incident, blast radius, approver and rollback path; approval requests reach the approver in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix: detect, diagnose, fix, review, verify, remember.

What comes in from Secoda. Data Workers connects to Secoda over its API and MCP server today. Monitor incidents and measurements come from Secoda's Monitors API; lineage, entities and glossary terms come over the MCP tools entity_lineage, retrieve_entity and glossary. Each fact arrives with its source and the time it was seen, and stays yours. Context Wizard joins them to what Secoda's lineage points to but doesn't hold (Snowflake query history, Prefect flow runs, dbt manifests and test results) through Data Workers' native Snowflake, PostgreSQL, dbt and Prefect connectors; dlt and Metabase connect over their APIs today. Your agent can then call explain_table for definition, lineage and trust score, blast_radius_analysis for what a change touches, get_quality_score for quality and get_incident_history for open incidents.

Setup over MCP today. Your Secoda admin enables MCP and creates an API token for a service user scoped to the pilot domain; Secoda documents setup through the open-source secoda/secoda-mcp server run with that token. 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": {
    "secoda": {
      "command": "python",
      "args": ["/path/to/secoda-mcp/server.py"],
      "env": {
        "API_TOKEN": "${SECODA_API_TOKEN}",
        "API_URL": "https://app.secoda.co/api/v1/"
      }
    },
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    },
    "dw-quality": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-quality"]
    },
    "dw-incidents": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-incidents"]
    }
  }
}

EU, APAC and self-hosted workspaces swap in their own API host. List the tools with /mcp. Secoda's run_sql queries through Secoda's own warehouse connection, so keep that service user's role narrow, or have the admin turn SQL off for AI. Then "why are partial sessions missing from tutor earnings?" gets the owner, glossary term and lineage from Secoda, lineage beyond the catalog from trace_cross_platform_lineage, the cause from get_root_cause and the table's state from run_quality_check, in one answer.

Where writes go. Data Workers proposes the dbt change as a diff for the owner to merge, including the Secoda monitor declared in the model's YAML, which Secoda picks up on its next dbt sync. It queues reruns through Prefect after approval. Catalog updates (a glossary definition, an answer, a clearer description) are drafted for the owner, who posts them in Secoda; Secoda's metadata sync can carry descriptions back into dbt as a pull request. Approved facts land in the Context Wizard graph. Secoda 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 monitor incident arrives explained with cause, owner and blast radius; nothing changes, and the log records what each action would have needed.
• •L2 propose. Data Workers drafts the dbt diff, rerun plan, glossary update and answer; a named owner approves in Spellbook first.
• •L3 act reversibly. For proven classes, such as rebuilding a week of a model after an approved upstream fix, Data Workers acts, verifies and keeps the undo path.
• •L4 autonomous. For a scoped, trusted class, it fixes, verifies and posts the receipt on its own.

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. The safety model is in is it safe to let AI agents change production data, sign-off in how approvals work for AI data agents and the levels in 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).

The same pattern runs on Atlan and DataHub, and, on the Atlassian side, Jira. The category answer is in how Data Workers is different from a data catalog, connectors in Data Workers integrations, and the wider view in the AI data catalog and agentic data catalog notes.

What changes for your team

Secoda teams tend to be small: the same three people answer Questions, chase incidents and fix dbt models. With Data Workers on top, those jobs run on autopilot at the level you set.

• •Incidents. A Secoda Monitor incident arrives traced to its cause, with the owner and a proposed fix attached.
• •Data quality. New values and broken filters get a test and a fix, confirmed when the monitor is back in range.
• •Cloud spend. Snowflake credits are tied to the dbt model behind them, with the fix drafted for its owner.
• •Access. Each proposed grant gets a dry run of effective privileges, sensitive columns and policy conflicts before the approver decides, alongside Secoda's own access requests.
• •Audits. Every change carries the incident, the owner who approved it, the diff and a rollback path.
• •Migrations. Schema moves are planned in approved waves, with rollback SQL for the owner to apply.

The team gets its week back, and the answers in Secoda keep matching the numbers.

Keep Secoda, or consolidate?

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

For most Secoda teams the answer is to keep it: your glossary, Questions history and documentation live there, and your people go there first. Atlassian ownership doesn't change that, and your team's assistant uses Secoda's documented API and MCP server side by side with Data Workers either way. What teams consolidate is the tooling around it: the script that turns monitor incidents into tickets, the rerun runbook, the spreadsheet that maps glossary terms to dbt models, a separate observability console. Teams that later want one agentic catalog can move to Spellbook without a cutover weekend, because Data Workers has read Secoda from the start. Weighing building this layer yourself on Secoda'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 catalog the company already pays for starts paying back in correct numbers. Breaks Secoda detects get fixed at the source the same morning, so the answers people read in Secoda, and the money that moves on them, stay right. Above, that is the difference between paying tutors $448,900 and underpaying about 600 of them by $36,300.

The risk story: Data Workers reads Secoda with one scoped service token. Every change shows its blast radius, goes to a named owner, lands through your existing dbt and Prefect workflows, is verified and leaves a receipt: trigger, diff, before and after checks, approver and undo path. Autonomy is set per domain from L0 manual to L4 autonomous. Zero migration: Secoda, Snowflake, dbt and Prefect stay where they are.

Why now: Secoda already hands your context to AI agents over MCP, and agents across the stack are starting to change things; a record of who approved what is cheaper to build before that queue grows. The first win is one domain where every monitor incident arrives explained and owned. What stays the same: your glossary, Questions, documentation, 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: "Secoda is where our people get answers about our data; Data Workers keeps those answers true, with the owner approving every fix and a receipt for each one."

Getting started

Start with a pilot. Pick one domain where Secoda Monitors already run, such as payouts, put Secoda's MCP server in your team's client with a scoped token, and let Data Workers explain every monitor incident the on-call brings it 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

Secoda is part of Atlassian now. Does that change how Data Workers connects? No. Atlassian acquired Secoda in December 2025. Secoda told customers their experience would not change while parts of its infrastructure move to Atlassian's Cloud Platform. Data Workers connects through Secoda's documented API and MCP server, and works with Jira too.

Does Data Workers write to Secoda? Catalog changes are drafted for the owner: Data Workers writes the glossary update, description or answer, and the owner posts it in Secoda. Your team's assistant only needs Secoda's read tools; Data Workers' agents never call them.

How is this different from Secoda AI agents? Secoda agents run a saved Secoda AI prompt on a schedule and report the results, such as stale tables or slow queries; they are read-only by design. Data Workers acts on the systems underneath: it traces the cause, proposes the change, gets it approved, runs it and verifies it.

Can Secoda Monitors and Data Workers checks run side by side? Yes. Keep your Secoda Monitors as the signal, including monitors declared as code in dbt YAML. Data Workers reads their incidents, adds its own checks where a fix needs proof, and can propose new Secoda monitors in the same dbt change.

What about Secoda access requests? Keep using them. Where a grant is proposed through Data Workers, it dry-runs it first (effective privileges after role inheritance, sensitive columns reached, policy conflicts, an expiry recommendation) and proposes the grant for the platform owner to apply.

What does Data Workers store? Metadata and scrubbed facts (definitions, lineage, owners, incident history, receipts) in your infrastructure, not copies of your tables. The hosted Conductor sees workflow metadata only.

Sources

• •Secoda, homepage (tagline; Atlassian banner), https://www.secoda.co/ (checked Oct 3, 2026)
• •Secoda, Atlassian acquires Secoda (updated Dec 4, 2025; Atlassian EVP Tiffany To on Rovo; customer commitments), https://www.secoda.co/blog/atlassian-acquires-secoda (checked Oct 3, 2026)
• •Secoda docs, MCP server (eight tools; setup), https://docs.secoda.co/features/ai-assistant/secoda-mcp-server (checked Oct 3, 2026)
• •Secoda docs, Secoda AI capabilities, https://docs.secoda.co/features/ai-assistant/secoda-ai-capabilities (checked Oct 3, 2026)
• •Secoda docs, Agents, https://docs.secoda.co/features/ai-assistant/secoda-ai-agents (checked Oct 3, 2026)
• •Secoda docs, Monitors, https://docs.secoda.co/features/monitoring (checked Oct 3, 2026)
• •Secoda docs, Questions, https://docs.secoda.co/features/ask-questions-in-secoda (checked Oct 3, 2026)
• •Secoda docs, Access requests, https://docs.secoda.co/features/access-requests (checked Oct 3, 2026)
• •Secoda docs, GitHub extension, https://docs.secoda.co/extensions/github (checked Oct 3, 2026)
• •Secoda API reference, Monitors and Questions, https://docs.secoda.co/api/reference/monitors and https://docs.secoda.co/api/reference/questions (checked Oct 3, 2026)
• •Secoda MCP repository (MIT), https://github.com/secoda/secoda-mcp (checked Oct 3, 2026)
• •Data Workers, Client setup (open-source docs), 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)