Chapter 2The agent: Formal definition and properties
This chapter fixes the term agent for the remainder of the book. It is a narrowing chapter, not the center of gravity. The book’s actual subject is the agentic system, defined in Chapter 1 as a system that embeds probabilistic reasoning components inside deterministic infrastructure; the thesis that reliability lives in that deterministic shell, not in the model, is what the rest of the book develops. The agent is the component whose definition this chapter fixes, for one reason: a reader needs to know whether the system in front of them is the kind of system this book’s patterns address. The four properties below are the discriminator that answers that question. They are deliberately strict so that architectural decisions can be reasoned about without ambiguity, and so that applying the book’s discipline to a system that is not an agent adds ceremony without benefit — a cost the preface warns against.
The definition here is intentionally structural. It is not tied to any particular model, framework, or prompting strategy. It is also not a claim about general intelligence; the book’s concern is bounded autonomy: explicitly constrained reasoning and action loops with cost, iteration, and risk limits enforced by architecture (Chapter 5).
Formal definition
An agent, as defined in this book, is:
Definition: Agent A stateful, goal-directed computational entity that reasons about possible actions, selects among them, executes actions in an environment, and updates internal state based on feedback.
This definition is intentionally compact. It excludes systems that merely compute outputs from inputs, and it excludes systems that can only talk but cannot act. It also excludes systems that can act but do not close the loop by incorporating feedback into subsequent decisions.
The definition is structural, not behavioral. It says nothing about whether the agent uses a large language model, a symbolic reasoner, a rule engine, or some combination. It says nothing about the model’s size or capability. What it asserts is the shape of the component: a closed loop with state, goal-directed choice, action, and adaptation. Any system with this shape is an agent under this book’s terminology; any system without all four properties is not.
The agent boundary
An agent is a logical boundary around a closed loop of (1) state, (2) goal-directed choice, (3) action, and (4) feedback-driven update.
A useful architectural test is whether you can draw an “agent box” and identify what crosses its boundary.
Several later patterns (Control, Governance, Memory) can be understood as externalizing parts of this box into deterministic infrastructure while leaving the agent with bounded decision-making. This is the payoff the definition earns: once the agent is a closed loop of state, choice, action, and feedback, the rest of the book is about which parts of that loop the architecture pulls out and enforces deterministically, so that the probabilistic component is left to reason inside limits it cannot widen. The agent boundary is therefore not a hard line drawn around a process; it is a logical line drawn around the closed loop of choice and feedback, and most of what makes an agent reliable in production lives outside that line, not inside it.
Four distinguishing properties
The definition above can be operationalized as four properties. Remove any one of them and the system ceases to be an agent under this book’s terminology.
1. Statefulness across steps
Statefulness means the agent carries information across reasoning/action iterations in a way that affects future choices. The state can be small (a handful of variables) or large (structured memory), but it must persist beyond a single function call.
Architecturally, this implies that the agent cannot be evaluated only as a pure mapping input -> output. The system must decide where state lives (in-process, external store, or a dedicated memory subsystem; see Chapter 7), how it is updated (append-only logs, snapshots, derived summaries), and how it is validated and governed (Chapter 6). Two confusions are worth disposing of quickly: having access to history is not the same as being stateful, since a stateless service can read a log and still behave as a pure function of the current request; and caching is not state, because it improves performance without representing commitments, hypotheses, or evolving beliefs. The practical test is whether a fact the agent established earlier can change what it does later. If the component’s behavior depends only on the current input and freshly queried data, it may be automated, but it is not operating as an agent. Whether that state also survives a process restart is a separate, production-strength requirement, taken up in Chapter 7.
2. Explicit or implicit goals
Goal-directedness means the agent’s behavior is evaluated against a notion of success that is not fully captured by the immediate input. The goal may be explicit (a declared objective and constraints) or implicit (policy-derived, role-derived, or inferred from a task description), but it must exist as something the agent can use to select among alternatives.
The selection is among open-ended alternatives, actions and sequences not reducible to a fixed, enumerable set of branches known at design time. This is the line between a goal-directed agent and a deterministic controller. A thermostat selects between on and off against a target temperature and adapts to feedback, yet no one would call it an agent: its choice set is fixed and its transitions are enumerable. When every action a system might take is known and encoded in advance, it is a workflow, however much state and feedback it carries (see the boundary cases below). The agent property requires that the space of choices be open.
Goals are architectural objects because they determine:
Goals also delimit responsibility. A well-designed agent has a goal that can be audited and bounded. “Be helpful” is too unconstrained to support reliable operation without substantial governance.
This leads to an architectural position the book defends throughout: implicit goals are an anti-pattern for reliable systems. A goal carried only as a role, “you are a helpful coding assistant”, is convenient in a demo and nearly impossible to govern, because a deterministic policy gate cannot evaluate whether an implied objective was satisfied, only whether an explicit one was. Promoting the goal to an explicit, measurable objective, stated with success criteria and constraints, is the first step in turning an agent from a plausible demo into a governable component. The definition admits implicit goals; the architecture discourages them.
In later chapters, goals interact strongly with bounded autonomy (Chapter 5). If you cannot state constraints (budget, allowed actions, unacceptable outcomes), you cannot bound autonomy in a meaningful way.
3. Capability to act upon an environment
An agent must be able to cause effects outside itself, invoking tools, mutating state in external systems, initiating workflows, making commitments, or otherwise changing the environment.
This property matters because it is the transition from analysis to operations. The moment an agent can act, side effects must be made observable and attributable, actions must be validated (schema, policy, authorization), and high-risk actions must route to escalation (Chapter 6). Environments can be physical (robots), digital (APIs, databases), or social (ticketing systems, communications); the book treats the environment abstractly, as the substrate in which actions have consequences and from which feedback is observed.
A system that generates text but cannot trigger actions is best treated as a decision-support component rather than an agent. It can still be valuable, but many of the failure modes of agentic systems (cascading side effects, irreversible actions) do not apply.
4. Adaptation based on outcomes
Adaptation means the agent incorporates feedback from the environment into subsequent reasoning and behavior. Feedback can be immediate (tool result, error code) or delayed (evaluation outcome, user correction), but it must change the agent’s future action selection. Adaptation is not necessarily learning in the ML sense; the book does not require gradient updates or fine-tuning, and it can be as simple as revising a plan after a tool call fails or recording a constraint and proceeding differently.
The distinction that earns its place here is architectural, between two time horizons. Intra-task adaptation happens within a single run; inter-task adaptation happens across runs, when the agent updates a persistent store so a mistake made today is not repeated in next week’s session. Both satisfy this property, but they rest on different memory architectures, working memory for the former, episodic or semantic memory for the latter (Chapter 7), and they carry different governance risk, because inter-task adaptation lets one session’s outcome change another session’s behavior. Adaptation also introduces the problems that motivate much of the rest of the book: feedback can be noisy, adversarial, or incomplete; the loop can oscillate without convergence; and the agent may overfit to short-term signals. Cognitive structures that improve reasoning under uncertainty (Chapter 4), governance constraints that prevent runaway adaptation (Chapter 6), and evaluation that detects drift across runs (Chapter 12) are the responses.
What is not an agent (boundary cases)
The definition earns its keep by excluding systems that look agentic but lack one of the four properties. Most boundary cases reduce to a single missing property and need only be named: a stateless service that computes a response from a request (no state, no goal-directed choice) is infrastructure, often the deterministic shell an agent runs inside; a scripted workflow or RPA process (state and action, but a fixed, enumerable choice set rather than open-ended selection) is a workflow, and the book recommends it over an agent wherever the domain is stable (Anthropic’s workflows sit on this side of the line, and their reliability comes precisely from omitting Properties 2 and 4); a planner that never executes (no action, no feedback) is a planning subsystem; a reactive tool router that maps inputs to tool calls with no goal-directed reasoning and no cross-step state is a router; and several “agents” packed into one prompt are one agent stylized as several unless each maintains independent state, goals, and adaptation. None of these is a value judgment, a workflow or a router is often the better tool, only a category statement: the patterns in this book address systems that have all four properties, and applying them elsewhere adds ceremony without benefit.
The one confusion worth developing, because it traps the most teams, is the chat interface. A chat surface that generates text but cannot execute actions, or whose actions are always carried out by a separate deterministic process the agent never selects, is not an agent under this definition; it is a decision-support component, however useful. Conversely, a chat interface can host an agent when the loop behind it includes tool invocation, feedback incorporation, and persistent state that influences subsequent steps. The interface is then a presentation layer over an agent, not the agent itself. The trap is to ship the first, call it an agent, and then apply agentic patterns to a system that has no loop to bound; the discipline is to ask, of the thing behind the chat box, whether it closes the loop, and to treat the patterns that follow as applicable only when it does.
Agents, tools, and deterministic infrastructure
The common architectural mistake is to treat the agent as the whole system. In production systems the agent is almost always a bounded component inside the deterministic shell — the tool adapters, schemas, policy gates, human oversight, memory stores, and trace that Chapter 1 named and that the rest of the book develops. The decomposition that matters is the one this definition sets up: the agent is the decision-maker inside a loop, and the surrounding infrastructure defines the permitted action surface. The full design of that loop, the envelope around the model, is the harness, introduced in Chapter 4 and designed in Chapter 19; this chapter’s job is only to fix what sits inside it.
The Skills layer (Chapter 10) extends this decomposition with a runtime mechanism for loading capability descriptions on demand. Skills do not change the agent boundary; they change what the agent can be asked to do without re-deploying the system. The architectural implication of Skills is treated in Chapter 10.
Bounded autonomy as a property of agents-in-systems
Bounded autonomy is not a moral stance; it is an engineering requirement. Unbounded loops and unconstrained action surfaces are not compatible with production reliability. The agent that satisfies all four properties is, by that fact, a component capable of doing real damage: it iterates, it spends, it acts on the world, and it carries state forward that can be wrong. Those four capacities are exactly what the definition admits, and they are exactly why the definition is strict enough to be worth bounding.
Bounding autonomy means imposing explicit limits on iterations, cost, time, action surface, data access, and reversibility. Some of these bounds can be internal to the agent (stop conditions); most must be enforced externally by the governance layer (Chapter 6), because an agent cannot be relied upon to police itself under uncertainty or adversarial conditions. Chapter 5 develops bounded autonomy as a discipline in its own right; the point here is only that the definition makes bounding necessary rather than optional, by admitting only systems capable of the loop-shaped damage the bounds exist to contain.
Summary
An agent, in this book, is defined by a closed loop: persistent state, goal-directed choice among actions, the capability to act on an environment, and adaptation based on feedback. The definition is deliberately strict so that architectural decisions can be reasoned about without ambiguity.
With the term fixed, Chapter 3 introduces the architectural forces that agentic patterns must balance, and the remainder of the book presents the patterns and the discipline that turns those balances into reliable systems.