AI glossary: LLM, RAG, agents and SQL in plain words
"RAG", "AI agents", "human in the loop", "Postgres". Job ads and the news put these words side by side as if they were one thing, and a complicated one. Most of them are simple ideas with shiny names.
This glossary is for owners and managers, not engineers. Each term gets one clear definition, an everyday comparison, what people mix it up with, and how we use it ourselves. The terms are in the order of the problem each one solves: from the model that writes text to the place where the data lives.
- LLM (large language model)
- RAG (answers from your own documents)
- AI agent
- Human in the loop (a person approves what matters)
- SQL and Postgres
LLM (large language model) #
An LLM (large language model) is a program trained on a huge amount of text that, given a question or an instruction, writes the most likely continuation: an answer, a summary, a translation or a draft.
Think of a very well-read intern. They have read millions of pages, none of them yours. They write fluently on any subject, yet they do not know your prices, your customers or what happened yesterday until you tell them. And they sometimes sound most sure of themselves exactly when they are wrong.
What it gets mixed up with. "AI" in general, a search engine and a database. On its own, a model does not search the web and does not keep records; it composes text from what it learned. ChatGPT, Claude and Gemini are apps built around such models, and they often add search and other tools on top. So if a model tells you today's price of something, it either got it from somewhere or it is guessing.
How we use it. In Taskinger, AI suggestions are off by default and run on the user's own key from Anthropic, OpenAI or Google, so on whichever model they choose. The AI assistants we build for clients run on Gemini and other models, Bulgarian included. The model is the engine. The rest of this page is about getting it to stick to the facts and do actual work.
RAG (answers from your own documents) #
RAG (retrieval-augmented generation) is a way for AI to answer from your own documents and data: the system first finds the passages that relate to the question, hands them to the language model, and the model answers from them instead of from memory.
It is an open-book exam. The student does not know everything by heart, but knows where to look and answers from the page in front of them. Without RAG the model sits the exam from memory and fills the gaps with plausible guesses.
What it gets mixed up with. "Training the model on our data". With RAG the model does not change; it reads the relevant piece at the moment of the question. That is why, when you change a price or a rule in the source, the next answer already knows it, with no retraining. RAG does not make an answer correct by itself, though. If the passage it finds is old or wrong, so is the answer, which is why quality depends mostly on how tidy your documents are.
How we use it. The assistant we built for a clinic's public website rests on the same idea. Its prices come from the same records the price page renders, and its clinical answers are an FAQ approved by the lead doctor, which it may quote and may not rephrase. Its instructions are assembled fresh for every conversation, so a promotion switched on in the admin panel changes the page and the assistant at once. How it is built, and the two bugs its test caught before patients did: Where AI assistants actually help.
AI agent #
An AI agent is a language model given a task and tools: it decides the next step itself, carries it out (searches, writes a file, opens a task, runs a check), looks at the result and keeps going until the task is done or it reaches a line it must not cross.
The difference is the one between an adviser and a colleague. A chatbot explains how to put the monthly report together. An agent opens the spreadsheet, builds the report and hands it to you for review.
What it gets mixed up with. A chatbot, and ordinary automation. A chatbot answers and stops. Automation of the "when an email arrives, copy it to the sheet" kind follows steps a person wrote in advance. An agent picks its own steps. That lets it do work nobody described down to the last detail, and it is exactly why it needs limits: what it may touch, what it may not, and what goes past a person.
How we use it. Vivan runs its own work with departments of AI agents: one for the company site, one per product and one for marketing. A manager agent writes the tasks, builder agents do them on a separate copy and cannot release anything themselves, and the manager reviews the finished work and sends it back with numbered fixes until it is right. Every action of an agent first passes a guard that stops sending mail, paying and deleting files before the action happens. What this looks like for one of your processes: AI agent departments.
Human in the loop (a person approves what matters) #
Human in the loop means an AI system stops at chosen points and waits for a person to approve, correct or reject the result before it goes out: before it reaches a customer, changes data or spends money.
Picture a new hire who writes the quotes but runs them past the manager before they are sent. Nobody checks every comma. The review sits where a mistake is expensive.
What it gets mixed up with. "The AI is not good enough yet, so a person checks everything." A well-made human in the loop is a short list of the decisions that matter, such as money, customers, legal text and publishing, which always wait for a person. Everything else flows on its own. That list is what lets AI do real work without you losing control.
How we use it. In Taskinger, a finished task that needs approval lands in the "Waiting for you" list of the person who may sign it off, with the agents' work at the top. They approve it or send it back with a comment saying what to fix. Taskinger's AI suggestions are not written into a workbook until a person approves each one. In SnapReceipt the model reads the receipt, but the lines open for review and you confirm them before they reach the budget.
SQL and Postgres #
SQL is the language for asking a database questions, such as "show every unpaid invoice from October", and Postgres (PostgreSQL) is one of the most widely used open-source databases that understand it. Neither is AI: they are where the data lives that AI reads and writes.
Postgres is the archive with the well-kept folders. SQL is the request form you hand the archivist. The language model is the clerk who reads the result and writes the letter to the customer. Archives have been around for decades; the clerk is the new part.
Why job ads put them next to AI. Every AI application has to keep its users, documents, conversation history and results somewhere. RAG has to search somewhere too: Postgres can also hold the "vectors" used to search by meaning, through the pgvector extension. That is why an AI engineer job ad asks for SQL as well. The model is one part of the system.
What it gets mixed up with. An AI that "knows" your data. A database answers exactly: with the same data, the same query returns the same result. A language model is flexible but not always exact. A good system keeps the numbers in the database and leaves the words to the model.
How we use it. Taskinger keeps its data in Firebase, a different kind of database with no SQL. Which database to use is an engineering choice and has nothing to do with AI. In the clinic assistant, prices are not written into the model's instructions as text: it reads them from the same records the price page renders.
Have a process where these words need to turn into work? Tell us about it.