Vocabulary in this field moves faster than the underlying ideas, and a fair amount of it exists to make ordinary engineering sound novel. These are the terms you will actually meet in a proposal or a technical conversation, defined as briefly as they can honestly be defined.

Where a term carries a decision rather than just a meaning, there is a link to the longer treatment.

Core concepts

AI agent
A system given an objective rather than a sequence of steps, with tools it can use to pursue it, that decides for itself when it is finished. All three properties have to be present; remove one and you have something simpler and usually preferable.
Agentic
An adjective for the loop: acting, observing the result, and deciding whether to continue. It is a real distinction and it is also the most over-applied word in the field — a great deal of software described as agentic is a sequence of prompts.
Large language model (LLM)
The component that takes text and produces text. On its own it cannot look anything up or do anything. It is a part of an agent, not a synonym for one.
Prompt
The text sent to the model. In production this is rarely handwritten prose — it is assembled from instructions, retrieved passages, tool definitions and the current input.
System prompt
The standing instructions that apply to every request: what the agent is for, what it must never do, what to do when unsure. Effectively a policy document written for a machine, and usually the first one anybody has written down.
Tool use
The mechanism by which a model can trigger real operations — searching a database, sending an email, calling an API. Also called function calling. This is where an agent stops being a text generator and starts being a system with consequences.
Orchestration
Coordinating the steps, tools and models that make up a working system, including what happens when a step fails. Most of what people call agent development is orchestration.
Multi-agent
Several specialised agents passing work between them. Occasionally the right structure for genuinely separable jobs. Frequently a way of turning one debugging problem into four, and worth being sceptical of when a single agent has not been tried.

If only one of these is worth being precise about, it is the first. The distinction between an agent and the three things adjacent to it is what determines the price and the testability of a project.

Knowledge and retrieval

RAG (retrieval-augmented generation)
Searching your own material for relevant passages and giving them to the model to answer from. The model learns nothing; it is handed the source at the moment it answers. This is the correct approach for nearly every business use case.
Grounding
Tying an answer to a specific source so it can be checked. The practical difference between a system people trust and one they quietly stop using.
Embedding
A numerical representation of a passage of text, arranged so that passages about similar things sit close together. What makes search by meaning possible rather than search by keyword.
Vector database
Storage built to find the nearest embeddings to a query quickly. A component, not a strategy — and rarely the reason a retrieval system is disappointing.
Chunking
How documents are split before indexing. It determines what can be found: too small and a passage loses the context that gave it meaning, too large and the relevant sentence is buried. There is no universally correct setting, so it has to be tested against real questions.
Context window
How much text the model can consider at once. Larger windows have not made retrieval obsolete — putting everything in the window is slower, more expensive and measurably worse at finding the relevant detail than retrieving the right passage.
Hallucination
A confident, fluent, specific and wrong answer. The important property is not that it happens but that it is indistinguishable in tone from a correct one, which is what makes it expensive: a visibly broken system gets reported, a confidently wrong one gets believed.
Fine-tuning
Adjusting a model’s weights with examples so it behaves differently — format, register, a specialised classification. It changes behaviour, not knowledge, and it does not reliably install facts.

The last two entries account for most of the confusion in buying conversations, because fine-tuning is usually requested to fix a knowledge gap that only retrieval can fix. The test for which one you need is short.

Running it in production

Guardrails
Constraints on what the agent may do, enforced by what it can actually reach rather than by instructions asking it not to. An agent with credentials for an operation will eventually perform that operation.
Escalation
The defined route by which work the agent should not finish reaches a person. The escalation rate is the most useful number an agent produces — an unusually low one normally means it is escalating less than it should, not handling more.
Human in the loop
A person reviewing or approving before an action takes effect. The distinction between drafting and sending is the entire difference between two risk profiles, and it is often requested mid-project as though it were a small change.
Evaluation (evals)
A set of real cases with known correct handling, run whenever anything changes. This is what separates an agent you can improve from one you can only hope about, and it is the component most often skipped.
Golden set
The curated cases in an evaluation suite, including the ones the team already knows are hard. Its value comes from being maintained — an eval set that stopped growing when the project shipped stopped being an eval set.
Observability
Recording the input, what was retrieved, which tools were called with which arguments, the output, and whether a person reviewed it. Without it, no question about a past decision has an answer.
Drift
The gap that opens as the real process changes and the agent does not. The dangerous kind is silent: nothing breaks, the agent simply handles a slightly wrong version of the job, a little more wrongly each month.
Prompt injection
Instructions smuggled into content the agent reads — an email, an uploaded document, a web page. Not reliably filterable, so the defence is narrow permissions and approval on anything irreversible rather than detection.

These eight are the difference between a demo and a system a business can depend on. A demo needs two of them.

Cost and limits

Token
The unit models are billed and measured in — roughly a word fragment. Both the input and the output are counted, which is why a system that stuffs a large context into every request is expensive in a way that is not visible in the code.
Inference
One run of the model. Where the per-task running cost comes from, which makes volume a design consideration rather than an afterthought.
Latency
How long a response takes. It matters more than it looks on paper, because an agent that runs a loop of several model calls and several tool calls adds those up, and a person waiting will notice.
Rate limit
The ceiling a provider puts on requests per interval. A real production constraint at volume, and one of the more common causes of an integration failing in a way nobody designed for.
Determinism
Whether the same input always produces the same output. Workflow automation is deterministic and can be tested exhaustively. An agent is not, which is why it needs evaluation against real cases instead.

Worth knowing that the running cost of a maintained agent tends to fall rather than rise, because the model that is correct for a task today is frequently not the cheapest one that can do it six months from now. The full set of things that move a quote is a longer subject.

The neighbouring technologies

Workflow automation
A defined sequence of steps with defined branches. If you can draw the whole process as a flowchart and the flowchart is right every time, this is what you want — cheaper to build, cheaper to run and far easier to verify than an agent.
RPA (robotic process automation)
Driving an existing user interface the way a person would. It solves exactly one problem: a system with no usable way in. It is not reasoning about anything and it breaks when the interface moves.
API
A documented way for one system to be used by another. Whether the systems in a process have one is the single strongest predictor of what an automation project will cost.
Webhook
A system notifying another that something happened, rather than being asked. What turns a scheduled automation into one that responds immediately.
Idempotency
The property that doing the same operation twice has the same effect as doing it once. Unglamorous and load-bearing: without it, a retry after a failure can send the second invoice.

The first two are the ones a proposal should be explicit about, because being sold an agent for a process that a flowchart would have handled is the most common way to overpay in this field.

If a term cannot be explained to the person who owns the process, it is not yet doing any work in the proposal.