-
-
Logo
-
Architecture Diagram
-
PR remediation button on work
-
chart bars
-
Activity Log
-
Artifact
Inspiration
Data catalogs excel at detecting schemas, lineage, and data quality issues, but closing the gap between detection and safe remediation remains a manual engineering bottleneck. In early iterations, running an automated scan generated a single, monolithic SQL script containing all detected fixes across an entire dataset. This forced a binary choice: either merge all 20 fixes at once via a Pull Request, or manually dissect raw SQL to exclude edge cases before merging.
We built Albugent v2.0 to solve this exact bottleneck. True human-in-the-loop governance requires fine-grained control: engineers need the ability to approve one patch immediately, reject another due to domain context, and leave a third for further review — without wrestling with monolithic SQL scripts or granting an unsupervised LLM direct write access to production databases.
What it does
Albugent v2.0 is an autonomous data governance agent and live dashboard that audits SQLite datasets for PII, quality anomalies, and pipeline staleness, providing two entry points over a shared deterministic core:
- Autonomous CLI Agent: Runs pure-Python profilers to generate reproducible SQL cleanup scripts, orchestrates an agentic investigation (Strands Agents SDK + AWS Bedrock Nova Pro) over read-only Model Context Protocol (MCP) tools, and opens a structured GitHub Draft PR containing an executive summary and SQL artifacts.
- Interactive Web Dashboard: A FastAPI + React UI displaying live KPIs, downstream lineage maps, and PII severity distributions. It unbundles detected anomalies into single-issue RemediationPatch proposals, letting engineers approve or reject fixes individually with one click, and can trigger the same agentic PR flow on demand.
How we built it
- Agent & MCP reasoning: Built with the Strands Agents SDK connected to AWS Bedrock (Nova Pro) and a FastMCP server exposing read-only tools (
inspect_dataset_schema, check_row_impact,score_dataset_risk) over stdio. - Deterministic backend: FastAPI directly invoking pure-Python profilers (
anomaly_profiler.py, pii_detector.py,lineage_discoverer.py) and NetworkX graph algorithms (betweenness centrality) for zero-LLM anomaly detection and SQL generation. - Frontend: React, Vite, Tailwind CSS v4, and Recharts for a real-time governance dashboard.
- Storage & structural isolation: Processes multi-domain SQLite datasets (
healthcare, fiction-retail,nyc-taxi) with complete write-path isolation — patch application (patch_applier.py) is a plain Python function called exclusively by the dashboard's approval endpoint, never exposed as an MCP tool.
Challenges we ran into
Dual-Entry Deterministic State Synchronization: Maintaining a unified, deterministic database state between two independent entry points (agent.py CLI and the FastAPI Web UI). Because both entry points operate on the exact same .db files, executing a patch via the dashboard alters the database in place—requiring the profiling engine to dynamically resolve these anomalies across subsequent CLI scans without state drift or race conditions.
Unbundling Monolithic Remediation into Discrete Patches: Refactoring the core engine from generating table-wide SQL scripts into isolated, single-anomaly RemediationPatch objects, while preserving accurate downstream lineage graph calculations and risk impact scores for each patch individually.
Structural Write-Path Isolation for Zero-Trust LLM Safety: Enforcing safety as an architectural boundary rather than a system prompt instruction. The patch applier (patch_applier.py) is a plain Python function deliberately excluded from MCP tool definitions, making it physically impossible for the LLM to execute database write operations under any prompt condition.
Silent Data-Contract Mismatches in Risk Scoring: Resolving subtle data-contract bugs where function signature mismatches caused evaluate_dataset_risk to receive incomplete parameter payloads, silently calculating overall dataset risk scores to zero without throwing explicit runtime exceptions.
Accomplishments that we're proud of
- Structural write isolation: Instead of relying on a system prompt telling the model "don't modify the database," we structurally isolated the write path — the LLM has no code path or tool that can execute a database write, regardless of what it's asked.
- Granular human-in-the-loop control: Replaced binary, all-or-nothing PR merges with individual, per-anomaly patch approval in a live dashboard.
- Fully deterministic remediation: Every SQL fix is compiled by a Python profiler, never generated by an LLM prompt — no SQL syntax errors, no statistical hallucination.
What we learned
- Strict division of labor: LLMs are valuable where a task requires reasoning over ambiguity — deciding what order to investigate datasets in, writing a readable executive summary. They're harmful where a task has one computable answer — PII detection, exact SQL generation. Blurring that line is where things go wrong.
- Structural safety beats prompt engineering: Safety should be an architectural constraint, not an instruction. Don't ask a model to be careful — remove its ability to do the dangerous thing at all.
What's next for Albugent v2.0
- Full circuit-breaker automation: The current circuit breaker computes and surfaces a HALTED/MONITOR/OK status per dataset, but doesn't yet halt downstream processing automatically — that requires wiring it into a real orchestrator.
- Critic/verifier agent pattern: A second agent pass to check the Phase 2 investigation report against raw tool output before it reaches the PR.
- Bedrock AgentCore deployment: Moving the agent runtime to Amazon Bedrock AgentCore for managed scaling, identity, and observability once this moves beyond single-operator use.
- Automated CI tests: CI-gated tests verifying SQL correctness post-patch, not just manual verification.
Log in or sign up for Devpost to join the conversation.