Source-linked AI summary
FL-MAESTRO: Multi-Agent LLM Orchestration for Resource-Constrained Federated Learning
Jiajun Wu, Zirui Wang, Jiayu Zhou, Qiang Ye, Steve Drew
TL;DR
Federated learning on volatile edge networks requires joint runtime decisions over topology, resources, and aggregation, but prior approaches typically handle these dimensions separately or at design time. FL-MAESTRO uses three specialist LLM agents, a coordinator, and a non-LLM feasibility check to make and validate the joint decision each round. On a non-IID benchmark, it matches the strongest energy-aware baseline’s accuracy while reducing wasted round energy from over a third to near zero.
Problem
Prior FL methods and agentic systems do not jointly orchestrate topology, resources, and aggregation at runtime while accounting for predicted client failures.
Method
FL-MAESTRO coordinates three specialist LLM agents, synthesizes their analyses, validates feasibility externally, and uses predicted-failure information to exclude clients likely to fail.
Results
FL-MAESTRO matches the strongest energy-aware baseline’s accuracy while cutting wasted round energy from over a third to near zero.
Takeaways & Limitations
Natural-text profiles and an open-weight backend support operation across heterogeneous device classes without cloud-LLM dependency or per-class energy models.
Abstract
from arXiv · showhide
In Federated Learning (FL), the communication topology is a runtime variable rather than a fixed design choice, since links and edge devices drop in and out during training. Each round, the server must commit three coupled decisions, namely the communication topology, per-client resource allocation, and the aggregation rule for combining local updates. Recent agentic systems have begun bringing large language models (LLM) into FL, but the existing line of work either operates at setup time or handles a single runtime dimension such as client selection. We propose FL-MAESTRO, a multi-agent orchestrator that makes the joint runtime FL decision directly through three specialist LLM agents, one per decision dimension. A coordinator combines their analyses into a single decision, and a non-LLM feasibility check confirms it before the round executes. Because the orchestrator consumes the server's predicted-failure list, it withholds clients whose updates would never be aggregated, which removes the dominant source of wasted round energy in classical FL on volatile edge networks. Because client state is read as natural-text profiles, the same orchestrator extends to heterogeneous device classes without per-class energy models. On a non-IID CIFAR-10 benchmark, FL-MAESTRO matches the accuracy of the strongest energy-aware baseline while cutting wasted round energy from over a third to near zero. Code is available at https://github.com/denoslab/FL-MAESTRO.
I. INTRODUCTION
FL-MAESTRO addresses runtime volatility in federated learning by jointly selecting topology, resources, and aggregation through coordinated specialist agents. It uses predicted-failure information and feasibility validation to reduce wasted energy while preserving accuracy.
- Dynamic edge conditions couple communication topology, resource allocation, and aggregation decisions that traditional FL methods do not jointly optimize.Clients and links change during training, so topology depends on which clients survive and on the other decisions made in the same round.
- Predicted-failure filtering withholds borderline-battery clients whose updates would not be aggregated, avoiding their wasted training and communication energy.The server computes predicted failures from client state, and the orchestrator consumes that signal directly.
- FL-MAESTRO makes the joint runtime decision through specialist agents for topology, aggregation, and resources, coordinated into one round-level decision.A non-LLM feasibility check verifies the synthesized decision before execution.
- Natural-text client profiles let the orchestrator span heterogeneous device classes without requiring per-class energy models.The system is also designed to run on a self-hosted open-weight LLM rather than requiring cloud connectivity.
- On a non-IID FL benchmark, FL-MAESTRO reduces wasted round energy from over a third to near zero while matching the strongest energy-aware baseline’s accuracy.An ablation suggests that lightweight agentic coordination is sufficient for the task.
II. RELATED WORK
Prior FL methods generally adapt one decision dimension while fixing the others, whereas runtime multi-agent work has not resolved joint orchestration.
- Classical FL methods fix star topology and uniform local-epoch budgets while varying aggregation weighting.
- Resource-aware and selection-aware methods adapt client epochs or selection but retain a fixed communication topology.
- Design-time multiagent systems and single-axis runtime agents leave the operational need for per-round joint orchestration open.
B. LLM Agents for FL Decisions
FL-MAESTRO targets runtime FL orchestration by jointly deciding topology, resources, and aggregation rather than optimizing a single axis. Its formulation uses dynamic client eligibility and coupled per-round decisions under changing device and network conditions.
- FL-MAESTRO addresses runtime joint orchestration across topology, resources, and aggregation, unlike prior LLM-FL systems focused on setup or selection.
- Each round selects an active subset from clients outside the predicted-failure list and commits topology, per-client resources, and aggregation weighting.
- The predicted-failure list flags clients expected to fail mid-round under unmodified FedAvg, enabling their exclusion to prevent wasted energy.
- Topology choices include star, hierarchical, ring, and P2P configurations, with communication cost depending on the selected topology and compression.
- Resource allocations specify local epochs, allocated bandwidth, and per-client compression, while aggregation supports uniform, data-size, loss-weighted, and explicit weights.
C. Coupling Constraints
The three runtime decisions are coupled through per-client energy and feasibility constraints. The resulting joint decision space is too large for exhaustive search.
- A client’s per-round energy cost combines computation and communication terms, linking resource allocation and topology choices through shared physical constraints.
- Compute energy scales with local epochs and inversely with client compute capability, while communication energy depends on communication cost, compression, and allocated bandwidth.
- The feasibility constraint compares each client’s energy cost with its normalized remaining battery because both are expressed as fractions of a full battery.
- The orchestrator must return a feasible joint decision over participants, topology, resources, and aggregation while respecting these constraints.
- The per-round decision space has cardinality O(2^|C\F|·|T|·Q·∏i|Ri|·4), making exhaustive search impractical.
A. Architecture Overview
FL-MAESTRO coordinates three specialist LLM agents to make coupled runtime FL decisions from the current federated-learning state.
- Each specialist agent receives the current FL state s(r), containing client profiles, global model state, remaining budgets, and prior-round decisions.
B. Specialist Agents
The specialist agents propose and revise the three decision dimensions using domain tools, after which a coordinator synthesizes and validates the joint decision.
- Specialist Agents: The TopologyAgent proposes a communication topology and configuration while reporting its communication cost.
- Specialist Agents: The AggregationAgent selects among four aggregation schemes and can configure hierarchical aggregator-to-child mappings.
- Specialist Agents: Agents begin with independent proposals and revise them using the other agents’ prior decisions until agreement or the analysis limit is reached.
- Specialist Agents: The coordinator synthesizes the final analyses, and a validator enforces eligibility constraints before returning the validated decision.
- Specialist Agents: The ResourceAgent proposes local epochs, compression, and bandwidth, then checks feasibility with energy-cost tools.
- Specialist Agents: Shared tools evaluate communication cost, energy cost, label diversity, and battery feasibility across the agents.
C. Coordinator and Validator
The coordinator synthesizes typed analyses from specialist agents into a joint FL decision, while a non-LLM validator checks and repairs feasibility before execution. The evaluation uses simulated heterogeneous CIFAR-10 settings, explicit metrics, baselines, and ablations.
- Coordinator and Validator: The Coordinator emits a typed JSON decision after synthesizing the three specialists’ constraint analyses.The decision includes topology, local epochs, client resources, and aggregation weights.
- Coordinator and Validator: The Validator enforces battery eligibility, aggregator capability, weight normalization within 10^-6, and local epochs in [1, 20].Infeasible decisions are clipped to the feasibility boundary rather than causing runtime crashes.
- Coordinator and Validator: Each round allows up to Dmax ∈ {2, 3} coordination iterations, with specialists revising proposals after seeing the other dimensions.This exchange enforces coupling without relying on a single global proposer.
- Evaluation setup: The study evaluates CIFAR-10 with Dirichlet non-IID partitioning at α ∈ {0.1, 0.3}, up to 50 rounds, and a 545,098-parameter CNN.Early stopping uses three rounds of patience and a minimum accuracy delta of 0.001.
- Evaluation setup: Two heterogeneous scenarios use N = 30 clients with varied battery, bandwidth, and compute, while the extreme scenario has α = 0.1 and predominantly one to two classes per client.The hard scenario uses α = 0.3 and forces 12 of 30 clients into a low-battery range [0.12, 0.20].
- Evaluation setup: Ablations compare a single generalist, independent specialists, coupled specialists, and added failure probing or negotiation.Results come from simulation on a single desktop workstation; only LLM inference uses dedicated hardware.
- Evaluation setup: The evaluation reports best test accuracy, wasted energy, failure rate, communication bytes, and average analysis rounds per FL round.Baselines include FedAvg, FedProx, FedNova, q-FedAvg, FedLE, ResourceAware, PipelineIndependent, and RuleBasedJoint.
B. Main Results
FL-MAESTRO leads on accuracy and energy in the reported head-to-head evaluation while preserving a zero-waste alternative on the efficiency frontier. Its server-side asynchronous coordination fits within the inter-round window and converges quickly.
- Main results: FLM-Coupled tops accuracy on both scenarios while holding wasted round energy to a few percent.FLM-Independent achieves exact zero waste and zero failures with a small accuracy gap.
- Main results: Classical baselines cluster an order of magnitude higher on wasted energy because they admit borderline-battery clients.The resource-aware heuristic closes part of the gap but trails the joint-orchestration variants.
- Main results: Coordination converges in 2.0 analysis rounds per FL round on average across all seeds and scenarios.Orchestration uses a 20–90 second per-round window across the two backends.
- Main results: Orchestration runs entirely server-side, adding no client-side computation or communication.It operates asynchronously between rounds, where client upload and server aggregation dominate the wall-clock at N = 30.
C. Robustness across seeds and backends
The reported accuracy ordering is directionally consistent across three seeds and reproduces with Qwen3.5-35b, while added negotiation or failure probing provides no measurable accuracy gain on this testbed.
- Robustness across seeds and backends: The extreme-scenario accuracy lead is sign-consistent across three seeds and reproduces on the open-weight Qwen3.5-35b backend.A paired one-sided t-test gives t = 0.32 (p = 0.39), so the authors report directional consistency rather than statistical significance.
- Robustness across seeds and backends: Qwen3.5-35b staying close to GPT-4.1-mini suggests smaller open-weight models can run FL-MAESTRO at cloud-LLM performance.The qualitative ordering of FLM-Coupled, FLM-Independent, and FLM-Single is preserved across both backends.
- Minimal coordination: Adding negotiation or multi-threshold failure probing yields no measurable accuracy gain on this testbed.The paper attributes the limited benefit to typed JSON actions, external feasibility validation, and concrete tool outputs.
- Minimal coordination: Multi-threshold failure probing directionally trades accuracy for safety, but the authors treat this as a Pareto shift rather than an established trade-off given N = 3.The authors caution against over-attributing the result on this controlled testbed.
E. Heterogeneous-schema deployability
FL-MAESTRO targets heterogeneous-schema deployments by reading client profiles as natural-text records and composing feasibility checks across device classes. This is presented as an architectural advantage, while larger-scale deployment remains future work.
- Heterogeneous-schema deployability: Natural-text client profiles let FL-MAESTRO compose feasibility checks across device classes without per-class energy predictors or failure taxonomies.Adding a device class becomes a prompt update rather than re-engineering the orchestration logic.
- Heterogeneous-schema deployability: The heterogeneous-schema advantage is analyzed architecturally but not evaluated in the controlled testbed.The testbed uses a single profile schema for all clients.
- Heterogeneous-schema deployability: Extending FL-MAESTRO beyond the 30-client controlled testbed remains future work.The authors identify prompt-context budget as a likely constraint for direct application to thousands of clients.