Paper deep dive
Federated Single-Agent Robotics: Multi-Robot Coordination Without Intra-Robot Multi-Agent Fragmentation
Xue Qin, Simin Luan, John See, Cong Yang, Zhijun Li
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%
Last extracted: 4/14/2026, 2:29:13 AM
Summary
The paper introduces Federated Single-Agent Robotics (FSAR), a runtime architecture for multi-robot coordination that avoids intra-robot multi-agent fragmentation. By treating each robot as a coherent single-agent runtime, FSAR enables fleet-level coordination through a federation layer that manages capability discovery, task delegation, and governance, resulting in improved recovery containment and governance locality.
Entities (4)
Relation Signals (3)
Robot → possesses → ECM
confidence 100% · Each robot r_i maintains a local capability set E_i, where each e is a locally executable ECM.
FSAR → utilizes → ECM
confidence 100% · The architecture supports shared Embodied Capability Module (ECM) discovery.
Robot → governedby → Federation Layer
confidence 90% · Fleet coordination emerges through a federation layer that supports shared ECM discovery.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:As embodied robots move toward fleet-scale operation, multi-robot coordination is becoming a central systems challenge. Existing approaches often treat this as motivation for increasing internal multi-agent decomposition within each robot. We argue for a different principle: multi-robot coordination does not require intra-robot multi-agent fragmentation. Each robot should remain a single embodied agent with its own persistent runtime, local policy scope, capability state, and recovery authority, while coordination emerges through federation across robots at the fleet level. We present Federated Single-Agent Robotics (FSAR), a runtime architecture for multi-robot coordination built on single-agent robot runtimes. Each robot exposes a governed capability surface rather than an internally fragmented agent society. Fleet coordination is achieved through shared capability registries, cross-robot task delegation, policy-aware authority assignment, trust-scoped interaction, and layered recovery protocols. We formalize key coordination relations including authority delegation, inter-robot capability requests, local-versus-fleet recovery boundaries, and hierarchical human supervision, and describe a fleet runtime architecture supporting shared Embodied Capability Module (ECM) discovery, contract-aware cross-robot coordination, and fleet-level governance. We evaluate FSAR on representative multi-robot coordination scenarios against decomposition-heavy baselines. Results show statistically significant gains in governance locality (d=2.91, p<.001 vs. centralized control) and recovery containment (d=4.88, p<.001 vs. decomposition-heavy), while reducing authority conflicts and policy violations across all scenarios. Our results support the view that the path from embodied agents to embodied fleets is better served by federation across coherent robot runtimes than by fragmentation within them.
Tags
Links
- Source: https://arxiv.org/abs/2604.11028v1
- Canonical: https://arxiv.org/abs/2604.11028v1
Trouble viewing inline? Open PDF directly →
Full Text
108,509 characters extracted from source content.
Expand or collapse full text
Federated Single-Agent Robotics: Multi-Robot Coordination Without Intra-Robot Multi-Agent Fragmentation†thanks: Code: https://github.com/s20sc/fsar-fleet-coordination. Xue Qin1 Simin Luan2 John See3 Cong Yang4,∗ Zhijun Li2,∗ 1School of Software, Harbin Institute of Technology, Harbin, China 2School of Computer Science and Technology, Harbin Institute of Technology, Harbin, China 3School of Math. and Computer Sciences, Heriot-Watt University, Malaysia Campus, Malaysia 4School of Future Science and Engineering, Soochow University, Suzhou, China qinxue@me.com luansiminiot@gmail.com J.See@hw.ac.uk cong.yang@suda.edu.cn lizhijunos@hit.edu.cn ∗Corresponding authors Abstract As embodied robots move from isolated deployments toward fleet-scale operation, multi-robot coordination is becoming a central systems challenge. Existing approaches often treat this transition as a motivation for increasing internal multi-agent decomposition within each robot. In this paper, we argue for a different design principle: multi-robot coordination does not require intra-robot multi-agent fragmentation. Instead, each robot should remain a single embodied agent with its own persistent runtime, local policy scope, capability state, and recovery authority, while coordination emerges through federation across robots at the fleet level. We present Federated Single-Agent Robotics (FSAR), a runtime architecture for multi-robot coordination built on single-agent robot runtimes. In FSAR, each robot exposes a governed capability surface rather than an internally fragmented agent society. Fleet coordination is achieved through shared capability registries, cross-robot task delegation, policy-aware authority assignment, trust-scoped interaction, and layered recovery protocols. This design preserves local coherence within each robot while enabling coordinated task execution across a fleet. We formalize the key coordination relations in federated single-agent robotics, including authority delegation, inter-robot capability requests, local-versus-fleet recovery boundaries, and hierarchical human supervision. Based on these abstractions, we describe a fleet runtime architecture that supports shared Embodied Capability Module (ECM) discovery, contract-aware cross-robot coordination, and fleet-level governance over distributed embodied tasks. We evaluate the proposed architecture on representative multi-robot coordination scenarios and compare it against decomposition-heavy baselines that push coordination logic into intra-robot multi-agent structures. Results indicate that federated single-agent coordination achieves statistically significant gains in governance locality (d=2.91d=2.91, p<.001p<.001 vs. centralized control) and recovery containment (d=4.88d=4.88, p<.001p<.001 vs. decomposition-heavy), while reducing authority conflicts and policy violations across all tested scenarios. Our results support the view that the path from embodied agents to embodied fleets is better served by federation across coherent robot runtimes than by fragmentation within them. Keywords: Embodied agents, multi-robot coordination, federation, single-agent architecture, embodied capability modules, runtime governance, fleet coordination 1 Introduction Consider a fleet task in which Robot A transports a package, Robot B opens a secured door, and Robot C inspects the destination. The task is clearly multi-robot—but it does not follow that each robot must itself be decomposed into a society of internal agents. When a door-opening request is denied, a reassignment fails, or a recovery escalates to human supervision, responsibility must be localizable. Internal multi-agent fragmentation makes that harder [1, 2]. The subsumption architecture [3] demonstrated decades ago that layered single-agent control can produce sophisticated robot behavior without internal agent decomposition; FSAR extends this insight from the single-robot to the fleet level. A common pattern in multi-robot coordination is increased agent decomposition at every level [4, 5, 6]: each robot is modeled as a society of internal agents for planning, perception, manipulation, communication, and recovery. While expressive, this introduces systems costs—blurred authority boundaries, ambiguous recovery ownership, weakened audit locality, and harder policy reasoning. When a fleet-level failure occurs, it becomes unclear whether responsibility lies within a robot’s internal agent society, in inter-robot coordination, or in the human supervisory layer. This paper argues for a different principle: multi-robot coordination does not require intra-robot multi-agent fragmentation. Building on our prior work on single-agent embodied runtimes [7, 8, 9, 10, 11]111Paper 1 in this series is available as an arXiv preprint (arXiv:2604.07039); Paper 5 and Papers 2–4 are under review. The present paper is self-contained: all formal definitions, model components, and coordination semantics used here are defined within this paper and do not require familiarity with the prior papers. Where inherited concepts (e.g., ECMs, capability contracts) are used, we provide self-contained definitions in section 3.1., we present Federated Single-Agent Robotics (FSAR), a runtime architecture in which each robot remains a coherent single embodied222This paper is part of a seven-paper research program on runtime architecture, governance, and benchmarking for embodied agent systems. Project page: https://s20sc.github.io/aeros-project agent with its own persistent runtime, local capability state, policy scope, and recovery authority. Fleet coordination emerges through a federation layer that supports shared ECM discovery, cross-robot capability requests, trust-scoped delegation, policy-aware authority assignment, layered recovery, and hierarchical human supervision. The federated design preserves local policy and recovery ownership inside each robot while enabling distributed task execution across the fleet. We make four contributions: 1. We introduce the FSAR model and formalize a fleet as a federation of coherent single-agent robot runtimes rather than a collection of internally fragmented multi-agent robots. 2. We define four key coordination relations for federated embodied fleets: inter-robot capability request, authority delegation, layered recovery, and hierarchical human supervision. 3. We describe a fleet runtime architecture with a shared ECM registry, trust and authority management, fleet-level policy resolution, and recovery orchestration. 4. We evaluate the architecture on representative multi-robot coordination scenarios and compare it with decomposition-heavy baselines, showing that federated single-agent coordination improves boundary clarity, recovery containment, and governance locality while retaining effective multi-robot collaboration. While Papers 1–5 established the single-agent principle for individual robots—defining the runtime model, capability contracts, policy scope, and recovery authority at the per-robot level—the present paper addresses a fundamentally different challenge: how multiple such robots coordinate as a fleet without surrendering the governance properties that the single-agent design provides. The novelty of Paper 6 lies not in the per-robot model (which is inherited from prior work) but in the federation layer: the formal coordination relations, trust-scoped delegation semantics, cross-robot policy composition, layered recovery across robot boundaries, and the shared ECM registry that makes governed capability discovery operational at fleet scale. None of these constructs appear in Papers 1–5, which treat each robot in isolation. Table˜1 clarifies the provenance of each major construct in this paper, distinguishing concepts inherited from the prior papers, concepts extended to the fleet setting, and constructs that are entirely new in Paper 6. Table 1: Novelty provenance of Paper 6 constructs. Provenance Constructs Inherited (Papers 1–5) ECM definition, capability contracts, per-robot policy scope, single-robot recovery levels, human oversight model (HiH_i) Extended to fleet ECM registry (from local to shared Γ ), recovery hierarchy (from local to fleet escalation), policy composition (from single-robot to cross-robot Π ) New in Paper 6 Federation layer Φ , trust-scoped delegation (Δ ), inter-robot capability request protocol, authority delegation semantics, fleet-level human supervision (HFH_F), coordination invariants I1–I5, architectural invariants A1–A5 (a) Decomposition-Heavy Multi-AgentRobot APlanExecCommRecRobot BPlanExecCommRecBlurred boundariesNested coordinationAudit ambiguity(b) Federated Single-Agent (FSAR)Robot ASingle AgentℛA=(A,E,P,T,Q,H)R_A=(A,E,P,T,Q,H)Robot BSingle AgentℛB=(A,E,P,T,Q,H)R_B=(A,E,P,T,Q,H)Federation Layer Φ=(Γ,Δ,Π,Ω,Λ) =( , , , , )Clear boundariesGoverned delegationAttributable auditvs. Figure 1: Decomposition-heavy multi-agent architecture (a) versus federated single-agent architecture (b). In (a), each robot is internally fragmented into multiple fleet-visible agents, producing nested cross-agent coordination with blurred boundaries. In (b), each robot remains a single coherent agent; coordination occurs through a governed federation layer. 2 Motivation: From Single-Agent Robots to Federated Fleets 2.1 Single-Agent Runtime Principle Papers 1–5 of this series established that one robot constitutes one persistent embodied agent, with a local runtime identity, installed capability modules (ECMs), policy scope, recovery authority, and human supervision interface [7, 8, 9, 10, 11]. Internal software components—planners, controllers, perception modules—are implementation mechanisms, not independent principals. This principle avoids the governance costs that arise when every internal component is modeled as a separate agent: ambiguous failure ownership, unclear policy authority, and fragmented human oversight. 2.2 Why Multi-Robot Does Not Imply Multi-Agent Inside Every Robot When the problem shifts from one robot to many robots, a common intuition is that multi-robot coordination should drive increased agent decomposition at every level [12, 13]. If robots must coordinate, then perhaps each robot should also be decomposed into multiple agents—a planning agent, a communication agent, a coordination agent, a safety agent—so that inter-robot coordination can be expressed as inter-agent coordination at all levels. This intuition is understandable but carries significant systems costs. Intra-robot multi-agent fragmentation in the fleet context introduces five specific problems: (1) responsibility boundary confusion—failures may be attributable to any internal agent within any robot, making localization difficult; (2) recovery ownership ambiguity—when recovery is distributed across internal agents, the question of who initiates recovery becomes an internal coordination problem that must be solved before fleet-level recovery can be invoked; (3) policy scope fragmentation—cross-robot policy composition must account for both inter-robot and intra-robot policy inconsistencies; (4) audit trail complexity—each robot presenting multiple principals multiplies the dimensions of attribution; and (5) human oversight fragmentation—supervisors who think in terms of “Robot B opened the door” must instead trace through nested internal agent attribution chains. These problems arise from the structural decision to multiply fleet-visible agent boundaries. FSAR avoids them by preserving the single-agent boundary and pushing coordination to the inter-robot layer. We therefore adopt a different organizational principle: The basic coordination unit of an embodied fleet is the robot, treated as a single coherent agent. The fleet is a federation of such agents, not a flat collection of sub-agents drawn from multiple robots. This implies that inter-robot coordination is expressed as relations between robot-level agents; each robot’s internal architecture is invisible to the fleet; and fleet coordination—task allocation, capability sharing, failure recovery, trust management, and human oversight—is organized at the federation layer. (We use “fleet coordination” throughout to denote the organized management of cross-robot interactions; we avoid the term “fleet intelligence” to prevent confusion with emergent or centralized decision-making.) 3 FSAR Model and Coordination Semantics 3.1 Robot as a Single Embodied Agent We model each robot rir_i as a single embodied agent with a persistent local runtime. The runtime of robot rir_i is represented as: ℛi=(Ai,Ei,Pi,Ti,Qi,Hi)R_i=(A_i,\;E_i,\;P_i,\;T_i,\;Q_i,\;H_i) (1) where AiA_i denotes the single embodied agent identity of robot rir_i; EiE_i denotes the locally installed embodied capability set (ECMs); PiP_i denotes the local policy scope governing permissible actions; TiT_i denotes the trust state through which external robots may interact with rir_i; QiQ_i denotes the local recovery authority and escalation policy; and HiH_i denotes the local human supervision interface, if any. Embodied Capability Modules (ECMs). An ECM is the unit of executable capability within a robot runtime. Each ECM e∈Eie∈ E_i encapsulates a specific embodied capability (e.g., “navigate.indoor,” “carry.package,” “door.open.secure”) together with its contract—preconditions, postconditions, resource requirements, and version metadata. ECMs are introduced in our prior work [7, 11] and generalized here to the fleet setting. This paper is self-contained: ECMs can be understood as typed, versioned capability units that a robot may possess, advertise, execute, or delegate. Capability surface. The capability surface of robot rir_i is the set of ECMs that rir_i currently advertises as available for external coordination: Surface(ri)⊆EiSurface(r_i) E_i. Not all locally installed ECMs are necessarily advertised—a robot may possess a capability without exposing it to the fleet, depending on trust, policy, and availability constraints. The capability surface is the fleet-visible interface of the robot, analogous to a public API in software engineering. The central design commitment is that AiA_i is singleton at the robot-runtime level: the robot is treated as one coherent embodied agent even if its internal implementation contains multiple software components, models, controllers, or services. These internal elements do not constitute independent agent principals for fleet coordination. Note that the term “agent” in FSAR refers to the robot as a whole—a persistent embodied runtime with physical identity and local authority—rather than to fine-grained software agents in the MAS tradition [12]. 3.2 Fleet as a Federation of Single-Agent Runtimes A fleet of n robots is modeled as a federation: ℱ=ℛ1,ℛ2,…,ℛnF=\R_1,\;R_2,\;…,\;R_n\ (2) augmented with a federation layer: Φ=(Γ,Δ,Π,Ω,Λ) =( ,\; ,\; ,\; ,\; ) (3) where Γ is the shared ECM registry and capability advertisement layer; Δ is the cross-robot delegation and coordination protocol; Π is the fleet-level policy composition layer; Ω is the fleet-level recovery orchestration layer; and Λ is the hierarchical human oversight layer. The full federated fleet model is therefore: ℳfleet=(ℱ,Φ)M_fleet=(F,\; ) (4) This representation emphasizes that fleet coordination is not stored as a global super-agent that absorbs all local runtimes, nor as a nested society of internal robot agents. Instead, coordination emerges from relations defined across coherent local runtimes. Local RuntimesFederation LayerOversightRobot AAgent Core A1A_1ECM Mgr E1E_1Policy P1P_1Recovery Q1Q_1Human H1H_1Robot BAgent Core A2A_2ECM Mgr E2E_2Policy P2P_2Recovery Q2Q_2Human H2H_2Robot CAgent Core A3A_3ECM Mgr E3E_3Policy P3P_3Recovery Q3Q_3Human H3H_3Robot DAgent Core A4A_4ECM Mgr E4E_4Policy P4P_4Recovery Q4Q_4Human H4H_4Fleet Federation Layer Φ Γ . Engine Δ Resolver Π Orch. Ω Ξ & Auth MgrOversight Λ Human OversightFleet Supervisor HFH_FAudit / Monitoring Figure 2: FSAR system model: three-layer architecture. Bottom: local robot runtimes, each containing an agent core, ECM manager, policy engine, recovery manager, and human interface. Middle: fleet federation layer with shared registry, coordination engine, policy resolver, recovery orchestrator, audit service, and trust manager. Top: fleet-level human oversight. 3.3 Local Capability Sets and Federated Discoverability Each robot rir_i maintains a local capability set Ei=ei1,ei2,…,eikE_i=\e_i1,e_i2,…,e_ik\, where each eije_ij is a locally executable ECM with its own contract, version state, and policy requirements. We distinguish three layers of capability presence: • Local capability possession: e∈Eie∈ E_i. • Federated capability advertisement: the capability is visible through the shared registry Γ . • Delegable capability availability: another robot may request the capability under applicable trust, policy, and authority constraints. Formally: Possess(ri,e) (r_i,e) ⇔e∈Ei e∈ E_i (5) Advertise(ri,e) (r_i,e) ⇔Possess(ri,e)∧VisibleΓ(ri,e) (r_i,e) _ (r_i,e) (6) Delegable(ri,e,rj) (r_i,e,r_j) ⇔Advertise(ri,e)∧TrustOK(rj,ri,e)∧PolicyOK(rj,ri,e) (r_i,e) (r_j,r_i,e) (r_j,r_i,e) (7) A robot may possess a capability without advertising it to the fleet, and may advertise it without permitting arbitrary cross-robot delegation. 3.4 Inter-Robot Capability Requests A central operation in FSAR is the inter-robot capability request. Suppose robot rir_i requires capability e, which it does not locally possess or cannot currently execute. It may request robot rjr_j to execute e on its behalf: Req(ri,rj,e,σ)Req(r_i,\;r_j,\;e,\;σ) (8) where σ denotes the task context or request scope. A request is admissible if and only if: AdmissibleReq(ri,rj,e,σ)⇔Possess(rj,e)∧Advertise(rj,e)∧TrustOK(ri,rj,e,σ)∧PolicyComposeOK(ri,rj,e,σ)∧LocalExecPreserved(rj,e) splitAdmissibleReq(r_i,r_j,e,σ) &Possess(r_j,e)\; \;Advertise(r_j,e)\\ & \;TrustOK(r_i,r_j,e,σ)\\ & \;PolicyComposeOK(r_i,r_j,e,σ)\\ & \;LocalExecPreserved(r_j,e) split (9) The final condition is especially important: delegation is not transfer of agenthood. Robot rjr_j executes the requested capability as its own local agent, under its own runtime, policies, and recovery authority. Request lifecycle. An inter-robot capability request proceeds through five phases: (1) Gap detection: rir_i determines e∉Eie∉ E_i or ¬Executable(ri,e,σ) (r_i,e,σ). (2) Federated discovery: rir_i queries Γ for candidates rj∣Advertise(rj,e)∧rj≠ri\r_j (r_j,e) r_j≠ r_i\. (3) Request formulation: rir_i constructs Req(ri,rj,e,σ)Req(r_i,r_j,e,σ). (4) Local evaluation: rjr_j performs admissibility checking, yielding one of accept, defer, negotiate, or reject. (5) Execution and completion: rjr_j executes e locally and returns Result(rj,e,σ)∈success(⋅),Result(r_j,e,σ)∈\ success(·), partial(⋅),failure(⋅) partial(·), failure(·)\. Boundary preservation. Inter-robot requests operate at the capability surface, not the internal runtime surface. The requesting robot specifies what it needs, not how the executing robot should achieve it. This yields three guarantees: no remote planning injection (rir_i cannot dictate rjr_j’s internal strategy); no remote policy override (rir_i’s request does not relax PjP_j); and no remote recovery takeover (failure during execution is first handled by QjQ_j). 1. Gap Detection2. Federated Discovery3. Request Formulation4. Local Evaluation5. Execution & Resulte∉Eie∉ E_i or not executableQuery Γ for candidatesReq(ri,rj,e,σ)Req(r_i,r_j,e,σ)accept / defer / negotiate / rejectrjr_j executes under ℛjR_jRequester rir_iExecutor rjr_j Figure 3: Five-phase lifecycle of an inter-robot capability request. Phases 1–3 are driven by the requesting robot rir_i; phases 4–5 are driven by the executing robot rjr_j under its own local runtime. 3.5 Authority Layers For a request Req(ri,rj,e,σ)Req(r_i,r_j,e,σ), we define four authority dimensions: • Request authority (areqa^req): whether rir_i may issue the request. • Execution authority (aexeca^exec): whether rjr_j may execute e under the request. • Override authority (aovra^ovr): whether the request may override local scheduling or conflict resolution. • Audit authority (aaudita^audit): whether the request and execution must be recorded under local, fleet, or human-visible audit trails. We write the authority tuple as: Auth(ri,rj,e,σ)=(areq,aexec,aovr,aaudit)Auth(r_i,r_j,e,σ)=(a^req,\;a^exec,\;a^ovr,\;a^audit) (10) This layered view prevents conflating the right to ask with the right to command, and conflating the right to execute with the right to override local runtime decisions. Request and execution authority. Request authority (areqa^req) is governed by trust relations, fleet-level role assignments, and task-specific delegation chains. Execution authority (aexeca^exec) is local to rjr_j and depends on PjP_j, the current runtime state, and ECM contract constraints. A critical principle is that execution authority is never automatically implied by request authority: the fact that rir_i is authorized to ask does not mean rjr_j is obligated to comply. Override authority determines whether a fleet-level request may override local scheduling. FSAR treats override authority as exceptional and scoped: aovr∈none,soft-priority,hard-preempt,emergency-onlya^ovr∈\ none,\; soft-priority,\; hard-preempt,\; emergency-only\ (11) Non-transitivity of delegation chains. When a fleet task involves a chain of delegations—rir_i requests rjr_j, and rjr_j in turn requests rkr_k—authority does not propagate transitively by default: areq(ri,rj,e1,σ)∧areq(rj,rk,e2,σ)⇏areq(ri,rk,e2,σ)a^req(r_i,r_j,e_1,σ)\; \;a^req(r_j,r_k,e_2,σ)\; \;a^req(r_i,r_k,e_2,σ) (12) A delegation chain Chain(σ)=[(Req1,Auth1),…,(Reqm,Authm)]Chain(σ)=[(Req_1,Auth_1),…,(Req_m,Auth_m)] is well-formed if and only if every link is independently admissible. Authority revocation. Authority in FSAR is not permanent. Revocation may be triggered by trust downgrade (repeated failures or policy violations), context expiration (task scope σ has concluded), or human override. Revocation takes effect at the next request boundary—it does not interrupt an already-executing capability. areqa^req: Request Authorityaexeca^exec: Execution Authorityaovra^ovr: Override Authorityaaudita^audit: Audit AuthorityAuth(ri,rj,e,σ)Auth(r_i,r_j,e,σ)Delegation Chainrir_irjr_jrkr_kAuth1Auth_1Auth2Auth_2⇏ transitiveNon-transitive by default Figure 4: Left: the four-dimensional authority tuple. Right: delegation chain non-transitivity—authority from rir_i to rjr_j and rjr_j to rkr_k does not imply authority from rir_i to rkr_k. 3.6 Trust Scopes Trust in federated fleets is scope-bound: Trust(ri,rj,e,σ)∈none,capability,task,session,persistentTrust(r_i,r_j,e,σ)∈\\ \ none,\; capability,\; task,\; session,\; persistent\ (13) These levels range from no delegation (none) to long-lived trusted peer relations (persistent). A robot may trust another robot for door opening in one task but not for access to sensitive inspection or close human-interaction capabilities. Trust is not static: it may evolve based on performance history, failures, operator approvals, or policy changes [14, 15]. FSAR does not require a fixed trust matrix; it requires that trust be explicit, scope-aware, and queryable. 3.7 Policy Composition Across Robots Each robot rir_i has a local policy scope PiP_i, but fleet tasks often span multiple robots. We define a policy composition function: Π(Pi,Pj,e,σ)→allow,deny,review (P_i,P_j,e,σ)\;→\;\ allow,\; deny,\; review\ (14) The three-valued outcome is intentional: some interactions are not outright forbidden but require higher-level review due to context ambiguity or unusual delegation patterns. A fleet-level task is admissible only if all required local policy scopes and composed fleet-level constraints are satisfied. 3.8 Layered Recovery Recovery proceeds through a monotone escalation hierarchy: RecLevel(ri,σ)∈local,peer,fleet,humanRecLevel(r_i,σ)∈\ local,\; peer,\; fleet,\; human\ (15) with ordering local≺peer≺fleet≺human local peer fleet human. Recovery ownership begins locally and expands outward only when the local runtime cannot contain the failure [16, 17]. Level 1: Local recovery. Robot rir_i attempts to resolve the issue within its own runtime, bounded by a recovery budget (tmax,nmax)(t_ ,n_ )—maximum time and retry attempts before escalation. Level 2: Peer-assisted recovery. If local recovery is insufficient, rir_i may request assistance from a peer rjr_j, either through capability substitution or environmental assistance, subject to the same trust and authority constraints as routine coordination. Level 3: Fleet reassignment. The recovery orchestrator Ω may reassign the task to a different robot. Reassignment requires that tasks define reassignment checkpoints—well-defined intermediate states from which another robot can resume. Level 4: Human escalation. The failure is escalated to human supervision through Λ , directed to local or fleet supervision depending on scope. Recovery actions are subject to the same authority constraints as routine coordination—a failure does not create new authority that did not exist before the failure. Level 1: Local RecoveryLevel 2: Peer-Assisted RecoveryLevel 3: Fleet ReassignmentLevel 4: Human Escalationbudget exceededno capable peerno feasible reassignRetry, rollback, replan(tmax,nmax)(t_ ,n_ ) boundedCapability substitutionEnvironmental assistCheckpoint-basedTask state transferHiH_i (local) orHFH_F (fleet-level)Prefer minimalescalation Figure 5: Layered recovery hierarchy with monotone escalation. Recovery begins locally and expands outward only when the current level’s budget or capacity is exhausted. 3.9 Hierarchical Human Supervision We define two primary supervisory levels: local supervision HiH_i (oversight specific to robot rir_i) and fleet supervision HFH_F (oversight over cross-robot coordination, policy exceptions, or unresolved conflicts) [18, 19]: Λ=(Hii=1n,HF) =(\H_i\_i=1^n,\;H_F) (16) Escalation to fleet supervision occurs when a local supervisor encounters a situation involving cross-robot dependencies outside local scope. Conversely, fleet supervision does not routinely override local supervision—it intervenes only when cross-robot conflicts require fleet-level resolution. Supervision density is a policy parameter, not a structural constant; it can be adjusted at runtime based on task type, environmental conditions, and operational phase. 3.10 Capability Advertisement Inter-robot coordination depends on a shared registry, but discoverability must be governed. Each advertisement record takes the form: Adv(ri,e)=(Vere,Contracte,TrustReqe,PolicyReqe,AuthProfilee,Availe,Embe)Adv(r_i,e)=(Ver_e,\;Contract_e,\;TrustReq_e,\;PolicyReq_e,\;AuthProfile_e,\;Avail_e,\;Emb_e) (17) where fields encode version metadata, ECM contract, required trust scope, policy constraints, authority profile, current availability state, and embodiment context respectively. The shared registry is not a raw capability marketplace—it is a governed discovery layer. Section˜4 develops the full registry semantics. 3.11 Coordination Invariants To preserve coherence in federated single-agent fleets, FSAR maintains five coordination invariants: I1 Local agent coherence. Each robot remains a single fleet-visible agent principal: ∀ri∈ℱ,PrincipalCount(ri)=1∀ r_i ,\;PrincipalCount(r_i)=1. I2 Delegation preserves local execution ownership. Req(ri,rj,e,σ)⇒LocalExecPreserved(rj,e)Req(r_i,r_j,e,σ) (r_j,e). I3 Policy admissibility is jointly composed. Exec(rj,e,σ)⇒Π(Pi,Pj,e,σ)≠denyExec(r_j,e,σ) (P_i,P_j,e,σ)≠ deny. I4 Recovery escalates outward monotonically. local≺peer≺fleet≺human local peer fleet human. I5 Audit attributability. Each cross-robot coordination event remains attributable to identifiable request, execution, and supervision principals. Having established the model and coordination semantics, table˜2 summarizes all principal symbols for reference. We now turn to the infrastructure that makes them operational. Table 2: Summary of principal notation. Symbol Meaning ℛiR_i Local runtime of robot rir_i: (Ai,Ei,Pi,Ti,Qi,Hi)(A_i,E_i,P_i,T_i,Q_i,H_i) AiA_i Agent identity of rir_i EiE_i ECM set (capabilities) of rir_i PiP_i Local policy scope of rir_i TiT_i Trust relations of rir_i QiQ_i Recovery state of rir_i HiH_i Local human supervisor for rir_i ℱF Fleet: r1,…,rn\r_1,…,r_n\ Φ Federation layer: (Γ,Δ,Π,Ω,Λ)( , , , , ) Γ Shared ECM registry Δ Cross-robot delegation protocol Π Fleet-level policy composition Ω Fleet-level recovery orchestration Λ Hierarchical human oversight: (Hi,HF)(\H_i\,H_F) HFH_F Fleet-level human supervisor AuthAuth Authority tuple: (areq,aexec,aovr,aaudit)(a^req,a^exec,a^ovr,a^audit) TrustTrust Trust evaluation function ReqReq Inter-robot capability request σ Task/coordination context 4 Fleet Architecture and Registry Semantics This section describes the runtime architecture that realizes the FSAR model and details the shared ECM registry that makes governed capability discovery operational. The architecture is organized across two layers—local robot runtimes and the fleet federation layer—with the registry as a core federation component. 4.1 Design Goals and Architectural Overview The architecture pursues five design goals: (1) preserve local runtime self-sufficiency; (2) support fleet coordination without absorbing local autonomy; (3) make every coordination event governed and auditable; (4) support heterogeneous robots with different capabilities, policies, and trust configurations; and (5) degrade gracefully when the federation layer is unavailable. The Local Runtime Layer manages each robot’s embodied capabilities, policy enforcement, recovery handling, and human supervision. The Fleet Federation Layer provides shared infrastructure for cross-robot coordination, including the governed capability registry. The relationship is asymmetric: the local runtime is authoritative for execution; the federation layer is authoritative for coordination. A local runtime may operate without the federation layer (isolated mode), but the federation layer cannot execute capabilities without local runtimes. Robot AAgent CoreECM ManagerPolicy EngineRecovery MgrFederation I/FRobot BAgent CoreECM ManagerPolicy EngineRecovery MgrFederation I/FRobot CAgent CoreECM ManagerPolicy EngineRecovery MgrFederation I/FRobot DAgent CoreECM ManagerPolicy EngineRecovery MgrFederation I/FFleet Federation Layer Φ Γ . Engine Δ Resolver Π Orch. Ω Ξ & Auth MgrOversight Λ Supervisor HFH_F Figure 6: Fleet runtime architecture. Each robot contains a self-sufficient local runtime with agent core, ECM manager, policy engine, and recovery manager, connected to the federation layer through a thin federation interface. The federation layer provides shared registry, coordination engine, policy resolver, recovery orchestrator, audit service, trust manager, and human oversight console. 4.2 Local Robot Runtime Components Each robot’s local runtime ℛiR_i contains: an Agent Core (persistent identity AiA_i and control center, the single fleet-visible principal); a Local ECM Manager (installing, loading, versioning, and executing ECMs in EiE_i); a Local Policy Engine (enforcing PiP_i on every capability execution, request evaluation, and recovery action); a Local Recovery Manager (implementing QiQ_i with local retry, rollback, replanning, and escalation); a Federation Interface (thin translation layer between local runtime state and the federation protocol—it publishes advertisements, evaluates incoming requests, and reports availability updates, but does not make autonomous coordination decisions); and a Local Human Supervision Interface (HiH_i, for monitoring, intervention, and override). 4.3 Fleet Federation Layer Components The federation layer Φ contains: the Shared ECM Registry (Γ , governed capability advertisement, structured queries, and dynamic availability tracking—detailed in section˜4.4 below); the Coordination Engine (Δ , cross-robot delegation protocol including request routing, negotiation management, delegation chain tracking, and completion tracking); the Trust and Authority Manager (trust state storage, authority evaluation, trust updates, and revocation); the Fleet Policy Resolver (Π , policy composition and fleet-level policy management—critically, it never silently overrides a local policy denial; conflicts are escalated, not suppressed); the Recovery Orchestrator (Ω , peer-assisted recovery, fleet reassignment, and escalation management, activated only when local recovery has failed); the Audit and Traceability Service (Ξ , recording all cross-robot coordination events with principal attribution); and the Human Oversight Console (Λ , fleet-level supervision interface HFH_F with intervention controls for trust modification, request approval, and supervision density adjustment). 4.4 Shared ECM Registry: Record Structure and Dynamics A fleet registry is not a centralized list of all installed capabilities—it is a governed discovery layer [20] that answers: which robot currently exposes which capability, under what contract, with what trust, policy, authority, and availability conditions? For each advertised capability, the registry stores a governed advertisement record (eq.˜17) with seven fields: VereVer_e (version metadata for semantic matching), ContracteContract_e (ECM contract for compatibility checking), TrustReqeTrustReq_e (required trust scope for delegation), PolicyReqePolicyReq_e (policy constraints for cross-robot use), AuthProfileeAuthProfile_e (authority profile), AvaileAvail_e (current availability state), and EmbeEmb_e (embodiment profile). The structure is shown in fig.˜7. Adv(ri,e)Adv(r_i,e): Advertisement RecordVersion VereVer_eContract ContracteContract_eTrust Req. TrustReqeTrustReq_ePolicy Req. PolicyReqePolicyReq_eAuth Profile AuthProfileeAuthProfile_eAvailability AvaileAvail_eEmbodiment EmbeEmb_eIdentityGovernanceAuthorityStatePhysical Figure 7: Structure of a capability advertisement record in the shared ECM registry. Fields are grouped by function: identity (version, contract), governance (trust and policy requirements), authority profile, operational state (availability), and physical context (embodiment). Availability is modeled as a first-class stateful property: Avail(ri,e)∈ready,busy,degraded,restricted,offlineAvail(r_i,e)∈\ ready,\; busy,\; degraded,\; restricted,\; offline\ This richer state prevents a frequent coordination error: assuming that discoverability implies immediate utility. The registry is authoritative about discoverability but never about execution: even after discovery succeeds, the callee robot evaluates admissibility under its local runtime. Given a request Q=(rA,e∗,σ,B,P)Q=(r_A,e^*,σ,B,P), the registry returns a candidate set: Cand(Q)=(rj,ej)∣Match(ej,e∗)∧Advertise(rj,ej)Cand(Q)=\(r_j,e_j) (e_j,e^*) (r_j,e_j)\ filtered by trust sufficiency, policy composability, authority profile, availability, and contract compatibility [21, 11]. Visibility may be global, domain-scoped, or trust-gated. Registry records are dynamically updated as robots enter degraded mode, withdraw capabilities during recovery, or change advertisement during upgrade rollouts. 4.5 Interaction Patterns and Deployment Components interact through recurring patterns: in normal delegation, a robot’s agent core detects a capability gap, the federation interface queries the registry, the coordination engine routes the request, and the callee executes locally. In policy-flagged coordination, the fleet policy resolver flags a request for human review. In recovery escalation, the recovery orchestrator coordinates peer assistance or fleet reassignment. These patterns compose within a single fleet task. The architecture supports centralized federation for small fleets, distributed federation with leader election for larger fleets, and peer-to-peer federation for intermittently connected fleets. In all topologies, the local runtime continues operating in isolated mode if the federation layer becomes unavailable. 4.6 Architectural Invariants and Model Mapping Five architectural invariants complement the coordination invariants I1–I5: A1 Local runtime self-sufficiency. Every robot can operate in isolated mode. A2 Coordination-only federation. The federation layer never directly executes capabilities. A3 No silent policy override. Policy conflicts are escalated, not suppressed. A4 Thin federation interface. All execution decisions are made by local runtime components. A5 Audit completeness. Every cross-robot event is recorded with principal attribution. Table˜3 provides the complete mapping from formal model elements to architectural components. Table 3: Mapping from formal model elements to architectural components. Model Element Architecture Component AiA_i (agent identity) Agent Core EiE_i (capability set) Local ECM Manager PiP_i (policy scope) Local Policy Engine TiT_i (trust state) Trust and Authority Manager QiQ_i (recovery authority) Local Recovery Manager + Recovery Orch. HiH_i (local supervision) Local Human Supervision Interface Γ (shared registry) Shared ECM Registry Δ (coordination protocol) Coordination Engine Π (fleet policy) Fleet Policy Resolver Ω (recovery orchestration) Recovery Orchestrator Λ (human oversight) Human Oversight Console Ξ (audit) Audit and Traceability Service 5 Evaluation To validate that FSAR’s abstractions compose into a working system, we conduct a simulation-based evaluation of both the coordination prototype and governance properties. A simulation-based approach is appropriate because the evaluation targets governance properties—authority attribution, recovery escalation, policy composition—that are observable at the protocol level and do not require physical dynamics. 5.1 Prototype and Fleet Configuration The prototype instantiates all components defined in section˜4: shared ECM registry, coordination engine with full request lifecycle, trust and authority evaluation, policy composition, layered recovery orchestration, audit logging, and hierarchical human oversight. The prototype fleet consists of four heterogeneous robots: • Robot A (Delivery): navigate.indoor, carry.package, handover.dropoff • Robot B (Access): navigate.indoor, door.open.basic, door.open.secure • Robot C (Inspection): navigate.indoor, inspect.visual, inspect.private_zone • Robot D (Heavy Transport): navigate.indoor, carry.heavy, grasp.robust Trust configuration: A↔BA B task-scoped; A↔DA D capability-scoped; B↔CB C session-scoped; C’s inspect.private_zone visible only to fleet supervisors and Robot B; D has no trust relation with C. 5.2 Coordination Workflows Three workflows validate distinct layers of the coordination model. Workflow 1 (Door Relay): Robot A detects a capability gap (door.open.secure∉EA door.open.secure∉ E_A), discovers Robot B via the registry, issues a trust-evaluated request (Trust=taskTrust= task, authority (1,1,0,1)(1,1,0,1), policy → allow), and Robot B executes under its own runtime ℛBR_B. This demonstrates structured delegation, trust scoping, policy composition, and auditability (fig.˜8). Workflow 2 (Layered Recovery): Robot D’s grasp actuator degrades during heavy transport. Recovery escalates through all four levels: local retry (budget exhausted after 2 attempts / 30s), peer query (no capable peer), fleet reassignment (infeasible), and human escalation to HFH_F (fig.˜9). This demonstrates monotone escalation, recovery budget enforcement, and audit trails through all levels. Workflow 3 (Human Supervision): Robots B and D simultaneously request Robot A’s carrying capability; the policy resolver produces review, escalating to HFH_F who prioritizes Robot B’s time-critical delivery. This demonstrates fleet-level supervision, the review outcome, and audited supervisor decisions. Table˜4 summarizes mechanism coverage across workflows. Robot ARegistry Γ B1. query: door.open.secure2. candidates: rB\r_B\3. Req(rA,rB,e,σ)Req(r_A,r_B,e,σ)4. evaluateTrust=taskTrust= taskΠ→allow → allow5. acceptexecute under ℛBR_B6. success(door_opened) Figure 8: Sequence diagram for Workflow 1 (Door Relay). Robot A discovers Robot B’s door-opening capability through the registry, issues a governed request, and Robot B executes under its own local runtime. Local: Retry grasp (attempt 1)partialLocal: Retry grasp (attempt 2)failBudget exhausted (30s,2)(30s,2)Peer: Query for grasp.*no peerFleet: Evaluate reassignmentinfeasibleHuman: Escalate to HFH_FresolvedLevel 1Level 2Level 3Level 4 Figure 9: Workflow 3: layered recovery escalation for Robot D’s grasp degradation. Recovery proceeds through all four levels—local retry, peer query, fleet reassignment evaluation, and human escalation—demonstrating monotone escalation with containment attempt at each level. Table 4: FSAR mechanisms exercised by each workflow. Mechanism WF1 WF2 WF3 Inter-robot request ∙ via recovery ∙ Trust evaluation task — task Authority tuple standard — standard Policy composition allow — review Registry discovery single no peer conflict Layered recovery — all 4 levels — Fleet reassignment — attempted — Human escalation — Level 4 conflict Delegation chain single — — 5.3 Evaluation Goals The evaluation is designed to answer five questions: 1. Does FSAR achieve comparable or better task completion compared to centralized and decomposition-heavy baselines? 2. Does FSAR improve governance locality—the ability to attribute decisions and actions to identifiable principals? 3. Does FSAR improve recovery containment—the ability to resolve failures at the lowest possible level? 4. Does FSAR reduce authority conflicts and policy violations compared to alternatives? 5. Does FSAR maintain operational clarity as fleet complexity increases? 5.4 Baselines We compare FSAR against two baselines. Both are author-constructed abstractions designed to isolate specific architectural properties; we detail their construction to support reproducibility and address the inherent limitation that they are not implementations of published systems. Centralized Fleet Controller (CFC). A single global coordinator assigns tasks, routes requests, and handles all recovery. Robots are thin execution endpoints with no local policy authority or recovery ownership. CFC is modeled after the centralized task-orchestration topology found in RoboOS [22] and classical centralized MRTA architectures [23]: a single coordinator maintains the global task queue, performs all capability matching, and issues execution commands to individual robots. CFC differs from RoboOS in that it does not implement RoboOS’s hierarchical LLM-based planning; instead, it uses the same capability-matching logic as FSAR but routes all decisions through the central coordinator. Recovery is centralized: any failure is immediately escalated to the coordinator, which decides whether to retry, reassign, or escalate to a human supervisor. This design choice ensures that CFC captures the architectural tendency of centralized coordination—single-point routing, global state visibility, but limited local autonomy—rather than any single system’s implementation specifics. Decomposition-Heavy Multi-Agent (DHMA). Each robot is internally decomposed into four fleet-visible agents (planning, execution, communication, recovery), following the per-robot agent decomposition pattern established by JADE/FIPA-based fleet coordination [24, 25] and more recently instantiated in LLM-based multi-agent systems such as CoELA [26] and ProAgent [27]. Inter-robot coordination occurs at the sub-agent level: a planning agent in Robot A may communicate directly with a communication agent in Robot B. Recovery ownership is distributed across each robot’s internal recovery agent, which must coordinate with the planning and execution agents before escalating. DHMA captures the architectural tendency of fine-grained agent decomposition—expressive internal structure, rich inter-agent communication, but blurred responsibility boundaries and complex attribution. Relationship to published systems. Table˜5 compares the architectural features of FSAR, CFC, DHMA, and three published multi-robot coordination systems: RoboOS [22], JADE-based fleet coordination [24], and ALLIANCE [28]. CFC shares RoboOS’s centralized coordination topology; DHMA mirrors JADE’s per-robot agent decomposition. ALLIANCE provides an instructive middle ground: it preserves robot-level agency (like FSAR) but uses motivational behaviors rather than explicit trust scoping for fault tolerance. Neither CFC nor DHMA replicates these systems exactly, but they capture the same architectural tendencies—centralized routing versus distributed sub-agent coordination—that published systems exhibit. We release the full baseline implementation code alongside the simulator to enable independent verification. Table 5: Architectural comparison of FSAR, evaluation baselines, and published systems. Features marked with ∙ are present; ∘ indicates partial support. Feature FSAR CFC DHMA RoboOS JADE ALLIANCE Single-agent robot ∙ ∙ — ∘ — ∙ Centralized coord. — ∙ — ∙ — — Intra-robot agents — — ∙ ∘ ∙ — Trust-scoped deleg. ∙ — — — ∘ — Layered recovery ∙ — ∘ ∘ — ∙ Policy composition ∙ ∘ ∘ — ∘ — Governed registry ∙ ∙ ∘ ∙ ∙ — Audit attribution ∙ ∘ — — ∘ ∘ 5.5 Simulator Architecture The evaluation uses a protocol-level simulator that models coordination events, message passing, and failure injection without simulating physical dynamics, sensor noise, or continuous-time control. This design choice reflects the paper’s focus on governance properties (authority attribution, recovery escalation, policy composition) rather than motion planning or perception accuracy. The simulator operates as follows. Clock model. A discrete event-driven clock advances through coordination events (request issued, capability evaluated, execution started, result returned, recovery triggered). Each event carries a logical timestamp; wall-clock durations for capability execution are sampled from scenario-specific distributions (e.g., (0.5,2.0)U(0.5,2.0) s for door.open, (1.0,5.0)U(1.0, 5.0) s for carry.package). Communication model. Inter-robot messages experience latency sampled from (50,500)U(50,500) ms. Messages are reliable (no packet loss), reflecting a controlled indoor deployment assumption. The federation layer processes requests in FIFO order per robot, with concurrent requests across robots resolved by logical timestamp. Robot state. Each simulated robot maintains the full runtime tuple ℛi=(Ai,Ei,Pi,Ti,Qi,Hi)R_i=(A_i,E_i,P_i,T_i,Q_i,H_i) as in-memory state. Capability execution transitions the robot through states (idle → executing → idle/degraded/failed). Trust and policy state are updated after each coordination event. Failure injection. Actuator degradation events are injected with configurable probability (pfail=0.3p_fail=0.3 for recovery-relevant scenarios). Degradation reduces capability reliability (success probability drops from 1.0 to 0.6) and may trigger the recovery hierarchy. Communication delays and trust violations are injected independently. Metric instrumentation. Every coordination event is recorded in a structured audit trace, from which all eight evaluation metrics are computed post-hoc. The simulator, baseline implementations, evaluation scripts, and random seeds are released as open-source supplementary materials.333https://github.com/s20sc/fsar-fleet-coordination 5.6 Evaluation Scenarios We evaluate on five scenarios of increasing coordination complexity. Scenario 1: Door Relay. Robot A delivers a package through a secured door operated by Robot B. Tests basic cross-robot delegation. Scenario 2: Collaborative Delivery. Robot A, B, and D coordinate a heavy delivery task requiring capability discovery, task segment transfer, and handoff. Tests contract-aware matching and fleet routing. Scenario 3: Failure Recovery Chain. Robot D experiences actuator degradation during a carrying task, triggering the full recovery hierarchy. Tests layered recovery and escalation. Scenario 4: Mixed-Trust Inspection. A secure inspection task requires trust-constrained delegation involving Robots B, C, and A under different trust scopes. Tests trust-scoped coordination and visibility. Scenario 5: Multi-Task Fleet Contention. Multiple concurrent tasks compete for shared robot capabilities, requiring priority resolution, policy composition, and human-supervised conflict resolution. Tests fleet-level governance under contention. 5.7 Experimental Setup The prototype fleet consists of four heterogeneous robots (n=4n=4): Robot A (mobile base with carrying capability), Robot B (manipulator arm with door-operation capability), Robot C (inspection platform with sensor suite), and Robot D (heavy-duty carrier with grasping capability). Each robot runs an independent local runtime process; the federation layer runs as a set of coordination services on a shared network. Each of the five scenarios is executed for 20 independent runs per architecture (FSAR, CFC, DHMA), yielding 100 runs per architecture and 300 runs total. Runs are seeded with distinct random seeds controlling failure injection timing, request arrival order, and initial robot positions. To ensure fair comparison, all three architectures receive the same seed sequence per scenario. Failure injection follows a controlled perturbation model: actuator degradation events are injected with probability pfail=0.3p_fail=0.3 per run in recovery-relevant scenarios (Scenarios 3 and 5); communication delays are sampled from (50,500)U(50,500) ms; and trust violations are injected in Scenario 4 to test visibility enforcement. The CFC and DHMA baselines are implemented to match FSAR’s capability set: CFC uses a single global coordinator process replacing the federation layer, while DHMA decomposes each robot into four internal agents (planning, execution, communication, recovery) with inter-agent coordination at both intra-robot and inter-robot levels. 5.8 Metrics We evaluate eight metrics. For the three governance-specific metrics that require interpretation, we provide operational definitions: • Coordination success rate: fraction of fleet tasks that reach a terminal success state within the allotted time budget. • Governance locality score: for each coordination decision (request, delegation, escalation, denial) in a run, we determine whether a single identifiable principal (a specific robot or a named supervisor) is recorded as the decision owner in the audit trace without requiring traversal of nested internal-agent delegation chains. The score is the fraction of decisions satisfying this criterion, averaged across runs. • Recovery containment rate: for each failure event, we record the lowest recovery level at which the failure was resolved (local, peer, fleet, or human). The containment rate is the fraction of failures resolved at levels 1 or 2 (local or peer), i.e., without escalation to fleet reassignment or human intervention. • Authority conflict count: number of events per run in which two or more principals simultaneously claim execution authority, override authority, or audit responsibility for the same coordination action. • Policy violation count: number of actions per run that proceed despite failing a local or fleet-level policy check, detected by post-hoc audit trace analysis. • Reassignment latency: wall-clock time from failure detection to either successful task reassignment to an alternative robot or escalation to the next recovery level. • Human intervention frequency: fraction of runs in which the fleet supervisor HFH_F is invoked for decision-making. • Audit attributability: for each coordination event (request issued, capability executed, recovery triggered, escalation performed), we check whether the audit trace jointly records (a) request origin, (b) execution owner, and (c) escalation/supervision owner. The score is the fraction of events for which all three fields are recoverable, averaged across runs. 5.9 Results Table 6: Evaluation results across five scenarios (n=100n=100 runs per architecture). Values show mean ± 95% CI. Higher is better for success, governance locality, recovery containment, and audit attributability. Lower is better for authority conflicts, policy violations, reassignment latency, and human interventions. Metric FSAR CFC DHMA Coord. success (%) 93.0 ± 1.9 94.0 ± 1.0 84.0 ± 1.0 Governance locality 0.94 ± 0.01 0.69 ± 0.01 0.53 ± 0.01 Recovery containment 0.89 ± 0.03 0.51 ± 0.04 0.80 ± 0.03 Authority conflicts 1.04 ± 0.03 3.79 ± 0.12 8.11 ± 0.04 Policy violations 0.40 ± 0.01 1.66 ± 0.06 3.34 ± 0.05 Reassign. latency (s) 3.01 ± 0.49 2.07 ± 0.28 5.18 ± 0.52 Human interv. (%) 14.0 ± 3.8 32.0 ± 5.6 19.0 ± 4.2 Audit attributability 0.98 ± 0.00 0.84 ± 0.01 0.53 ± 0.01 Coordination success. FSAR and CFC achieve comparable task completion rates (93% and 94%, respectively), while DHMA shows measurably lower success (84%). FSAR exhibits higher variance (std==9.8%) than CFC (std==4.9%), reflecting the fact that federated coordination outcomes depend on per-scenario trust and recovery dynamics, whereas CFC’s centralized controller produces more uniform (but less governed) outcomes. The near-parity between FSAR and CFC on this surface metric is notable: CFC’s centralized controller handles simple task routing efficiently, but as the governance metrics below reveal, this comes at substantial cost to decision attribution and recovery locality. DHMA suffers from coordination overhead in internally fragmented robots, particularly in recovery and contention scenarios. Governance and attribution. FSAR achieves the highest governance locality (0.94 vs. 0.69 CFC, 0.53 DHMA) and audit attributability (0.98 vs. 0.84, 0.53), reflecting its design commitment that every coordination decision is attributable to a single identifiable robot or supervisor. CFC obscures the requesting/executing distinction through its centralized controller; DHMA distributes decisions across internal agents, making attribution substantially harder. Governance locality: a worked computation. To clarify this metric, consider a Scenario 1 run with 10 coordination decisions. In FSAR, 9 of 10 decisions name a single identifiable principal without traversal: “Robot A requested door.open,” “Robot B accepted and executed,” “Robot A detected completion.” The one exception is a recovery escalation where audit must traverse the fleet layer before identifying Robot B’s recovery manager, yielding a score of 9/10=0.909/10=0.90. In CFC, the central controller is logged as the decision owner for 7 of 10 decisions (requests, assignments, completions all route through the coordinator). While the controller is a single identifiable entity, it is not the correct decision-making principal—it obscures which robot initiated the request and which made the execution commitment. Our metric requires that the logged principal be the operationally responsible entity, not merely an identifiable relay. The 3 remaining decisions that CFC attributes correctly are robot-local events (e.g., Robot B’s actuator self-check) that do not pass through the coordinator, yielding 3/10=0.303/10=0.30 for that run. CFC’s aggregate score of 0.69 across all scenarios is higher because simpler scenarios (1 and 2) involve fewer coordinator-mediated decisions. In DHMA, a single decision such as “accept delegation” may involve Robot B’s communication agent receiving the request, its planning agent evaluating feasibility, and its execution agent confirming resources—three internal agents with no single identifiable owner, scoring 0 for that decision. Recovery and conflict metrics. FSAR contains 89% of failures locally (vs. 51% CFC, 80% DHMA) and produces the fewest authority conflicts (1.04 vs. 3.79 CFC, 8.11 DHMA). CFC’s low containment reflects its structural limitation: lacking local context, it escalates conservatively, producing the highest human intervention rate (32% vs. 14% FSAR). DHMA’s many internal agents create overlapping authority scopes that drive high conflict counts. FSAR’s reassignment latency (3.01s) falls between CFC (2.07s, immediate centralized routing) and DHMA (5.18s, propagation through agent layers). 00.250.500.751.00.93.94.84Coord.Success.94.69.53Gov.Locality.89.51.80RecoveryContain.1.03.88.1Auth.Confl.†0.41.73.3PolicyViol.†3.0s2.1s5.2sReassign.Lat.†14%32%19%HumanInterv.†.98.84.53AuditAttrib.FSARCFC (Centralized)DHMA (Decomposition-Heavy)†For these metrics, lower raw values are better; bars show inverted scale (taller = better). Raw values shown above bars. Figure 10: Evaluation results across all eight metrics. For metrics where lower is better (marked †), bars are inverted so taller always indicates better performance; raw values are shown above each bar. FSAR achieves the best or near-best performance on seven of eight metrics, with CFC showing lower reassignment latency due to its centralized routing. 5.10 Ablation Study To understand the contribution of individual FSAR components, we conduct ablation experiments by selectively removing trust evaluation, policy composition, layered recovery, and the shared registry. Unlike the single-scenario ablation common in prior work, we run each ablation across all five evaluation scenarios (100 runs per condition, 500 runs total) to demonstrate that each component contributes robustly across different coordination contexts. Table 7: Ablation results aggregated across all five evaluation scenarios. Each row removes one FSAR component while keeping the others intact. Configuration Success Gov. Loc. Rec. Cont. Auth. Conf. Pol. Viol. Audit Full FSAR 0.95 0.94 0.90 1.18 0.46 0.98 −- Trust evaluation 0.97 0.94 0.90 1.65 0.46 0.96 −- Policy composition 0.96 0.95 0.90 1.14 0.64 0.98 −- Layered recovery 0.74 0.93 0.97 1.14 0.46 0.98 −- Shared registry 0.46 0.94 0.90 1.23 0.46 0.93 The ablation reveals clear component-specific contributions across different coordination contexts. Removing the shared registry causes the most severe degradation in task success (0.95→ 0.46), with cross-robot scenarios particularly affected (Door Relay drops from 0.95 to 0.20; Collaborative Delivery from 0.85 to 0.10) because robots cannot discover peer capabilities. Removing layered recovery reduces overall success to 0.74, with the Failure Recovery scenario dropping from 1.00 to 0.20 as all failures escalate directly to human intervention without local or peer recovery attempts. Removing trust evaluation increases authority conflicts (1.18→ 1.65 overall; 1.20→ 2.85 in Mixed-Trust Inspection) because robots accept requests from untrusted peers, but paradoxically improves success rate slightly (0.95→ 0.97) since no legitimate requests are blocked by trust gates. Removing policy composition increases policy violations (0.46→ 0.64) as cross-robot actions proceed without composed policy checks. 5.11 Qualitative Case Analysis We highlight four cases that illustrate FSAR’s governance advantages across different coordination layers. Case 1: Trust boundary enforcement (Scenario 4). Robot D attempted to participate in a private-zone inspection task but could not discover the required capability in the registry due to trust-constrained visibility. In DHMA, Robot D’s internal communication agent discovered the capability through a nested agent query that bypassed visibility constraints, leading to an unauthorized delegation attempt. Case 2: Recovery containment (Scenario 3). Robot D’s grasp degradation was contained through local recovery (retry with adjusted parameters) in 67% of runs under FSAR, requiring no fleet-level intervention. Under CFC, the same failure was immediately escalated to the central controller in 100% of runs. Under DHMA, internal agent confusion about recovery ownership caused 23% of runs to enter a recovery loop before escalation. Case 3: Authority conflict under contention (Scenario 5). Two concurrent fleet tasks both required Robot B’s door.open.secure capability. Under FSAR, the fleet policy resolver Π identified the conflict, applied priority-based resolution, and queued the lower-priority request with an explicit defer response—producing zero authority conflicts across all 20 runs. Under CFC, the central controller assigned both tasks simultaneously (lacking local scheduling awareness), generating an authority conflict in 85% of runs that required human supervisor intervention. Under DHMA, the conflict propagated across Robot B’s internal planning and execution agents, with each agent independently attempting to negotiate, causing an average of 2.4 authority conflicts per run. Case 4: Audit trail completeness (Scenario 2). In a collaborative delivery requiring capability handoff from Robot A to Robot D, FSAR’s audit trace recorded the complete delegation chain: Robot A’s gap detection, registry query, request formulation, Robot D’s admissibility check, execution, and result—with each event attributed to a named principal. Under CFC, the audit recorded “coordinator assigned task to Robot D” without capturing Robot A’s original request or Robot D’s local admissibility evaluation, leaving 3 of 7 coordination events unattributed. Under DHMA, Robot D’s internal agent handoff (communication agent → planning agent → execution agent) produced 4 additional unattributed internal events per coordination action. 5.12 Statistical Significance To assess whether observed differences are statistically reliable, we conduct paired t-tests and report Cohen’s d effect sizes for all pairwise architecture comparisons across the eight evaluation metrics (table˜8). All tests use n=100n=100 paired observations per architecture (5 scenarios × 20 runs). Results are corroborated by non-parametric Wilcoxon signed-rank tests, which yield consistent significance levels. Table 8: Statistical significance of pairwise metric comparisons (paired t-test, n=100n=100 per architecture). Effect sizes reported as Cohen’s d. Metric Comparison t p d Sig. Coord. success FSAR vs CFC −0.33-0.33 0.7440 0.05 n.s. FSAR vs DHMA 2.88 0.0047 0.42 p<.01p<.01 CFC vs DHMA 3.13 0.0022 0.45 p<.01p<.01 Governance locality FSAR vs CFC 22.63 <.0001<.0001 2.91 p<.001p<.001 FSAR vs DHMA 42.23 <.0001<.0001 4.88 p<.001p<.001 CFC vs DHMA 14.04 <.0001<.0001 2.03 p<.001p<.001 Recovery containment FSAR vs CFC 10.14 <.0001<.0001 1.44 p<.001p<.001 FSAR vs DHMA 3.31 0.0012 0.48 p<.01p<.01 CFC vs DHMA −7.55-7.55 <.0001<.0001 1.12 p<.001p<.001 Authority conflicts FSAR vs CFC −29.23-29.23 <.0001<.0001 4.12 p<.001p<.001 FSAR vs DHMA −37.78-37.78 <.0001<.0001 5.16 p<.001p<.001 CFC vs DHMA −15.71-15.71 <.0001<.0001 2.05 p<.001p<.001 Policy violations FSAR vs CFC −17.67-17.67 <.0001<.0001 2.65 p<.001p<.001 FSAR vs DHMA −32.57-32.57 <.0001<.0001 3.92 p<.001p<.001 CFC vs DHMA −12.49-12.49 <.0001<.0001 1.79 p<.001p<.001 Reassign. latency FSAR vs CFC 2.04 0.0438 0.30 p<.05p<.05 FSAR vs DHMA −3.74-3.74 0.0003 0.54 p<.001p<.001 CFC vs DHMA −5.36-5.36 <.0001<.0001 0.74 p<.001p<.001 Human interventions FSAR vs CFC −2.93-2.93 0.0040 0.42 p<.01p<.01 FSAR vs DHMA −0.88-0.88 0.3818 0.12 n.s. CFC vs DHMA 2.01 0.0470 0.29 p<.05p<.05 Audit attributability FSAR vs CFC 26.44 <.0001<.0001 3.56 p<.001p<.001 FSAR vs DHMA 36.69 <.0001<.0001 5.09 p<.001p<.001 CFC vs DHMA 14.13 <.0001<.0001 2.01 p<.001p<.001 FSAR’s advantages on governance locality (d=2.91d=2.91 vs. CFC, d=4.88d=4.88 vs. DHMA), authority conflicts (d=4.12d=4.12 vs. CFC, d=5.16d=5.16 vs. DHMA), and audit attributability (d=3.56d=3.56 vs. CFC, d=5.09d=5.09 vs. DHMA) are all statistically significant at p<.001p<.001 with large effect sizes (d>0.8d>0.8). For coordination success, FSAR vs. CFC is not significant (p=0.74p=0.74), consistent with our claim that FSAR preserves task completion while improving governance properties. The two non-significant comparisons (FSAR vs. CFC on success; FSAR vs. DHMA on human interventions) confirm that FSAR’s gains are concentrated in governance metrics rather than reflecting a wholesale performance shift. Interpreting large effect sizes. The Cohen’s d values for governance-specific metrics (d=2.91d=2.91–5.165.16) exceed the conventional “large” threshold of d>0.8d>0.8. These are structural artifacts reflecting fundamental architectural differences, not surprising empirical findings. Governance locality is architecturally guaranteed in FSAR (single-agent ownership) but structurally degraded in DHMA (decisions distributed across sub-agents). The low within-architecture variance reflects each design’s consistency, and the large d values indicate that the metrics successfully capture the intended architectural distinctions. In systems evaluation, where architectures impose deterministic constraints on measured properties, such values are expected. 5.13 Baseline Fairness and Reproducibility All three architectures are evaluated under identical conditions: same random seeds, failure injection timing, and request arrival order across all 300 runs. CFC implements standard centralized coordination following the topology of [23, 22]; DHMA follows established multi-agent decomposition practices as instantiated in [12, 5, 24]. We acknowledge that CFC and DHMA are author-constructed and thus inherently subject to implementation choices that may favor FSAR. To mitigate this, both baselines use the same core capability-matching and task-execution logic as FSAR; they differ only in coordination topology and recovery routing. Results should be interpreted as evidence of architectural tendencies rather than definitive comparisons against optimized published systems. The full simulator code, baseline implementations, evaluation scripts, and random seeds are released as open-source supplementary materials to enable independent replication and extension. 5.14 Scaling Experiment To assess whether FSAR’s governance properties hold as fleet size increases, we extend the evaluation to n∈4,8,16n∈\4,8,16\ robots. Larger fleets are constructed by replicating the four role templates (delivery, access, inspection, heavy transport) with scaled trust matrices. Table˜9 summarizes key metrics. Table 9: Scaling experiment across fleet sizes n∈4,8,16n∈\4,8,16\. n Arch. Success Gov. Loc. Rec. Cont. Auth. Conf. Audit 4 FSAR 0.93 0.94 0.89 1.0 0.98 CFC 0.94 0.69 0.51 3.8 0.84 DHMA 0.84 0.53 0.80 8.1 0.53 8 FSAR 0.91 0.94 0.87 1.2 0.98 CFC 0.88 0.65 0.47 4.8 0.81 DHMA 0.79 0.49 0.76 10.3 0.48 16 FSAR 0.88 0.93 0.85 1.5 0.97 CFC 0.81 0.59 0.42 6.2 0.78 DHMA 0.72 0.44 0.71 14.1 0.42 FSAR’s governance metrics remain stable across fleet sizes: governance locality degrades minimally (0.94→ 0.93), recovery containment decreases only 4 percentage points (0.89→ 0.85), and audit attributability stays at 0.97–0.98. In contrast, CFC’s governance locality drops substantially (0.69→ 0.59) as the centralized controller becomes an attribution bottleneck, and its recovery containment falls to 0.42 because centralized recovery cannot scale to 16-robot contention. DHMA shows the steepest degradation: authority conflicts grow roughly linearly with fleet size (8.1→14.18.1→ 14.1) because internal agent count scales quadratically (4n4n agents for n robots), amplifying inter-agent coordination conflicts. Task completion degrades for all architectures at larger scales, but at different rates. FSAR’s success rate drops 5 points (93%→ 88%), CFC drops 13 points (94%→ 81%) due to centralized coordination bottleneck, and DHMA drops 12 points (84%→ 72%) due to compounding agent-level coordination failures. These results suggest that FSAR’s local-first design scales more gracefully than either baseline, particularly for governance-sensitive metrics. Scaling analysis. The observed degradation trends across n∈4,8,16n∈\4,8,16\ are consistent with the architectural complexity of each approach. FSAR’s coordination cost is dominated by registry lookups (O(logn)O( n) with indexing) and pairwise trust checks, which predicts sub-linear governance degradation—matching the data (governance locality: 0.94→0.930.94→ 0.93). CFC’s centralized controller processes O(n)O(n) requests sequentially, predicting linear degradation—matching the observed pattern (0.69→0.590.69→ 0.59). DHMA’s internal agent count grows as O(kn)O(kn) for k agents per robot, producing O(k2n2)O(k^2n^2) potential inter-agent interactions, predicting super-linear conflict growth—matching the authority conflict trend (8.1→14.18.1→ 14.1). We deliberately refrain from quantitative extrapolation to larger fleet sizes, as three data points are insufficient for reliable curve fitting. Validating these architectural predictions at n=32n=32 and beyond is an important direction for future work. 5.15 Discussion of Evaluation Limitations The evaluation operates on a protocol-level simulator with fleets of 4–16 robots across 5 scenarios. Results demonstrate architectural properties rather than production performance. Scaling to larger fleets, real hardware, and real-time constraints is future work. The evaluation scenarios, while representative, do not cover all possible fleet coordination patterns. The quantitative results should be interpreted as directional evidence of FSAR’s governance advantages rather than as absolute performance benchmarks. Threat to validity: author-constructed baselines. Both CFC and DHMA are designed by the same authors as FSAR. Although we ground their designs in published systems (table˜5) and release all implementation code, the comparison is inherently favorable: the authors understand FSAR’s strengths and may have unconsciously designed baselines that expose them. Independent replication using third-party implementations of published multi-robot coordination systems (e.g., ALLIANCE [28], JADE-based fleet coordination [24]) would provide stronger evidence. We consider this the most important limitation of the current evaluation. 6 Discussion 6.1 Why Federation Instead of Intra-Robot Fragmentation The central position of this paper is that the move from single-robot autonomy to multi-robot coordination need not induce intra-robot multi-agent fragmentation. This claim reflects a systems judgment about where coordination complexity should live. If each robot is internally decomposed into multiple fleet-visible agents, responsibility for execution, recovery, policy checking, and human supervision becomes distributed across nested layers. In contrast, FSAR treats the robot as the principal of embodied agency and pushes cross-robot coordination into explicit fleet-layer relations. Federation is not the rejection of modularity. It is the placement of modularity at the correct layer: within each robot for implementation, across robots for coordination. 6.2 Coherence and Governance Locality A deeper claim of FSAR is that coherence matters. A robot is not just a bundle of callable services. It is an embodied runtime with persistent state, local physical constraints, and ongoing recovery obligations. Capability execution affects bodies, environments, safety envelopes, and task continuity. Treating such execution as just another remote function call is a category mistake. FSAR treats coherence not as an aesthetic preference but as a systems property: the authority to execute, recover, deny, or escalate remains as close as possible to the local runtime that bears the consequences. Delegated execution remains attributable, policy composition remains explicit, recovery remains layered, and human review becomes better scoped. This combination of coherence preservation and governance locality is anticipated to be especially valuable in enterprise or public-deployment settings where explainability, accountability, and approval structure matter as much as raw task completion—though validating this claim in production environments remains future work. When governance locality is not desirable. There are deployment contexts where FSAR’s emphasis on governance locality may be counterproductive. In military operations, unified command authority may deliberately override local robot autonomy to enforce coordinated maneuvers—a centralized fleet controller (CFC) pattern where global optimization outweighs local coherence. Similarly, in emergency response scenarios (e.g., search-and-rescue after a building collapse), the urgency of the situation may favor rapid centralized reallocation of all robots to a single objective, bypassing the trust-scoped delegation that FSAR requires. In these contexts, the governance overhead of FSAR’s trust checks, policy composition, and layered recovery may introduce unacceptable latency. FSAR’s design assumes that governance clarity is worth its coordination cost; in time-critical scenarios where a single human commander must direct all robots simultaneously, a flatter authority model may be more appropriate. We note that FSAR’s federation layer could be configured with permissive trust defaults and minimal policy checks to approximate centralized control when needed, but this would effectively disable the governance properties that motivate the architecture. 6.3 Limits of the Single-Agent Fleet Principle The single-agent principle should not be overstated, and the decomposition-heavy approach has genuine strengths that merit acknowledgment. Multi-agent decomposition can offer superior parallelism in planning and execution, enable finer-grained fault isolation within individual robots, and support negotiation-based coordination protocols (e.g., the Contract Net Protocol [29]) and coalition formation methods [30] that are natural for resource allocation in large heterogeneous fleets. In domains with tightly coupled multi-robot manipulation [31], where continuous joint-space coordination is required, the “one request, one callee” abstraction may be less natural than shared multi-agent planning [32]. Similarly, market-based approaches to task allocation [33, 34] may yield more efficient global outcomes than federated delegation when the cost function is well-defined and global optimization is tractable. FSAR’s advantage is not in raw coordination efficiency but in governance clarity: attributable decisions, containable recovery, and auditable authority chains. Some robots may internally implement complex modular architectures; FSAR only claims these internal structures need not become the unit of fleet-visible agency. Future work should investigate hybrid designs that preserve FSAR’s governance properties while selectively incorporating multi-agent coordination for tightly coupled subtasks. These limitations clarify that FSAR is best understood as a runtime and governance architecture for coherent multi-robot coordination, not as a universal theory of all distributed robotics. A concrete friction scenario. Consider Robot D executing a heavy grasping task while simultaneously needing to plan its next navigation waypoint. In a decomposition-heavy architecture, a planning agent and an execution agent can operate concurrently with independent control loops. In FSAR, Robot D is a single agent: its runtime must serialize or internally pipeline these activities. FSAR handles this through internal modularity (the runtime may use concurrent software components) without exposing this concurrency as fleet-visible agency. The friction arises when a fleet-level request arrives during concurrent internal activity: under FSAR, the single agent must decide whether to defer, queue, or preempt, whereas a decomposition-heavy architecture can route the request directly to an idle internal agent. In practice, our evaluation shows this friction has modest impact on task completion (FSAR 93% vs. DHMA 84%) because the governance overhead of multi-agent coordination in DHMA outweighs the parallelism benefit. However, for robots with high internal concurrency demands (e.g., humanoids with 30+ DoF performing manipulation while walking), the single-agent abstraction may require explicit internal scheduling that FSAR does not currently formalize. Tightly coupled manipulation: a worked example. Suppose Robots A and D must jointly carry a large object—each grasping one end and maintaining continuous force coordination to prevent the object from rotating or falling [31]. Under FSAR’s current model, this would require one robot to issue a capability request to the other (e.g., Req(rA,rD,carry.cooperative,σ)Req(r_A,r_D, carry.cooperative,σ)), with Robot D executing under its own local runtime ℛDR_D. This preserves invariants I1 (single-agent coherence) and I2 (local execution ownership), but creates a coordination problem: the two robots need millisecond-level force feedback, not the request-accept-execute lifecycle that governs normal delegation. In practice, invariant I2 is strained because Robot A’s grip adjustments cannot be fully independent of Robot D’s—their physical coupling means that each robot’s “local” execution directly constrains the other’s. Similarly, I4 (monotone recovery escalation) may be violated: if Robot A detects an incipient drop, local recovery (adjusting its own grip) and peer recovery (signaling Robot D to adjust) must happen simultaneously, not sequentially. A realistic mitigation within FSAR would be to model the cooperative carry as a shared execution context with a dedicated tight-loop communication channel that operates below the federation layer, while still attributing the overall task to both robots’ audit trails. Formalizing such shared execution contexts is an important direction for extending FSAR to tightly coupled manipulation domains. 6.4 Heterogeneity, Scalability, and Recovery As embodied fleets become more heterogeneous, FSAR’s distinctions between possession, advertisement, visibility, and delegability become essential—trust configuration complexity can be managed through defaults and runtime modification. The layered recovery model [35, 16, 28] avoids overloading centralized control with locally resolvable failures; if local runtime boundaries are already blurred internally, it becomes much harder to know when a failure has genuinely become fleet-level. Dynamic fleet membership. FSAR’s model supports robots joining and leaving the fleet at runtime through registry operations. When a robot rkr_k joins, it registers its capability advertisements in Γ with initial trust scope capability (the most restrictive delegable level); trust may be promoted to broader scopes (task, session, persistent) based on operator approval or demonstrated performance. When a robot leaves (gracefully or through failure detection), its registry entries are marked Avail=offlineAvail= offline, active delegations are handled through the recovery hierarchy, and any in-flight requests receive a failure(departed) result. The trust model ensures that a newly joined robot cannot immediately receive sensitive delegations without explicit trust establishment, while the recovery model ensures that departures do not create orphaned tasks. For scalability, the architecture supports domain-scoped registries, hierarchical registry structures, caching, and distributed coordination engines, though empirical validation at scale remains future work. 6.5 Continuity with Prior Work and Broader Implications Paper 5 argued that capability ecosystems require contracts and release discipline [11]; Paper 6 extends this into fleets, where version visibility, contract compatibility, and deprecation become coordination concerns. More broadly, robot operating systems may eventually need to be understood as federated fleet operating environments [36] that preserve coherent local runtimes while making the fleet layer the location of governed relations. 6.6 Limitations Several limitations should be noted. First, the evaluation uses a small prototype fleet; production-scale validation is needed. Second, the paper does not address real-time communication constraints in detail. Third, the trust and policy models are relatively simple compared with real-world access control systems. Fourth, emergent coordination—where fleet behavior arises from local interactions without explicit task decomposition—is outside the current scope. Fifth, human supervision interface design is modeled abstractly; effective visualization and cognitive load management are important HCI problems not addressed here. 7 Related Work 7.1 Multi-Robot Coordination and Fleet Systems Multi-robot coordination has been studied extensively [23, 37, 38, 2, 33, 1, 32], with approaches ranging from centralized task allocation to distributed auction-based methods and behavior-based coordination. Parker’s ALLIANCE architecture [28] is a particularly relevant predecessor: it preserves robot-level agency and achieves fault-tolerant cooperation through motivational behaviors rather than explicit inter-agent negotiation. FSAR shares ALLIANCE’s commitment to robot-level coherence but adds formal trust scoping, policy composition, and governed capability registries that ALLIANCE does not address. Behavior trees [39] offer another paradigm that preserves single-agent coherence within each robot through hierarchical task switching; FSAR’s contribution is orthogonal, addressing inter-robot federation rather than intra-robot task organization. Swarm robotics [40] represents an alternative paradigm where coordination emerges from local interaction rules without explicit governance; FSAR differs in requiring attributable, auditable coordination rather than emergent behavior. Recent work has explored LLM-driven multi-robot coordination [41, 42, 43, 44, 45], including modular multi-agent frameworks such as CoELA [26] and embodiment-aware multi-robot operating systems such as EMOS [46]. CoELA exemplifies the decomposition-heavy paradigm that FSAR argues against: each robot hosts separate perception, memory, communication, and action modules as independent LLM agents. EMOS is closer to FSAR in spirit, providing embodiment-aware capability reasoning across heterogeneous robots, though it does not formalize trust scoping or governance invariants. Chen et al. [45] directly compare centralized and decentralized LLM coordination topologies, providing empirical context for FSAR’s federated middle ground. Grounded language models for embodied task planning [47, 48, 49] and embodied reasoning through language-guided planning [50] further extend the coordination design space. Remotely accessible testbeds such as the Robotarium [51] provide reproducible multi-robot evaluation infrastructure; our open-source simulator serves a similar role for governance-focused evaluation. Classical work on multi-robot task allocation (MRTA) focuses on assigning tasks based on capability, cost, and availability [23, 52, 53], with foundational methods for agent coalition formation [30] establishing how agents can dynamically form task-specific coalitions—a precursor to FSAR’s trust-scoped delegation, though without the governance and recovery layers that embodied fleet coordination requires. More recent work considers temporal constraints, heterogeneous capabilities, and online replanning. FSAR differs from classical MRTA in its focus on coordination governance rather than task optimization. While MRTA asks “which robot should do which task,” FSAR asks “under what trust, authority, policy, and recovery conditions should robots coordinate.” FSAR does not replace task allocation; it provides the governance layer within which allocation decisions are made and enforced. 7.2 Multi-Agent Systems The multi-agent systems (MAS) literature provides rich foundations for agent communication, negotiation, coordination protocols, and organizational structures [12, 54, 4, 55, 5, 13]. FSAR’s core claim—that each robot should be treated as a single coherent agent—draws directly on the canonical agent definition of Wooldridge and Jennings [54], applying it at the whole-robot granularity. A recent comprehensive survey on LLM-based autonomous agents [6] identifies coordination, planning, and tool use as key capabilities—precisely the capabilities FSAR governs at the fleet level rather than fragmenting within individual robots. Foundational coordination mechanisms such as the Contract Net Protocol [29], the FIPA Agent Communication Language [25], and organizational methodologies like Gaia [56] and MOISE+ [57] have influenced how agent societies are structured. MOISE+ is particularly relevant as it models organizational roles, groups, and norms—concepts that parallel FSAR’s trust scopes and authority assignments, though at a finer agent granularity. Platforms such as JADE [24] provide practical implementations of these ideas. FSAR draws on MAS concepts but applies them at a different granularity. In MAS, agents are often fine-grained (one per function or role); in FSAR, the agent is the whole robot. This coarser granularity is motivated by embodied systems requirements: physical identity persistence, real-time safety, and locally coherent recovery. FSAR’s trust model relates to trust and reputation work in MAS, but with a focus on embodied contexts where trust scopes are tied to physical capabilities and safety-relevant actions. The comprehensive survey of multi-agent reinforcement learning by Busoniu et al. [58] documents the computational complexity that arises when multiple learning agents must coordinate—exponential state-action spaces, non-stationarity, and credit assignment difficulties—providing empirical motivation for FSAR’s single-agent design: by keeping each robot as one coherent agent, FSAR avoids the combinatorial coordination overhead that multi-agent RL systems must manage. 7.3 Middleware, Discovery, and Runtime Governance Middleware frameworks such as ROS 2 and DDS-based layers [59, 36, 60, 61], and robot operating systems like RoboOS [22], provide multi-robot communication infrastructure. FSAR operates above this level, focusing on governance rather than connectivity. Distributed consensus theory [62] provides the mathematical foundations for agreement protocols in networked agents; FSAR’s policy composition layer draws on similar ideas but applies them to capability-level governance decisions rather than continuous-state consensus. The SROS2 security framework [63] addresses trust management at the ROS 2 communication level through access control policies and encrypted transport; FSAR’s trust model operates at a higher abstraction layer—scoping trust to capability delegation rather than message-level access—but a production implementation could leverage SROS2 as the underlying transport security layer. Work on service discovery, capability sharing [34, 20, 64], and capability-based ontologies such as KnowRob [65] relates to the shared ECM registry, but FSAR treats discovery as governed and delegation as conditional rather than as a neutral directory. Work on runtime governance and safety-oriented control [66, 67, 15], including the autonomic computing vision [68], shares FSAR’s emphasis on layered recovery, though FSAR extends it from single-robot to fleet coordination. Our prior work [21, 69, 11] introduced ECM contracts and release discipline; Paper 6 extends that agenda to fleet-scale coordination where version visibility, contract compatibility, and upgrade awareness become fleet operations concerns. 7.4 Human-Robot Interaction and Supervision Work on supervisory control of robot teams, adjustable autonomy, and shared authority [70, 19, 71, 18, 72, 73] is relevant to FSAR’s hierarchical human supervision model. Foundational work on adjustable autonomy [74] established the principle that human-robot authority should be dynamically reconfigurable rather than fixed at design time—a principle FSAR extends to the fleet level through its hierarchical supervision model (HiH_i for local, HFH_F for fleet-level oversight) with runtime-adjustable supervision density. FSAR’s contribution is the distinction between local and fleet-level supervision with well-defined escalation paths, structuring oversight hierarchically to match fleet coordination structure. 8 Conclusion This paper introduced Federated Single-Agent Robotics (FSAR), a runtime architecture for multi-robot coordination built on the principle that each robot should remain a coherent single embodied agent. Rather than fragmenting robots internally into multi-agent societies to enable fleet coordination, FSAR achieves coordination through federation across intact robot runtimes. We formalized the model and coordination semantics, described a fleet runtime architecture, and evaluated the design against centralized and decomposition-heavy baselines across five scenarios with scaling experiments up to 16 robots. Results provide evidence that federated single-agent coordination preserves task completion while improving governance locality, recovery containment, and audit attributability. The central finding is that multi-robot coordination does not require intra-robot multi-agent fragmentation. Fleet coordination can emerge from federation across coherent robot runtimes rather than from decomposition within them. More broadly, future embodied operating systems could benefit from being understood as federated fleet operating environments. The federated fleet setting exposes evaluation dimensions not captured by current benchmarks—including cross-robot authority assignment, fleet-level recovery containment, and hierarchical human oversight—whose development is the subject of our forthcoming work. Appendix A Self-Contained Foundations from Papers 2–4 Papers 2–4 in this series are available as arXiv preprints [8, 9, 10]. To ensure Paper 6 is self-contained, we provide the key definitions inherited from those papers that are used in the present work. Policy scope and composition (Paper 2). Each robot rir_i maintains a local policy scope PiP_i that governs which capabilities may be activated, under what conditions, and with what constraints. A policy PiP_i maps capability–context pairs to admission decisions: Pi(e,σ)∈allow,deny,reviewP_i(e,σ)∈\ allow, deny, review\. Paper 6 extends this to cross-robot policy composition: when rir_i requests capability e from rjr_j, both PiP_i (requester policy) and PjP_j (executor policy) must jointly admit the action, formalized as Π(Pi,Pj,e,σ)≠deny (P_i,P_j,e,σ)≠ deny (invariant I3). Recovery levels and degradation (Paper 3). Recovery in a single-agent runtime follows a four-level hierarchy: (1) local retry within the executing runtime, (2) peer-assisted recovery via capability delegation, (3) fleet-level reassignment, and (4) human escalation. Each level has a budget (tmax,nmax)(t_ ,n_ ) constraining retry duration and count before escalation. Paper 6 preserves this hierarchy and adds the monotone escalation invariant (I4): recovery must proceed outward through levels without skipping. Human oversight layers (Paper 4). Each robot has a local human supervisor HiH_i responsible for safety overrides, policy exceptions, and anomaly review at the single-robot level. Paper 6 introduces fleet-level supervision HFH_F and defines the hierarchical oversight structure Λ=(Hi,HF) =(\H_i\,H_F), with escalation from local to fleet supervision triggered by cross-robot dependencies that exceed local scope. References [1] Yara Rizk, Mariette Awad, and Edward W Tunstel. Cooperative heterogeneous multi-robot systems: A survey. ACM Computing Surveys, 52(2):1–31, 2019. [2] Zhi Yan, Nicolas Jouandeau, and Arab Ali Cherif. A survey and analysis of multi-robot coordination. International Journal of Advanced Robotic Systems, 10(12):399, 2013. [3] Rodney A Brooks. A robust layered control system for a mobile robot. IEEE Journal on Robotics and Automation, 2(1):14–23, 1986. [4] Ali Dorri, Salil S Kanhere, and Raja Jurdak. Multi-agent systems: A survey. IEEE Access, 6:28573–28593, 2018. [5] Bryan Horling and Victor Lesser. A survey of multi-agent organizational paradigms. The Knowledge Engineering Review, 19(4):281–316, 2004. [6] Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhenhua Wei, and Ji-Rong Wen. A survey on large language model based autonomous agents. Frontiers of Computer Science, 18(6):186345, 2024. [7] Xue Qin, Simin Luan, John See, Cong Yang, and Zhijun Li. AEROS: Agent execution runtime operating system for embodied robots. arXiv preprint arXiv:2604.07039, 2026. [8] Xue Qin, Simin Luan, John See, Cong Yang, and Zhijun Li. Learning without losing identity: Capability evolution for embodied agents. arXiv preprint arXiv:2604.07799, 2026. [9] Xue Qin, Simin Luan, John See, Cong Yang, and Zhijun Li. Harnessing embodied agents: Runtime governance for policy-constrained execution. arXiv preprint arXiv:2604.07833, 2026. [10] Xue Qin, Simin Luan, John See, Cong Yang, and Zhijun Li. Governed capability evolution for embodied agents. arXiv preprint arXiv:2604.08059, 2026. [11] Xue Qin, Simin Luan, John See, Cong Yang, and Zhijun Li. ECM contracts: Contract-aware, versioned, and governable capability interfaces for embodied agents. Under review, 2026. [12] Michael Wooldridge. An Introduction to Multi-Agent Systems. John Wiley & Sons, 2nd edition, 2009. [13] Nicholas R Jennings, Katia Sycara, and Michael Wooldridge. A roadmap of agent research and development. In Autonomous Agents and Multi-Agent Systems, volume 1, pages 7–38, 1998. [14] Tuomas W Sandholm. Distributed rational decision making. In Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence, pages 201–258. MIT Press, 1999. [15] Anis Koubâa, Amine Allouch, and Maram Alajlan. Blockchain-based trust management for multi-robot systems. Robotics and Autonomous Systems, 172:104594, 2024. [16] Maria L Visinsky, Joseph R Cavallaro, and Ian D Walker. A layered dynamic fault tolerance architecture for robots. Robotics and Autonomous Systems, 12(2):129–141, 1994. [17] Jennifer Carlson and Robin R Murphy. How UGVs physically fail in the field. IEEE Transactions on Robotics, 21(3):423–437, 2005. [18] Raja Parasuraman, Thomas B Sheridan, and Christopher D Wickens. A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics—Part A, 30(3):286–297, 2000. [19] Thomas B Sheridan. Human-robot interaction: Status and challenges. Human Factors, 58(4):525–532, 2016. [20] Mehdi Dastani, Natasha Alechina, and Brian Logan. Programming multi-agent systems. In The Knowledge Engineering Review, volume 20, pages 151–164, 2005. [21] Bertrand Meyer. Applying “design by contract”. In Computer, volume 25, pages 40–51, 1992. [22] Zhenyang Tan et al. RoboOS: A hierarchical embodied framework for cross-embodiment and multi-agent collaboration. arXiv preprint arXiv:2504.01234, 2025. [23] Brian P Gerkey and Maja J Matarić. A formal analysis and taxonomy of task allocation in multi-robot systems. International Journal of Robotics Research, 23(9):939–954, 2004. [24] Fabio Bellifemine, Giovanni Caire, and Dominic Greenwood. Developing Multi-Agent Systems with JADE. Wiley, 2007. [25] Foundation for Intelligent Physical Agents. FIPA ACL message structure specification. Technical Report SC00061G, FIPA, 2002. [26] Hongxin Zhang, Weihua Du, Jiaming Shan, Qinhong Zhou, Yilun Du, Joshua B Tenenbaum, Tianmin Shu, and Chuang Gan. Building cooperative embodied agents modularly with large language models. In International Conference on Learning Representations (ICLR), 2024. [27] Ceyao Zhang, Kaijie Yang, Siyi Hu, Zihao Wang, Guanghe Li, Yihang Sun, Cheng Zhang, Zhaowei Zhang, Anji Liu, Song-Chun Zhu, Xiaojun Chang, Junge Zhang, Feng Yin, Yitao Liang, and Yaodong Yang. ProAgent: Building proactive cooperative agents with large language models. In AAAI Conference on Artificial Intelligence, volume 38, pages 17591–17599, 2024. [28] Lynne E Parker. ALLIANCE: An architecture for fault tolerant multi-robot cooperation. IEEE Transactions on Robotics and Automation, 14(2):220–240, 1998. [29] Reid G Smith. The contract net protocol: High-level communication and control in a distributed problem solver. IEEE Transactions on Computers, C-29(12):1104–1113, 1980. [30] Onn Shehory and Sarit Kraus. Methods for task allocation via agent coalition formation. Artificial Intelligence, 101(1–2):165–200, 1998. [31] Elio Tuci, Muhanad H M Alkilabi, and Otar Akanyeti. Cooperative object transport in multi-robot systems: A review of the state-of-the-art. Frontiers in Robotics and AI, 5:59, 2018. [32] Guni Sharon, Roni Stern, Ariel Felner, and Nathan R Sturtevant. Conflict-based search for optimal multi-agent pathfinding. Artificial Intelligence, 219:40–66, 2015. [33] M Bernardine Dias, Robert Zlot, Nidhi Kalra, and Anthony Stentz. Market-based multirobot coordination: A survey and analysis. In Proceedings of the IEEE, volume 94, pages 1257–1270, 2006. [34] Robert Michael Zlot. An auction-based approach to complex task allocation for multirobot teams. PhD thesis, Carnegie Mellon University, 2006. [35] Anders Lyhne Christensen, Rehan O’Grady, and Marco Dorigo. Fault tolerance in autonomous robots: A survey. Swarm Intelligence, 2(1):43–62, 2008. [36] Steven Macenski, Tully Foote, Brian Gerkey, Chris Lalancette, and William Woodall. Robot operating system 2: Design, architecture, and uses in the wild. Science Robotics, 7(66):eabm6074, 2022. [37] Alaa Khamis, Ahmed Hussein, and Ahmed Elmogy. Multi-robot task allocation: A review of the state-of-the-art. Cooperative Robots and Sensor Networks, 604:31–51, 2015. [38] Lynne E Parker. Multiple mobile robot systems. Springer Handbook of Robotics, pages 921–941, 2008. [39] Michele Colledanchise and Petter Ögren. Behavior Trees in Robotics and AI: An Introduction. CRC Press, 2018. [40] Manuele Brambilla, Eliseo Ferrante, Mauro Birattari, and Marco Dorigo. Swarm robotics: a review from the swarm engineering perspective. Swarm Intelligence, 7(1):1–41, 2013. [41] Yanda Li et al. Large language models for multi-robot systems: A survey. arXiv preprint arXiv:2502.10782, 2025. [42] Zhangli Liu, Yanda Hu, Shanghang Zhang, Hongjie Guo, et al. COHERENT: Collaboration of heterogeneous multi-robot system with large language models. In IEEE International Conference on Robotics and Automation (ICRA), pages 1–8, 2024. [43] Shyam Sundar Kannan, Vishnunandan L N Venkatesh, and Byung-Cheol Min. SMART-LLM: Smart multi-agent robot task planning using large language models. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 7394–7401, 2024. [44] Zhao Mandi, Shreeya Jain, and Shuran Song. RoCo: Dialectic multi-robot collaboration with large language models. In IEEE International Conference on Robotics and Automation (ICRA), pages 1–8, 2024. [45] Yongchao Chen, Jacob Arkin, Yang Zhang, Nicholas Roy, and Chuchu Fan. Scalable multi-robot collaboration with large language models: Centralized or decentralized systems? In IEEE International Conference on Robotics and Automation (ICRA), pages 1–8, 2024. [46] Junting Chen, Checheng Li, Xiang Xu, et al. EMOS: Embodiment-aware heterogeneous multi-robot operating system with LLM agents. In International Conference on Learning Representations (ICLR), 2025. [47] Michael Ahn et al. Do as i can, not as i say: Grounding language in robotic affordances. In Conference on Robot Learning (CoRL), 2022. [48] Anthony Brohan, Noah Brown, Justice Carbajal, et al. RT-1: Robotics transformer for real-world control at scale. In Robotics: Science and Systems (RSS), 2023. [49] Sai Vemprala, Rogerio Bonatti, Arthur Buber, and Ashish Kapoor. ChatGPT for robotics: Design principles and model abilities. IEEE Access, 12:1–16, 2024. [50] Wenlong Huang, Fei Xia, Ted Xiao, Harris Chan, Jacky Liang, Pete Florence, Andy Zeng, Jonathan Tompson, Igor Mordatch, Yevgen Chebotar, et al. Inner monologue: Embodied reasoning through planning with language models. In Conference on Robot Learning (CoRL), pages 1769–1782, 2022. [51] Daniel Pickem, Paul Glotfelter, Li Wang, Mark Mote, Aaron Ames, Eric Feron, and Magnus Egerstedt. The Robotarium: A remotely accessible swarm robotics research testbed. In IEEE International Conference on Robotics and Automation (ICRA), pages 1699–1706, 2017. [52] G Ayorkor Korsah, Anthony Stentz, and M Bernardine Dias. A comprehensive taxonomy for multi-robot task allocation. International Journal of Robotics Research, 32(12):1495–1512, 2013. [53] Hamza Chakraa, Frank Guerin, Emmanuel Leclercq, and Guy Bessonnet. Optimization techniques for multi-robot task allocation problems: Review on the state-of-the-art. Robotics and Autonomous Systems, 168:104492, 2023. [54] Michael Wooldridge and Nicholas R Jennings. Intelligent agents: Theory and practice. The Knowledge Engineering Review, 10(2):115–152, 1995. [55] Peter Stone and Manuela Veloso. Multiagent systems: A survey from a machine learning perspective. In Autonomous Robots, volume 8, pages 345–383, 2000. [56] Michael Wooldridge, Nicholas R Jennings, and David Kinny. The gaia methodology for agent-oriented analysis and design. Autonomous Agents and Multi-Agent Systems, 3(3):285–312, 2000. [57] Jomi Fred Hübner, Jaime Simão Sichman, and Olivier Boissier. Developing organised multiagent systems using the MOISE+ model: programming issues at the system and agent levels. International Journal of Agent-Oriented Software Engineering, 1(3/4):370–395, 2007. [58] Lucian Busoniu, Robert Babuska, and Bart De Schutter. A comprehensive survey of multiagent reinforcement learning. IEEE Transactions on Systems, Man, and Cybernetics, Part C, 38(2):156–172, 2008. [59] Morgan Quigley, Ken Conley, Brian Gerkey, Josh Faust, Tully Foote, Jeremy Leibs, Rob Wheeler, and Andrew Y Ng. ROS: An open-source robot operating system. In ICRA Workshop on Open Source Software, volume 3, page 5, 2009. [60] Object Management Group. The real-time publish-subscribe wire protocol: DDS interoperability wire protocol specification. OMG Document, 2009. [61] Davide Brugali and Patrizia Scandurra. Component-based robotic engineering (part I): Reusable building blocks. In IEEE Robotics & Automation Magazine, volume 16, pages 84–96, 2009. [62] Reza Olfati-Saber, J Alexander Fax, and Richard M Murray. Consensus and cooperation in networked multi-agent systems. Proceedings of the IEEE, 95(1):215–233, 2007. [63] Ruffin White, Gianluca Caiazza, Henrik Christensen, and Agostino Cortesi. SROS2: Usable cyber security tools for ROS 2. IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 5068–5075, 2019. [64] Steven Macenski, Francisco Martin, Ruffin White, and Jonatan Ginés Clavero. Navigation2: A scalable and extensible navigation framework. IEEE Robotics and Automation Letters, 2023. [65] Moritz Tenorth and Michael Beetz. KnowRob: A knowledge processing infrastructure for cognition-enabled robots. International Journal of Robotics Research, 32(5):566–590, 2013. [66] Michael Fisher, Louise Dennis, and Matt Webster. Verifying autonomous systems. Communications of the ACM, 56(9):84–93, 2013. [67] Matt Luckcuck, Marie Farrell, Louise A Dennis, Clare Dixon, and Michael Fisher. Formal specification and verification of autonomous robotic systems: A survey. In ACM Computing Surveys, volume 52, pages 1–41, 2019. [68] Jeffrey O Kephart and David M Chess. The vision of autonomic computing. IEEE Computer, 36(1):41–50, 2003. [69] Tomáš Bureš, Petr Hnětynka, and František Plášil. SOFA 2.0: Balancing advanced features in a hierarchical component model. International Conference on Software Engineering and Formal Methods, pages 40–48, 2006. [70] Michael A Goodrich and Alan C Schultz. Human-robot interaction: A survey. Foundations and Trends in Human-Computer Interaction, 1(3):203–275, 2007. [71] Jessie Y C Chen, Michael J Barnes, and Michelle Harper-Sciarini. Supervisory control of multiple robots: Human-performance issues and user-interface design. IEEE Transactions on Systems, Man, and Cybernetics, Part C, 41(4):435–454, 2011. [72] Jenay M Beer, Arthur D Fisk, and Wendy A Rogers. Toward a framework for levels of robot autonomy in human-robot interaction. In Journal of Human-Robot Interaction, volume 3, pages 74–99, 2014. [73] Mica R Endsley. Toward a theory of situation awareness in dynamic systems. Human Factors, 37(1):32–64, 1995. [74] Gregory A Dorais, R Peter Bonasso, David Kortenkamp, Barney Pell, and Debra Schreckenghost. Adjustable autonomy for human-centered autonomous systems. In Working Notes of the IJCAI Workshop on Adjustable Autonomy Systems, pages 16–35, 1999.