What Even Is an Agent? (And Why Now?)

The word "agent" is the most overloaded term in AI right now, and the resulting confusion is hurting both research and engineering.

In the past two years, the same five-letter word has been stretched to mean a one-shot prompt template, a RAG chatbot that runs a single retrieval call, a multi-step planner that orchestrates a dozen tools, and a fully autonomous system that browses the web, writes code, opens pull requests, and ships them. Vendor marketing pages call a temperature-controlled summarizer an "AI agent." Research papers use "agent" to mean a multi-day autonomous process that burns through thousands of dollars of compute in a sandbox. A product manager tells you "we need an agent" and you genuinely cannot tell whether they need a stateless function or a long-running stateful service.

This is more than an aesthetic complaint. The fuzziness hides real architectural decisions, real cost tradeoffs, and real failure modes. When someone says "we need an agent," you cannot tell whether you need to design for latency, persistence, rollback, observability, or all of the above. When a research paper claims an "agent" achieves 60% on some benchmark, you cannot tell whether the system behind the number is comparable to the one you're shipping to production. The term has become a Rorschach test: it reveals what the speaker wants to build, not what they are actually building.

So before we can talk about how to architect agents, we have to agree on what we mean. This chapter is the foundation of the book. We are going to do three things:

1. Settle on a working definition of an LLM-based agent — precise enough to make architectural decisions with, flexible enough to cover the systems you will actually build in 2025. 2. Trace the intellectual lineage, from Russell and Norvig's rational agents to the LLM-powered systems shipping today, and show which classical ideas survived the transition and which ones quietly got dropped. 3. Build a working fifty-line agent in Python — a tiny research helper that searches the web, summarizes, and cites — and use it as a concrete anchor for every concept in this chapter.

By the end, you will have a shared vocabulary for the rest of the book. Every time you see the word "agent" in subsequent chapters, you should be able to map it back to the definition we set up here.

1. The Word "Agent" Is Broken (and Why That Hurts)

The history of computing is full of overloaded terms that eventually got nailed down. "Operating system" used to mean whatever Unix vendor you happened to use. "Cloud" used to mean somebody else's computer. "API" used to mean a library function call. The community eventually converged on a definition because the cost of ambiguity exceeded the cost of commitment. We have not done that for "agent" yet, and the field is paying for it.

Three forces keep the term fuzzy.

Marketing pressure. "Agent" sells. The word has gravitas. It implies autonomy, intelligence, and capability, all in a single syllable. A vendor that calls its product a "chatbot" sounds like 2022. A vendor that calls the same product an "AI agent" sounds like 2025 and can charge three times as much. The incentive to use the word is strong, and the disincentive — being technically wrong — is invisible to the buyer. The result: a million product pages claim "agentic AI" with definitions that range from "we put a system prompt in front of GPT-4" to "we have a system that can independently file your taxes."

Research imprecision. The academic literature compounds the problem. Benchmarks like SWE-bench, GAIA, and HumanEval are routinely described as "agent benchmarks," but the systems evaluated on them vary wildly. Some are zero-shot chain-of-thought prompters with no tools. Some

are evaluation scripts that loop over a real environment. The numbers are not comparable, and yet they sit side by side in benchmark leaderboards as if they were.

Engineering imprecision. The third force is the one that hurts the most day-to-day, because it lives inside your own team. A senior engineer hears "agent" and pictures a stateful service with persistence, retry, observability, and a budget. A junior engineer hears the same word and pictures a loop that calls an LLM until it stops calling tools. Both are correct, and both are wrong, and the resulting code reviews are exhausting. The architectural consequences of these two pictures are completely different. The first picture is something you deploy, monitor, and page on. The second picture is a script you run from a notebook and hope. Calling them both "agents" forces the team to relitigate the architecture every time someone says the word.

The fix is not to declare one meaning correct and wage war on the others. The fix is to pick a definition for the purposes of this book, name the axes along which real systems vary, and never let the bare word "agent" appear in a design document without qualification. That is what the rest of this chapter is for.

2. A Brief History of "Agent"

The word did not start in marketing. It started in classical AI, and the classical definition is more useful than most modern ones — even if the field has drifted away from it.

In *Artificial Intelligence: A Modern Approach*, Russell and Norvig define an agent as anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators. The word "anything" is deliberate. A thermostat is an agent. A dog is an agent. A chess program is an agent. A human being is an agent. The definition is deliberately indifferent to the substrate of intelligence. What makes something an agent is not what it is made of, but the relationship between its perceptions, its internal state, and its actions.

The classical definition comes with four properties that turn out to be remarkably durable:

1. Perception. The agent has *some* way of taking in information about the world. For a thermostat, that is a thermometer. For a chess program, that is the board state. For an LLM-based agent, that is the input context — the user message, retrieved documents, tool results, prior steps. 2. Action. The agent has *some* way of changing the world. For a thermostat, that is the furnace relay. For a chess program, that is the move. For an LLM-based agent, that is a function call, a written response, or both. 3. Rationality. The agent selects actions to maximize some performance measure, given its percept sequence and prior knowledge. Russell and Norvig are careful to distinguish rationality from omniscience or perfection. A rational agent does the best it can with what it has. A chess program that loses to Magnus Carlsen is still a rational agent; it just has limited compute. 4. Autonomy. The agent's behavior is determined at least in part by its own experience, not solely by built-in knowledge. A pure lookup table is not an agent. A system that learns, plans, or adapts is.

If you accept this framing, then the LLM-based systems we are calling "agents" in 2025 are the fourth or fifth generation of the same conceptual lineage. The lineage runs roughly:

• **Reflex agents (1950s–1980s).** Condition–action rules. Percept → lookup table → action. No memory, no model of the world. Useful, brittle, not what anyone means by "agent" in 2025.
• **Model-based reflex agents (1980s–1990s).** Maintain an internal representation of how the world works. Can reason about consequences of actions. Classic robotics and planning systems.
• **Goal-based and utility-based agents (1990s–2010s).** Plan sequences of actions to achieve explicit goals, or maximize an explicit utility function. This is the era of STRIPS, PDDL, and classical planning.
• **Reinforcement learning agents (2010s).** Learn a policy from reward signals. AlphaGo is the canonical example. Perception, action, and rationality, with autonomy driven by gradient descent rather than hand-coded rules.
• **LLM-based agents (2023–present).*