AI as SQL: ask Gluesync from Query Forge

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. 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. 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.

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
3. Ask against gluesync.ai
4. Review. Run only what you accept

Related

• Query Forge: federated SQL across agents — why / when / what / how (live today)
• Query Forge docs
• AI as SQL (solutions) — 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 — 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.