The only AI glossary you’ll need this year
In robotics and physical AI, terminology is no longer just a communications problem. It is now part of deployment reality.
A product team can say it is “using an LLM,” a supplier can promise “deep learning,” and an investor can ask whether a system is “AGI-adjacent,” but those labels do not tell an operator what the robot can do on the floor, what latency budget it needs, what data leaves the site, or how often the model has to be retrained. That gap is widening faster than most teams can absorb.
That is why a living, plain-English AI glossary matters in 2026. Not as a reference page. As a control surface.
TechCrunch’s new glossary coverage reflects the same shift: the field is producing new terms faster than most product, engineering, procurement, and diligence processes can normalize them. For companies shipping humanoids, autonomy stacks, warehouse robots, and industrial physical AI, this matters because vocabulary now shapes design choices, procurement language, risk reviews, and rollout expectations.
When the words change, the deployment assumptions change too
A glossary only matters if it changes behavior. In physical systems, the cost of misunderstanding is concrete.
If a vendor says a system uses “deep learning,” that could mean a perception model running on a GPU at the edge, or it could mean a cloud-hosted pipeline that depends on periodic uploads of production video. If a team says “training,” they may mean offline pretraining in a data center or a small on-site fine-tune after deployment. If they say “inference,” they may be talking about a 20 millisecond control loop or a 2 second batch decision that is fine for inspection but unusable for real-time manipulation.
The glossary needs to translate those terms into operational questions:
- Where does compute run: on-device, at the edge, or in the cloud?
- What is the latency budget per control decision?
- What data is collected, retained, anonymized, or sent off-site?
- How often is the model retrained or updated?
- What failure modes appear when the model drifts?
That is the deployment value of a plain-English glossary. It turns vocabulary into specifications.
The terms that matter most in robotics and physical AI
A useful glossary does not define every acronym equally. It prioritizes the terms that routinely distort planning.
AGI
AGI stands for artificial general intelligence. In plain English, it usually means a system that can handle a very wide range of tasks at a level comparable to humans. In deployment terms, that is not a procurement category for near-term robotics programs.
Why it matters: AGI is often used loosely in pitches and investor decks, which can create false expectations about what a humanoid or autonomy stack can do today. For operators, the practical question is narrower: can this system perform one bounded task reliably enough to justify operational use?
LLMs
LLMs are large language models. They are statistical models trained on large text datasets to generate or transform language.
Why it matters: In physical AI, LLMs are often useful for orchestration, instruction parsing, operator copilots, maintenance interfaces, or task planning. They are not automatically good control systems. If a robot workflow depends on an LLM for safety-critical reasoning, teams should ask what guardrails exist, what the fallback behavior is, and whether the model is being used to suggest actions or execute them.
Neural networks
Neural networks are machine-learning models built from layers of connected units that learn patterns from data.
Why it matters: This is the base structure behind many perception and control systems. The deployment question is not whether the stack “uses neural networks,” but how those networks behave on your data, in your environment, under your latency and uptime constraints.
Deep learning
Deep learning is a subset of machine learning that uses multi-layer neural networks, typically requiring larger datasets and more compute than simpler methods.
Why it matters: Deep learning has made vision, speech, and multimodal perception much better, but it also raises compute cost, data handling, and maintenance complexity. A deep-learning model that works in a lab may still need compression, quantization, pruning, or hardware-specific optimization before it can run economically on a robot.
Training vs inference
Training is when a model learns from data. Inference is when a trained model is used to make predictions or decisions.
Why it matters: This distinction drives architecture and cost. Training is usually compute-heavy and often happens in the cloud or a centralized environment. Inference is what happens in the field, and it may need to run at the edge to meet latency, reliability, or privacy constraints. In robotics, confusion here leads to bad procurement decisions: teams buy for training-scale compute when they really need inference efficiency, or they assume the cloud can support real-time operations when the network cannot.
A practical benchmark: if a manipulation task needs a response window under 100 milliseconds, cloud round-trips are often a poor fit unless the control loop is largely local and the cloud only supports higher-level planning. In warehouse or factory deployments, even small delays can compound when a system has to coordinate sensing, planning, and actuation across multiple machines.
Transfer learning
Transfer learning means taking a model trained on one task or dataset and adapting it to a related task.
Why it matters: This is one of the most important terms for robotics deployment because real sites rarely match training data. Transfer learning can reduce the amount of site-specific data needed, lower retraining cost, and shorten rollout time. But it also introduces risk: a model adapted from one facility, lighting condition, payload profile, or object class may underperform if the target environment differs too much.
What a living glossary changes in day-to-day operations
The best reason to maintain a living glossary is not educational. It is operational alignment.
In product meetings, a plain-English glossary reduces the chance that “autonomy,” “generalization,” or “foundation model” means something different to each stakeholder. In procurement, it forces vendors to define whether they are selling a model, a runtime, a sensor package, or a managed service. In risk reviews, it helps teams separate capability claims from deployment constraints.
That matters because robotics programs fail slowly when definitions are loose. A team may approve a pilot believing the system can learn on site, only to discover that updates require a cloud workflow and a retraining queue. Or an investor may benchmark two vendors as if both were selling the same thing, when one is really offering a perception stack and the other is offering a full-stack autonomy platform with very different maintenance obligations.
This is where the glossary becomes a working document. It should sit near product specs, not in a static wiki nobody reads.
The investor case: clarity shortens diligence
Investors do not need more AI hype. They need a way to compare deployments without getting trapped in terminology.
A living glossary helps separate genuine capability from buzzword compression. If a company says its robot “uses AGI,” that should trigger a definition check. If a warehouse vendor claims an LLM is part of its control stack, diligence should ask whether the model affects user interaction only, or whether it is influencing task planning, exception handling, or actuation decisions.
That kind of clarity shortens diligence because it anchors terminology to measurable deployment outcomes:
- latency budgets
- edge-versus-cloud split
- retraining cadence
- data retention policy
- model update path
- failure and rollback behavior
In other words, the glossary turns a conversation about AI labels into a conversation about operating conditions.
How to use a living glossary without turning it into paperwork
A glossary only earns its keep if teams update and apply it.
A practical adoption path looks like this:
- Assign ownership. One person or a small group should maintain definitions across product, engineering, and operations.
- Use plain English first. The definition should explain the term as it affects deployment, not just as a textbook concept.
- Tie each term to a decision. For example: does this term affect latency, safety, privacy, uptime, or retraining?
- Review on a cadence. Monthly is often enough for fast-moving robotics teams; quarterly may work for later-stage programs, but only if the market and model stack are stable.
- Embed it in core artifacts. Add glossary terms to product specs, procurement requirements, risk registers, and investor memos.
A useful rule: if a term cannot be translated into an operational question, it does not belong in the decision memo yet.
Appendix: sample glossary entry
Training vs inference
Plain-English definition: Training is when the model learns from data. Inference is when the trained model is used to make decisions in the real world.
Why it matters in deployment: Training usually happens off-site on heavier compute. Inference is what the robot runs during operation, often under strict latency, power, and reliability limits.
Questions to ask:
- Does inference happen on the robot, at the edge, or in the cloud?
- What is the maximum acceptable delay?
- How often does the model need to be updated?
- What happens if the network fails?
Operational implication: If the system cannot meet inference latency on-site, it may not be suitable for real-time control.
Suggested update cadence: Review monthly, or whenever the model architecture, deployment environment, or safety requirements change.
The point of a living glossary is not to freeze the language. It is to keep the language close enough to reality that teams can still make good decisions while the field moves.
If your team is building, buying, or funding robotics and physical AI systems, the next step is simple: subscribe, contribute definitions, and integrate the glossary into product specs and risk registers before the terminology outruns the deployment.
