Applied AI
A SQL agent knows the schema and still chooses the wrong table
DDL alone rarely tells an agent which tables are current, meaningful or safe to query. Give it bounded evidence and verify the generated SQL.
October 26, 2026
A database schema can be syntactically complete and operationally misleading. A recent data engineering discussion describes agents repeatedly discovering old or empty tables and issuing overly broad queries when DDL was the only context. The post promotes the author's own tools, so its value is the concrete failure mode, not proof that a particular product solves it.
Curate the search space
Start with a short catalog of approved analytical tables: business meaning, grain, freshness, owner, expected row scale and key relationships. Mark deprecated, migration and test tables so the agent does not treat them as equivalent candidates. A small vetted set usually improves a buyer-facing question more than unrestricted access to hundreds of similarly named relations.
Provide bounded examples
Column names do not reveal whether status means an order state, a customer state or a data quality flag. Give the agent safe per-column statistics and a few approved examples where policy allows. Avoid dumping sensitive rows into prompts. Use aggregate distributions or masked samples, and make timeouts and row limits part of the query tool. A generated query should be inspectable before expensive or sensitive execution.
Evaluate table choice before answer quality
Build a set of real business questions with an expected source table, join path and aggregation grain. Score table selection, SQL validity, cost and final answer separately. If the agent picks a stale snapshot, a fluent explanation is still wrong. Review failures with data owners and update the catalog, not just the prompt.
Adovo’s view
An agent does not discover business truth from DDL. It inherits the decisions the data team has made visible. Give it a governed map, then hold it accountable for the route it takes.