Foundations of Agentic Systems: Definitions, Taxonomy, and Architectural Mental Models

Foundations of Agentic Systems

Every builder of LLM applications eventually hits the same wall. You start with a prompt. You wrap it in a function. You connect it to a search API. You add a retry loop. Three weeks later you have a system that calls three models, four tools, and a vector store, and you cannot honestly say whether what you built is "an agent," "a workflow," or just "a chat function with delusions of grandeur." The vocabulary has collapsed. Marketers call every wrapper an agent. Researchers use the same word for reinforcement-learned game players and for LLM tool-users, two systems with almost nothing in common except the four letters. This chapter is the antidote. It establishes the conceptual vocabulary used in every later chapter of this book, gives you a precise definition you can defend, traces the lineage of the field so you know what design ideas you are inheriting, and walks through three reference architectures you will see again and again in production code. By the end of it you will have implemented an eighty-line ReAct agent from scratch and you will know exactly which lines to extend when your system needs to scale.

What Makes Something an Agent: A Working Definition

The word *agent* comes from *agere*, Latin for "to act." In software, an agent is any computational entity that perceives its environment and acts upon it through some notion of choice. That definition is fifty years old and almost useless in modern practice because every program perceives input and produces output. A thermostat perceives temperature and acts on a heater. By the loose definition, every `if` statement is an agent. The harder question is what kind of agency matters for the systems we build today.

The most useful operational definition, refined across decades of multi-agent systems research, rests on four properties: autonomy, reactivity, proactivity, and social ability. An agent operates without direct human intervention once given goals. It responds in timely fashion to changes in its environment. It does not merely react; it exhibits goal-directed behavior initiated by the agent itself. And it interacts with other agents or humans through some form of communication. Adopt this rubric and you can classify almost any system you encounter without arguing about branding.

The first property, autonomy, is the one most often claimed and least often delivered. A script that always runs in the same sequence is not autonomous no matter how clever the prompt inside it. An LLM call wrapped in a loop that decides whether to call a search tool or stop is autonomous only if that decision is genuinely chosen by the model conditioned on its current state, not hard-coded by the developer. The distinction matters because autonomy is what makes a system resilient when reality diverges from the developer's mental model. A non-autonomous pipeline fails silently when its assumption is violated; an autonomous agent detects the divergence and replans. We will return to this distinction every time we discuss cost, reliability, and observability.

Reactivity is what separates an agent from an oracle. A pure language model, given a static prompt, produces a static response. It does not care whether the world changed between its tokens. An agent, by contrast, takes in observations at decision time. When a tool returns an error, a reactive agent changes course. When a competitor publishes a paper, a reactive research agent drafts a different summary. The feedback loop between action and observation is what makes the system adaptive. Strip it out and you are back to a stateless completion API.

Proactivity is the property people most often forget. An agent does not only react to events; it pursues goals. A monitoring agent that sits idle when nothing is wrong is still an agent, because it is waiting for the right moment to act on a goal it was given. A retrieval-augmented chatbot that only answers when poked is not an agent; it is a service. The distinguishing mark of agency is that goals exist in the system, not just in the prompting layer. The simplest way to operationalize this is to ask: who notices when the goal is satisfied? In a real agent, the agent itself notices. In a service, only the user notices.

Social ability is the property that scales agents into multi-agent systems. A single autonomous, reactive, proactive agent is a controller. Two or more such agents that exchange messages, delegate subtasks, and coordinate through a shared protocol form a society. This book treats social ability as an architectural choice rather than a requirement because most production systems today use it sparingly. When you hear "multi-agent" in a sales pitch, ask one question: what protocol do the agents use to disagree? If the answer is "they don't," you are looking at one agent wearing multiple hats.

With these four properties fixed, you can place every LLM application on a continuum. A bare completion call is none of the four; it is a function. A RAG pipeline wrapped in code that always runs in the same order is reactive only in the thinnest sense. A RAG pipeline where the model decides whether to retrieve, and how many times, before answering, is reactive and autonomous. Add a planner that invents subgoals on its own and you have proactivity. Add a second agent that critiques the first and you have the seed of social ability. Each of those steps is a real engineering choice, not a stylistic flourish, and each one has a known failure mode that we will discuss in subsequent chapters.

A more pragmatic test for the working engineer is to ask three questions. First, who decides when the system stops? If the developer does, it is a pipeline. If the system does, it has autonomy. Second, what triggers work? If only an external event, it is a service. If an internal goal plus an event, it is an agent. Third, where does the planning happen? If at compile time, it is a script. If at run time, it is an agent. These questions do not produce a yes-or-no answer; they produce a profile of agency. Use that profile when you document your system and you will avoid ninety percent of the rhetorical confusion that plagues the field.

Historical Evolution: From Symbolic Planners to LLM Reasoners

The current explosion of agentic systems is not the first wave; it is the third. Understanding what each previous wave got right and where it failed is the cheapest education you can buy, because every design decision in modern agentic systems is a response to a problem someone tried to solve in 1970, 1995, or 2018.

The symbolic wave ran roughly from the late 1960s through the early 1990s. Its central insight was that intelligent behavior could be decomposed into search over symbolic state. The canonical artifact of this era is STRIPS, the Stanford Research Institute Problem Solver, which represented planning problems as initial states, goal states, and operators with preconditions and effects. Given a goal, STRIPS would search backwards, choosing actions whose effects matched the goal's unmet preconditions, then recursively solving the subproblems. The system was elegant, provably correct under certain assumptions, and almost completely unable to deal with the mess of the real world. Its descendants, including the Planning Domain Definition Language (PDDL), are still used in robotics and logistics, and you will recognize STRIPS-style state-action-effect triples inside modern agent tool schemas more often than you expect.

A second emblem of the symbolic wave is SHRDLU, Terry Winograd's program that could carry on a dialogue about a simulated blocks world. SHRDLU was impressive in 1970 because it appeared to understand natural language, plan actions, and remember context, all at a moment when doing any one of those things at all was a research milestone. SHRDLU was also a closed system. It knew everything there was to know about its world because the world was six types