You're on OvalEdge: Keep the Governance Suite, Add the Control Plane That Keeps It True

Your governance program runs on one platform. OvalEdge holds the catalog, lineage, business glossary, data products, quality rules, access policies and privacy workflows on one data model and one workflow engine, licensed by connector, never by how much data you govern. A lean team runs it. Nine governance agents do the heavy lifting with humans in the loop: Curo curates assets and asks the right person through the Question Wall, Lingo builds the glossary, Helm recommends owners for approval, Notary certifies what meets your standards, Litmus recommends quality rules, Sift classifies PII, PHI and financial data and applies your governance policies, and Apex, Packer and Nexus prioritize, package and connect it all. askEdgi answers cross-system questions from that context, and the OvalEdge MCP server hands the same governed metadata to Claude, Copilot and Cursor. OvalEdge is the all-in-one governance suite. Data Workers does the operations work that keeps it true, behind your approvals.

A classification is a decision. Someone still has to make the warehouse mask the column, the view stop passing it through and the report refresh clean. That job is what this guide covers.

Key takeaways

• •OvalEdge keeps its job. Catalog, lineage, glossary, quality rules, access requests, privacy workflows and the governance agents stay where they are.
• •OvalEdge's context becomes Data Workers' map. Classifications, owners, certifications and lineage come in over the OvalEdge MCP server or REST API and join what lands in Snowflake each night.
• •A classification turns into protection that follows the column. When Sift marks a new column as PII, Data Workers finds every place it flows, drafts the warehouse and view changes with rollback SQL, and routes them to the named owner.
• •Writes land where your team owns change. Snowflake changes go to the platform owner to apply; the steward applies the OvalEdge note Data Workers drafts.
• •Start with a pilot. One regulated domain, read-only, then one change class.

OvalEdge is the all-in-one governance suite. Data Workers is the control plane that keeps it true.

OvalEdge is built so a small team can run enterprise governance without stitching tools together. Its MCP server, open source on GitHub under MIT with 25 tools, grew fast in 2026: customer applications from April 30, crawl-to-crawl change analysis and native access discovery on June 16, effective object access and quality rule recommendations on July 3, OAuth 2.0 and an MCP audit log export on August 4.

Around the suite sits everything that decides whether its policies hold: the application database, the SSIS packages, the Snowflake tables and views, and the Power BI models people open each morning. Data Workers covers that side and uses OvalEdge's governance as its map.

A Wednesday at a regional lender on Snowflake (an illustrative example):

The blast radius counts are part of the illustration; in your estate they come from the lineage. OvalEdge did its part exactly: Sift classified the column the night it landed, the lineage reached from SSIS to Power BI, and the access request went through a business approval. The gap sat in a Snowflake tag, a view and a refresh owned by other teams. Without the trace, the morning refresh would have carried full tax IDs into a model shared across the lending team.

Why doesn't OvalEdge just do this itself?

Because OvalEdge built a great product for one job: being the single place a lean team governs its data. That job is broad on purpose, and its design keeps people in charge of every decision that matters.

You can see that in how it writes. Helm recommends owners for approval. The MCP server runs every request under the signed-in user's permissions, and its governed writes (glossary terms, tags, descriptions, governance roles, CDEs, custom fields, quality rules) show a confirm preview and post only after the user confirms. Those writes change OvalEdge's own record. Where your team has OvalEdge enforce access on a supported platform, it does; many teams keep Snowflake masking in the platform team's code, which is exactly where a gap like Wednesday's opens.

Changing an SSIS-fed Snowflake view and a warehouse tag owned by another team, then proving the Power BI model is clean, is a different product. It needs blast radius across systems OvalEdge doesn't run, scoped credentials, a named-owner approval, rollback SQL, a verified result and a receipt. That product is Data Workers.

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

OvalEdge owns one slice outright, with catalog and governance as its two home stages. 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 suite you already run.

These are directional scores of scope, not benchmarks.

How OvalEdge and Data Workers work together

Your people stay where they are: stewards and analysts in OvalEdge and askEdgi, engineers in Claude, Copilot or Cursor with the OvalEdge MCP server. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, its owner, blast radius, checks and rollback. 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 end to end (detect, diagnose, fix, review, verify, remember) under per-domain guardrails.

What Context Wizard does with OvalEdge's context. Three things come in, each with its source and time.

• •Owners and stewards. The owner or steward on an OvalEdge asset approves changes to it, by Slack or email request with the decision in Spellbook.
• •Classifications and certifications. A Sift classification is a signal to check protection downstream; a Notary certification marks the tables people trust most. Both arrive as sourced facts; a named person promotes them to authoritative, and no agent can promote its own work.
• •Lineage. OvalEdge's lineage already reads your SSIS packages and Power BI models, so SQL Server and SSIS reach Data Workers through it. Data Workers connects natively to Snowflake and joins that lineage to its own with trace_cross_platform_lineage; Power BI connects over its API today. explain_table returns a table's definition, lineage, documentation and trust score.

When a fix should change OvalEdge's record, Data Workers proposes it for the steward to apply through OvalEdge's own confirm step. Approved facts land in the Context Wizard graph.

Setup over MCP today. Both servers sit in the same client. For Data Workers, clone the open-source repository and add start-agent.sh entries, as the client setup docs show. For OvalEdge, clone ovaledge/oe_mcp, put an OvalEdge user token and secret in its .env, and run it over stdio, or point the client at your team's remote OvalEdge MCP endpoint.

// Example: .mcp.json for Claude Code
{
  "mcpServers": {
    "ovaledge": {
      "command": "poetry",
      "args": ["-C", "/path/to/oe_mcp", "run", "oe-mcp-local"]
    },
    "dw-governance": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-governance"]
    },
    "dw-context-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-quality": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-quality"]
    }
  }
}

List the tools with your client's own command (/mcp in Claude Code). Then "is the new tax ID column protected everywhere it goes?" draws on OvalEdge's catalog_asset_details, lookup_tags and asset_lineage for the classification, owner and path, and on blast_radius_analysis for what it reaches.

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

• •L0 manual. Connected, not acting; your engineer compares OvalEdge's classifications with Snowflake by hand.
• •L1 observe. Each new sensitive column arrives explained with its classification, owner and blast radius; nothing changes, and the permission ladder logs what each action would have needed.
• •L2 propose. Data Workers drafts the tag, view or masking change with rollback SQL; the owner approves in Spellbook and applies it.
• •L3 act reversibly. For proven classes, such as queuing a rerun of a failed load through the orchestrator after an upstream fix, Data Workers acts, verifies and keeps the undo path ready. Masking stays a proposal at every level.
• •L4 autonomous. For a scoped, trusted class, such as late loads into one domain, Data Workers queues the rerun, verifies and posts the receipt for review.

Approvals are covered in how approvals work for AI data agents, the levels in autonomy levels L0 to L4 explained, and the risk in is it safe to let AI agents change production data, how Data Workers handles PII and where does our data go. The agents run in your infrastructure: your data stays in your systems, and the hosted Conductor sees workflow metadata only.

Teams on other governance suites follow the same pattern: see You're on Collibra, You're on Microsoft Purview and You're on Informatica, the category view in how Data Workers differs from a data catalog, the Collibra, Alation, DataHub and OpenMetadata comparison and Data Workers integrations.

What changes for your team

OvalEdge teams spend much of the week on the handoff between a governance decision and the system that has to honor it. With Data Workers on top, those jobs run on autopilot at the level you set.

• •Incidents. A failed quality rule arrives with its cause traced to the load, view or source change behind it, and the fix drafted for the owner.
• •Data quality. Rule failures from OvalEdge's Remediation Center turn into fixes, reruns and a verified result the owner signs off.
• •Cloud spend. Snowflake spend is traced to the model behind it, with the change drafted for its owner.
• •Access. Each request is dry-run first: effective privileges after role inheritance, the sensitive columns it would reach, policy conflicts and a least-privilege recommendation with an expiry. On Databricks Data Workers applies the approved Unity Catalog grant; on Snowflake the grant is proposed for the owner to apply, and the ledger records it with its expiry for review.
• •Audits. Every change carries the classification, the owner, the diff, the checks and a rollback path (who owns the agents).
• •Migrations. A move from SQL Server onto Snowflake runs in planned waves, with parity checks tracked and the completion gate held for the owner's sign-off.

Keep OvalEdge, or consolidate?

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

For most OvalEdge teams the answer is to keep it. Your glossary, classifications, access workflows and privacy records live there, and your AI tools already read it over MCP. What teams consolidate is the tooling around it: a separate observability tool, the scripts that turn a classification into a ticket for the platform team. Weighing a build on OvalEdge's MCP server yourself? 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. For the wider category, see what is an agentic data platform.

The case for your CFO

The outcome: the governance suite the company already licenses pays back in policies that hold in production. Every classification and access decision in OvalEdge becomes a check that the warehouse, views and reports match it.

The risk story is plain. OvalEdge stays the record of what the data is and who may use it. At L1 the agents observe and change nothing. At L2 every change is proposed with its blast radius and goes to the owner named in OvalEdge. At L3 only proven, reversible change classes run without a fresh approval, and masking always needs one. Every action leaves a receipt: trigger, diff, checks, approver and undo path. Unanswered requests expire and escalate; they never auto-grant.

Why now: agents already read OvalEdge over MCP, and regulators ask how sensitive data is protected, not only whether it was classified. The first win is one regulated domain, read-only, where every new sensitive column arrives with its classification, its reach and the protection it still needs. What stays the same: OvalEdge, SQL Server, SSIS, Snowflake, Power BI, your stewards, your change process and your permissions. 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: "OvalEdge decides what our data is and who may use it; Data Workers makes our systems match, with the owner approving every change and a receipt for each one."

Getting started

Start with a pilot. Pick one regulated domain, such as lending or claims, connect the OvalEdge MCP server next to Data Workers read-only, and let Data Workers check every new column against Sift's classifications and the masking that should follow before you turn on the first change class. Plans are on the pricing page; the pilot is credited in full against the first year.

FAQ

Does Data Workers write to OvalEdge? OvalEdge connects over its MCP server or REST API, used by your team's assistant side by side with Data Workers, and OvalEdge stays the record by design. When a fix should change a description, tag or owner, Data Workers drafts it for the steward to apply. Approved facts land in the Context Wizard graph.

We already have OvalEdge's governance agents. Why add Data Workers? Sift, Notary, Helm and the rest keep OvalEdge's record current. Data Workers works on the systems that record describes, such as the Snowflake table, the view and the Power BI model, with an approval and a receipt for each change.

OvalEdge can enforce access policies. Where does Data Workers fit? Where OvalEdge enforces on a supported platform, keep it. Data Workers checks the copies, views and models a policy has to reach, catches a new column before the next crawl and drafts the change for whichever system owns it.

Does Data Workers apply masking in Snowflake? The platform owner does. Masking is always a proposal: Data Workers dry-runs it, drafts the change with rollback SQL and routes it to the owner, then re-checks the warehouse and records the result.

Does askEdgi overlap with Data Workers? They meet. askEdgi answers business questions from OvalEdge's governed context. Data Workers keeps the tables under those answers correct and answers cross-platform questions about the estate itself.

What does Data Workers store, and where? The agents run in your infrastructure and keep the context graph, receipts and audit log there, not copies of your tables. The hosted Conductor sees workflow metadata only.

Sources

• •OvalEdge, homepage (Unified Data Governance Platform; one platform; 170+ connectors), https://www.ovaledge.com/ (checked Oct 3, 2026)
• •OvalEdge, Governance Agents (Apex, Curo, Lingo, Helm, Packer, Notary, Litmus, Sift, Nexus), https://www.ovaledge.com/platform/governance-agents (checked Oct 3, 2026)
• •OvalEdge, Notary agent, https://www.ovaledge.com/agent/notary (checked Oct 3, 2026)
• •OvalEdge, Helm agent, https://www.ovaledge.com/agent/helm (checked Oct 3, 2026)
• •OvalEdge, Curo agent, https://www.ovaledge.com/agent/curo (checked Oct 3, 2026)
• •OvalEdge, askEdgi, https://www.ovaledge.com/product/askedgi (checked Oct 3, 2026)
• •OvalEdge, Data Quality (Remediation Center, legacy quality debt), https://www.ovaledge.com/product/data-quality (checked Oct 3, 2026)
• •OvalEdge, Data Access (classify, protect, monitor, ad-hoc access), https://www.ovaledge.com/product/data-access (checked Oct 3, 2026)
• •OvalEdge, Data Privacy Compliance and Access, https://www.ovaledge.com/solutions/data-privacy-compliance (checked Oct 3, 2026)
• •OvalEdge, Enterprise Context Graph, https://www.ovaledge.com/platform/enterprise-context-graph (checked Oct 3, 2026)
• •OvalEdge, Pricing (licensed, not metered), https://www.ovaledge.com/pricing (checked Oct 3, 2026)
• •OvalEdge, APIs and Integrations, https://www.ovaledge.com/product/api-integrations (checked Oct 3, 2026)
• •OvalEdge Knowledge Portal, Model Context Protocol (MCP server tools, permissions), https://docs.ovaledge.com/mcp-server/model-context-protocol (checked Oct 3, 2026)
• •OvalEdge Knowledge Portal, MCP Server What's New (Apr 30, Jun 16, Jul 3 and Aug 4, 2026), https://docs.ovaledge.com/mcp-server/whats-new (checked Oct 3, 2026)
• •OvalEdge Knowledge Portal, Release 8.2, https://docs.ovaledge.com/minor-release/release8.2 (checked Oct 3, 2026)
• •OvalEdge, oe_mcp repository (MIT; governed writes with confirm preview; local stdio setup), https://github.com/ovaledge/oe_mcp (checked Oct 3, 2026)
• •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
• •Data Workers, Spellbook Data Catalog (preview), https://dataworkers.io/product/spellbook-data-catalog/ (checked Oct 3, 2026)
• •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)