November 5, 2026
SQL SIG Monthly Meeting
Remember, remember: searching by meaning, in T-SQL
November was the meeting the group had been building toward. Earlier sessions called REST APIs from T-SQL and made the STAR data warehouse describe itself. This one put models to work on that foundation, entirely inside SQL Server 2025 and entirely on a local machine.
It started with a question from Amanda at the Billing SIG: how do you find the time entries where staff used an AI tool, when people spell the tool’s name every possible way? A LIKE search came first, then a vector search by meaning, then a local language model that judged the shortlist.
The same search then pointed at the warehouse’s own table descriptions, and two agents, Neo and Smith, used it to write, run and check their own SQL. The discussion afterwards turned to the question every firm will face next: who should an agent be allowed to see?
Monthly Meeting
1h 36m
Recording length20 Attendees
Multiple firmsRecording
AvailableWhat this meeting covered
Embedding models, language models and agents
What each kind of model does, why an LLM only ever returns text, and why an agent is the loop a developer writes around it.
From a LIKE search to a search by meaning
A new vector column, an external model, one embedding per row and a cosine distance: the time-entry search rebuilt in T-SQL, then handed to a local LLM to judge.
A warehouse that can search itself
The AI-ready warehouse’s 641 table and column descriptions, embedded so a plain-English question finds the right tables, and two agents that use them to write and check SQL.
Who should an agent be allowed to see?
A discussion of agent security: a read-only SQL user, role-based access, Entra groups, and where the permission data should live.
Three kinds of models, one loop
An embedding model turns text into meaning
The meeting opened by asking the group for the difference between an embedding model and a language model. An embedding model takes text and returns an array of numbers that represents what the text means. Two texts with similar meanings produce similar arrays, even when they share no words.
The intelligence is in producing the numbers. Comparing them afterwards is plain arithmetic, so a search over stored vectors needs no model at all, only the one call that turns the question into a vector. Other kinds of models, such as diffusion models for images, were mentioned and left aside.
A language model is a function with a brain
A large language model takes text and returns text. It knows only what it learned before its training cutoff, so a question about the latest SQL Server version may get an outdated answer, and on its own it cannot search the web or run a query.
What it can do is ask. When the developer describes the available tools in advance, the model replies with a structured request, usually JSON, naming the tool and its arguments. The developer’s code decides whether to carry out that request, runs it, and sends the result back as more text.
An agent is the loop around the model
An agent is that exchange repeated: the model asks, the code acts, the result goes back, until the model decides it can answer. The model never executes anything itself. In the chat, Joshua summed it up as agents being a harness on top of the LLM.
The Blue J question
Where the example came from
At the Billing SIG in September, Amanda described how her firm identified time entries where staff used Blue J, an AI tax research tool, for example to support a technology fee. Searching the narrative text meant keeping up with every way a name can be typed, so the firm moved to a checkbox, a practical answer that many firms would recognize.
The demonstration used a small sample table of 18 time entries with an answer column marking which ones really used an AI tool. Some entries only talked about AI, plans or vendors, which is not the same as using it. A few were in other languages.
The LIKE search
The demonstration began where most of us begin. A LIKE pattern for Blue J found the entries spelled the expected way and missed the misspellings, such as Bleu J. It also matched an entry that happened to contain the word blue and, later, the letter J. Extending the pattern to every AI tool would still catch entries that only mention AI.
LIKE compares characters, not meaning. Regular expressions, new in SQL Server 2025, sit between the two and were skipped on purpose.
Running models locally, without installing anything
Everything in the demonstration ran on a laptop. A model needs two things: a runtime and the model file. The runtime was llama.cpp’s Vulkan build, which uses whatever GPU the machine has. It runs from a downloaded folder with no installation, and removing it means deleting the folder.
Its llama-server program hosts a model and exposes an OpenAI-style API on a local port. The embedding model was Harrier from Microsoft, roughly 600 MB, a small download because it only converts text into vectors.
Teach SQL Server the model, then store the meaning
SQL Server 2025 adds a vector data type and create external model. The external model points at an API, a local one here, though the same statement could point at a hosted provider. A single update then stores one vector per time entry through ai_generate_embeddings, a function that makes one API call per row.
-- One vector per time entry, from a local embedding model. alter table demo.timeEntry add embedding vector(1024); create external model harrier with ( location = 'https://localhost:10101/v1/embeddings', api_format = 'OpenAI', model_type = embeddings, model = 'harrier-oss-v1-0.6b' ); update t set t.embedding = ai_generate_embeddings(t.detail use model harrier) from demo.timeEntry t;
A search by meaning
The search turns the question into a vector with the same model, then ranks rows by vector_distance using cosine distance. Only the question needs an API call; the comparison is ordinary SQL, and a vector index can make it faster on large tables.
-- Search by meaning: one API call for the question, then plain SQL.
declare @question nvarchar(400) = 'used an AI tool to do this work', @cutoff float = 0.45;
declare @question_vector vector(1024) = ai_generate_embeddings(@question use model harrier);
select
t.id,
t.detail,
distance = vector_distance('cosine', t.embedding, @question_vector)
from demo.timeEntry t
where vector_distance('cosine', t.embedding, @question_vector) <= @cutoff
order by distance;Better, and still not a judge
Searching for AI tools in general rather than Blue J alone, the vector search found entries the LIKE search missed, including ones in other languages, such as the French IA. At a cutoff of 0.45 it got three of the 18 entries wrong: one heavily misspelled Blue J entry and entries that talk about AI.
A comparison of cutoffs showed the trade-off. At 0.50 nothing was missed, at the cost of six false positives. That looser setting was chosen on purpose for the next step: treat the vector search as a fast shortlist that leaves nothing out, then bring in a language model to decide.
Sarah Conner reviews the evidence
A stored procedure with a persona
The shortlist went, as JSON, to a stored procedure given the identity of Sarah Conner. Her system prompt says what to decide for each entry, explains that Blue J is an AI tax research tool, since the model’s training predates it, and states that talking about AI is not using it. She answers with an id and a yes or no for each entry.
The call is the same sp_invoke_external_rest_endpoint pattern used for HubSpot in June, with a JSON payload naming the model and the messages. The language model was Qwen 3.8, about 27 GB, running in a second llama-server with a 128K-token context. Temperature 0 asks for the same answer every time, and the JSON response format keeps the reply parseable.
A perfect score on the sample
Once the model was loaded, the judgment took roughly 15 to 20 seconds and matched the answer column for all 18 entries, including the misspellings, the other languages and the entries that only mention AI. That is a result on an 18-row sample, not a measurement on a firm’s real time entries.
The pattern is the point: a cheap, instant vector search narrows millions of rows to a shortlist, and the slower, costlier model only reads the shortlist. In the chat, Ben noted that this combination, SQL Server finding the relevant data and a language model interpreting it, is the foundation of retrieval-augmented generation.
Strictly speaking, Sarah was one model call rather than an agent: there was no loop.
The warehouse looks inward
Descriptions written and tested by models
The October meeting introduced the AI-ready STAR data warehouse and its descriptions of every table and column. Amine recounted how they were made: a capable model drafted them from his STAR knowledge base, then many small, low-cost models, given only the descriptions, wrote SQL for test questions collected from the SQL, Billing and AR SIGs.
On the first pass about 6 of roughly 15 questions per table were answered correctly. The descriptions were revised and retested until the small models answered the reported questions correctly. That is evidence about that test set, not a guarantee for every question.
Too much to read at once, quick to search
Together the descriptions run to about 200 KB of text, too much to hand an agent all at once. Instead, the 641 descriptions were copied into a table and embedded with the local model, 641 API calls in about 22 seconds, without per-call network latency or a bill.
A question such as where the write-offs are then returns the closest tables and columns instantly, ranked by distance, even when the question shares no words with the description. Before SQL Server 2025, a search like this would have needed a specialized vector database.
Take the red pill: Neo and Smith
Neo does the work
Agent Neo is a real agent: a loop of up to 10 turns with three tools, described to the model in the API’s native tool format. find_tables runs the vector search over the warehouse descriptions, describe returns a table’s rules and columns, and run_select runs one SELECT statement.
Each turn, the model either requests tools or answers. The procedure carries out each request and returns the result as JSON. run_select wraps the model’s query in dynamic SQL under execute as user for a read-only user, so a query can only read, and a statement like drop database fails on permissions.
Smith checks it
Agent Smith uses the same model with a different job. He receives the question, Neo’s SQL and answer, and the written rules of the tables that SQL uses, then approves or lists the problems. A rejection sends Smith’s notes back to Neo for a second round. In the chat, Joshua called it an adversarial review.
Which five client industries have the most active clients?
Asked that question live, Neo searched for client, industry and status tables, read the client and client status descriptions, searched again for an industry lookup, read that table, and only then wrote and ran one query using the filters those descriptions require. Smith approved it on the first round.
None of those steps were scripted. The procedure only defined what Neo could ask for; the order of the requests and the final SQL came from the model working through the warehouse’s own documentation.
Why SQL developers have an advantage
Everything in the session was ordinary SQL Server: tables, loops, stored procedures, JSON and a REST call. Agents and their instructions can live beside the data, every exchange can be logged to a table, and the same code works against a hosted model by changing the URL. Ben remarked that most agents work like that, but he had never seen one built in SQL Server.
Who should an agent be allowed to see?
The agent acts as itself, not as you
Joshua raised the issue his firm faces when offering plain-language access to STAR data. The demonstration’s agent queried as one read-only SQL user, so it did not inherit the asking person’s permissions, and an agent could surface information the STAR interface would never show that person. Amine agreed and stressed that the session’s code was for demonstration only.
Two approaches, both valid
Amine described keeping access rules in code: role-specific SQL accounts, and inline table functions that take the user and apply the firm’s rules, such as access to jobs under a person’s assigned partner, using data STAR already holds. Joshua proposed Entra groups, so the people responsible for membership maintain it and developers build the logic on top.
Ben observed that two things can be true at once: the right answer depends on the organization’s size and how responsibility is split. Joshua added that columns can be tagged, for example with extended properties, to drive what a user may see. Amine suggested that in a master data warehouse above each system’s own warehouse, Entra could be one more source, and committed to returning to agent security at a future meeting.
Questions after the demo
Joshua asked whether the warehouse takes a firm’s customizations into account. It is built on the common STAR structure, and its validation procedures stop a load when one of its assumptions does not hold, which Joshua likened to unit tests. A firm’s custom fields remain its own extensions. Ben pointed to the warehouse download on the Resources page, and a GitHub repository was requested.
Greg asked about source control. Amine showed the instance-level DDL history from the September meeting: server triggers that record every schema and configuration change in a table, useful after an upgrade or an unexplained slowdown, and readable by an agent that needs to know what changed.
Independence from LIKE.
November showed that searching by meaning, judging with a language model and letting an agent explore are now features of the database itself. The work that made them reliable was familiar: a well-described warehouse, a read-only user, and SQL a developer can inspect. The next question is who gets to ask.
Search by Meaning
Judge the Shortlist
Loop with Tools
Guard the Data
About the Host
Amine Fayad is the STAR SQL SIG Leader and Co-Founder of Encapsulated. For nearly three decades, his work has spanned .NET, SQL Server, and the construction of reporting engines, automation platforms, workflow systems, enterprise integrations, and SODA-inspired database service architectures.
This meeting showed how Amine takes a new SQL Server feature from a member’s question to a working demonstration. He built every step in plain T-SQL on a laptop, from the first vector to two cooperating agents, so other developers could see exactly where the model ends and their own code begins.