Glossary
The AI terms that actually come up when a team is choosing, testing, or operating a system, defined the way a practitioner would explain them to a leader who has to make the call, not memorize the vocabulary.
Definitions
A model trained on large amounts of text to predict and generate language. It powers chat assistants, drafting, and summarization. An LLM is fluent by default but not reliable by default, which is why how you ground, constrain, and evaluate it matters more than which model you pick.
A design where the system first retrieves relevant documents from your own sources, then asks the model to answer using them. RAG is how you get an AI to answer from your knowledge rather than its training, and it is only as good as the retrieval and the citations behind each answer.
Embeddings turn text into numerical vectors so passages with similar meaning sit near each other. A vector database stores those vectors so the system can find the most relevant passages for a question. Together they are the retrieval engine underneath most RAG systems.
A system that can take actions toward a goal, not just answer a question: it can call tools, run steps, and react to results. The reasoning is rarely the hard part. Memory, scheduling, recovery from failures, scoped permissions, and approvals are what make an agent reliable in production.
A multi-step process run by one or more agents that hand off to each other, often on a schedule and with a person at the points that need judgment. For real work, a team of specialist agents is usually easier to operate and trust than a single generalist holding everything in one thread.
Further training a model on your own examples so it adapts to a specific style or task. It is powerful but often reached for too early. For most needs, prompting and retrieval get you there faster and cheaper, and fine-tuning earns its cost only when those have hit a clear ceiling.
The prompt is the instruction and context you give a model. Prompt engineering is the practice of shaping that input to get reliable output. It is real work, but it is the surface of a system, not the foundation; durable results come from retrieval, evaluation, and workflow design, not clever wording alone.
The amount of text a model can consider at once, including your instructions, the retrieved documents, and the conversation so far. When work exceeds the window, the system has to summarize or retrieve selectively, which is a large part of why RAG and memory design exist.
When a model produces confident, fluent text that is wrong or invented, such as a citation to a case that does not exist. It is a property of how these models work, not a bug that gets fully patched, so the defense is design: grounding answers in sources, exposing citations, and building review into the workflow.
Grounding means tying an answer to specific source material rather than the model's general memory. Citations expose which sources were used so a reviewer can check them. In any high-stakes use, an answer a person can trace back to a source is worth far more than a confident answer they cannot.
A test set tied to the work the system actually does, scored on a rubric, run repeatedly so quality becomes a number rather than an impression. Evals are how you know a system is good enough before rollout and how you catch a regression after a model upgrade before a customer does.
The constraints that keep a system inside safe boundaries: limits on what it can access, checks on its output, and rules about what it must refuse or escalate. Guardrails are how you let a useful system take real actions without giving it a blast radius you would regret.
A design where a person reviews or approves the AI's work at the points that carry risk, rather than the system acting unsupervised end to end. The goal is to put human judgment exactly where it changes the outcome, and to let automation carry the rest.
Running a trained model to produce an output, as opposed to training it. Inference is the recurring cost and the latency you feel in production, so where and how you run it, by API or on your own infrastructure, is a real engineering and economic decision.
The decision between assembling an AI capability from existing products and models or building a custom one. For most companies the default is buy, configure, and evaluate; building earns its cost only when proprietary data, a specific workflow, a compliance boundary, or scale economics make the off-the-shelf option genuinely worse. More on when to build vs. buy AI.
Engaging a senior AI leader part-time to set direction, review architecture, guide vendors, and build an operating rhythm, before or instead of a full-time executive hire. It gives a team a senior AI point of view without the cost and commitment of a permanent role. See fractional AI leadership.
An independent technical review of an AI product, vendor, or system, covering architecture, model choices, evaluation rigor, data handling, security, scalability, and team, usually for an investor, acquirer, or buyer who needs an honest read before committing. See AI technical due diligence.
Next step
Bring the system, vendor, or decision you are weighing. The first call is about goals, constraints, and whether it is a serious fit.
