Canonical: https://molo17.com/blog/ai-as-sql-query-forge-gluesync-ai/ Markdown mirror: https://molo17.com/blog/ai-as-sql-query-forge-gluesync-ai/index.md Title: AI as SQL on Query Forge | Gluesync · MOLO17 Description: Gluesync 2.3 AI as SQL on Query Forge: show SQL, narrate answers, ask→review→run, IDE, automation, federated estates. [← All articles](/blog/) Article # AI as SQL: ask Gluesync from Query Forge  1 Oct 2026 [Gluesync](/blog/?category=gluesync) 5 min read Week-after follow-up to Query Forge: seven AI-as-SQL workflows on the same jdbc:gluesync:// wire. You already have a SQL client open. The question isn’t “do I need another chat window?” It’s “can I ask this estate without leaving the tool I trust?” **AI as SQL** is the Gluesync 2.3 follow-up to [Query Forge federation](https://molo17.com/blog/query-forge-federated-sql-why-when-what-how/). On the same `jdbc:gluesync://` connection you already use for cross-agent reads, you ask in plain English and get a normal result row: an answer, an optional SQL draft, citations, and a conversation id for follow-ups. Direction on the 2.3 living track — same caution as our [AI Hub tease](https://molo17.com/blog/coming-in-gluesync-2-3-ai-powered-data-integration/). Query Forge federation is live today. The `gluesync.ai` catalog is Hub work for 2.3, not “available now.” ## The door (in one sentence) Most products turn English into SQL inside a chat UI, and often run it for you. AI as SQL flips that: **SQL in → answer + optional draft out**, as a ResultSet. You review. You run. Your company’s LLM keys. Your user’s permissions. AI suggests SQL — it does not run it for you. ```sql SELECT answer, proposed_sql, citations, conversation_id FROM gluesync.ai WHERE question = 'retrieve the 100 most recently created customers'; ``` ## Use cases (make these yours) These are the workflows buyers already expect from “AI in SQL.” Here is how each one maps on Gluesync. ### 1\. Show me the SQL — don’t run it yet **What people want:** Ask in English, see the statement, decide later. **What you get:** The `proposed_sql` column — a draft for human review. Gluesync never auto-executes it. **You do:** Read it in DataGrip/DBeaver (long cells are fine). Run only what you accept as a separate real SELECT on Forge or in Query Studio. ### 2\. Answer in English — not only a query **What people want:** A plain-language answer, not just a SQL string to decode. **What you get:** The `answer` column — orientation in English — plus `citations` so you can see what the model leaned on. **You do:** Use the answer to decide next steps; treat citations as inspectable work product, not a chat bubble you can’t paste into a ticket. ### 3\. Ask → review → run (the trust loop) **What people want:** Help without a silent side effect on production data. **What you get:** One row with both `answer` and `proposed_sql`. Nothing in that loop mutates pipelines or sync. **You do:** 1. Ask 2. Review 3. Run yourself — under the same PAT and SafetyGate path you already trust That is the enterprise beat: AI drafts; your hands still own the expensive action. ### 4\. Stay in the IDE (no Alt-Tab chat) **What people want:** DataGrip / DBeaver as the place they live — not a portal chat for every “how do I…?” **What you get:** `gluesync.ai` on the same `jdbc:gluesync://` connection as your federated schemas. **You do:** Orient in English where you already work, then run accepted SQL next to your other queries. Query Studio’s AI helper remains a separate door inside the product (chat + Tab). Two doors, one policy. ### 5\. Script it, schedule it, demo it **What people want:** Repeatable asks in jobs and playbooks — not only a browser session. **What you get:** Prepared statements (`WHERE question = ?`), audited as the caller’s PAT. Same shape partners and SEs can put in a demo pack. **You do:** Morning health scripts, partner runbooks, CI checks — still never auto-run `proposed_sql`; your job runs a separate real query when you mean to. ### 6\. Federate first — then ask on the same wire **What people want:** One estate, many agents (including legacy), without copying everything into a warehouse just to ask a question. **What you get:** Morning cross-agent JOINs on Query Forge. Afternoon `FROM gluesync.ai` on that **same** JDBC URL. **You do:** Name a table, schema, agent, or database in the question — Hub matches **whole names** (case-insensitive), not substrings. A unique match automagically **grounds on that agent’s schema** (resolved IDs show on the result row). Prefer paired `pipeline_id` + `agent_id` when you want to pin the scope yourself — explicit IDs always win. If two names match with equal strength, the ask fails closed with candidates rather than guessing; a stronger match wins. If nothing unique matches, grounding stays empty — Hub does not invent an agent. Optional `provider_id` for BYO models (including local Ollama). ### 7\. Follow up without starting over **What people want:** “Only active ones” / “last week” without losing context. **What you get:** Reuse `conversation_id` on the next SELECT. **You do:** Two SELECTs in the same client session — not a new chat thread in another app. * * * ## What this is not - Not a chat product that replaces Query Studio AI helper - Not AI Studio (that’s the BYO vault / agent workspace — prerequisite for providers) - Not row-level “enrich every ticket with an LLM in the SELECT list” (different category) - Not a promise that every BI tool’s proprietary AI panel lights up — truth is JDBC clients on `jdbc:gluesync://` once Hub exposes the catalog - Not GA today — 2.3 look-ahead ## What does not change - Your infrastructure stays yours - Your models stay yours (BYO; empty vault fails closed) - Your permissions stay yours (caller PAT — no elevated AI service account) - MCP on this path is **read-only** - `proposed_sql` never runs itself - Nothing mutates via `gluesync.ai` ## When you’re ready to try the shape Once your Hub exposes the catalog (2.3 line): 1. Configure at least one LLM provider under **Settings → LLM providers** 2. Connect as you already do for [Query Forge](https://docs.molo17.com/gluesync/latest/gs-modules/query-forge.html) 3. Ask against `gluesync.ai` 4. Review. Run only what you accept ## Related - [Query Forge: federated SQL across agents](https://molo17.com/blog/query-forge-federated-sql-why-when-what-how/) — why / when / what / how (live today) - [Query Forge docs](https://docs.molo17.com/gluesync/latest/gs-modules/query-forge.html) - [AI as SQL (solutions)](https://molo17.com/solutions/ai-as-sql/) — outcome page (staging until GO) - AI as SQL docs (after 2.3 publish): `/gluesync/v2.3/core-hub/ai-as-sql.html#name-grounding` — not live yet - [AI Hub](https://molo17.com/ai-hub/) — broader 2.3 AI story **Short version:** Query Forge already made your agents one SQL system. AI as SQL makes the workflows people already expect from “AI in SQL” — show the draft, get the answer, stay in the IDE, script it, federate then ask — without giving the model a free pass past you. [← Older article MS SQL Server CDC: transaction log versus change tracking](/blog/ms-sql-server-cdc-transaction-log-vs-change-tracking/) ## Keep reading 1. [Mentioned in this article Query Forge: federated SQL across agents, without a warehouse One JDBC URL into Core Hub. Schemas map to the agents you already run. Cross-agent joins without standing up a warehouse. 24 Sep 2026](/blog/query-forge-federated-sql-why-when-what-how/) 2. [Mentioned in this article AI Hub is coming — not another chatbot on your sync tool AI Hub is coming this month — not another chatbot on your sync tool. Gluesync 2.3 puts AI in the control plane across 59+ databases. 13 Sep 2026](/blog/coming-in-gluesync-2-3-ai-powered-data-integration/) 3. [Gluesync Gluesync Core Hub MCP server: pipelines, SQL, and ops from your AI client Embedded Model Context Protocol server inside Core Hub: 55 RBAC-safe tools, SSE and streamable HTTP, dynamic Query Studio database tools. Available in Core Hub 2.2.10.x. 9 Sep 2026](/blog/gluesync-core-hub-mcp-server/) [Back to all articles](/blog/) [More in Gluesync →](/blog/?category=gluesync)