Why AI teams need a living glossary before the next deployment

The fastest-growing risk in AI deployment may be linguistic.

As terms like AGI, LLM, AI agents, RLHF, tokens, caching, and distillation spread through product decks, incident reviews, vendor demos, and policy memos, the language itself starts to drift faster than the systems it describes. TechCrunch’s May 9 glossary piece captured the moment well: the point was not just to define acronyms, but to acknowledge that the field is inventing a new working vocabulary in real time. That matters because once a term is used in a launch plan or governance meeting, it stops being a curiosity and becomes part of how teams make decisions.

This is why the right response is not another static AI glossary. It is a living one.

Why terminology is now a deployment issue

In earlier software cycles, a glossary was often a nice-to-have: a reference page for onboarding, maybe a style guide appendix. In AI, that model breaks quickly. The same phrase can mean different things across model providers, product teams, and compliance groups. “Agent,” for example, may refer to anything from a tool-using assistant with limited workflow scope to a more autonomous system that chains actions, calls APIs, and keeps state across steps. “AGI” is even looser; TechCrunch’s coverage underscored that even leading labs do not use the term consistently.

That ambiguity creates practical problems. Product managers may specify an “agentic” feature without clarifying whether it is deterministic orchestration or probabilistic task completion. Engineers may assume “memory” means a prompt cache, while leadership imagines persistent user state. Risk teams may hear “RLHF” and assume a mature alignment process when the implementation is closer to a narrow preference-tuning loop.

When terms drift, deployments slow down in subtle ways: requirements get rewritten, approval cycles lengthen, monitoring criteria get muddied, and postmortems spend too much time disentangling what was meant in the first place. The spike in coverage around AI vocabulary on 2026-05-09 is a signal that the stack is moving faster than shared language. The glossary becomes a coordination layer, not a glossary for its own sake.

What a living glossary changes in practice

A living glossary is not a static page of definitions. It is a maintained artifact with owners, versioning, and a feedback loop.

That means three things.

First, definitions are plain-language and tied to actual system behavior. If a team uses “LLM,” the entry should say what the model does in the product, what it does not do, and which workflow it sits inside. If “RAG” appears in a roadmap, the definition should point to retrieval infrastructure, index freshness, citation handling, and the failure modes that matter in production.

Second, the glossary changes with the field. TechCrunch’s own framing matters here: the site presented the glossary as something updated regularly, which is the right posture for a domain where features, model classes, and deployment patterns evolve on a monthly cadence. Versioned entries can record when a term was added, what changed, and which teams approved the wording. That makes the glossary auditable rather than ceremonial.

Third, it is integrated into the tools people already use. The best glossary is not trapped in a wiki tab no one opens. It shows up in product requirement docs, incident templates, design reviews, model cards, and rollout checklists. If a term is attached to a workflow, it becomes useful. If it is only attached to an explanation, it fades.

The core terms that matter once AI is in production

The point of a glossary is not to flatten every term into one-sentence simplicity. It is to make the operational meaning explicit.

AGI

Artificial general intelligence is one of the most overburdened phrases in the field. TechCrunch’s coverage rightly treats it as nebulous, and the term remains more directional than operational. For a product team, the useful question is not whether a model “is AGI,” but what capability threshold is being claimed, by whom, and for which task class. A living glossary should connect the term to internal decision points: do not use AGI in launch language unless the product, policy, and research teams have agreed on the specific meaning.

LLM

Large language model should be defined in deployment terms: a model that predicts and generates text, often used as a general-purpose interface layer for summarization, extraction, drafting, or tool routing. The glossary should note where the model sits in the workflow, whether it is fine-tuned or prompted, and what telemetry is needed to evaluate quality.

AI agents

This term needs the most discipline. In practice, it should be mapped to tooling such as function calling, orchestration frameworks, planning loops, external API access, and state management. A team should be able to answer: what actions can the agent take, what guardrails are in place, what happens on failure, and where a human must re-enter the loop?

RLHF

Reinforcement learning from human feedback is often used as shorthand for “the model was aligned,” but that is too broad. The glossary should spell out that RLHF is one alignment technique among others, and should identify where human preference data enters the training pipeline, how it affects behavior, and what limits remain.

Neural networks, weights, tokens, training, inference, caching, diffusion, distillation

These are the terms that become important once a system moves from demo to production.

• Neural networks should be defined as the architecture class underlying many modern models, with a note on how they relate to parameterized prediction.
• Weights are the learned parameters that store model behavior.
• Tokens are the units the model processes, which matters for context length, cost, and truncation.
• Training is the phase where the model learns from data; inference is where it is used to produce outputs.
• Memory caching affects latency and cost, especially in repeated or long-context interactions.
• Diffusion models matter in image and media generation workflows.
• Distillation refers to compressing or transferring capability from a larger model to a smaller one, often to reduce cost or improve deployment efficiency.

Each of those entries should point to a real operational question: Does this affect latency? Cost? Evaluation? Safety? Rollout scope? If the answer is yes, the glossary entry should make that link explicit.

Why the mechanics matter for governance

Once a glossary is tied to deployment realities, it becomes more than a communications aid. It becomes governance infrastructure.

A rollout review can use the glossary to standardize what counts as an “agent,” what qualifies as “human oversight,” or what “memory” means in a given system. A risk review can use it to separate model capability from product capability, which is often where mispricing happens. An incident response playbook can use it to clarify whether a failure occurred in retrieval, generation, orchestration, or post-processing.

That distinction matters because AI incidents are often misread through vague labels. If a team says the model “hallucinated,” that may conceal a prompt issue, a retrieval failure, a bad citation pipeline, or a missing control in the user workflow. A living glossary does not eliminate ambiguity, but it makes ambiguity visible earlier, when it is still cheap to correct.

It also creates a better interface between product and policy. Compliance teams do not need poetry; they need definitions that map to controls. Engineers do not need slogans; they need terms that describe what the system does under load. Editors and docs teams can help by keeping the language readable, but the technical burden is to ensure the words line up with the stack.

What to do this week

Teams do not need to wait for a perfect taxonomy. They need a lightweight governance loop.

Start with the 15 to 20 terms that show up most often in your roadmap, architecture docs, risk assessments, and customer-facing messaging. For each term, write a definition in plain language and add three fields: where it appears in the product workflow, what tool or system it maps to, and who owns updates.

Then assign version control. If the meaning of “agent” changes because the product adds persistent memory or external actions, the glossary entry should change with it. If a model moves from batch evaluation to online inference, the definitions around training, inference, and caching should be updated together.

Finally, make the glossary visible in the places where decisions happen. Link it from launch templates, review docs, and incident forms. Ask reviewers to flag any term that feels overloaded, outdated, or too vague to support a release decision.

The real value here is not educational polish. It is operational alignment. In a market where AI rollout is accelerating and the vocabulary is still settling, a living glossary gives teams a shared, current language for what they are building, shipping, and governing. That is less about knowing the right word and more about making sure the word still means the same thing by the time the system goes live.