
Overview & result
Ask questions about a SQLite database in plain English. Qwen generates SQL and explanations; Jev reviews whether the question is clear, the SQL matches it, and the explanation is supported by returned rows. Deterministic code enforces read-only execution and row limits; Vercel Eve manages the agent loop and human approvals.
From the original post
I built a data analyst agent with Jev as the review layer!
Qwen handles the main agent work, Jev acts as the review layer, and Vercel eve runs the agent loop, tool execution, and human approval flow.
The agent takes a plain-English question about the data, inspects the database schema, writes the SQL, runs the query, and explains the result.
The interesting part is what happens around that main loop.
Qwen is responsible for generating the SQL and the final answer, while Jev reviews the parts where semantic judgment is actually useful. Anything that can be checked reliably with code stays deterministic.
Jev reviews the agent at three points:
- Before the agent starts, it checks whether the user's question is clear enough to answer from the available data.
- After Qwen generates the SQL, it checks whether the query actually represents what the user asked.
- After the query runs, it checks whether the final explanation is grounded in the returned rows.
For example, we tested it with:
“Who is our best customer?”
The question sounds simple, but “best” could mean highest revenue, most purchases, highest average order value, or something else.
Instead of letting Qwen silently choose a metric, Jev flagged the question as ambiguous and asked for clarification.
The same separation applies to SQL execution.
Qwen can propose a query, but it cannot decide whether that query is safe to run. The tool accepts only a single read-only `SELECT`, SQLite runs in read-only mode, results are capped at 200 rows, and queries without a `WHERE` clause can require human approval before execution.
Those checks do not need another model call.
But a query can be completely safe and still answer the wrong question.
A deterministic rule can verify that the SQL is read-only. It cannot reliably judge whether a query for “revenue last month” accidentally calculates revenue across all time.
That is where Jev comes in.
It reviews the proposed SQL against the original question and schema before execution. After the rows come back and Qwen writes the explanation, Jev reviews that answer again to check whether the claims are actually supported by the returned data.
The project uses a local SQLite sales database, Qwen through the Vercel AI Gateway, Gradio for the interface, and only two database tools: "inspect_schema" and "run_sql".
No single model is responsible for everything. Qwen generates, Jev reviews, deterministic code controls execution, and Vercel eve manages the agent loop and approval flow.
GitHub Repo: https://github.com/Sumanth077/Hands-On-AI-Engineering/tree/main/ai_agents/nl_data_analyst_agent
100% open source.
How Jev fits in the loop
- Load a SQLite file or the fictional sales example in Gradio. Jev reviews the question against the schema and known metric definitions.
- Qwen proposes SQL. Code validates it and binds the original question; Jev reviews semantic relevance before execution.
- SQLite runs read-only queries with a 200-row cap; queries without WHERE require human approval. These controls are independent of Jev.
- Qwen writes the explanation. Jev reviews grounding in the returned rows and flags a confident mismatch as an unverified draft for user review.
How to reproduce
- Open the author’s ai_agents/nl_data_analyst_agent folder in the linked repository; follow its README with Node.js 24+, Python 3.10+, pnpm and uv.
- Configure your own AI_GATEWAY_API_KEY following the README. Both Qwen and Jev requests incur provider charges.
- Run pnpm run dev and uv run python main.py in separate terminals, then open the local Gradio interface on port 7860.
- Choose Use demo database, ask one of the README’s example questions, and inspect SQL, rows and approval prompts.
Why this build matters
Offers a practical review layer for SQL analysis: a read-only query can still answer the wrong question.
Limitations
- Source and code inspected; no independent end-to-end analysis or performance benchmark was run.
- The default Jev confidence threshold is 0.70. Low-confidence, inconsistent or unavailable reviews fail open with notes; deterministic SQL restrictions and approvals still apply.
- Designed for local SQLite use. Public or production deployment needs authentication, access controls and stronger query limits.
- Question, schema and answer evidence are sent through the configured model gateway; use appropriate data for the provider.