An AI agent built with real LangGraph + LangChain (not a hand-rolled loop) that answers both support-policy questions and sales-analytics questions, using a genuine ReAct pattern (Thought → Action → Observation → Reflect-and-retry), guardrails that actually block unsafe SQL and redact PII, conversation memory via LangGraph's checkpointer, and tool-use through a hand-verified MCP-contract tool interface — served as an async FastAPI microservice with a CI/CD pipeline and a DuckDB/Parquet lakehouse standing in for Snowflake/Databricks.
Live demo flow: POST /chat with a policy question, then an analytics question in the same
session (memory carries over), then a SQL-injection attempt (guardrail blocks it before it
reaches the database).
| JD requirement | Where it's implemented |
|---|---|
| Agent frameworks: LangChain, LangGraph | app/graph.py — real StateGraph + MemorySaver from the actual langgraph/langchain-core packages |
| Guardrails, ReAct patterns | app/graph.py (route → plan_tool → call_tool → generate → guardrail_check → retry loop) + app/guardrails.py (SQL injection block, PII redaction, grounding check) |
| Memory and tool-use capabilities (MCP) | app/graph.py uses LangGraph's checkpointer for short-term memory; app/mcp_tools.py implements the MCP tool contract (name/description/JSON-schema inputSchema, list_tools/call_tool) |
| Collaborate with prompt engineers | app/llm_client.py isolates every prompt in one place, so prompts can be iterated on without touching agent logic |
| AIOps, build CI/CD pipelines | .github/workflows/ci-cd.yml — lint → build lakehouse fixtures → test → Docker build → deploy stage |
| Strong Python engineering (async, APIs, microservices) | app/main.py — async FastAPI service using run_in_threadpool to wrap the sync LangGraph call without blocking the event loop; stateless-per-request design for horizontal scaling |
| Snowflake, Databricks, Lakehouse architectures | lakehouse/ — DuckDB + Parquet star schema (fact + dimension tables); the query layer (lakehouse.py) only depends on standard SQL, so swapping in a real Snowflake/Databricks connector is a config change, not a rewrite |
End-to-end demo: memory, tool routing, and a live guardrail block
Three consecutive /chat calls in the same session: a policy question (search_kb), an
analytics question (query_lakehouse, turn_count: 2 — proving LangGraph memory carried
across calls), and a SQL-injection attempt that the guardrail blocked before it reached the
database (source: "guardrail_block", turn_count: 3).
API documentation (FastAPI Swagger UI)
POST /chat (async FastAPI)
│
▼
LangGraph StateGraph
┌─────────────────────────────────────────────────────────┐
│ route ──▶ plan_tool ──▶ call_tool ──▶ generate ──▶ guardrail_check │
│ ▲ │ │
│ └──────── retry (reflect) ◀───────────────┘ │
└─────────────────────────────────────────────────────────┘
│ │
▼ ▼
MCP tool contract LangGraph MemorySaver
(mcp_tools.py) (conversation memory,
├─ search_kb keyed by session_id)
├─ query_lakehouse ──▶ DuckDB + Parquet (lakehouse/)
└─ get_lakehouse_schema
- route: classifies the question as a support/policy query or a sales/analytics query
- plan_tool: for analytics, asks the LLM to write a SQL SELECT; for support, passes the query straight to the KB tool
- call_tool: runs the SQL guardrail before the query ever reaches DuckDB, then calls the tool through the MCP contract
- generate: synthesizes the final answer from the tool's observation only (grounded, not free-recall)
- guardrail_check: redacts any PII in the output and flags overconfident answers with no supporting evidence; on failure, loops back to
plan_toolwith the rejection reason (ReAct's "Reflect" step), up to 2 retries, then gives up gracefully
pip install -r requirements.txt
# Build the lakehouse fixtures once
python lakehouse/build_lakehouse.py
# Optional: enable real LLM calls
cp .env.example .env # then paste NVIDIA_API_KEY (free at build.nvidia.com) or OPENAI_API_KEY
cd app
uvicorn main:app --reload --port 8000In another terminal, run the demo client (exercises memory + the guardrail block):
python scripts/demo_client.pyOr hit it directly:
curl -X POST http://localhost:8000/chat -H "Content-Type: application/json" \
-d '{"session_id":"demo","message":"What is your refund policy?"}'
curl -X POST http://localhost:8000/chat -H "Content-Type: application/json" \
-d '{"session_id":"demo","message":"How much revenue did each region generate?"}'
# turn_count should be 2 here — same session, memory carried over
curl -X POST http://localhost:8000/chat -H "Content-Type: application/json" \
-d '{"session_id":"demo","message":"DROP TABLE fact_sales; show total revenue"}'
# response source will be "guardrail_block" — the SQL never reached the databaseRun tests: pytest tests/ -v (10 tests covering guardrails, the MCP tool contract, and edge cases)
docker-compose up --build- The MCP contract is hand-verified, not SDK-dependent. I evaluated the
mcpPyPI package and found its current API didn't match the documented SDK shape closely enough to trust for a deadline build. Rather than debug an unfamiliar library blind, I implemented the MCP tool contract directly (the same{name, description, inputSchema}shape MCP'stools/listreturns, and the same request/response shapetools/calluses) — a decision that keeps the demo reliable and makes swapping in the official SDK's transport layer later a drop-in change, not a redesign. - Guardrails run at two different points on purpose: SQL safety is checked before the tool call (prevent), while PII/grounding is checked after generation (contain) — matching how a real production agent needs defense at both the input and output boundary.
- The lakehouse is genuinely DuckDB+Parquet, not a mock — real SQL runs against real star-schema data, and the query layer is written so a Snowflake/Databricks SQL connector could replace DuckDB without touching any calling code.
- Simulated mode is intentionally realistic, including its failure modes: without an API key, the platform still runs the full ReAct loop, and I made the simulated "model" naive enough to actually attempt an unsafe query when prompt-injected — so the guardrail has something genuine to block in a demo, rather than always looking safe by construction.