Foundations of Multi-Agent Systems: Agency, Rationality, and Interaction

What does it mean for a software entity to be an "agent," and why does cooperation among such entities demand something more than the message passing that already pervades distributed computing? If we cannot answer this question with precision, the entire edifice of multi-agent systems engineering rests on a fog of metaphors: actors that do not act, services that do not serve, swarms that do not swarm. The cost of imprecision here is not academic. Every later decision in this book—about how to design roles, which communication protocol to adopt, how to reach collective decisions, how to verify emergent behavior—presupposes a clear answer to the foundational question of agency. This chapter builds the conceptual vocabulary that will be used throughout the rest of the text. We begin by formalizing what an agent is, distinguishing essential properties from convenient fictions. We then examine rationality in its computational guises: perfect, bounded, procedural, and intentional. We construct the perceive-reason-act loop and use it to demarcate the agent from its environment. With this vocabulary in hand, we can finally say precisely what a multi-agent system (MAS) is, and—more importantly—what it is not. We contrast MAS with microservices, the actor model, and swarm robotics, isolating the engineering concerns that are genuinely new. We then enumerate the failure modes that emerge only when autonomous entities interact: emergent miscoordination, partial observability, and non-stationarity. A worked example—tracing the evolution of a single-agent scheduler into a multi-agent logistics system—makes these abstractions concrete. The chapter closes with a roadmap of the three pillars on which the rest of the book is built: role design, communication, and collective decision-making.

1.1 What Is an Agent? The Anatomy of Digital Agency

The term "agent" is one of the most overused in computer science, applied indiscriminately to user interface assistants, mobile robots, reinforcement learners, and web crawlers. To engineer cooperative intelligence, we need a definition that is at once precise enough to exclude ordinary software components and generous enough to encompass the variety of systems we wish to build.

Definition 1.1 (Agent). An *agent* is a computer system situated in some environment, capable of autonomous action in that environment to meet its design objectives.

This definition has three load-bearing components: *situatedness*, *autonomy*, and *goal-directedness*. Each deserves scrutiny.

Situatedness. Unlike a pure function—say, a sorting routine—an agent exists in a world that it can change. The environment may be physical (a robot in a warehouse), computational (a network of servers), or simulated (a virtual marketplace). What matters is that the agent's actions have consequences in that world, and that the world can change independently of the agent. This situatedness is what makes the engineering problem interesting: we cannot enumerate the agent's possible states in advance. The environment may be partially observable (the agent cannot see everything), stochastic (the same action in the same state may have different outcomes), non-stationary (the dynamics change over time), and continuous (the state space has no natural discretization). Each of these properties forces design choices that would be absent in a closed-world computation.

A second-order consequence of situatedness is that the agent must maintain an internal representation of the world—or learn one on the fly—because its sensors provide only a fragment of the relevant state. This representational commitment is one of the deepest sources of complexity in agent engineering. Get the representation wrong and the agent will misinterpret its perceptions; overspecify it and the agent will be unable to update quickly enough under time pressure.

Autonomy. An agent decides for itself which actions to perform, without direct external instruction. This rules out objects whose every method is invoked by a controller. Autonomy does not imply independence—an agent may receive requests from users or other agents—but it does imply that the agent has discretion over whether and how to satisfy those requests. A web service that simply executes whatever its HTTP caller requests is not, by this definition, an agent. A personal assistant that prioritizes, defers, or refuses incoming requests is.

Autonomy has at least three degrees. *Strong autonomy* means the agent has full discretion over its actions, including the choice of whether to act at all. *Weak autonomy* means the agent has discretion within a constrained space, such as choosing the order of operations but not which operations to perform. *Operational autonomy* is the practical compromise: the agent has discretion over the *how* of its actions but its *what* is determined by a higher-level goal or contract. Most engineered agents operate at the level of operational autonomy, because full strong autonomy is incompatible with predictability in safety-critical settings.

Goal-directedness. An agent acts to further its design objectives. These objectives may be hard-coded (a thermostat's setpoint), learned (a reinforcement-learned policy), or delegated (a user task). The agent need not have explicit representations of goals—a thermostat's behavior can be described in terms of goals without the thermostat itself maintaining any symbolic representation. What is essential is that there exist some description of behavior in which the agent's actions are rational relative to objectives.

The source of the goal matters less than its existence. An agent may receive its goals from a designer at compile time (a robotic vacuum cleaner designed to maximize area covered), from a user at run time (a conversational assistant receiving an instruction), or from another agent through communication (a dispatcher receiving a re-planning request). In each case, the agent must have some internal mechanism for treating the goal as a constraint on its action selection. This mechanism—however implemented—is what makes the system an agent rather than a reactive circuit.

From these three primitives we derive the canonical five properties widely used in the agent literature. Although different authors enumerate them slightly differently, the convergent list is:

1. Autonomy — control over internal state and behavior. 2. Reactivity — the ability to perceive the environment and respond to changes in a timely way. 3. Proactivity — the ability to exhibit goal-directed behavior by taking the initiative, not merely reacting. 4. Social ability — the ability to interact with other agents (and possibly humans) through some communication language. 5. Rationality — the property that the agent acts so as to further its objectives, given the information available to it.

It is worth dwelling on what each property excludes. *Reactivity* without *proactivity* yields a thermostat: it responds to temperature changes but does not act to anticipate them. *Proactivity* without *reactivity* yields a stubborn optimizer: it pursues its goal while ignoring the world crumbling around it. *Social ability* without *autonomy* yields a coordinator: it relays messages but has no independent goals of its own. The conjunction of all five is what separates an agent from a component, a service, an actor, or a robot.

A note on weak and strong agency. The agent literature distinguishes *weak agency*—the ascription of agency as an explanatory stance (Dennett's intentional stance)—from *strong agency*—the claim that the agent literally has mental states such as beliefs and desires. For engineering purposes, we adopt weak agency. Whether or not a thermostat "really believes" the room is too cold is irrelevant; what matters is that describing its behavior in intentional terms is more compact and predictive than describing its electrical circuits. We will return