AI Agent Terminology: A Working Glossary

Use this as a reference

The rest of this course assumes you know these terms. Skim it now, and come back whenever a later lesson uses a word you've lost track of.

Grouping the terms by what they describe

These terms cluster into a few natural groups, which is worth noticing before you try to memorize them individually. Some describe the loop itself (turn, orchestration, stopping condition) -- how the agent's execution is structured. Others describe how information gets in (context window, retrieval, embedding, vector database, chunking) -- the mechanics of getting the right facts in front of the model. Others describe architecture choices (planner, multi-agent system, orchestrator-workers, reflection) -- how responsibility is split across one or more models. And a last group describes safety and correctness (grounding, guardrail, hallucination) -- how you keep an agent's actions and claims trustworthy. Later lessons in this course are organized along roughly these same four groupings.

Two pairs people mix up

Memory vs. context: context is what's actually in the model's input on this specific call; memory is the broader system (often outside the context window, stored in a database) that decides what to pull into that context on this turn. An agent can have gigabytes of memory but only a small slice ever fits in context at once.

Tool vs. function: in everyday conversation these are used interchangeably, but "tool" is the agent-facing concept (a capability the model can choose to invoke, described in natural language) while "function" or "function call" is often the specific mechanism -- a structured, typed call with a name and arguments -- that a given API uses to expose that tool to the model.

Why these terms matter for debugging

Understanding terminology is practical, not just academic. When something goes wrong in an agent system, the diagnosis depends on naming what broke. "The agent is being dumb" is not fixable; "the agent's memory isn't retaining prior results" or "retrieval is bringing back stale documents" is. Each term corresponds to a component or mechanism you can actually tune or fix. This glossary is designed so that when a later lesson says "the model's stopping condition," or "the orchestrator exceeded the turn budget," you know exactly what mechanism is being discussed and how it affects behavior.

A tiny agent trace, annotated with terminology

To see how these terms apply in practice, consider a minimal agent run annotated with the relevant vocabulary:

Input: "What was Tesla's revenue growth from Q1 to Q2 2024?"
Goal: Get financial data on Tesla and compare quarters

Turn 1:
  - Orchestrator loads Goal + empty Context
  - LLM Core receives context, plans: "I need financial data"
  - Tool Call: search_financial_api("Tesla Q1 Q2 2024 revenue")
  - Tool Result: { "Q1_revenue": 21.46B, "Q2_revenue": 25.18B }
  - Turn budget decremented: 1/10 Turns used

Turn 2:
  - Orchestrator appends Tool Result to Memory and Context
  - Context Window now contains: Goal + Q1 & Q2 revenue in one input
  - LLM Core receives larger context, plans: "I have the data, can compute growth"
  - Calculates: (25.18 - 21.46) / 21.46 = 17.4% growth
  - Stopping condition met: response.is_final_answer = True
  - Returns: "Tesla's revenue grew 17.4% from Q1 to Q2 2024"

In this trace: the Goal was stated in natural language; the Orchestrator ran the loop; the LLM Core made decisions; Context Window grew as results were appended; Turn budget was tracked; a Tool Call was routed to a real financial API; the Memory retained the result for the next iteration; and the Stopping condition ended the loop when the Orchestrator recognized the model's signal.

Terminology in three frameworks

The same concepts show up across frameworks, but names vary. Understanding the underlying concept matters more than memorizing every framework's specific terminology.

LangChain/LangGraph uses: Agent, State, Tool, Turn (iteration), AgentAction/AgentFinish (deciding to continue or stop)

Anthropic's native patterns use: Agent Loop, Tool Use, Orchestration, Stopping Condition, Message History

OpenAI Assistants API uses: Assistant, Tool Call, Run, Message

All three are implementing the same loop (Orchestrator → Plan → Act → Observe → repeat), just with different vocabulary. Once you understand the loop, translating between frameworks is straightforward. The hard part is not learning each framework's API; it's understanding the underlying concepts that every framework implements.

Framework terminology mapping table

For quick reference, here's how the same concepts are named across three common frameworks:

Notice the pattern: every framework has the same components, just with different names. Learning one framework well is 80% of learning another.

How terminology breaks down in debugging

When an agent fails, the terminology is not just academic -- it's diagnostic. Here's how you'd use these terms to explain the failure to a colleague:

Vague version: "The agent is broken."

Useful version: "On turn 5, the LLM core called the fetch_results tool even though it had already called it on turn 2. The memory component didn't surface the cached result from turn 2 into the context for turn 5, so the model didn't know the data was already available."

The second version immediately points to a fix: check the memory system, ensure that cached results are being retrieved and injected into context.

Or: "The agent exceeds the context window on iteration 4. The context started at 500 tokens. Each tool result is ~600 tokens. After three results, context is 2,300 tokens. On iteration 4, adding another result would exceed the 4,096-token context window of the model we're using."

This points to a different fix: either use a model with a larger context window, implement context compression (summarize older results before appending new ones), or call a separate summarization step to create briefer tool results.

Without the terminology, "the agent is broken" is a dead end. With it, you have a specific target to fix.

Recognizing these terms in the wild

As you read agent documentation or papers, you'll see these terms pop up. Being able to map documentation's vocabulary to your mental model of "orchestrator → perceive → plan → act → observe" will make it much easier to understand how a new framework or technique works. For instance, "using reflection in agent loops" maps to: after the model produces a response, before returning it, run a second pass where the model checks its own work (an additional act → observe cycle). "Context pruning" maps to: managing the context window by removing or summarizing old information. "Tool grounding" maps to: ensuring the model's tool calls are being executed against real data sources, not guesses.

Edge cases and nuance in terminology

Stopping condition vs. hard stop: A stopping condition is what the orchestrator checks for (the model signals it's done, a turn limit is hit). A hard stop is what the orchestrator enforces (the loop actually exits). In production, you always want both: the model's own judgment and a hard turn limit, in case the model's judgment is wrong.

Context window vs. available context: The context window is the maximum size the model can handle (e.g., 8,192 tokens). Available context is how much of that you actually use for this specific call (it might be less, to leave room for the model's response). An agent might have a 100,000-token context window available, but if it's running a task that only needs 2,000 tokens for the current turn, it uses only 2,000.

Memory vs. state: Memory is what the agent remembers (stored facts, past actions, results). State is the current configuration of the system (which step are we on, what's the current goal, what tools are available). An agent's memory might be vast, but its state is always just the current turn's working data.

Turn budget vs. cost budget: A turn budget is "the agent can take at most 10 iterations." A cost budget is "the agent can spend at most $1.00 in API calls." Both are useful stopping conditions; they measure different resources.

Case study: Terminology applied to a real failure

Imagine an agent that's supposed to "find customer support tickets and route them to the right department." It's supposed to stop after finding and routing 5 tickets. Instead, it routes one ticket, then loops indefinitely, calling the ticket-search tool over and over with the same query.

Here's how terminology helps diagnose the problem:

• Wrong diagnosis: "The model is broken."
• Better diagnosis: "The orchestrator's stopping condition is checking the wrong thing. It's waiting for the model to signal it's done (the LLM core's responsibility), but the model doesn't recognize when it has enough information. The turn budget isn't enforced, so the loop never exits based on a hard limit."
• Fix: Add a turn limit (hard stop) and/or redefine the goal more clearly ("Route 5 tickets, then stop explicitly") so the model's stopping-condition signal aligns with the orchestrator's expectation.

Without the vocabulary of "orchestrator," "stopping condition," and "turn budget," the fix is a mystery. With it, the problem is immediately clear.

Common mistake

Assuming that "grounding" and "retrieval" mean the same thing. Retrieval is one common way to achieve grounding, but you can also ground a response in a live API result, a tool's direct output, or a user-provided document with no retrieval step at all. Grounding is the goal (verifiable answers); retrieval is one specific technique for getting there. A system that calls an API to get current stock prices is grounded (verifiable) but uses no retrieval; a system that searches a local vector database of research papers is using retrieval but may or may not be grounded (depends on whether the papers are actually relevant).