A query agent is an AI agent that turns a plain-English request into a working, executable query against your actual datasources. Unlike text-to-SQL tools, a query agent indexes the schemas of every connected source, SQL, NoSQL, and APIs, and can join across them in a single prompt.
Our thesis: text-to-SQL was the wrong frame for AI-assisted querying, and the industry spent two years proving it. Generating a SQL string is the easy 20 percent. The hard 80 percent is knowing which datasource holds the answer, handling sources that do not speak SQL at all (MongoDB, Elasticsearch, REST APIs), joining across them, and leaving behind a governed, reusable dataset instead of a one-off string. That harder job is what a query agent does, and having built one at Knowi, we can be specific about what that takes.
Quick Summary (TL;DR)
- A query agent converts natural language into configured, executable queries at the datasource layer, not just SQL text for one database.
- The defining capability is cross-source work: one prompt can join a MongoDB collection to a MySQL table without an ETL pipeline in between.
- Query agents index datasource schemas first, which is why they resolve vague requests (“the sending activity data”) to the right table in the right database.
- Text-to-SQL tools break on NoSQL and APIs because there is no SQL to generate; a query agent speaks each source’s native query language.
- Query agents are conversational: you refine the query over multiple turns in the same session instead of re-prompting from scratch.
- In Knowi, the Query Agent is enabled per datasource by an admin, so teams control exactly which data AI can touch.
Table of Contents
What Does a Query Agent Actually Do?
A query agent sits between a human question and a configured query. The workflow has four steps, and each one is work a data analyst would otherwise do by hand.
1. It indexes your datasources
Before answering anything, the agent indexes the schema of every datasource it is enabled on: tables, collections, fields, and structure. This index is what lets it resolve “the customer table” to the right object in the right database. When schemas change, a re-index refreshes its map.
2. It interprets the request and picks the source
Given “query the full sendingActivity table from the mongo database”, the agent identifies the datasource, the collection, and the shape of the query needed. No manual connection setup, no browsing a schema tree.
3. It configures the query, including joins across sources
This is the step that separates the category. A prompt like “join the full sendingActivity table from MongoDB with the full customer table from MySQL with a left outer join” produces a configured cross-database join. In traditional stacks, that sentence is a data engineering ticket: pipeline both sources into a warehouse first, then query.
4. It hands you a query you can inspect and run
The output is a populated query editor, ready to preview and execute, not a black-box answer. You can read what the agent built, refine it conversationally over multiple turns, and even ask it to name the resulting dataset (“name my dataset Customer Campaign Data”). The result is a governed, reusable asset.
Query Agent vs. Text-to-SQL: Why the Difference Matters
Text-to-SQL assumes your data lives in one relational database with a clean schema. In practice, the questions worth asking span systems: product events in MongoDB, transactions in PostgreSQL, logs in Elasticsearch, campaign data behind a REST API. A SQL generator cannot even address three of those four.
Benchmarks tell the same story on pure SQL accuracy. On the Spider 2.0 benchmark of real enterprise text-to-SQL workflows, even frontier-model frameworks solved well under half of the tasks, versus roughly 90 percent on older single-table academic benchmarks. The gap is context: real schemas, multiple dialects, and multi-step logic. An agent that indexes schemas and works iteratively is an architectural answer to that gap, not a bigger prompt.
This is the same argument driving the MCP and data-layer agent ecosystem: AI needs governed, structured access to the data layer itself, not string generation at arm’s length. It is also the foundation of agentic BI as a category.
How a Query Agent Works in Practice: A Walkthrough
Here is the concrete flow in Knowi, one working implementation of the pattern. The technical documentation has the full setup detail.
An admin first enables the agent per datasource: open the datasource settings under Queries and Data Sources and check “Enable Query Agent”. This is a deliberate governance choice. AI access to data is opt-in, source by source, so a team can enable the analytics replica and leave the HR database untouched.
From there, an analyst clicks “Create with AI” in the query builder and types what they want. The agent indexes the enabled sources, interprets the request, and populates the query editor. The analyst previews the data, refines in follow-up turns (“filter to the last 90 days”, “add a left outer join to the customer table from MySQL”), and saves a named dataset.
Two details from production use are worth calling out. First, multi-turn refinement matters more than first-shot accuracy, because real questions are discovered iteratively. Second, keeping the human at the preview step, inspecting the query before execution, is what makes the agent trustworthy enough for governed environments.
Watch a query agent join MongoDB and MySQL from one sentence?
Your data lives in databases, warehouses, APIs, and documents. Knowi connects directly to all of them, combines results without ETL, and turns them into dashboards, AI-powered insights, and embedded analytics. Deploy in the cloud or keep everything inside your environment with Private AI.
What you can do with Knowi:
- Connect SQL, NoSQL, REST APIs, and cloud data warehouses in one platform.
- Build dashboards without moving data into a separate warehouse.
- Ask questions in natural language and get answers backed by the underlying query.
- Embed dashboards, AI assistants, and analytics directly into your application.
- Chat with documents, spreadsheets, PDFs, and operational data from a single interface.
- Keep sensitive data private with cloud, hybrid, or self-hosted deployment options.
Used by SaaS, healthcare, manufacturing, IoT, and enterprise teams that need analytics across multiple data sources without the complexity of traditional BI stacks.
How Query Agents Compare to Adjacent Tools
| Capability | Text-to-SQL Generator | SQL Copilot (IDE assistant) | Query Agent (e.g. Knowi) |
|---|---|---|---|
| Input | Natural language, one database at a time | Autocomplete and edits inside SQL you are writing | Natural language across all enabled datasources |
| NoSQL and API sources | Not supported, SQL only | Not supported, SQL only | Native support: MongoDB, Elasticsearch, REST APIs, and SQL databases |
| Cross-source joins | No, requires a warehouse first | No, single connection scope | Yes, joins across databases in one prompt without ETL |
| Schema awareness | Prompt-stuffed or manual | Reads the connected schema | Indexes all enabled datasources, re-indexes on schema change |
| Output | A SQL string to copy elsewhere | Edited SQL in your editor | A configured, previewable query that saves as a named, reusable dataset |
| Governance | Depends on where you paste it | Developer’s own credentials | Admin enables per datasource; user permissions apply |
Our verdict: if your data genuinely lives in one relational database, a text-to-SQL tool or copilot is enough. The moment your question spans a second system, especially a non-SQL one, only the agent pattern holds, because the bottleneck was never SQL syntax, it was source access and joining. For the platform landscape, see the best agentic BI tools in 2026.
Where Query Agents Fit in the Agentic BI Stack
A query agent is the bottom half of an agentic BI platform. It gets governed data in and shapes it into datasets. Its counterpart, the dashboard agent, operates on top of those datasets: analysis, widgets, filters, scheduled reports, and alerts, all conversational. Evaluating platforms on both layers, rather than a single chat demo, is the fastest way to separate agentic architecture from AI marketing.
Frequently Asked Questions
Can a query agent join data across two different databases?
Yes, this is the category’s defining capability. A single prompt can request, for example, a left outer join between a MongoDB collection and a MySQL table, and the agent configures the cross-source query without an ETL pipeline or warehouse in between.
Does a query agent work on MongoDB and other NoSQL databases?
A true query agent does, because it generates each source’s native query language rather than SQL only. Text-to-SQL tools cannot address MongoDB, Elasticsearch, or REST APIs at all, which is the main practical difference between the two categories.
How does a query agent know which table holds the data I am asking about?
It indexes the schema of every datasource it is enabled on before answering, so it can resolve a phrase like “the customer table” to the right object in the right database. When your schema changes, a re-index refreshes that map.
Can I see and edit the query an AI agent builds before running it?
Yes, and you should require this in any tool you evaluate. The agent’s output is a populated query editor that you preview, refine in follow-up conversation, and then execute, which keeps a human checkpoint between AI interpretation and live data.
How do teams control which data an AI query agent can access?
Access is opt-in per datasource. In Knowi, an admin checks “Enable Query Agent” on each datasource individually and user role permissions still apply, so sensitive sources can simply stay unindexed and invisible to the agent.
How accurate are AI-generated queries on real enterprise schemas?
On realistic benchmarks like Spider 2.0, standalone text-to-SQL frameworks solve well under half of enterprise-grade tasks, far below their scores on academic single-table tests. Schema indexing, multi-turn refinement, and a human preview step are the practical mitigations, which is why the agent pattern outperforms one-shot generation.