top of page

The Honest Glossary

Shift Quality Editorial
11 minutes ago
9 min read

Fifteen terms that mean less than they sound like, and a few that mean more.



This is not a neutral glossary. It is a position paper in glossary form. Every term in current AI and tech discourse has a marketing definition and an engineering definition. The marketing definition is what gets you to nod at the demo. The engineering definition is what you live with at 2 a.m.


These are the engineering definitions. If you disagree with any of them, that is exactly what they are for.



Agent (noun) A program that calls an LLM in a loop. The hard part is not the loop. The hard part is what the program is allowed to do when the LLM is wrong, which is most of the time. Most "agents" shipping in 2026 are demos in production cosplay — they autocomplete a task you could have done in a script, then bill you for the privilege. A real agent is one that can take an action your business cannot easily undo, has been allowed to do so, and has been monitored for the consequences. By that standard, the number of production agents is far smaller than the number of products called "agents." Nobody counts the first number, which tells you something on its own. (The ways the real ones break are catalogued in AI Agents Fail in Production in the Same Five Ways.)



Agentic (adjective) See: agent. Adding "-ic" to a noun that already means something specific is how the marketing team negotiates with the engineering team. The engineering team loses.



Moat (noun) What a startup says it has. What it usually has is a head start. The difference is whether the gap widens or narrows when a competitor shows up — and almost no one knows the answer to that about their own product. Real moats in AI tooling in 2026 are short. The model is rented. The infrastructure is rented. The customer relationship can be rented away if the product underneath is replaceable. The only durable moats are deep domain integration, switching costs that are real and not manufactured, and proprietary data that the customer cannot get elsewhere. Most things called "moats" are none of those.



Platform (noun, abused) A piece of software that other people build on top of. Most things called platforms are products with an API. The test: if your ecosystem disappeared tomorrow, would your business still work? If yes, you have a product. That is fine. Stop calling it a platform.



AI-native (adjective) A claim that the product was built around an LLM rather than having an LLM added to it. Sometimes true. Often it means the founders started after 2022 and the existing competitors did not. The interesting question is not when the product was built. The interesting question is whether the workflow makes sense without the LLM. If yes, the LLM is a feature. If no, the LLM is the product, and the product has the same risk profile as the model provider.



Copilot (noun, capitalized or not) Originally GitHub Copilot, released as a technical preview in June 2021. Now: any AI assistant a vendor wants to imply is helping but not replacing. Microsoft turned it into a brand. Everyone else turned it into a category. The interesting thing is that the metaphor implies a human pilot. In airplanes, copilots are licensed pilots. In software, copilots are confident interns. Worth checking which one a vendor means.



Foundation model (noun) A large pretrained model that other systems are built on. The word "foundation" implies stability — a foundation of a building does not move once it is poured. AI foundation models are repriced quarterly, deprecated annually, and replaced by their successors before you have finished writing the system prompt. The metaphor is the wrong one. They are more like the floor of a rented apartment. Useful. Yours until the lease renews.



Reasoning model (noun) A model that does extended internal computation before producing a final answer — chain-of-thought rollouts at scale. The reasoning is real in the sense that the model does more work and gets better answers on hard problems. The reasoning is not real in the sense that you can audit it the way you would audit a colleague's argument. The internal traces are not a transparent record of how the model thinks. They are a record of what the model wrote down on the way to writing down what it wrote down. The distinction matters when something goes wrong.



Fine-tuning (noun) The process of taking a pretrained model and continuing training on your own data to change its behavior. Most people who say "we should fine-tune the model" mean "we should give the model more context." Those are different things. Fine-tuning changes weights. Context engineering does not. If your problem is that the model does not know about your domain, you usually want RAG. If your problem is that the model does not behave the way you want, you sometimes want fine-tuning. Knowing which you have is the entire engineering problem, and When Prompting Isn't Enough walks the decision.



RAG (noun, retrieval-augmented generation) Looking things up and showing them to the model before asking the question. The single highest-leverage technique in production AI in 2026. The reason it does not feel impressive is that it is mostly information retrieval — search, ranking, chunking, embedding lookups — with an LLM as the last step. The unsexy work is the work that ships. RAG has expanded as a term to cover any system that retrieves before generating, including systems where the retrieval is doing the entire job and the generation is decoration. That is fine. Pay attention to where the value actually comes from.



Vector database (noun) A database optimized for similarity search on embedding vectors. The 2023 hype cycle implied you needed a dedicated one. By 2026, Postgres can do this competently for most workloads via pgvector, and the dedicated vector databases have either added more general database features or accepted being a specialized tier. The interesting question is no longer "which vector database." The interesting question is "do you have a retrieval problem that needs anything more than Postgres."



MCP (noun, Model Context Protocol) An open protocol Anthropic announced in November 2024 for connecting LLMs to tools and data sources. Adopted widely through 2025 and 2026. The genuine value: a standard way to expose a tool to multiple model providers without rewriting the integration each time. The hype: everything is becoming "MCP-compatible," which sometimes means "we wrote an MCP server" and sometimes means "we put the MCP logo on the marketing site." Worth knowing which, and worth knowing that every MCP server you connect is a new trust boundary (MCP Is Your New Attack Surface).



Hallucination (noun) The polite word for "the model is wrong." Specifically, generating output that is fluent and confident but factually incorrect or fabricated. The word went mainstream with ChatGPT's launch in late 2022, and it was useful then because it captured something distinctive about how these models failed — fabricating sources, inventing functions, citing nonexistent papers. The word is now actively harmful, because it suggests the failure is rare and weird, when in fact it is a structural property of the technology. Models are wrong all the time. The interesting engineering work is not eliminating hallucination. It is building systems that survive it.



Open source (adjective, applied to AI models) A term being torn into pieces. Some "open source" models are open weights — you can download and run them — but the training data, training code, and license restrictions are not open in any traditional sense. Some are genuinely open in every dimension. Most are somewhere in between. The Open Source Initiative released version 1.0 of its Open Source AI Definition in October 2024, and few large model releases meet it. The industry has mostly ignored it. The honest version: when a vendor says "open source," ask which of (weights, code, data, license) are actually open, and what the license actually permits. If they cannot answer cleanly, they are using the term for marketing, not for technical accuracy.



Vibe coding (noun) Andrej Karpathy's coinage, from a post in February 2025. Coding by describing what you want to an LLM and accepting what it produces without reading it carefully. As a personal experimentation mode, it is liberating and produces real software fast. As a team practice for non-trivial systems, it produces software that runs until it does not, written by no one in particular, owned by no one in particular, debugged by everyone in particular. The honest assessment is that vibe coding is a great way to start things and a poor way to finish them. The hard work in software is rarely the part where you start. (The longer version: Vibe Coding: Building Software by Feel.)



The glossary at work: one pitch, translated


Composite example, built from patterns in vendor reviews. The organisation and product are invented.


A regional insurer's architecture review board gets a deck for a claims-triage product. The headline slide reads: "An AI-native, agentic platform that uses RAG over your policy documents, with MCP support for your existing tools." That is four glossary terms in one sentence. The board chair, who has been burned before, runs the deck through the definitions above one term at a time, and turns each into a question the vendor has to answer with a description of behaviour rather than an adjective.


  • "Agentic" became: what can it do, without a human approving, that we cannot easily undo? The answer was that it drafts a triage recommendation and a human adjuster accepts or rejects it. That is a useful product. It is not an agent by the definition above, and it means the risk sits in the adjuster's review step, not in autonomous action.

  • "AI-native" became: does the workflow make sense without the model? It does: it is the insurer's existing triage queue with a suggested-priority column. So the model is a feature, and the board can ask what happens to the queue when the model provider has an outage. The vendor had not thought about it.

  • "RAG over your policy documents" became: where does the retrieval quality come from, and how is it measured? This was the strongest answer. The vendor showed a held-out set of 200 past claims with the policy clauses a human expert had matched, and its retrieval hit rate on that set. That is the unglamorous work, and it was real.

  • "MCP support" became: which MCP servers, written by whom, with what permissions? One read-only connector to the document store, written by the vendor. Narrow, which is good, and now it is written down.


The board's decision changed shape. Instead of approving an "agentic platform," it approved a recommendation tool with a named human checkpoint, a retrieval benchmark the vendor would re-run every quarter, and a fallback for model outages written into the contract. Same product, honest premise. The budget line moved from "AI transformation" to "claims tooling," which is where it belonged.


Run it on the next deck


Before the next demo, spend ten minutes on this:


  1. Highlight every term from this glossary that appears in the pitch materials.

  2. For each one, write the behaviour question it implies, using the entries above as the template: what it does, what it touches, who checks it, what happens when it is wrong.

  3. Send the questions ahead of the meeting and mark each answer as behaviour (a list of actions, a data flow, a measured number) or adjective (the term restated in other words).


Our rule of thumb, not a published benchmark: if more than half the answers come back as adjectives, ask for a named production reference before you give the vendor a second meeting. If most come back as behaviour, the vendor has already done the thinking you were about to do for them. Evaluating New Tools Without the Hype covers the rest of the evaluation once a vendor passes this first screen.


Why the words matter


The reason language matters here is that the words shape what gets bought, what gets built, and what gets blamed when things go wrong. When a vendor calls a script an "agent," a procurement team approves a budget on the wrong premise. When an executive calls a feature "AI-native," an engineering team accepts a constraint they would have argued with otherwise. When a model failure gets called a "hallucination," a remediation plan gets written that treats the failure as occasional and exotic when it is structural and routine.


Regulators have started treating the gap between the word and the system as more than a style problem. In March 2024 the US SEC settled its first "AI washing" cases, against two investment advisers that had overstated their use of AI. In September 2024 the FTC's Operation AI Comply went after companies using AI claims to deceive customers. Those were extreme cases. The everyday version is a budget approved on a word nobody defined.


You can decide what these words mean inside your own organization. You will not be able to decide what they mean in the industry. The next best thing is a glossary your team wrote down. One way to build it: take the five terms that appeared most in last quarter's vendor decks, give each a one-paragraph engineering definition and the behaviour question it implies, and ask the two people who would be paged when the system fails to edit it. Keep it next to your vendor-review template so it gets used when the pitch decks arrive.


Take this one, edit it, fight with it. The point is not that you agree with these definitions. The point is that your team has its own.


Sources




Part of the Perspectives guide — ShiftQuality's field notes on building, AI, and business.

 
 
bottom of page