Agentic Data-Quality Investigator with LangGraph and MCP

A planned AI agent that picks up a failed data-quality check, investigates with read-only SQL and lineage tools exposed over MCP, and drafts an incident note with evidence — while a human approves anything beyond reading.

BlueprintA planned build: the design, steps and acceptance criteria. Nothing here has been built or run yet.

Advanced

PythonLangGraphMCPClaudeSQLPostgreSQLApache Airflow

~/ideas/agentic-data-quality-investigator

Architecture diagram

Drag the canvas or scroll horizontally to follow the flow

Trigger

Quality checks

Planned

Freshness, volume, uniqueness and referential checks run by Airflow; a failure publishes an alert with table, check and run id.

To

● Data plane: source records → JSONL → Parquet → warehouse● Control plane: execution IDs, job parameters and status━━ Implemented path┄┄ Planned integration● Colored dots show verification status

ch. 011 / 5

Overview & goal

The problem

When a data-quality check fails at 6 a.m., the first hour is the same detective work every time: which upstream table changed, did row counts drop, was something deployed, is this a known pattern? This project explores whether an agent can do that first hour of investigation — and hand a human a clear, evidenced draft.

What this build will deliver

A LangGraph agent triggered by a failed check.
An MCP server exposing read-only investigation tools.
An incident draft with the queries it ran and what they showed.
A human review step before anything else happens.

Safety first

The agent can read, never write. It works through a read-only database role with row limits and timeouts, every tool call is logged, and reruns or fixes stay with a human.

ch. 022 / 5

Architecture

Data-quality investigator architectureSwipe to explore →Technical diagram

A failed quality check triggers a LangGraph agent, which calls read-only tools on an MCP server backed by a read-only warehouse role, checkpoints its state, and drafts an incident report for human review.

The agent's loop

Investigation loopSwipe to explore →Technical diagram

The agent reads the failure, forms hypotheses, queries for evidence, evaluates whether evidence is enough, loops or drafts the report, with a step limit.

Key design decisions

Tools over free-form SQL access. run_select enforces SELECT-only, allowed schemas, a row cap and a timeout; other tools return lineage, check history and recent deploys.

MCP for the tool layer. The same tool server can be used from an IDE assistant or another agent, and permissions live in one place.

Explicit state and step limits. The graph state records hypotheses, evidence and tool calls; a hard cap on steps and tokens stops runaway investigations.

Confidence, not certainty. The report states a likely cause with the evidence for it and what would confirm it.

ch. 033 / 5

Build plan

1
Failure scenarios
Seed a sample warehouse and script five realistic failures: late upstream load, duplicate keys after a bad join, schema change, partial load, and a true data change that is not a bug.
2
MCP tool server
Implement read-only tools with validation, limits and logging; test each tool without any model involved.
3
Agent graph
LangGraph state and nodes: read failure, hypothesize, act, evaluate, draft; checkpoints after each step.
4
Report format
Structured output: summary, evidence table (query plus result), likely cause, confidence, next step.
5
Human loop
Post drafts to a review queue; record accept, edit or reject to measure usefulness.
6
Evaluation
Run all scripted failures repeatedly; compare the stated cause with the known cause.

ch. 044 / 5

Acceptance criteria

Check	How	Pass condition
Read-only	Attempt INSERT/UPDATE/DDL through every tool	All rejected by the tool and the database role
Correct cause	Scripted failures, repeated runs	Cause matches the known cause; rate recorded
Evidence	Every claim in the draft	Backed by a logged tool result
Bounded	Step and token limits	No run exceeds them
Not-a-bug case	Genuine data change scenario	Agent says data looks valid rather than inventing a cause

Results will be recorded here after the build; until then these are the targets.

ch. 055 / 5

Interview angles

How do you let an agent touch production data safely? Narrow tools, least-privilege database roles, limits, audit logs and human approval for anything beyond reading.
Why MCP? One permissioned tool server reusable across clients, instead of bespoke integrations.
How do you evaluate an agent? Scripted scenarios with known answers, repeated runs, and checks that every claim maps to evidence.
What does the data engineer bring to an AI project? Lineage, quality checks, access control and reproducible scenarios — the parts that make an agent trustworthy.