botminds.aiRequest a demo

Academy · Solutions · Agentic Search

Build: Enterprise data Q&A

In one line. An assistant that lets non-technical staff ask plain-language questions over tabular data — the agent writes read-only SQL against a Datasheet underneath. You’ll build. A Sales Data Datasheet (sourced from a connection or materialised from a View), a Sales Analyst chat agent that becomes a SQL agent by attachment, a persona that shows its query and assumptions, and the consumer Chat experience. You’ll use. D5 · Drive & datasheet, A3 · Your first agent, A5 · Tools & functions, E4 · Chat & search experience, E7 · Shaping the experience.

Your operational truth lives in tables, not prose: a sales ledger, an inventory feed, a transactions export. Today only the analysts who speak SQL can ask them anything; everyone else waits for a report. This build gives staff an assistant that answers “top 10 customers by revenue last quarter” or “how many orders shipped late in March?” correctly, with the agent writing the SQL underneath. Budget about 30 minutes plus the Datasheet’s first materialise run. You need a project (E1 · Getting oriented), at least one LLM registered (A2 · LLMs & services), the Datasheet model from D5 · Drive & datasheet, and your tabular data ready: a spreadsheet, a database or API the platform can reach, or a Collection you already extract from.

How this differs from B1 · Policy assistant: both are Agentic Search, but they retrieve in opposite ways. The Policy assistant does vector RAG — it embeds your question, finds the nearest document chunks, and quotes them. This assistant does SQL retrieval — it writes a SELECT against a flat table and computes the answer. Vector search can’t reliably count or rank; SQL can’t paraphrase a paragraph. Same pattern, two engines — and the single wire that picks the engine is what you attach on the agent’s Knowledge tab: a Datasheet means SQL agent.

(A) spreadsheet / database / API ──┐            (B) a Collection you already extract from
     via a source connection       │                → View of its labels → materialise
                                   ▼                                   │
                     Sales Data (DATASHEET — a flat SQL table) ◄───────┘
                     customer · region · product · order_date · revenue …
                     + system cols _BM_STATUS · _BM_RUN_ID · _BM_JOB_ID
                                   │ attach on the agent's Knowledge ▸ Datasheet sub-tab
                                   ▼
                     Sales Analyst (chat agent)
                     datasheet bound ⇒ built-in SQL toolkit switches on
                                   │
                                   ▼  App ▸ Chat
     You: "Top 10 customers by revenue last quarter."
     Analyst: "Here are the top 10 … [table]
               I ran: SELECT customer, SUM(revenue) … GROUP BY … LIMIT 10"

Two halves: the data layer (get rows into a Datasheet) and the assistant (a chat agent whose attached Datasheet turns on the SQL toolkit).

Steps

Stage 1 — Get your data into a Datasheet

A Datasheet is the platform’s structured-data layer: a flat SQL table an agent can query directly (D5 · Drive & datasheet). It lives at Studio ▸ Data Model ▸ Data. There are exactly two sourcing paths — pick the one that matches where your data already lives.

(A) Sourced from a connection (B) Materialised from a View
Use when… your data is in a spreadsheet / database / API your data is the extracted fields of a Collection you already process
Rows come from a source connection pulling the external system a saved View’s columns, flattened into the table
Typical case a sales export, an ERP feed, an inventory CSV “I already extract invoices — let me analyse them”

Path A — sourced from a spreadsheet, database, or API:

  1. Open Studio ▸ Data Model ▸ Data.
  2. Click + Datasheet (footer of the left rail) to open the add-datasheet dialog.
  3. Name: Sales Data. Description: Quarterly sales ledger — customers, regions, products, revenue.
  4. Choose its source: pick or create a source connection (a database, spreadsheet, or API binding — the same connections listed under the left rail’s Sources tab). For a one-off spreadsheet, create a connection pointing at it; for a live system, a DB/API connection.
  5. Confirm. The Datasheet appears in the list with a status icon. Open it: the Data sub-tab shows the rows, Run Info shows the first materialise run.

Path B — materialised from a document View. If your numbers are really extracted fields from documents you already process (e.g. the amount / vendor / date pulled from invoices in B3 · Invoice settlement), don’t re-key them — flatten them:

  1. Build a View over that Collection surfacing the columns you want to analyse — e.g. customer, region, revenue, order_date (E7 · Shaping the experience).
  2. In Studio ▸ Data Model ▸ Data, click + Datasheet, name it Sales Data, and for its source point it at that View instead of a connection. Each document becomes a row; each surfaced label becomes a column.

Both paths stamp three platform-managed system columns beside your own — you neither create nor edit them:

Column Meaning
_BM_STATUS the row’s processing status (e.g. OK / pending / error)
_BM_RUN_ID which materialise/refresh run produced the row
_BM_JOB_ID which ingestion job the row is associated with

They let the platform reconcile rows across re-runs without duplicating them — and your agent can filter on them too (e.g. only _BM_STATUS = 'OK' rows).

Sanity-check the data before you wire an agent: on the Data sub-tab, toggle Filter and run a query like "region" = 'EMEA' (quoted-column syntax: "col" = 'value'), then Apply Query. If that returns the rows you expect, the agent’s SQL tool will too — you’re issuing SQL against the very same backing table the agent reads.

Under the hood. The backing table is named like DATA_SHEET_{id}_{guid}. The Data tab’s filter, the Run Info history, and the agent’s SQL tool all read that one table.

Checkpoint. Sales Data appears in the Datasheets list with a healthy status icon; its Data tab shows your rows plus the three _BM_* system columns; a Filter query returns the slice you expect.

Stage 2 — Build the “Sales Analyst” chat agent (it becomes a SQL agent)

The table exists; now build the Reader that answers over it — the agent editor from A3 · Your first agent.

  1. Go to Studio ▸ Agent Builder ▸ Agents. Click + Agent ▸ Agent — the tabbed editor opens beside a live Playground.
  2. Persona tab — who the agent is (you’ll tune the prompt fully in Stage 3). Name: Sales Analyst. Description: Answers plain-language questions over the Sales Data table.
  3. Model tab — what powers it. Pick your project’s LLM Model. Set Agent Mode = Thinking while you tune (you’ll watch it choose columns and write SQL); flip to Fast for production. Leave Advanced sampling at defaults.
  4. Knowledge tab — the load-bearing step. This tab has three sub-tabs — a View, a Datasheet, and (flag-gated) Knowledge collections (A3 · Your first agent, Tab 3). Open the Datasheet sub-tab and attach Sales Data. That single attachment is what makes this a SQL agent.
  5. Capabilities / Output / Governance tabs — leave at defaults. You do not register anything on the Tools page: the SQL search toolkit is a built-in toolkit that switches on automatically the moment a Datasheet is attached on the Knowledge tab (A5 · Tools & functions).
  6. Click Save Agent.

Why attaching a Datasheet is enough — the capability rule. An agent’s capability is data-driven by its config: bind a datasheet_id and it becomes a SQL agent; bind a view_id and it becomes a search agent; bind neither and it’s a general agent. You never tick a “make this SQL” switch — the attachment is the switch. This is the same Knowledge-tab wire as the Policy assistant; only what you attach (Datasheet vs Knowledge collection) selects the engine.

Watch out — the number-one “why won’t it answer my data question?” mistake. Skip the Knowledge ▸ Datasheet attachment and the agent has no SQL tool — it will either refuse counting questions or guess a number from thin air. No Datasheet attached = no SQL toolkit = no real analytics. Check the Knowledge tab first. The attachment is also your scope boundary: the agent queries only the table you gave it.

Don’t confuse the two agent-to-data relationships: a Worker (intake agent) runs on each document and is set on a collection’s Agents tab; a Reader answers over the data and is set here, on the agent’s Knowledge tab. This Sales Analyst is a Reader.

Checkpoint. In the editor’s Playground, set Input Type = Text, ask “How many rows are in the sales data?”, and press Enter. You should see it run a SELECT COUNT(*) (expand the Agent Build Log / tool calls to watch) and return a number. If it refuses or guesses, re-check the Datasheet attachment in step 4.

Stage 3 — Tune the persona to explain its answers

A SQL agent that only emits a number is a black box. A trustworthy one shows its work — the query it ran and the assumptions it made — so a non-technical user can sanity-check the answer.

  1. Back on the agent’s Persona tab, open Instructions (the system prompt — the soul of the agent). Use the field co-pilot to draft, then edit to roughly:

    You are the Sales Analyst. Answer questions **only** from the attached `Sales Data` table by
writing read-only SQL. For every answer: (1) state the result clearly, in a **table** when it's
a list or ranking; (2) show the **SQL you ran**; (3) name any **assumptions** (date ranges,
how you defined "last quarter", filters like `_BM_STATUS = 'OK'`). If a question needs a column
the table doesn't have, say so plainly — never invent figures. Round money to whole units.

  2. Save Agent.

Make assumptions explicit. Plain-language analytics is full of ambiguity: “last quarter”, “top customers” (by revenue? by orders?), “late” (vs which date?). Telling the agent to state its assumptions turns a guess the user can’t see into a statement they can correct — “by last quarter I mean Apr–Jun; tell me if you meant the fiscal quarter.” That one instruction does more for trust than any model setting.

Under the hood — how structured Q&A differs from document retrieval. A vector-RAG agent embeds the question and pulls the nearest document chunks. A SQL agent does something fundamentally different: it reads the table’s column names, writes a SELECT (with WHERE / GROUP BY / ORDER BY / LIMIT as the question demands), runs it read-only against the backing table, and answers from the computed result set. That’s why it can count, sum, rank, and trend — operations vector search can only fake. The flip side: it can only answer what the columns support. No region column means no “by region” answer.

Checkpoint. In the Playground, ask “What’s total revenue by region?” — you get a table, the SQL it ran, and a one-line note on any assumptions.

Stage 4 — Configure the Chat experience and ship it to end-users

Configure the consumer Chat surface (E7 · Shaping the experience), then use it as an end-user would (E4 · Chat & search experience).

  1. Go to Studio ▸ Chat ▸ General.
  2. Default Questions — seed the analytics people actually ask, as one-click starters: Top 10 customers by revenue last quarter · How many orders shipped late in March? · Total revenue by region this year · Which product had the biggest month-over-month growth?. Drag to reorder; tick Pin default questions so they stay on an empty chat.
  3. Chat Greeting Text: Hi — ask me anything about our sales data: totals, trends, top-N. I'll show you the query I ran.
  4. Leave Hide Chat References at your preference — a SQL agent’s receipt is the query it shows, not a document chip, so references matter less here than in the Policy assistant.
  5. Save. The unsaved-change red dot clears on a successful save.
  6. Now open App ▸ Chat. The empty chat shows your greeting and pinned starters. Click “Top 10 customers by revenue last quarter”. Watch the thinking… footer; expand the Agent Build Log to see the agent compose and run its SELECT. Read the answer table and the query it reports. Ask a follow-up — “now just for EMEA” — and notice it remembers the thread.

Default questions double as documentation and a demo script. Write ones whose answers you’ve already verified in the Playground, so a first-time user’s first click always lands clean.

Checkpoint — the success condition for the whole build. A non-technical user asked a plain-language analytics question in chat and got a correct answer computed from the data, with the SQL shown. That’s an Enterprise data Q&A assistant.

Stage 5 — Test it

A few-minute acceptance pass. Ask one of each question shape and verify against what you’d compute yourself:

  1. Count / filter. “How many orders shipped late in March?” — expect a specific number, and the agent should show a WHERE-filtered COUNT(*). Cross-check it with a Data-tab filter from Stage 1.
  2. Top-N / ranking. “Top 10 customers by revenue last quarter.” — a 10-row table ordered descending, with GROUP BY customer … ORDER BY SUM(revenue) DESC LIMIT 10.
  3. Aggregate / trend. “What’s the trend of monthly revenue this year?” — a per-month breakdown (a table or chart), GROUP BY month.
  4. Honest refusal. Ask for something the table doesn’t have — e.g. “What’s each customer’s credit score?” when there is no such column — the agent should say the data doesn’t include it, not fabricate scores. If it invents figures, re-check the “never invent” instruction in Stage 3.
  5. Conversation memory. Ask a follow-up that depends on the previous answer (“now just EMEA”) — it should narrow the prior query. Then + New chat and ask the follow-up alone — no context.

If all five pass, the assistant is accurate, honest, and conversational — ship it.

Make it production-worthy

  • One assistant for both structured and unstructured questions. The real prize: a single chat that answers “how many refunds did we issue last month?” (data) and “what’s our refund policy?” (docs). The Knowledge tab takes both a Datasheet and a Knowledge collection, so wire both onto one agent: build the Knowledge collection per B1 · Policy assistant Stages 1–2, then on the Sales Analyst’s Knowledge tab keep the Sales Data Datasheet attached and add the collection on the Knowledge collections sub-tab (flag-gated by knowledgeCollections). The agent then carries two retrieval tools at once and the model picks per question: a “how many” question runs SQL; an “explain the policy” question runs vector retrieval and cites the page. Tighten the persona so it’s explicit about which it used.
  • Scope by role. Sales figures are sensitive. Build the assistant once, then gate who can open its chat with Access Roles (G1 · Access & roles). For tiered data (regional managers see only their region), materialise a per-region Datasheet (or a View filtered by region) and give each audience an agent attached only to its slice — the attachment is the data boundary.
  • From answers to a dashboard. Chat answers a question on demand; a dashboard answers the same questions standing. The Datasheet you built is also a feed for a per-collection or project dashboard (E5 · Dashboards & inbox) — pin the top-N and trend tiles so the numbers your starters compute live on a page, while chat handles the ad-hoc follow-ups.
  • Reusable shape — “ask-my-data”. Get a Datasheet → attach on the Knowledge tab → tune the persona to explain → queried chat. Re-skin it for inventory, transactions, HR headcount, support tickets, an IoT feed — the build is identical; only the table changes.

Where to go next

Prefer learning inside the product? The same academy lives in the platform's Learn menu — every screen links to the chapter that explains it.

See the platform live