What a Bot Should Resolve Before Writing SQL

“Thanks, that's it” is not a request for SQL. “How did you get that number?” may only need an explanation of an earlier result. If every message starts a new search and query, the bot does work the user did not request.

Before accessing data, it helps to identify what the answer needs to do. Counts, lists, comparisons, and explanations have different requirements.

Classify the request

Start with a few categories based on actual questions. A list needs a row limit. An aggregate needs a definition of what to count and how to group it. A comparison may fit in one query or require several steps.

Classification can use a separate model call, but measure whether that call justifies its cost and delay. A simple application may combine it with another step.

Intent classification does not replace authorization. A correctly understood question can still request data the user may not access.

Resolve the entities

“Show employees in Prague” requires a mapping from employees to records and from Prague to a particular office or location. Typos and different word forms can map to the same concept.

The location code should come from the data. If several records match, the system needs a way to preserve that ambiguity or ask a follow-up question.

Turn relative time into boundaries

“Last month” requires a reference date, time zone, and an interpretation such as the previous calendar month. The next stage should receive an explicit interval.

Code can calculate those boundaries. It still matters whether the question refers to a hire date, a posting date, or a contract date. Include those distinctions in test questions alongside misspellings and conversational follow-ups.