137AI > Agents > Physical Agents > Multi-Agent Fleets & Swarms
Multi-Agent Fleets & Swarms
Multi-agent fleets and swarms are not a type of autonomous physical agent. They are a mode of operation in which many agents act in coordination, producing properties that no individual-agent treatment captures.
A robotaxi fleet under Waymo or Apollo Go orchestration is a fleet. A warehouse robot population under Amazon orchestration is a fleet. An agricultural drone formation coordinating spraying across a field is a swarm. A defense drone formation conducting reconnaissance is a swarm. Each combines individual agents covered on dedicated entity pages with a coordination layer that produces capability and risk surface no individual agent has on its own.
Fleets and Swarms Are Not the Same Thing
The terms are often used interchangeably in popular usage and even in industry materials. The technical distinction matters because the two modes have different control architectures, different attack surfaces, and different governance implications.
A fleet is a population of agents under centralized orchestration. A fleet management system handles dispatch, routing, monitoring, and intervention. Individual agents in the fleet operate largely independently, executing their assigned tasks while reporting telemetry back to the orchestration layer. Most current robotaxi, delivery robot, autonomous truck, and warehouse robot deployments are fleets in this sense.
A swarm is a population in which coordination is emergent from inter-agent communication, often without or with minimal centralized control. Each agent observes its neighbors and adjusts its behavior based on local rules. The collective behavior emerges from the interaction rather than being directed from a central point. True swarm operation is less common in commercial deployment than fleet operation. Drone swarms in agricultural, defense, and inspection applications are the most prominent examples.
Many real deployments combine both modes. A robotaxi fleet uses centralized orchestration for dispatch but inter-vehicle communication for local coordination at intersections. A drone formation may take overall mission direction from a central operator while coordinating positioning through swarm protocols. The distinction is therefore less binary in practice than in theory, and the governance and security analysis must address both architectural elements.
Where Fleets and Swarms Are Deployed
The deployed examples span the Physical Agents category and increasingly bridge into Personal & Ambient and Software Agent territory.
| Deployment | Operating Mode | Scale |
|---|---|---|
| Robotaxi fleets (Waymo, Tesla Robotaxi, Apollo Go, Zoox, Pony.ai, WeRide) | Centralized fleet management with limited inter-vehicle coordination | Hundreds to thousands of vehicles per operator per market |
| Delivery robot fleets (Starship, Serve, Coco, Nuro) | Centralized dispatch with local route negotiation | Dozens to hundreds of robots per service area |
| Warehouse robot fleets (Amazon Robotics, Symbotic, Locus, Geek+) | Centralized orchestration in controlled facility environment | Thousands of robots per facility at the largest deployments |
| Agricultural drone swarms (XAG, DJI Agras and competitors) | Coordinated formations with swarm-style local interaction | Tens of drones per operation |
| Defense drone swarms | Swarm protocols with mission-level command | Variable; emerging at meaningful operational scale |
| Industrial humanoid fleets (early pilots at automotive plants and logistics facilities) | Centralized fleet management, currently small-scale | Tens of robots per pilot deployment |
| Autonomous trucking platoons (early commercial trials) | Lead-truck-and-follower coordination with V2V protocols | Two to four trucks per platoon in current trials |
The Orchestration Layer
The orchestration layer is the central system that controls a fleet. It is itself a system, with its own architecture, credentials, APIs, and operational practices. Understanding the orchestration layer is the foundation for understanding fleet-level risk because compromise of the orchestration layer reaches every agent the layer controls.
A typical robotaxi orchestration layer includes dispatch systems that assign trips to vehicles, routing systems that compute and update paths, monitoring systems that observe vehicle telemetry and trigger interventions, remote operations interfaces where human supervisors can take action, fleet management dashboards for operational oversight, OTA distribution channels for software and policy updates, and integration points with payment processors, mapping services, traffic infrastructure, and customer service platforms.
The orchestration layer is typically cloud-hosted, with the conventional architecture of a large-scale software system. Identity and access management, network segmentation, audit logging, and threat detection apply as they would for any consequential software system. What differs from a typical cloud application is the reach: a compromised orchestration layer is not just one compromised system. It is access to whatever portion of the deployed fleet the orchestration layer controls.
The amplification is structural. The orchestration layer exists because the operator wants centralized control over the fleet. Centralized control is the operational value proposition. Distributing control to limit blast radius reduces the operational benefit that justified the orchestration layer in the first place. The controls that bound the risk operate at the orchestration layer itself: blast-radius limits, authority partitioning, staged rollout discipline, fleet-wide intervention authority. These controls are covered further in the controls discussion later on the page.
Swarm Coordination Protocols
Where fleets depend on centralized orchestration, swarms depend on inter-agent communication. The protocols vary by application but share common elements: each agent broadcasts position and intent to neighbors, each agent receives broadcasts from neighbors within range, each agent applies local rules to determine its own next action based on the collective state.
The local rules can be simple in principle. Agricultural drone swarms often use rules like maintain spacing of N meters from nearest neighbors, follow the assigned grid pattern, return to base if low on resources. Defense and inspection swarms use more complex protocols that can include role assignment, formation reshaping in response to environmental conditions, and adaptive behavior based on detected objects or events.
The attack surface differs from fleets. There is no central orchestration layer to compromise, but the inter-agent communication protocol becomes the central target. A successful spoofing attack against the communication layer can mislead every agent in the swarm without compromising any individual agent. Sybil attacks where false agents are injected into the swarm protocol can shape collective behavior. Jamming the communication layer can fragment the swarm or trigger fallback behaviors that the attacker has anticipated.
Attack Surface Inventory at Fleet and Swarm Level
The ten-dimension attack surface taxonomy applies at fleet and swarm level with shifted weights. Several dimensions that are moderate or significant for individual agents become very significant or even critical at fleet and swarm scale. For broader context on why the same surface is the value and the exposure, see Convenience as Attack Surface.
| Dimension | Applicability at Fleet/Swarm Level | Notes |
|---|---|---|
| Physical access | Moderate | Individual agent compromise through physical access exists but is limited to one agent; orchestration layer is the higher-value physical target |
| Identity and authentication | Very significant | Operator credentials for the orchestration layer are the highest-leverage credentials in the system; a single compromised admin account can reach the entire fleet |
| Command and control channels | Very significant | Fleet management APIs, remote operations channels, dispatch interfaces all carry the authority to direct many agents at once |
| Perception and sensors | Moderate | Sensor attacks at individual agent level remain significant; coordinated sensor attacks across many agents are an emerging concern |
| Connectivity surface | Very significant | Fleet connectivity is operational requirement; persistent network exposure to orchestration plane and inter-agent communication channels |
| OTA and update pipeline | Critical | Single OTA pipeline reaches the entire fleet; this is the most concentrated attack surface in fleet operation, see The OTA Loop as Attack Surface |
| Data capture and retention | Very significant | Fleet-wide telemetry aggregation produces datasets with substantial surveillance value; access to the aggregated data is a high-value target |
| Integrations and permissions | Significant | Orchestration layer integrates with many external systems; the integration surface scales with the size of the operator's commercial relationships |
| Behavioral and policy boundary | Very significant | Policy changes pushed through the orchestration layer apply to the entire fleet; a malicious policy change has fleet-wide consequences |
| Multi-agent coordination | Critical | The defining dimension for fleets and swarms; the orchestration plane and inter-agent protocols are the primary attack surface, see Multi-Agent Coordinated Misuse |
Fleet-Specific Risks That Individual-Agent Risks Do Not Capture
Several risk categories emerge at fleet level that have no individual-agent equivalent.
| Risk | Description | Why It Is Fleet-Specific |
|---|---|---|
| Coordinated misbehavior | Many agents acting in coordination produce consequences no single agent could | Coordination is the defining property; individual-agent controls do not address it |
| Orchestration-layer compromise | A single compromise of the central control system reaches every agent | Individual agents do not have a central control system to compromise at scale |
| Fleet-wide policy or update propagation | A malicious or flawed update reaches the entire fleet simultaneously through the OTA pipeline | Individual agents do not propagate; the fleet shares a common OTA channel |
| Aggregate data exposure | Fleet telemetry aggregation produces datasets that exceed the value of any individual agent's data | The aggregate dataset exists only at fleet level |
| Cross-fleet coordination by adversaries | Adversaries who compromise multiple fleets can coordinate across operators in ways no individual operator can detect | Detection requires cross-operator data sharing that does not currently exist |
| Single-operator dependency for many agents | A regulatory action, financial event, or operational failure at the operator affects every agent in the fleet | Individual agents have individual exposure; fleets share their operator's risk |
Fleet-Level Controls
Controls designed for individual agents are necessary but not sufficient for fleet operation. The controls that address fleet-specific risk operate at the orchestration layer and the coordination protocol.
Authority partitioning limits how much of the fleet any single operator credential can command. The principle is least-privilege applied to fleet operation: a dispatcher does not need fleet-wide policy authority, a maintenance technician does not need to send commands to vehicles in service, a remote operations supervisor does not need to push OTA updates. Partitioning the authority across roles and credentials limits the blast radius of any single credential compromise.
Blast-radius limits on coordinated commands prevent any single instruction from reaching the entire fleet at once. The mechanism is to require additional verification for instructions that exceed a threshold of affected agents. A command that affects ten vehicles is routine. A command that affects ten thousand requires explicit human approval at multiple levels.
Staged rollout discipline applies to policy and software updates. The orchestration layer pushes changes to a canary subset first, monitors behavior, and only then expands the rollout to the broader fleet. A malicious or flawed change does not reach the entire fleet before its effects can be observed and corrected.
Fleet-wide intervention authority gives operators the ability to suspend autonomous operation across the fleet when coordinated anomaly is detected. The intervention is not a per-agent emergency stop but a fleet-level pause that protects against scenarios where the compromise is faster than per-agent response.
Cross-platform telemetry correlation lets operators see patterns that no single agent reveals. A few unusual behaviors at single agents may not trigger alerts; the same behaviors aggregated across the fleet may show a coordinated pattern that warrants response. The correlation often requires data sharing across organizations, which raises governance questions of its own.
Governance and Regulatory Gaps
Most regulation governing autonomous physical agents addresses individual platforms. Vehicle safety regulation governs individual vehicles. Industrial machinery safety governs individual machines. Aviation regulation governs individual aircraft. The fleet-level properties of multi-agent operation do not have clean regulatory homes.
Fleet management as a regulated activity is partially addressed by transportation operating authority requirements (taxi licensing, commercial trucking authority) and by aviation operations rules (Part 135 for commercial drone operations). These cover the operator's authority to run the fleet but do not address fleet-level cybersecurity, orchestration layer integrity, or coordination protocol governance.
Orchestration layer cybersecurity is partially covered by general cybersecurity regulation and by UN-R 155 for connected vehicles, but no jurisdiction has built a regulatory regime specifically for fleet management infrastructure of autonomous physical agents. The result is that the highest-leverage attack surface in the autonomous physical agent ecosystem operates under cybersecurity regulation designed for general IT systems.
Swarm protocols and inter-agent communication are largely unaddressed. Drone swarm operation falls under aviation regulation for the airspace use but not for the inter-drone communication that defines swarm behavior. Industrial swarm protocols operate under industrial safety regulation. Civil and commercial swarm operations outside these domains have limited regulatory coverage.
The broader analytical frame for these gaps appears in Autonomous Physical Agents as a Regulatory Category.
The Reframe
Fleets and swarms are where the autonomous physical agent category becomes operationally consequential. An individual robotaxi is a vehicle. A fleet of ten thousand robotaxis is a public infrastructure system. An individual humanoid is a machine. A fleet of humanoids operating across a logistics network is an industrial system. An individual drone is an aircraft. A swarm of drones is a tactical or operational capability with no individual-aircraft equivalent.
The risk surface that follows is correspondingly different from individual-agent risk surface. Fleet-level controls and fleet-level governance are the elements that determine whether autonomous physical agent deployment at scale is safe, accountable, and resistant to misuse. The work of building both is uneven across operators and largely missing from regulatory frameworks. Multi-agent fleets and swarms are therefore not only a technical category but one of the most consequential governance frontiers in the autonomous physical agent ecosystem.
Related Coverage
Physical Agents | Multi-Agent Coordinated Misuse | The OTA Loop as Attack Surface | Autonomous Physical Agents as a Regulatory Category