AI agent terminology, once and for all: plain-English definitions of agent, tool, harness, loop, guardrail, orchestrator, and eval

Specification meetings often expose hidden misalignment. One team calls something an agent, another calls it an orchestrator, and the implementation that follows is unrecognizable. The confusion stems not from misunderstanding but from seven overlapping terms without clear definitions.

An AI agent is a large language model system that determines its own next step, calls a tool, observes the result, and decides what to do next. It operates with autonomy, unlike a chatbot that waits for each new command. The remaining six terms describe different components and structures within that system.

AI agent terminology quick reference

How they fit together

Agent and tool are the distinction that matters most. Many people label any conversational LLM an agent, but something essential is missing: the ability to act. An agent has value because it can call tools, query a CRM, open a ticket, send an email. Without tools, even the most sophisticated model is only conversational.

Harness is rarely discussed by outsiders and most decisive in practice. It is the programming framework that wraps the model, connecting tools, managing conversation history, deciding when to halt, and handling retries on failure. The model is the engine; the harness is the chassis and transmission. Most failures originate not in the model but in the harness: memory overflow, misaligned tool response formats, unhandled timeouts causing system failure.

Loop is the agent's repeating cycle. It is not a single question-and-answer exchange but repeated cycles of thinking, calling a tool, observing results, and determining the next step, until the task completes or a stop condition is reached. A loop set too loosely causes the agent to circle endlessly, consuming tokens. Set too tightly, it abandons the task at the first difficulty. This requires field adjustment.

Guardrail specifies which data the agent cannot access, which actions require human approval, and which outputs must be blocked. Consider an agent that processes refunds: a guardrail might read anything over five thousand dollars escalates to human review. Autonomy without guardrails in production is not capability but liability.

Orchestrator enters when more than one agent exists. A customer service agent, an audit agent, and a review agent each serve different purposes. The orchestrator determines which agent handles a request first, how outputs transfer between agents, and what occurs when something stalls. Single-agent systems rarely require orchestration, do not add this layer for sophistication alone.

Eval is easiest to skip and most important not to. It is a test suite with scoring that answers one hard question: did the update actually improve performance, or does it merely feel better? Without eval, every prompt adjustment is speculation. With eval, results are measurable.

Why getting these distinctions right matters

These distinctions matter because budgets and responsibilities align to these components. When a client reports the agent is inaccurate, the problem could be a misconfigured tool, a loop that does not converge, guardrails blocking needed actions, or the absence of eval so no one knows what is actually wrong. Matching the symptom to the right component allows for targeted fixes.

The most significant effort in the field goes into building solid harness, loop, guardrail, and eval architecture. A polished demo has no value. An agent deployed and actively used is what counts.