NewFree sixty minute diagnostic on the work you would most like off your team. Written recommendation either way, whether or not we build it. Book it

AI agent glossary

"Agent" is the most inflated word in AI right now. It gets stamped on chatbots that answer one question, on scripts that were called macros last year, and on genuinely autonomous systems that plan and act on their own.

When every vendor uses the same word for different things, a buyer cannot tell what they are actually being sold.

This AI agent glossary fixes that by defining the terms plainly, in the order they matter, so you can read a product page and know whether "agent" means something real or something relabelled.

Each term below sits under its own heading with a short, self contained definition and a one line note on what it means in practice for a business, not a research lab.

The terms are grouped by what they describe: what an agent is, how one is built, and the newer vocabulary that has become standard as agents moved into real deployments through 2025 and 2026.

How this AI agent glossary is arranged

Read the core terms first if you are new to the topic; they draw the line between a true agent and the simpler things often sold as one.

The architecture section explains the parts a working agent is assembled from, which is useful when a proposal lists "memory" or "orchestration" and you want to know what you are paying for. The advanced section covers the terms that appear in current tooling and governance discussions.

Where a term has a deeper page of its own, we link to it so you can go from a definition to a full explanation without hunting.

Real examples

To see how these terms fit together, picture an agent that handles inbound supplier invoices. Its perception is reading each emailed invoice and querying the purchase order system. Its tools let it match the invoice to an order, flag discrepancies and draft a payment entry.

Its agentic loop checks each invoice, decides whether it matches, and acts or escalates. A human in the loop approves anything over a set value, guardrails stop it paying anything itself, and grounding against the actual order data keeps it from approving an invoice with no real order behind it.

Every one of those terms is doing concrete work in a single, ordinary finance task. That is the point of the vocabulary: it lets you describe precisely what a proposed system will and will not do, and where a person stays in control.

For the full range of what agents can be pointed at, see our guide to the types of AI agents and the broader complete guide to AI agents.

How to move from agent vocabulary to a build

You do not need to memorise this list to make a good decision.

Use it as a reference the next time you read an agent proposal or product page: check whether "agent" means a real agentic loop or a relabelled chatbot, ask which tools it can call and what its guardrails are, and confirm where a human stays in the loop on consequential actions. Those three checks filter out most of the overclaiming.

When you are ready to move from vocabulary to a real deployment, the sensible first step is deciding which of your processes actually warrants an agent rather than a simpler automation. Many do not, and being honest about that saves money.

For the wider AI vocabulary these terms sit inside, see our AI glossary; for the automation terms an agent is often compared against, see the automation glossary.

Deploying an autonomous system also carries responsibilities around oversight and data. The UK's National Cyber Security Centre publishes Guidelines for secure AI system development, a practical reference worth reading before any agent touches sensitive systems.

Diagram: four stages arranged around a ring with arrows running clockwise between them, a marked core at the centre, and three smaller circles spurred off the outside on dashed leads.

Plain definitions, written for someone deciding rather than building Updated July 2026

A

ActionAgent architecture terms
Action is the step where an agent does something in the outside world through a tool, as opposed to reasoning about what to do. Every agentic loop alternates between deciding and acting. In practice: actions are where the risk lives; a wrong action changes real data, which is why action steps are usually where oversight is placed.
Agent handoffMulti agent and advanced terms
Agent handoff is the moment one agent passes a task, and the context needed to continue it, to another agent or to a human. Clean handoffs preserve what has been done so far. In practice: a handoff to a person is the safety valve in most business deployments; the design question is what gets escalated and with how much context attached.
Agentic AICore agent terms
Agentic AI describes AI systems built to act, not just answer, taking multi step actions towards an outcome instead of returning a single response. It is the umbrella term for the current wave of agent products. In practice: "agentic" signals intent to act autonomously; check whether the product delivers that or just uses the word for marketing.
Agentic loopAgent architecture terms
The agentic loop is the repeating cycle an agent runs: observe the current state, reason about the next step, take an action, observe the result, and repeat until the goal is met or a limit is hit. In practice: this loop is the engine of any real agent; understanding it tells you why agents can handle open ended tasks that fixed automations cannot.
AI agentCore agent terms
An AI agent is a software system that takes a goal, decides the steps to reach it, and carries those steps out using tools and data, adjusting as it goes rather than following a fixed script. The deciding and adjusting are what separate it from ordinary automation. In practice: if it cannot change its own next step based on what it finds, it is automation with an AI label, not an agent.
Approval gateControl and safety terms
An approval gate is a point where the agent must stop and get a person's authorisation before continuing. It is the practical way to run useful automation on consequential work. Put gates where the cost of being wrong is high, not on every step, or people will approve without reading.
Automation botCore agent terms
An automation bot follows a predefined sequence of actions, often clicking through screens or moving data on a fixed rule. It is reliable and predictable precisely because it does not decide anything. In practice: if the work is the same every time and the rules never bend, an automation bot is cheaper and safer than an agent, and often the better choice.
Autonomous agentCore agent terms
An autonomous agent runs a task through to completion with little or no step by step human input, making its own choices about sequence and method within limits you set. Autonomy sits on a scale; almost no business agent is fully unsupervised. In practice: the useful question is not "is it autonomous" but "how much is it allowed to do before a person is asked to confirm."
Autonomy levelMulti agent and advanced terms
Autonomy level describes how much an agent is permitted to do without human confirmation, from suggesting an action, to acting then reporting, to acting unsupervised. It is a dial you set, not a fixed property. In practice: most safe business deployments start low, with the agent proposing and a person approving, and raise autonomy only where the task has proven low risk.

C

CapabilityCore agent terms
A capability is something an agent is able to do, usually because a tool has been made available to it. Capabilities are granted rather than emergent: an agent can only reach the systems you connect it to. Listing them explicitly is the clearest way to answer the question of what an agent could possibly do.
ChatbotCore agent terms
A chatbot is a conversational interface that responds to messages, usually one turn at a time, without independently carrying out tasks in other systems. Many chatbots are useful and none are agents by default. In practice: a chatbot answers; an agent goes and does. If a "sales agent" only replies in a chat window, it is a chatbot.
Context engineeringAgent architecture terms
Context engineering is deciding what goes into the model's limited context window on any given step, and what is left out. As systems grow it becomes the main lever on both quality and cost, more so than prompt wording. The discipline is choosing the few things that matter rather than including everything available.
Context windowMulti agent and advanced terms
The context window is the amount of text an agent can hold in view at once, covering its instructions, the current task, retrieved data and recent steps. Exceed it and the earliest content drops away. In practice: a small window forces harder choices about what an agent can consider at once; it is a real constraint on how much a single step can take in.
Cost ceilingControl and safety terms
A cost ceiling is a hard cap on what one run or one period may spend. Because agents decide how much work to do, cost is variable in a way traditional software is not. A ceiling turns an open ended risk into a known maximum, which is usually what makes finance comfortable.

D

DelegationAgent architecture terms
Delegation is one agent passing responsibility for a piece of work to another, along with the context needed to continue it. Done well it mirrors how a team divides work. Done badly, context is lost at the boundary and the receiving agent redoes work or contradicts what was already decided.
DeterminismControl and safety terms
Determinism is whether the same input reliably produces the same output. Rules are deterministic; models are not, though settings can narrow the variation. It matters most when an automated decision has to be defended later, because "it varies" is a poor answer to an auditor.
Dry runControl and safety terms
A dry run executes an agent's plan without letting it write anything, so you can inspect what it would have done. It is the safest way to test against real data. It is the step most often skipped before go live, and the one that most often would have caught the problem.

E

Episodic memoryAgent architecture terms
Episodic memory records specific past interactions as discrete events the agent can recall later, closer to "what happened last Tuesday" than to a general fact. In practice: it lets an agent reference a particular earlier case, which matters for tasks like following up on a specific client thread rather than a generic pattern.
Escalation pathControl and safety terms
An escalation path is the defined route by which an agent hands a case to a person. It needs a named owner and a channel that someone actually watches. An agent that escalates into an unmonitored queue has not handed the work over, it has hidden it.
Evaluation setControl and safety terms
An evaluation set is a fixed collection of test cases with known good outcomes, run against an agent to measure whether it works and to detect regression. Because agents are not deterministic, spot checking is not a substitute. This is the difference between believing a system works and knowing it does.

F

FallbackControl and safety terms
A fallback is the defined behaviour when the preferred route fails: a simpler model, a rule, or a human. Well chosen fallbacks are what make a system degrade gracefully instead of stopping. The wrong fallback quietly produces worse results while looking like everything is fine.
Function callingMulti agent and advanced terms
Function calling is the mechanism by which a model requests a specific external function with structured arguments, which the surrounding system then runs. It is the technical basis of most tool use. In practice: it is a building block, not a product feature; you rarely need to think about it directly, but it is what makes tool use work under the hood.

G

GoalCore agent terms
A goal is the outcome an agent is given, as opposed to the steps it should take. Working from a goal rather than a script is the whole distinction between an agent and an automation. It also means the goal has to be stated precisely, because a vague goal produces confident work in the wrong direction.
GroundingMulti agent and advanced terms
Grounding ties an agent's output to verifiable, current information from your own systems or trusted sources, rather than letting it rely on the model's general training. It is the main defence against confident but wrong answers. In practice: an ungrounded agent guesses from memory; a grounded one checks the source first, which is essential anywhere accuracy is not optional.
GuardrailsMulti agent and advanced terms
Guardrails are the constraints that limit what an agent may do: which tools it can use, what it must never touch, what needs approval, and how it behaves at the edges. They are enforced by the system around the model, not left to the model's goodwill. In practice: guardrails are what make an autonomous agent safe to deploy; a build without explicit ones is not ready for real data.

H

HarnessAgent architecture terms
A harness is the surrounding code and infrastructure that runs an agent: it feeds the model its inputs, executes the tool calls the model asks for, and loops the results back in. The model reasons; the harness makes the reasoning do anything. In practice: when a vendor says their agent is "built on" a well known model, the harness is the part they actually built, and where quality varies most.
Human in the loopMulti agent and advanced terms
Human in the loop means a person reviews or approves certain agent actions before they take effect, keeping human judgement in control of consequential steps. In practice: this is the standard safe pattern for business agents: the agent does the work, a person approves anything that changes money, records or outbound communication.

I

Idempotent actionControl and safety terms
An idempotent action is one that can safely be repeated without changing the result beyond the first time. Since agents retry, any action that creates or sends something needs this property. Without it, a single retry becomes a duplicate invoice.
Intelligent agentCore agent terms
Intelligent agent is the older, academic term for any system that perceives its environment and acts on it to meet a goal. It covers everything from a thermostat to a modern LLM based agent, so it tells you little on its own. In practice: treat it as a category label, not a spec; ask what the agent actually perceives and what it can do.

L

Long term memoryAgent architecture terms
Long term memory stores information an agent keeps across many tasks and sessions, such as your preferences, past decisions or reference facts, usually in an external store it can search. In practice: this is what lets an agent improve with use and stay consistent with how your organisation does things over weeks and months.
Loop limitControl and safety terms
A loop limit caps how many times an agent may iterate on a task. Agents can get stuck retrying variations of a step that will never succeed, and the limit is what stops that consuming a budget overnight. Hitting the limit should escalate, not fail quietly.

M

MemoryAgent architecture terms
Memory is how an agent retains information across steps or sessions so it does not start blank each time. It is usually split into short term, long term and episodic memory, each holding a different kind of context. In practice: good memory is what makes an agent feel like it "knows" your business rather than re asking the same questions.
Model Context Protocol (MCP)Multi agent and advanced terms
The Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools and data sources through one consistent interface, so each new integration does not need bespoke plumbing. In practice: MCP is why connecting an agent to your systems is getting faster and cheaper; it standardises the connection layer that used to be built from scratch every time.
Multi agent systemMulti agent and advanced terms
A multi agent system uses several specialised agents that each handle part of a task and pass work between them, rather than one agent doing everything: perhaps one to collect data, one to draft, one to review. In practice: multi agent designs can be more capable but add coordination risk; for most business tasks a single well built agent is simpler and easier to trust.

O

ObservabilityAgent architecture terms
Observability is how well you can see what a system is doing in production without stopping it. For agents it covers traces, costs, failure rates and escalation volumes. Agents fail in ways that look like success from the outside, which is why watching output alone is not enough.
ObservationAgent architecture terms
An observation is what comes back after an agent takes an action: the tool's result, the error, the retrieved document. The loop of acting and observing is how an agent corrects course. An agent that cannot observe the outcome of its own actions is not an agent, it is a script.
OrchestrationAgent architecture terms
In an agent context, orchestration is the control layer that decides which step, tool or sub agent runs next and in what order, keeping a multi step task coherent from start to finish. In practice: orchestration is the difference between an agent that completes a job reliably and one that loops, stalls or acts out of sequence. It is often the hardest part to get right.

P

PerceptionAgent architecture terms
Perception is how an agent takes in information about its task and environment: reading an email, querying a database, receiving the result of a previous action. It is the input stage of every step the agent takes. In practice: an agent is only as good as what it can perceive; if it cannot see the relevant system, it cannot act on it.
Permission scopeControl and safety terms
Permission scope is the set of systems and actions an agent is allowed to reach, and the boundary that actually contains it. Because prompt instructions can be talked around, scope is the control that holds. Grant the narrowest scope the job needs, not the widest the credentials allow.
PersonaCore agent terms
A persona is the role and voice an agent is instructed to adopt, set in its system prompt. It matters for anything customer facing, because tone is part of the product. It is instruction rather than identity, and it should never be relied on as a safety measure.
PlanningAgent architecture terms
Planning is when an agent breaks a goal into an ordered set of sub steps before or during execution, rather than reacting one action at a time. Stronger planning produces more reliable multi step work. In practice: planning quality is why two agents on the same model can perform very differently; the model matters less than how well the system plans and checks itself.

R

ReActMulti agent and advanced terms
ReAct is a widely used agent pattern in which the model alternates between reasoning about a problem and acting on it, using each action's result to inform the next thought. In practice: it is one of the standard designs behind many agents; knowing the name helps you read technical proposals, but the pattern matters more than the label.
ReasoningAgent architecture terms
Reasoning is the internal process by which an agent works out what to do next from what it currently knows. In modern agents it is handled by the underlying language model, sometimes with steps made explicit. In practice: visible reasoning helps you audit why an agent did something, which is valuable when a decision needs to be explained or defended.
ReflectionAgent architecture terms
Reflection is when an agent reviews its own output or intermediate results and revises them before continuing, effectively checking its own work. In practice: a reflection step catches obvious mistakes before they become actions, and is one of the cheaper ways to make an agent noticeably more reliable.
Retrieval augmented generation (RAG)Multi agent and advanced terms
Retrieval augmented generation (RAG) has an agent search a specific set of documents or data for relevant passages and feed them to the model as context, so answers are based on your material rather than general training. In practice: RAG is how an agent answers accurately from your policies, contracts or records; it is grounding applied to a body of documents.
RollbackControl and safety terms
Rollback is the ability to undo what an automation did. Some actions reverse cleanly, such as a database write; others do not, such as an email to a customer. Knowing which of your agent's actions are irreversible tells you exactly where the approval gates belong.
RouterAgent architecture terms
A router is the component that decides which agent, tool or path a request should take. It is often the cheapest place to improve a system, because sending work to the right handler beats making every handler better. It is also a sensible place to keep a rule rather than a model.

S

ScaffoldAgent architecture terms
Scaffolding is the structure placed around a model to shape how it works: the prompts, tool definitions, memory setup and control flow that turn a general model into a reliable agent for a specific job. In practice: the same model with better scaffolding produces far better results; scaffolding, not the model name, is usually what you are really buying.
Short term memoryAgent architecture terms
Short term memory holds the information an agent needs for the task it is doing right now: the current request, recent steps, intermediate results. It clears once the task ends. In practice: this is the working scratchpad; it keeps a single job coherent but remembers nothing once that job is done.
Side effectControl and safety terms
A side effect is any lasting change an action makes in the world: an email sent, a record updated, a payment made. Side effects are the actions that cannot be undone by stopping the agent, which is why they deserve tighter permissions and, usually, an approval gate.
StateAgent architecture terms
State is what the system knows about the current job as it progresses: what has been done, what came back, what remains. Agents are only as reliable as their state handling, because an agent that forgets a step it already completed will cheerfully repeat it. Durable state is what makes a long running agent safe to resume.
SubagentAgent architecture terms
A subagent is an agent invoked by another agent to handle part of a task. It keeps each one's context focused on a smaller problem, which usually improves quality. The cost is coordination, and a system of many subagents is considerably harder to debug than one that does the work itself.
System promptMulti agent and advanced terms
The system prompt is the standing instruction that sets an agent's role, rules and boundaries, applied to every task before any specific request. It is where much of an agent's behaviour is defined. In practice: a well written system prompt is a large part of why an agent stays on brand and in scope; it is quietly one of the most important pieces of the build.

T

Task decompositionCore agent terms
Task decomposition is an agent breaking a goal into smaller steps it can actually carry out. It is where most of the quality difference between agents shows up, because a bad decomposition cannot be rescued by good execution. Watching how a system decomposes a real task tells you more than any benchmark.
TimeoutControl and safety terms
A timeout is the limit on how long a step may take before it is abandoned. Without one, an agent waiting on a hanging service can stall a queue indefinitely. It should always pair with a defined fallback, or a timeout simply converts a slow failure into a silent one.
Tool schemaAgent architecture terms
A tool schema is the machine readable description of what a tool does and what inputs it expects. It is how a model knows a tool exists and how to call it correctly. Most tool calling failures are schema failures: a vague description produces a plausible call with the wrong arguments.
Tool useMulti agent and advanced terms
Tool use is an agent's ability to call external functions to act beyond conversation: fetching data, running an operation, updating a system. It is the capability that turns a language model into something that can do work. In practice: every claim that an agent "handles" a task rests on tool use; ask exactly which tools it is allowed to call and with what permissions.
ToolsAgent architecture terms
Tools are the external functions an agent can call to get things done: send an email, look up a record, run a calculation, update a system. Without tools an agent can only talk. In practice: the tools you connect define what an agent can actually change; the list of tools is the real scope of what it can do.
TraceAgent architecture terms
A trace is the recorded sequence of everything an agent did on one run: prompts, tool calls, results, decisions. It is the only practical way to work out why an agent did something surprising. Building traces in from the start is far cheaper than adding them after the first incident.

Agent jargon questions worth asking a vendor

Use this ai agent glossary as a reference while evaluating agent products or proposals. Look up each term a vendor uses, check the definition against what they are actually offering, and use the "in practice" notes to ask sharper questions about scope, tools and oversight before you commit to anything.
An ai agent glossary usually groups terms three ways: core terms that define what an agent is and how it differs from a chatbot or bot; architecture terms covering the parts an agent is built from, such as memory, tools and the agentic loop; and advanced terms like MCP, guardrails and handoff that describe modern agent deployment.
A chatbot responds to messages one turn at a time and does not independently carry out tasks in other systems. An AI agent takes a goal, plans steps, and uses tools to act, adjusting as it goes. The short test: a chatbot answers, an agent goes and does the work.
Guardrails are the enforced limits on what an agent may do: which tools it can use, what it must never touch, and what needs human approval. They are built into the system around the model rather than trusted to the model itself, and they are what makes an autonomous agent safe to run on real business data.
An agentic loop is the repeating cycle an agent runs: it observes the current state, reasons about the next step, takes an action, observes the result, and repeats until the goal is met or a limit is reached. This loop is what lets an agent handle open ended tasks that a fixed automation cannot.
MCP, the Model Context Protocol, is an open standard for connecting agents to external tools and data through one consistent interface, so each integration does not have to be built from scratch. For a business, it means connecting an agent to your systems is becoming faster and cheaper than it was.
Vendors use "agent" to mean very different things, from a real autonomous system to a simple chatbot. A glossary lets you cut through that, tell what you are actually being sold, and ask precise questions about scope and oversight, so you buy the capability you need rather than the one the marketing implies.
Start with the terms that separate real agents from simpler tools: AI agent, chatbot and automation bot, then agentic loop, tools, guardrails and human in the loop. Those seven let you read almost any agent proposal and judge whether it describes genuine autonomy or an ordinary automation wearing a newer name.

Checking whether a product is really an agent

Knowing the vocabulary is the easy part; deciding whether an agent earns its place in your operation is the part that saves or wastes money.

An automation audit is how we separate that with you: we look at which of your repeated processes an agent could genuinely run end to end, judge honestly where a simpler automation would do the same job for less, and design anything worth building around the systems you already have.

When an agent is the right answer, our workflow agents service is how we build it and keep it dependable as your work changes.

Book an automation audit to find out which, if any, of your processes is worth handing to an agent.