Foundations of Multi-Agent Systems

Foundations of Multi-Agent Systems

What separates a multi-agent system from a microservice mesh, a cluster orchestrator, or a conventional distributed application? The distinction is not a matter of node count, deployment topology, or even the presence of autonomous behavior in isolation. It is a question of *coordination under partial observation*: when no single component has complete information, complete authority, or complete control over the others, and the system's aggregate behavior emerges from interactions you cannot prescribe in advance, the agent abstraction becomes not just useful but architecturally necessary. This opening chapter builds the conceptual vocabulary every subsequent chapter relies on. We will define what an agent *is* (as opposed to what engineers typically call one), lay out the axes along which multi-agent systems vary, sketch the historical lineage that brought us from Contract Net to GPT-tool agents, and introduce the four cooperating layers—role design, communication, conflict resolution, and collective decision-making—that organize the rest of the book. By the end, you will have a decision matrix you can apply to any candidate workload, plus annotated maps of three production MAS deployments that anchor the abstract layers in concrete engineering trade-offs.

1.1 What Counts as an Agent

The term *agent* is one of the most overloaded words in computer science. We have software agents, intelligent agents, autonomous agents, user agents, conversational agents, reinforcement-learning agents, and—since 2023—LLM agents, tool agents, and AI agents. Engineers often use these terms interchangeably, but for orchestration engineering the distinctions matter. We adopt a deliberately strict definition that excludes many systems routinely labeled "multi-agent" in marketing literature, because the failures that motivate this book usually arise from invoking the agent abstraction where it does not apply.

1.1.1 The Four Properties

We treat an agent as a software entity that simultaneously satisfies four properties. None of them is individually sufficient; all four together are necessary.

Situated. An agent is embedded in an environment it can perceive and act upon. The environment may be physical (a warehouse floor, a datacenter), digital (a file system, a database, a network), or mixed (a browser, an IDE, an API mesh). Situatedness is not a synonym for "has sensors"; it implies that perception and action are *first-class* in the agent's interface, that the agent's state is shaped by what it observes, and that its actions change the world in ways that affect future observations. A pure function with no side effects is not an agent. A daemon that polls a queue is arguably not an agent either: it perceives but does not act on a world that responds to it. A warehouse robot that reads lidar and moves a chassis is; a sub-process inside a build pipeline usually is not.

Autonomous. An agent exercises control over its own internal state and behavior. It does not require step-by-step external instruction to produce an action; it selects among alternatives given its goals and current beliefs. Autonomy is a spectrum, not a binary. A thermostat is autonomous in a thin sense; a chess engine in a much thicker sense; an LLM-based planner that decomposes a high-level goal into a tool sequence is autonomous at yet another level. For orchestration engineering, autonomy matters because it determines *who owns the decision*. If a central scheduler tells every node exactly what to do at every tick, you do not have a multi-agent system—you have a master/slave controller, regardless of how many nodes are involved.

Goal-directed. An agent has objectives it tries to bring about. These may be specified by a designer, learned from interaction, or negotiated with other agents. The crucial feature is that an agent's behavior is evaluable against an outcome: we can ask whether the action was a step toward the goal, a step away, or orthogonal. Goals may be expressed as utility functions, reward signals, preference orderings, natural-language instructions, or formal specifications. The richer the goal representation, the more flexibility the agent has in choosing means, but also the harder the verification problem becomes.

Bounded in resources. An agent operates under constraints on time, memory, computation, communication bandwidth, or money. This property distinguishes agents in our sense from the idealized rational actors of classical economic theory or from Turing-machine abstractions. Boundedness is what forces agents to *delegate*, *approximate*, *negotiate*, and *coordinate*. If a single agent had unbounded resources and complete information, there would be no architectural reason for plurality—multiplicity is a response to limitation.

These four properties follow a long lineage in distributed AI. The most-cited formulation is due to Wooldridge and Jennings (1995), who emphasized situatedness, autonomy, reactivity, and proactivity; later refinements by Castelfranchi, Falcone, and others added social ability and rationality under bounded resources. Our four-property definition collapses these into the operational criteria an engineer can actually verify.

1.1.2 What an Agent Is Not

To make the definition concrete, it helps to enumerate common categories of system that *do not* qualify as agents under our definition, even though marketing copy might call them that.

• **Microservices.** A microservice is a stateless or stateful component behind an API. It is not situated (it has no persistent perception of a world; it only responds to requests), not autonomous (its caller determines when and why it runs), and not goal-directed in the relevant sense—it executes prescribed logic rather than selecting among alternatives. Microservices are the right primitive when coordination is fully prescribed and centralized. We use them heavily inside MAS as *implementation vehicles* for agents, but a mesh of microservices is not, by itself, a multi-agent system.
• **Serverless functions.** Lambdas and their cousins are reactive, ephemeral, and externally triggered. They share the situatedness weakness: they have no continuous model of their environment, only the inputs to a single invocation. They are excellent building blocks for agents that need bursty, event-driven computation, but a serverless topology is not a MAS.
• **Cluster managers.** Kubernetes, Nomad, and Borg schedule and supervise workloads. Internally they may have algorithmic autonomy (the scheduler chooses placements), but the *workloads* they run are not agents, and the managers themselves are best understood as infrastructure controllers with deterministic policies, not as participants in a society of peers.
• **Multi-threaded or multi-process programs.** Concurrency primitives do not create agents. The threads inside a process share memory by default, are scheduled cooperatively or preemptively, and have no persistent identity outside their immediate process. They are tools an agent might use to parallelize its own deliberation.

These contrasts are not pedantic. They anticipate a question that will recur throughout this book: *when you observe surprising collective behavior in a distributed system, is that behavior the product of agent-level autonomy, or is it an emergent artifact of the protocol layer below the agents?* The first case calls for MAS techniques; the second usually calls for fixing the protocol.

1.1.3 Why Boundedness Drives Multiplicity

The fourth property—bounded resources—is the hinge on which the rest of the book turns. Bounded agents cannot achieve their goals alone. They must either (a) partition the problem across multiple agents and coordinate the parts, (b) handle tasks in parallel to make wall-clock time tolerable, or (c) call upon specialized expertise they themselves lack. Any one of these pressures pushes a designer toward a multi-a