Agentic AI glossary

An AI agent is an application that pairs a language model (the ability to reason) with tools (the ability to act) to accomplish a goal: in essence, a language model in a loop using tools.

Rather than just replying to a single prompt, the agent plans, takes action, and observes the result, repeating the loop until the task is done, with little or no human input at each step.

Agentic AI is software that acts autonomously toward goals, rather than only generating content. Where generative AI produces a piece of text or an image from a prompt, agentic AI decides the next steps, uses tools, and takes actions to reach an outcome.

It is the difference between “write me an email” and “resolve this customer request”: agentic AI takes on the task end to end, within the limits you define.

RAG, short for retrieval-augmented generation, is the technique of grounding a model's answers in an external knowledge base. Before answering, the system retrieves the relevant passages from your documents and hands them to the model as context.

The result is an answer anchored in your own data (more accurate, updatable, and verifiable), instead of relying only on what the model memorized during training.

Agentic retrieval is when the agent itself decides when to consult the knowledge base, calling search as a tool and on demand. It can search several times, refine the query, and combine sources as its reasoning unfolds.

This differs from passive context injection, where passages are automatically inserted before the answer: here, searching is a deliberate decision by the agent, which tends to surface more relevant information and less noise.

A tool is a capability the agent can call to act in the world: searching the knowledge base, running a calculation, calling an API, querying an external system, and more.

Tools are what turn a language model, which only produces text, into an agent that can carry out real tasks. The agent chooses which tool to use and when, according to the goal.

A skill is a packaged bundle of instructions and resources that gives an agent a new capability, loaded on demand when the task calls for it. Think of it as a specialized “procedure manual” the agent opens only when needed.

Loading on demand keeps the agent's context lean: instead of loading everything at once, it reaches for the right skill at the right moment, gaining a specific capability without losing focus.

MCP, the Model Context Protocol, is an open standard for connecting an agent to external tools and systems. It works like a “universal plug”: instead of a bespoke integration for every service, the agent speaks a common language with any compatible tool.

This lets you expand what an agent can do by wiring it to external data sources and applications in a standardized, reusable way.

Orchestration is the layer that drives the agent: it plans the steps, keeps memory of what has happened, and runs the reasoning loop in which the agent decides, acts, and observes the result.

Orchestration is what coordinates model, tools, and context so the agent moves coherently toward the goal, rather than producing isolated answers.

Context engineering is the practice of curating the right information into the model's limited attention. Because a model can only consider a finite amount of context at once, deciding what to include, and what to leave out, largely determines the quality of the answer.

It is the evolution of prompt engineering: the focus shifts from just the wording of the prompt to curating the whole set of information (instructions, retrieved knowledge, history) that reaches the model at the right moment.

A multi-agent system brings together several specialist agents that collaborate to solve a task. Instead of a single generalist agent, each one handles a part of the problem with its own instructions and tools.

A common pattern is one agent calling another as if it were a tool: a coordinator delegates subtasks to specialists and assembles the results, making the system more modular and easier to evolve.

Human-in-the-loop is the design in which people approve or oversee an agent's consequential actions before they take effect. Rather than acting alone on sensitive decisions, the agent proposes and waits for the go-ahead.

This “propose, then approve” pattern keeps control in human hands exactly where consequences matter, combining the agent's speed with human judgment.

A guardrail is a policy or validation control that bounds what an agent may do. It works like a fence: it defines scope limits, permissions, and allowed actions, blocking anything outside those rules.

Examples include restricting the agent to a set of tools, limiting permissions by role, or refusing requests outside that assistant's purpose. Guardrails make an agent's behavior safer and more predictable.

The knowledge base is the set of curated documents an assistant grounds its answers in: manuals, policies, catalogs, FAQs, and other material you trust.

It is this base, not the model's generic memory, that gives the assistant answers specific to your business. Keeping it organized and up to date is what keeps the answers correct and trustworthy.

On the platform, a Charla is a single AI assistant with its own instructions, its own knowledge base, and its own access list. It is the unit of isolation: each Charla is independent of the others.

This design lets you run several assistants side by side (one for support, another for sales, another for an internal process) without one's knowledge or access leaking into another.