Cool Things You Can Do with Glean: Ask SQL Server Anything

Every day, business teams have questions only the data can answer: which accounts are at risk, where margin is leaking, what actually changed this quarter. But that data sits in SQL Server, behind queries most business users don’t write. So the question becomes a ticket, the ticket joins the analytics backlog, and the answer arrives hours or days later — often after the moment to act has passed.

We built the Glean SQL Server Query Action to close that gap. A business user asks a question in plain language. Glean queries live SQL Server data, does the analysis, and returns the answer traced back to the exact records it came from.

Here’s what that actually looks like.

In action: from a catastrophe total to a concentration nobody asked about

The demo runs against Kestrel Mutual, a fictional property and casualty carrier with a synthetic, deterministically seeded claims database. No real policyholders, but a real deployment: live Azure SQL, live Glean agent, live queries.

The scenario is a hail storm that hit Texas six weeks earlier. What follows is a single conversation.

Turn 1: the headline number. “What’s our total exposure from the Texas hail storm, by line of business?” Glean returned $32,827,750 incurred across 90 claims — $26,356,750 still in reserve, $6,471,000 paid to date, loss dates spanning two days. Sixteen of the ninety were reserved above policy limit.

Line of business	Claims	Reserve	Paid	Incurred	Over-limit
Commercial Property	21	$11,710,000	$3,510,000	$15,220,000	2
Commercial Auto	22	$8,480,000	$1,710,000	$10,190,000	5
Homeowners	24	$5,153,750	$1,005,000	$6,158,750	5
Personal Auto	23	$1,013,000	$246,000	$1,259,000	4
Total	90	$26,356,750	$6,471,000	$32,827,750	16

It didn’t stop at the table. It flagged two things unprompted: claim counts are nearly even across the four lines, but Commercial Property and Commercial Auto together carry 77% of incurred severity. And the over-limit concentration is inverted — the commercial auto and personal lines have the most claims reserved above limit, which usually points to coverage or limit-verification issues rather than pure severity.

That is the difference between retrieval and analysis. Nobody asked whether the over-limit pattern was consistent with the severity pattern. The model noticed it wasn’t.

Turn 2: follow the money. “Pull the full financials on the two Commercial Property claims that carry 30% of the excess.” Glean made parallel calls against the claim-financials dataset and returned the detail per claim.

Turn 3: widen it. “Pull everything else tied to Brazos Logistics and Ironwood.” Both pulls came back with exactly 82 claims each — and the agent said so plainly: “Let me aggregate rather than eyeball this.”

Turn 4: the finding. The aggregation surfaced what the original question would never have reached. “Brazos” wasn’t one insured. It resolved to three separate legal entities — Contracting, Logistics, Properties. So did “Ironwood”: Fabrication, Industries, Foods.

Family	Claims	Open	Open reserve	TX hail claims	TX hail incurred
Brazos (3 entities)	82	33	$6,299,990	15	$7,147,500
Ironwood (3 entities)	82	39	$7,932,900	14	$8,480,000
Combined	164	72	$14,232,890	29	$15,627,500

Two corporate families, 164 claims, $15.6M of hail exposure between them — roughly half the entire event. The account-level concentration flagged a turn earlier was far larger than the two claims it started from.

The agent also flagged the 82/82 symmetry as suspicious on its face, and closed with three things it wanted verified before anyone acted on the number. That instinct matters more than the number itself. An analyst who hands you a figure without caveats is the one to worry about.

The part that closes a regulated buyer

Reading data is table stakes. The hard question from anyone responsible for a regulated system is what happens when the AI wants to change something.

The action is built as two separate tools, and the split is the whole security argument:

• The read tool answers questions and can do nothing else. It reaches a set of curated datasets — open inventory, adjuster workload, claim financials and reserve adequacy, catastrophe exposure, claim lookup. It reads views, not the underlying tables, so the blast radius is defined by what those views expose.
• The write tool performs exactly three sanctioned operations — update status, assign an adjuster, add a note — each through a stored procedure. It cannot compose arbitrary SQL. There is no generic “run this query” endpoint anywhere in the system.

Business rules live in the database, not in the prompt. Assigning an adjuster is license-checked: try to assign a claim to someone not licensed in the state where the loss occurred and the write is refused, with the reason. No clever phrasing gets around it, because the rule isn’t in the instructions the model can read. It’s in the procedure the model has to go through.

Every write is:

• Attributed to the signed-in person via their company sign-in, not a shared service key
• Audited in a table the action can write to through the procedure but cannot read or alter
• Idempotent, so a retry can’t double-apply

That’s the standard we hold it to: every answer traced to its source, every change signed by a real person and logged. AI you can put in front of regulated data, with receipts.

What’s under the hood

The path is short. A user’s question goes to a Glean agent, which calls a custom action defined by an OpenAPI spec, which reaches an Azure Function, which queries Azure SQL.

The agent turns the question into a tool call and narrates the result. The custom action is the contract Glean imports. The Azure Function authenticates the caller, runs the parameterized query, caps the result set, and returns typed rows. Credentials never appear in code: the inbound secret lives in Key Vault, and the Function reaches SQL through a managed identity mapped to a read-only database user.

That last point is worth sitting with. The database grant is the security boundary — not the prompt, not the model’s judgment. The action can only ever see what that one identity can see. Scope the grant to a schema, a set of views, or a single table, and you’ve scoped the AI.

Behind it: Bicep infrastructure-as-code, unit and integration tests, CI/CD with federated OIDC so no long-lived secrets sit in GitHub, and Application Insights with end-to-end correlation IDs.

Why this matters

For the business user, the win is obvious. A question that used to cost a ticket and a two-day wait now costs a sentence.

The more interesting effect is on the analytics team. The questions that get intercepted at the chat layer are the ones the data already answers: what’s open, who’s overloaded, what the storm cost. What still lands on an analyst’s desk is the work that genuinely needs one — new models, new data, questions the schema can’t yet reach. That’s a better use of analyst time and a much more honest signal about where the data platform needs to go next.

There’s a governance dividend too. Once a database is queryable in plain English, every view name and column becomes a user-facing surface. Curating those views isn’t overhead you accept for the sake of AI. It’s the same modeling discipline that makes the warehouse good, finally with a reason to prioritize it.

If you want to see this running against your own SQL Server environment, get in touch. We’ll walk through what a scoped, read-only first phase looks like on your data.

All figures above come from a synthetic, deterministically seeded demo database. Kestrel Mutual is fictional.