Governed NL→SQL Agent

The problem

Natural-language querying is compelling, but in regulated finance you cannot ship a black box that writes and runs its own SQL against production data. Every answer has to be explainable, reproducible, and logged. The interesting question isn’t “can an LLM write SQL” — it’s “how do you let it help without handing it the keys.”

Approach

The core stance is a division of labour: the model interprets, deterministic code executes. The LLM classifies intent and drafts a candidate query. From there, ordinary Python and SQL take over — the parts you can test, prove, and audit.

• Intent classification and query drafting handled by the model, constrained to a known schema.
• Generated SQL passed through deterministic validation before it ever touches the database.
• Read-only execution against a scoped surface — no writes, no unbounded scans.
• Every step — prompt, draft, validation result, final query, rows returned — written to an audit log.

Architecture

A thin orchestration layer routes each request through interpret → validate → execute → log. The model never runs anything directly; it proposes, and the deterministic pipeline disposes. That boundary is the whole design, and it’s what makes the system defensible in a regulated setting.

What it demonstrates

This is the atomic unit the rest of my work is built on. It shows LLM flexibility without surrendering auditability — the exact trade a bank’s controls function needs met before natural-language tooling can go near real data. The same pattern scales up into the multi-agent AML assistant.