What is an Agent?

Few words in software are currently asked to do as much work as agent. It names research prototypes, coding assistants, customer-support products, and entire company strategies — sometimes all in one paragraph. This page pins the word down: where the definition comes from, what the LLM era actually changed about it, how the major modern definitions differ and where they agree, and which nearby systems are not agents. It is deliberately about the definition. The mechanics of how an agent runs — the observe-reason-act cycle — live in agent-loop.html">foundations-agent-loop.html, and the capability ladder from a bare model call up to a multi-agent system is laid out in the overview; neither is repeated here.

The classical definition: perceive and act

Long before language models, AI had a settled answer. Russell and Norvig's Artificial Intelligence: A Modern Approach — the field's standard textbook since its first edition in 1995 — defines the term in one sentence: "An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators." Nothing in that sentence is about intelligence, software, or even computers. A thermostat qualifies. So does a mail-sorting robot, a chess program, and a human being. What makes something an agent is a relation — a perceive-decide-act coupling with an environment — not a technology.

The textbook then makes the decision part precise. An agent's behavior is described by an agent function that maps any given percept sequence — the complete history of everything the agent has ever perceived — to an action. The agent's choice at any instant may depend on its built-in knowledge and on that entire history, but never on anything it has not perceived. The agent function is an abstract, mathematical object; what runs in practice is an agent program that implements it.

Not every mapping is a good one, so the definition comes with a quality bar. A rational-agent is defined by the book as follows: "For each possible percept sequence, a rational agent should select an action that is expected to maximize its performance measure, given the evidence provided by the percept sequence and whatever built-in knowledge the agent has." Rationality is expected performance given what has been perceived — not omniscience, and not perfection in hindsight.

This 1995-era framing still frames everything, and it is worth pausing on why. Because it defines agency by the agent-environment relation rather than by any implementation, it survives every change of implementation. You can swap the agent program — from hand-written rules, to search, to a learned policy, to a prompted language model — and the definition does not move. The LLM era performed exactly that swap.

What the LLM era changed: the model becomes the policy

What changed is not the definition of an agent but the implementation of its central component. The mapping from percept history to next action has a standard name — reinforcement learning calls it the policy — and for decades it was built by hand: rules, state machines, planners, trained task-specific models. In an LLM agent, the policy is a prompted language model. The model reads everything perceived so far and emits the next action, and no engineer wrote the mapping; it is elicited from a general model by a prompt.

Once you see that substitution, the classical vocabulary and the vocabulary used across this site line up term for term:

• The context-window carries the percept sequence and the agent's state: the goal, the transcript of actions taken, and every observation returned so far. Assembling it is the "observe" step.
• Tool-use calls are the actuators. The typed, named capabilities an agent may invoke — read a file, query a database, call an API — are exactly its means of acting on the environment, which is why the loop page calls the tool set the agent's action space.
• Tool results are the percepts. Each result the environment returns is folded back into context, extending the percept sequence for the next decision.
• The prompted model is the agent program — the controller that inspects the percept sequence and selects the next action, rather than the whole program.

flowchart TB
    subgraph Classical["Classical vocabulary (Russell & Norvig)"]
        ENV1["Environment"]
        SEN["Sensors: percepts"]
        PSEQ["Percept sequence
(full history to date)"]
        POL["Agent program
(policy: percept history → action)"]
        ACT["Actuators: actions"]
        ENV1 --> SEN --> PSEQ --> POL --> ACT --> ENV1
    end

    subgraph Modern["LLM-agent anatomy"]
        ENV2["World: APIs, files, services"]
        TRES["Tool results / observations"]
        CTX["Context window
(goal + transcript + results)"]
        LLM["Prompted language model
(controller)"]
        TCALL["Tool calls"]
        ENV2 --> TRES --> CTX --> LLM --> TCALL --> ENV2
    end

    SEN -. "corresponds to" .- TRES
    PSEQ -. "corresponds to" .- CTX
    POL -. "corresponds to" .- LLM
    ACT -. "corresponds to" .- TCALL

Read each loop top to bottom and the correspondence is the whole story: the two cycles are the same cycle, thirty years apart. This mapping is the page's core claim. When the rest of this site says context, tools, results, and model, it is speaking Russell and Norvig's language with new nouns — and every question the classical framing raises (what counts as the environment? what is in the percept sequence? is the policy any good?) has a direct, practical counterpart in agent engineering.

The modern definitions, honestly compared

With the classical frame in place, the competing modern definitions stop looking contradictory. Three are load-bearing in current practice, and each emphasizes a different axis of the same underlying idea.

Anthropic: who decides the next step

Anthropic's Building Effective Agents begins by conceding the fight over the word: "'Agent' can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over extended periods, using various tools to accomplish complex tasks. Others use the term to describe more prescriptive implementations that follow predefined workflows." Its resolution is to file every variation under the broader term agentic system, and to draw one architectural line inside that space: workflows run on predefined code paths, while agents dynamically direct their own processes and tool usage. That distinction — examined in depth in foundations-agent-loop.html, and the organizing line of this whole site — makes the defining question who controls the next step: the engineer at design time, or the model at runtime. It is an architectural test you can apply to a codebase.

OpenAI: on whose behalf, and how independently

OpenAI's A Practical Guide to Building Agents defines the term from the user's side: "Agents are systems that independently accomplish tasks on your behalf." The guide then gives the definition teeth with two core characteristics: an agent "leverages an LLM to manage workflow execution and make decisions," recognizing when the workflow is complete and correcting itself when needed — halting and handing control back to the user on failure — and it has access to tools to interact with external systems, "always operating within clearly defined guardrails." It also rules things out explicitly: "Applications that integrate LLMs but don't use them to control workflow execution — think simple chatbots, single-turn LLMs, or sentiment classifiers — are not agents." The emphasis here is delegation: an agent acts on someone's behalf, with enough independence that they do not steer each step.

Hugging Face: how much control, on a spectrum

The Hugging Face smolagents documentation refuses the binary altogether. Its definition — "AI Agents are programs where LLM outputs control the workflow" — comes with an immediate qualification: with this definition, "agent" is not a discrete, 0-or-1 property; instead "'agency' evolves on a continuous spectrum, as you give more or less power to the LLM on your workflow." It grades that spectrum by what the model's output is allowed to control:

(The same table's top tier also includes code agents, where the model writes executable code as its actions.) This is a finer-grained cut of the same axis as the four-stage spectrum in the overview — bare call, tool-augmented call, agent with a loop, multi-agent system — so the two ladders can be read side by side rather than learned twice.

Reading the three together

These are convergent definitions with different emphases, not rival theories. Anthropic asks who controls the next step — an architectural test on the code. OpenAI asks on whose behalf and how independently the system acts — a product test on the user relationship. Hugging Face asks how much control the model has — a degree rather than a threshold. All three agree on the criterion that carries the weight: the model directs the control flow. They differ mainly on whether to treat that criterion as a boundary you cross (Anthropic, OpenAI) or an axis you slide along (Hugging Face) — and the classical definition quietly underwrites all of them, since "the model directs the control flow" is just "the policy chooses the actions" said in modern dress.

What an agent is not

A definition earns its keep at the boundary. Four common systems live near it, and each fails the test for exactly one reason.

A chatbot perceives plenty — every user message is a percept — and it responds fluently, but its output lands on a human's screen and stops there. It performs no actions, changes no external state, and can check nothing against the world; OpenAI's guide names "simple chatbots" and "single-turn LLMs" among its explicit non-agents. The excluding criterion: it has no actuators — nothing it emits acts on an environment.

A RAG pipeline looks agent-adjacent because it consults the world before answering. But in classic retrieval-augmented generation the consultation is wired in: the pipeline retrieves every time, at the same point, in an order the engineer fixed, and the model never decides whether to retrieve, what to look up next, or when to stop. (An agent may of course use retrieval as one tool among several — the difference is who invokes it.) The excluding criterion: retrieval is fixed control flow, not model-directed action.

A copilot genuinely acts on an environment — it edits real code in a real editor — but a human drives every step: each action is proposed, reviewed, and accepted turn by turn, and between actions the initiative returns to the person. An agent inverts that relationship, driving itself between checkpoints and involving the human as a human-in-the-loop gate at chosen moments rather than as the motor of each step. The excluding criterion: the human, not the model, chooses each next step.

A workflow or chain may invoke many model calls and many tools, yet the order in which they run is written by an engineer — Anthropic's "predefined code paths." The model fills in slots inside a control flow it did not choose and cannot alter. None of this makes workflows lesser; they are often the right choice, being more predictable and cheaper — see the closing argument of foundations-agent-loop.html for when each wins. The excluding criterion: the control flow is fixed at design time, not chosen by the model at runtime.

A minimal working definition

Distilling the classical relation, the modern emphases, and the boundary cases into one sentence gives the definition the rest of this site points at:

An agent is a system in which a language model, given a goal, controls its own control flow — repeatedly choosing actions from a typed action space and folding each observation back into its context until it, or its guardrails, decides the goal is met.

Three parts of that sentence are load-bearing. The model controls its own control flow is Anthropic's architectural line and the top of Hugging Face's spectrum; it is what excludes the chatbot, the RAG pipeline, and the workflow. A typed action space is the classical actuator requirement made concrete as tool-use — an agent must be able to act on an environment through declared, structured capabilities, not merely emit text. And termination decided by the model or its guardrails captures both OpenAI's "recognizes when a workflow is complete" and the stopping conditions that make autonomy safe to run; it is what separates an agent from a copilot, where the human decides when each step, and the task, is done.

Everything after this page conjugates that noun. The agent loop is its runtime shape; tool use is its action space; memory is how its percept sequence is kept useful inside a finite window; the protocol pages are how it reaches tools and peers; and orchestration is what happens when you compose several of them.