#16. Weekly AI for Newsroom Round Up. How to manage intents to help AI?

Hello! This is Sergei. Ready for a nerdy newsletter? Here we go.

I’ve been building a composite news media dashboard — one place where a newsroom can look at performance across all platforms at once: website, social, YouTube, podcasts. Not as separate channels, but as a single product. To avoid endless dashboards and edge cases, I ended up doing the simplest thing: an AI chat over the entire database, across all datasets and platforms.

The hardest part was to figure out how to avoid AI overload and hallucinations when the model is asked questions about a lot of data. The solution was architectural. I designed a three-stage AI processing flow that keeps things simple, controlled, and predictable.

Here’s how it works.

When a user types a message into the Dashboard chat, the system runs it through three stages.

Stage 1: Intent classification.

A Groq model (I’m using openai/gpt-oss-20b here) reads the user’s message along with a lightweight summary of the database schema. Its job is very narrow: decide whether this is actually a data question, identify which tables and fields are involved, understand the time range, and infer what kind of output the user expects. If it’s not a data question — greetings, help, clarification — the system responds immediately without touching the database.

Stage 2: SQL generation.

Only if Stage 1 confirms this is a real data query do we move on. The model receives the full schema (tables, columns, JSONB keys), the classified intent from Stage 1, a few carefully chosen examples, and the user_id for row-level security. The output is a single SQL query. Nothing else. No explanations, no comments. The prompt is strict so the SQL is machine-parseable without guessing.

Stage 3: Execution and answer synthesis.

The backend runs the SQL. If something fails validation or errors out, the pipeline stops and returns a safe message. If it succeeds, the raw result rows are sent back to Groq model together with the original question. The model then turns those rows into a natural-language answer. The user gets the explanation, and optionally a small inline table with the raw data.

Why not do all of this in one prompt? Because separation matters. Stage 1 acts as a gatekeeper and keeps the heavy prompts short. Stage 2 is isolated because SQL must be precise — once you mix it with “helpful explanations,” models start hallucinating clauses. Stage 3 ensures the model explains actual query results, not something it half-remembers.

And it works.