DataHub Steward Squad

A multi-agent AI team that reads DataHub over MCP, finds governance risks (failing checks, untagged PII, blast radius), writes approval-gated fixes back, and verifies them.

Comment

DataHub Steward Squad — agents that turn DataHub context into governed action

🧭 Inspiration

Data teams don't fail because they lack a catalog — they fail because nobody turns what the catalog knows into action. DataHub already stores what matters: who owns each dataset, what it feeds, which quality checks pass or fail, and where sensitive PII lives. But that context just sits there. I wanted an agent that reads it and does something a steward would actually approve.

🤖 What it does

DataHub Steward Squad is a multi-agent team that runs a full read → analyze → write back → verify loop over the Model Context Protocol (MCP) against real DataHub.

Five deterministic specialists do the detection, and a Chief Steward powered by Claude reasons over their grounded findings:

  • Catalog Scout — selects relevant assets & coverage gaps
  • Lineage Investigator — traces upstream/downstream blast radius
  • Quality Sentinel — catches failing assertions & untagged PII
  • Stewardship Writer — drafts approval-gated MCP writeback proposals
  • Release Captain — packages SQL guardrails, a dashboard, and demo evidence
  • Chief Steward (Claude) — reasons the findings into a prioritized action plan

Crucially, it doesn't just plan — it writes fixes back through the official mcp-server-datahub mutation tools and re-reads to prove they landed.

📊 Real results (from an actual run)

On the bundled Finance fixture (--query revenue):

  • 4 assets inspected → 5 findings (1 critical, 4 high)
  • Critical: finance.fct_revenue failing a negative-revenue assertion — 18 rows observed vs 0 expected ("refund adjustments arriving without offsetting credit memos") — feeding certified downstream (Executive Revenue KPI, churn_risk_model)
  • customer_email flagged as untagged PII
  • 2 approval-gated writebacks applied and verified: customer_email.tags [] → ['PII']

Pointed at a real local DataHub over MCP, the same loop scales to 6 assets, 13 findings, 6 verified writebacks.

🛠️ How I built it

  • Core in pure Python (standard library only) — the offline path has zero dependencies, so judges can run it in seconds.
  • Real MCP loop: an MCP client launches the official mcp-server-datahub via uvx, reconstructs the graph from real search / get_entities / get_lineage calls, and applies approved fixes through real update_description / add_tags / save_document tools. I inspected the real server's interface and wrote an adapter for its GraphQL-shaped responses — I do not reimplement DataHub.
  • Two reasoning engines: a Claude engine (real agentic reasoning, called over the stdlib — no SDK) with a deterministic fallback, so it always runs, key or no key.
  • Zero-credential offline mode: a bundled DataHub-shaped mock MCP server speaks the same tool names as the official one, so the demo never breaks.
  • Approval-gated by design: every mutation is a proposal until a human approves it.
  • Generates a dashboard.html, risk report, executive brief, SQL guardrails, and a machine-readable writeback plan.

🧩 Challenges I faced

  • Driving the real MCP server, not a mock of my own imagination — I recorded real server responses (tests/fixtures/live/) and wrote an adapter for its GraphQL shapes.
  • Keeping the LLM honest — Claude only reasons over findings the deterministic agents actually detected, so it can't invent risks.
  • Live/offline parity — the mock and the real server share tool names so behavior matches.
  • Verifiable mutations — re-reading through MCP to prove a change actually landed.

📚 What I learned

  • MCP is a genuinely good read and write governance layer, not just a retrieval protocol.
  • Grounding an LLM to a fixed set of detected facts makes agentic output trustworthy.
  • You can test a live integration offline by checking parsers against recorded real-server responses — 29 tests, green, including the live adapter.

🚀 What's next

  • More mutation tools (owners, glossary terms, domains) and more specialist agents.
  • Contribute the stewardship pattern back as a DataHub Skill.
  • Scale the same governed loop to any DataHub tenant.

▶️ Try it (zero credentials)

python -m datahub_steward_squad run --query revenue --focus-domain Finance
# offline MCP writeback loop:
python -m datahub_steward_squad mcp-demo --apply
# point it at real DataHub:
python -m datahub_steward_squad mcp-demo --live --apply

Sample outputs are in examples/outputs/latest/. Run the suite with python -m unittest discover -s tests (29 tests, green).

📝 Disclosure

New work for the Build with DataHub hackathon. Uses affaan-m/ECC as a design reference for multi-agent team structure only — no ECC source is copied. Licensed Apache-2.0.

Built With

Share this project:

Updates