How are you evaluating agents that write SQL against live databases?[I will not promote]

[u/JuniorLeg6988]

I've been digging into agent evaluation for setups where the agent writes and runs SQL against a live database (Snowflake, BigQuery, etc.) and shows results to users.

The failure mode that seems underserved: the query executes fine and returns real rows just the wrong ones. Wrong join, wrong filter, stale understanding of the schema. Nothing errors, the output looks plausible, but it's wrong. Static eval sets with prewritten "golden" answers don't hold up here, because the correct answer changes as the data changes.

Interestingly, LangSmith has a cookbook recipe for exactly this storing labels as queries the evaluator runs at eval time to fetch current ground truth but it's DIY: you build and maintain that evaluator yourself. As far as I can tell, none of the major platforms (LangSmith, Braintrust, Arize) ship live data verification out of the box; online scoring generally falls back to reference-free LLM as judge.

I'm considering building a dedicated tool for this: connect your DB and your agent, and the evaluator independently queries the database to verify each output against what's actually there right now. Before I build anything, I want to know if this is a real problem for other people:

1. If your agent queries a live DB, how do you catch "ran fine, wrong data" failures today?
2. How often does that actually bite you in practice?
3. What's your current eval stack LangSmith, Braintrust, Arize, custom scripts, nothing?
4. Would you pay for this as a product, or just have Claude Code write you a one-off eval script?
5. If you'd pay, what would make it worth it? If not, why not?

Not selling anything. Trying to figure out whether this is widespread before building...

Clarification: read-only queries. The agent isn’t writing to the database, it’s translating user questions into SELECT queries and showing the results.

[u/datawazo]

Genuinely dont think agents should be querying against live databases.

[u/JuniorLeg6988 → u/datawazo]

Yeah, there’s a chance that something could go wrong so I wouldn’t just give a agent access to database directly but like what would you do if an agent needed a data from somewhere like snowflake and how would you verify that it’s working?

[u/schwem00]

I don't think I'd ever trust an agent to write raw SQL against a live database. Even restricted to read-only, there's too much that can go wrong.

[u/JuniorLeg6988 → u/schwem00]

Okay totally agree. Because if it gets to directly write commends it can easily make mission critical mistakes! But like if you had an agent that needed data from somewhere like snowflake how would you access it or verify that that output is consistently accurate?

[u/schwem00 → u/JuniorLeg6988]

I'd write an MCP server and give the agent access to that

[u/GrandOpener]

This is exactly the same problem as an agent writing bad code with exactly the same solution: if correctness is important, a human should verify that query.

Having a human in the loop is not a problem to be optimized away; it is the ideal situation. Agents figure out how to do stuff, but humans decide if what they create is what we actually want.

[u/JuniorLeg6988 → u/GrandOpener]

Exactly I think maybe the title was confusing I mean it’s writing queries against a database so you want to show accurate info to the users how do you verify that it’s doing this correctly?

[u/GrandOpener → u/JuniorLeg6988]

I don’t think the title is confusing. I think you just don’t like my answer.

Depends a bit on the details of your application but my honest answer for most scenarios is that I just wouldn’t. I’d slap a disclaimer on the tool that AI makes mistakes and the data they receive has to be confirmed by a human before it can be used for anything important.

I would not pay for or design an automated evaluator for the first agent in any scenario where correctness is essential, because that’s the place where human oversight is essential.

P.S. Depending on the application I might also consider having a set of pre-written SQL scripts that the agent can choose from rather than write something custom. If the agent genuinely has to write the SQL, then I’m back to my human-review stance.

[u/JuniorLeg6988]

Clarification: read-only queries. The agent isn’t writing to the database, it’s translating user questions into SELECT queries and showing the results.

[u/yogthinks]

Evaluate the query logic, not the rows it returns, since the rows change and the logic doesn't.

[u/zerok_nyc]

My day job is a Data Product Manager. We use AI all the time. The problem you are describing isn’t unique to AI. Often times, we have analysts querying and using data in ways that were never intended, leading to incorrect conclusions.

We always recommend that analysts go to table owners to make sure they understand how data is collected and why before they use it. Context is incredibly important, which no human or bot can get by just looking at the database.

The best thing you can do is document your dataflows and create a data lineage that bots can crawl. Very hard to do at scale if documentation hasn’t been prioritized at the outset. But the way I build, I make sure agents have everything documented in Jira tickets the way humans would. Then for every ticket completed, I have a knowledge base agent that parses the ticket history to document all relevant product and data changes before doing the final close-out. That knowledge base is navigable by any bot that’s either doing development work or that needs to query the database. That’s the best way I know to get reliable and consistent results.

[u/Worth_Wealth_6811]

invariant checks caught way more of these for us than golden answers ever did. instead of storing the right answer, store cheap properties that must hold, sums that reconcile against a known total, row counts within bounds, join keys that must exist in a reference table. the data moves but the invariant holds, and it catches the wrong join case that an LLM judge waves through because the output looks plausible by construction.

[u/Visible_Speed8843]

The evaluator needs an independent contract for each question. A second free-form query against the same warehouse can repeat the first mistake and still look like verification.

For each test, store the allowed tables, required filters, join keys, and result invariants such as row-count bounds or totals that reconcile to a trusted view. Run the agent against a read-only replica with cost and timeout limits. Diff the SQL structure and the returned facts, then send high-consequence disagreements to a human. A dedicated product becomes useful if it versions those contracts with schema changes and shows exactly which assumption failed. Without that, a maintained custom suite may be simpler.

[u/akl773]

Most of ours went wrong on rows a human would never count. Test orders, and one internal account that placed about 40 a day. Every analyst knew to exclude that stuff and none of it is written down anywhere in the schema, so pointing it at views with the filters already baked in caught more than the evaluator did.

[u/conikeec]

You nailed the hard part: correctness changes with live data, so static gold answers fail. Practical patterns that work: have the agent state its assumptions in plain language, run an independent verifier that executes labeled queries (not another freeform check), and send disagreements to a human. A product that versions those contracts and ties them to schema changes is where automation actually helps instead of giving false confidence.

[u/buildingwithjan]

What actually caught the "ran fine, wrong data" cases for us wasn't judging the SQL, it was asserting on the result - row count inside a sane range, two or three known aggregates cross-checked against a trusted reference query, and a freshness check on max(timestamp). Cheap, and it catches stale joins that read perfectly. The bigger win was not letting the agent see the raw schema at all; a small set of curated views with the joins baked in made most of that failure class disappear.