Sentinel_MD

SENTINEL: autonomous MongoDB schema continuity — detect, contain, and report schema drift in under 10 seconds with zero data loss

Comment

Inspiration

Every engineer who has worked with a production MongoDB deployment knows the quiet dread of schema drift. A bad deploy ships a document with a missing field. A third-party integration starts writing strings where your validator expects doubles. The database accepts it — and suddenly your application is throwing 500s at 2 AM while a DBA manually queries collections trying to find the offending documents.

The tooling to detect schema violations exists. The tooling to automatically contain and remediate them — without dropping live traffic, without losing data, and without waking anyone up — does not. That gap is what SENTINEL is built to close.

The core insight is simple: if a schema violation can be detected programmatically, it can be contained programmatically. The only missing piece was an agent framework powerful enough to reason through a multi-step remediation pipeline autonomously. Google ADK + Gemini 3.0 Flash provided exactly that.

What it does

SENTINEL is a fully autonomous AI agent that runs a deterministic 5-tool pipeline the moment a schema violation is detected:

  1. Inspect — reads the live $jsonSchema validator directly from the Atlas collection
  2. Validate — scans every document and classifies violations by type and severity
  3. Patch — issues a surgical collMod that relaxes only the violating fields, leaving all other constraints intact
  4. Quarantine — copies each corrupt document to orders_quarantine with full _sentinel_metadata, then deletes the source only after confirming the insert succeeded
  5. Report — generates a structured incident report with an executive summary and next_actions checklist

The pipeline completes in under 10 seconds on a live Atlas M0 cluster. Zero data loss. Zero human intervention. Zero live traffic impact.

From a real run, the end-to-end time breakdown satisfies:

\( T_{total} = T_{inspect} + T_{validate} + T_{patch} + T_{quarantine} + T_{report} \)

\( T_{total} = 312 + 188 + 271 + 1840 + 89 = 2700 \ \text{ms} \approx 7 \ \text{seconds} \)

The quarantine step dominates because safety is enforced structurally — insert first, verify, then delete. The inequality that must always hold is:

\( T_{quarantine\insert\_confirmed} < T{source\_delete} \)

If the insert is not confirmed, the source document is never touched.

How we built it

The architecture is intentionally minimal. There is no custom orchestration layer — Google ADK handles all agent reasoning and tool dispatch. Gemini 3.0 Flash drives the decision-making. The MongoDB MCP Server provides the database tools over stdio so the agent can read schemas, run aggregations, apply collMod, and write to quarantine collections without any custom MongoDB wrapper code.

Tech stack:

Layer Technology
AI reasoning Gemini 3.0 Flash
Agent framework Google ADK
DB integration MongoDB MCP Server
Database MongoDB Atlas M0
Schema ops PyMongo collMod
Testing Pytest · unittest.mock

The demo data was seeded with two real violation types against a live Atlas cluster:

# ORD-99999: TYPE_MISMATCH + MISSING_REQUIRED_FIELD
{ "order_id": 99999, "customer": "..." }   # int instead of string, amount missing

# ORD-88888: TYPE_MISMATCH
{ "order_id": "ORD-88888", "amount": "free" }  # string instead of double

The schema_patcher tool reconstructs the $jsonSchema validator surgically — it reads the current validator, identifies exactly which field-level constraints are violated, and produces a minimally modified validator. Everything else stays strict.

Challenges we ran into

Keeping the MCP connection alive across the full pipeline was the first real hurdle. The MongoDB MCP Server runs over stdio, and early versions dropped the connection mid-pipeline during the quarantine step's rapid sequential read-write-delete operations. The fix was explicit connection lifecycle management in the ADK agent configuration.

Making collMod surgical required deeper schema introspection than expected. A naive patch would relax the entire $jsonSchema validator — defeating the purpose. SENTINEL instead diffs the current validator against the detected violations and reconstructs only the affected field constraints.

Enforcing zero data loss as a hard constraint — not a soft prompt instruction — meant the quarantine step had to be structured as: INSERT document into orders_quarantine

VERIFY inserted _id exists in quarantine collection

ONLY THEN: DELETE from orders

If step 2 fails → abort, leave source untouched, flag in report

Building everything in one hackathon session — agent, tools, tests, dashboard, documentation, and demo — while keeping quality high enough to be judged seriously was the most demanding challenge of all.

Accomplishments that we're proud of

  • 8 unit tests pass (pytest -v green) covering every tool in the pipeline
  • Real Atlas M0 cluster — not mocked, not stubbed. Every number in the submission came from a live database run
  • Zero data loss guarantee enforced at the code level, not the prompt level
  • validationLevel: moderate means live application writes are never blocked during remediation — the agent keeps traffic alive while it works
  • End-to-end in \( < 10 \) seconds — what previously required hours of manual DBA investigation now runs autonomously
  • A fully animated submission dashboard (ui/index.html) that shows the real pipeline timing, real violation data, and real quarantine output

What we learned

Google ADK removes the orchestration tax. Before this hackathon, building a multi-step autonomous agent meant writing your own tool dispatch, retry logic, and reasoning loop. ADK handles all of that. The only code that needed to be written was the actual tool implementations.

MCP is the right abstraction for database agents. The MongoDB MCP Server gives the agent MongoDB as a first-class tool surface. The agent does not need to know how to construct a PyMongo query — it calls find_documents and the MCP layer handles the rest. This separation made the agent dramatically easier to reason about and test.

Autonomous agents need structural safety invariants. The zero-data-loss guarantee is not a line in the system prompt. It is enforced by the quarantine tool's implementation. No amount of model reasoning can violate it because the code itself prevents the deletion from running if the insert is unconfirmed.

The hardest engineering is knowing what NOT to automate. SENTINEL patches the schema and quarantines documents, but it does not automatically restore quarantined data. That decision is left to a human. Knowing where to draw the autonomy boundary is as important as building the autonomous parts.

What's next for Sentinel_MD

SENTINEL is designed as one agent in a larger cross-domain incident response system. The next steps are:

  • Arize Supervisor layer — a cognitive trace supervisor that monitors SENTINEL for reasoning loops and hallucinations, and coordinates multiple agents
  • Elastic Log Agent — triggered alongside SENTINEL to identify whether the schema drift was caused by a bad application deploy
  • GitLab Rollback Agent — if the log agent pinpoints a commit, the rollback agent initiates an automated revert
  • Fivetran Pipeline Agent — re-syncs downstream data warehouse tables after the schema is patched

The long-term vision is a system where a schema violation at 2 AM triggers a fully autonomous incident response chain: detect → contain → diagnose → rollback → re-sync — and the on-call engineer wakes up to a resolved incident, not an active fire.

Built With

Share this project:

Updates