# 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.

- Source: https://akshaythakare.com/ideas/agentic-data-quality-investigator
- Stack: Python, LangGraph, MCP, Claude, SQL, PostgreSQL, Apache Airflow
- Tags: agents, data-quality, mcp, langgraph, blueprint
- Updated: 2026-10-11

## 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.

> **Note: Blueprint status**
>
> This is a plan. It has not been built or run; the architecture explorer marks every part **Planned**.

## 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.

## Architecture

```mermaid
flowchart TB
  accTitle: Data-quality investigator architecture
  accDescr: 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.
  C[Failed quality check] --> A[LangGraph agent]
  A <--> M[MCP server: read-only tools]
  M --> W[(Warehouse: SELECT-only role)]
  A --> S[(Run state + audit log)]
  A --> R[Incident draft]
  R --> H[Human review]
```

## The agent's loop

```mermaid
flowchart TB
  accTitle: Investigation loop
  accDescr: The agent reads the failure, forms hypotheses, queries for evidence, evaluates whether evidence is enough, loops or drafts the report, with a step limit.
  U[Read failure and history] --> P[Form hypotheses]
  P --> Q[Run a tool for evidence]
  Q --> E{Enough evidence or step limit?}
  E -- no --> P
  E -- yes --> D[Draft report with confidence]
```

## 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.

## Build plan

### 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.
  
### MCP tool server
Implement read-only tools with validation, limits and logging; test each tool without any model involved.
  
### Agent graph
LangGraph state and nodes: read failure, hypothesize, act, evaluate, draft; checkpoints after each step.
  
### Report format
Structured output: summary, evidence table (query plus result), likely cause, confidence, next step.
  
### Human loop
Post drafts to a review queue; record accept, edit or reject to measure usefulness.
  
### Evaluation
Run all scripted failures repeatedly; compare the stated cause with the known cause.

## 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.

## 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.

Related reading: [Data quality checks](/notes/data-warehousing/data-quality-checks), [Tool-calling patterns](/notes/agentic-ai/tool-calling-patterns), [Model Context Protocol](/notes/ai-tools/model-context-protocol), [Agent memory](/notes/agentic-ai/agent-memory).