SQL agent vs text-to-SQL — why the validator difference matters.

A text-to-SQL tool generates fresh SQL on every question. The model reads your prompt, reads your schema, writes a new SELECT, runs it. Every turn is a coin-flip on whether the SQL is correct, and you cannot audit what you did not write.

A verified SQL agent inverts that. It routes your question to a query your team already wrote, reviewed, and trusted. If a verified query matches the intent, the agent executes it deterministically and returns the result. Only when no verified query matches does the agent fall back to generation, and even then, it generates inside a typed SQL contract bound to your schema.

The verified library compounds with every question your team asks. The text-to-SQL prompt resets every turn.

Schema hallucination. The model invents column names that look right but do not exist (customer_lifetime_value when the real column is ltv_usd). Runs in dev, fails in prod, takes an hour to debug.

Join drift. The model picks a join key that is correct for one question and wrong for the next (user_id vs account_id vs customer_id) and you only notice when the numbers do not tie out to last quarter’s report.

Aggregation errors. AVG of pre-computed ratios, SUM across snapshot tables, COUNT DISTINCT on a column that has nulls. Plausible-looking numbers, wrong math, decisions made on top of them.

A verified SQL agent avoids these by routing to pre-verified queries instead of regenerating SQL each turn: typed contract enforcement at L1 + L2.

A verified SQL agent helps wherever your team has analytical patterns that repeat. Revenue by segment, retention by cohort, funnel conversion by source: anything you have written more than twice belongs in the verified library. The agent owns the library; your team owns the queries.

It does not help for genuinely novel questions a verified library cannot answer. For those, the agent falls back to generation under a typed contract: slower than a text-to-SQL tool, but the output is contract-bound to read-only SELECT and your RLS-aware schema. You can also ship the result back into the library as a verified skill, so the next person asking it gets the verified path.

Pick a SQL agent when your analytical work compounds. Pick a text-to-SQL tool when it does not.

Pick a verified SQL agent when: your team has 50+ SQL queries already written; analysts are tired of rewriting variations; you need an audit trail; you want answers your security team can sign off on; you want the same SQL working tomorrow that worked today.

Pick a text-to-SQL tool when: you have no SQL library to compile; the volume is low enough that fresh-generation works; you are prototyping and need answers in five minutes; auditability is not a hard requirement; your data is small enough that occasional regeneration errors do not matter.

The two are not mutually exclusive. Many teams run both: a verified SQL agent for production workflows, a text-to-SQL tool for exploration. The choice is which one anchors your daily analytics work.

Chion’s agent runs every SQL through two validator layers before execution. Layer 1 (L1) enforces read-only SELECT: INSERT, UPDATE, DELETE, DROP, ALTER are rejected at the parser, in code, not in the LLM. Layer 2 (L2) enforces a typed SQL contract bound to your schema: only columns your role can see, only joins your schema declares, only aggregations valid for the column types involved.

If a verified query in your library matches the intent, the agent uses it directly. If not, the agent generates SQL inside the contract, runs it through the validator, executes read-only, and surfaces the result with the SQL visible underneath. Every turn writes to an immutable audit trail.

Same architectural pattern as the comparison above, made concrete: routing > regeneration.