Say the Mission, Execute the Swarm: Agent-Enhanced LLM Reasoning in the Web-of-Drones

Abstract: LLMs are increasingly explored as high-level reasoning engines for cyber-physical systems, yet their application to real-time UAV swarm management remains challenging due to heterogeneous interfaces, limited grounding, and the need for long-running closed-loop execution. This paper presents a mission-agnostic, agent-enhanced LLM framework for UAV swarm control, where users express mission objectives in natural language and the system autonomously executes them through grounded, real-time interactions. The proposed architecture combines an LLM-based Agent Core with a Model Context Protocol (MCP) gateway and a Web-of-Drones abstraction based on W3C Web of Things (WoT) standards. By exposing drones, sensors, and services as standardized WoT Things, the framework enables structured tool-based interaction, continuous state observation, and safe actuation without relying on code generation. We evaluate the framework using ArduPilot-based simulation across four swarm missions and six state-of-the-art LLMs. Results show that, despite strong reasoning abilities, current general-purpose LLMs still struggle to achieve reliable execution - even for simple swarm tasks - when operating without explicit grounding and execution support. Task-specific planning tools and runtime guardrails substantially improve robustness, while token consumption alone is not indicative of execution quality or reliability.

• The paper introduces a code-free architecture that combines W3C Web of Things, MCP tool calls, telemetry feedback, and runtime guardrails to let LLMs manage UAV swarms in closed loop.
• The evaluation shows GLM achieved the strongest overall results, including 100% area-coverage success with a planner and 90% smart-irrigation success, while model performance varied substantially by mission and tool support.
• The findings show that structured execution and termination safety matter more than token usage, but simulation-only testing, empirically derived guardrails, and experiments limited to 10 drones leave real-world scalability unresolved.

Overview and motivation

This paper, by Iannoli et al. of the University of Bologna (accepted at IEEE WoWMoM 2026), investigates whether LLMs can autonomously manage UAV swarms in real time from natural-language mission objectives. The authors identify three obstacles that limit prior work: heterogeneous drone control surfaces that fragment interoperability, the inability of standalone prompting to sustain long-running closed-loop tasks, and the safety risks introduced by non-deterministic LLM behavior in physical systems. Most existing approaches rely on static code generation at mission initialization; this work instead proposes a code-free architecture in which the LLM orchestrates swarm behavior entirely through structured tool invocations over a standardized device abstraction.

The paper addresses two research questions: how LLM-based techniques can be exploited for real-time UAV swarm management from natural-language objectives, and how mature current LLM-based agents are for mission-critical drone applications.

Architecture

The framework comprises three subsystems organized around a W3C Web of Things (WoT) abstraction and a Model Context Protocol (MCP) gateway:

• WoT ecosystem: drones, sensors, abstract mission state, and services are uniformly exposed as WoT Things described by machine-readable Thing Descriptions (TDs), with properties, actions, and events as affordances. Three Thing classes are supported: Physical Things (drones, sensors), Virtual Things (mission state), and Service Things (planners, external APIs). A Thing Description Directory (implemented with Zion) supports discovery via metadata and JSONPath queries, enabling late binding without hard-coded identifiers.
• MCP-based WoT Gateway: the exclusive bridge between the agent and the WoT layer, exposing core tools for resource discovery and affordance-mediated interaction. It enforces a strictly WoT-directed execution model.
• Agent: composed of an LLM, an Agent Core, and an MCP client. The Agent Core maintains a persistent core prompt encoding execution invariants (mandatory state verification, safe termination conditions, exclusive MCP-mediated interaction), conditionally activated runtime guardrail prompts derived empirically from observed failure patterns, and optional helper tools that wrap recurring execution patterns such as synchronization and completion verification—without bypassing the WoT-directed model.

Three novelties distinguish the design: hardware-independent interoperability through WoT (N1), real-time system-state retrieval via MCP-mediated TDs (N2), and autonomous closed-loop reasoning in which telemetry and event feedback are appended to the context and incorporated into subsequent reasoning steps across multiple tool-calling phases, without human intervention (N3). Runtime guardrails trigger on conditions such as inferred completion without state verification, stalled non-progressing tool calls, or attempted termination while drones remain armed or airborne. This mechanism improves robustness without embedding task-specific control logic in code—an important property, since guardrails constrain reasoning rather than dictating control policy.

Implementation

The system is fully containerized. Each UAV is exposed as a WoT Thing by a dedicated Servient that forwards commands via MAVProxy to ArduPilot SITL instances over MAVLink, chosen for vendor neutrality and well-defined semantics. Action inputs are validated at the Servient boundary (e.g., takeoff requires strictly positive altitude; GUIDED mode is set before takeoff). The MCP gateway is a NestJS server with Zod-validated schemas, separating action invocation from completion verification to support asynchronous long-running operations. The Agent is implemented in Python with LangChain. Prompts and example TDs are released publicly on Zenodo.

Experimental evaluation

Experiments use 10 multirotor UAVs under stable conditions, with each (model, experiment) configuration repeated over 10 runs; non-determinism arises exclusively from LLM inference. Six function-calling-capable LLMs are compared: GPT v5.2, DeepSeek v3.2, GLM v4.7, Grok v4.1 Fast, Claude Haiku v4.5, and Qwen3 8B. Four missions are evaluated: area coverage with a task-specific planning tool (plan_area_coverage, which computes grid-cell altitudes from camera FOV geometry), area coverage without the tool (ablation), formation control with deliberately adversarial slot assignment maximizing displacement and enforcing 5 m spacing to stress collision avoidance, and smart irrigation requiring range-constrained sensor collection plus a deterministic decision rule ($\overline{H} \le 57\%$ or $\overline{T} \ge 30^\circ$C). Success criteria are binary and include safe termination (all participating drones disarmed, mode in {LAND, RTL}) and zero collisions. Token accounting uses provider-reported usage metadata per iteration, capturing cumulative long-horizon reasoning cost.

Key results

Area coverage. With the planner enabled, GLM achieves a 100% success rate, followed by Grok at 70% and DS at 60%; GPT reaches only 20%, frequently failing final landing/disarming despite reaching waypoints. In the no-tool ablation—with a weaker success criterion—GPT attains 100%, GLM 70%, and DS 60%, while Grok and Qwen fail entirely (0%). Notably, GPT performs better without the planner, exhibiting error-prone interactions with it; GLM and Claude lose 30 and 10 percentage points respectively when it is removed. This contradicts the assumption that task-specific tools uniformly help: their benefit is model-dependent. Successful with-tool runs are generally faster (GLM: ~250 s vs. ~351 s without), though Claude is an exception. A pronounced token spike in the first ~5% of no-tool executions indicates models engaging in intensive internal planning to compensate for missing external support.

Formation control. GPT leads at 60% success, GLM at 50%, DS and Qwen at 20%; Grok and Claude achieve 0%. Collision counts reveal a safety–performance trade-off: GPT records three collisions versus two for GLM, while Qwen collides substantially more than all others. Grok and Claude rarely collide—their failures stem from incomplete termination rather than safety violations. Across successful runs, GLM matches GPT's performance with substantially fewer tokens and fewer collisions, making it the more cost-effective and safer choice.

Smart irrigation. Under full-success criteria, GLM reaches 90%, Grok 50%, GPT 40%, DS 30%; Claude and Qwen fail. Failure-mode decomposition is informative: GLM collects all readings and applies the decision rule correctly in 100% of runs, failing only on premature termination; Grok's dominant failure is data collection (70% collection and decision correctness); GPT and DS both collect readings in 90% of runs but show only 40% decision correctness, with opposite biases—GPT over-triggers irrigation (false positives) while DS under-triggers (false negatives). Irrigation is the most token-expensive task, and GPT incurs markedly higher token usage than GLM despite lower success.

Cross-cutting findings

Three conclusions emerge consistently. First, grounding LLM reasoning through typed tools and WoT abstractions is essential for reliable long-horizon execution; even strong reasoners fail simple swarm tasks without explicit execution support. Second, smaller or latency-optimized models (Qwen 8B, Grok Fast) cannot sustain multi-step missions without additional scaffolding such as helper tools. Third—and perhaps most counterintuitively—token consumption is not predictive of mission success or reliability: some models consume fewer tokens with the planner enabled than without, and GLM's superior success rates come with lower token overhead than GPT's. Execution robustness appears to depend on reasoning structure and feedback integration rather than model verbosity or cost.

Limitations and open questions

The authors acknowledge several constraints. All experiments are conducted in ArduPilot SITL simulation under clear, stable weather; real-world flight validation, communication degradation, and dynamic environmental disturbances remain untested. The irrigation decision rule is deliberately simplistic—a threshold disjunction rather than an agronomic model—so results speak to coordinated data collection, not domain-realistic decision quality. Guardrails were derived empirically from observed failures rather than designed systematically, raising questions about coverage of unobserved failure modes. Success criteria conflate task achievement with safe termination, and the "early-exit" category shows several models achieve objectives without satisfying completion constraints, suggesting termination discipline is a distinct open problem. Finally, whether the closed-loop approach scales beyond 10 drones, or generalizes to missions not represented in the tool set, is left unexamined.

Conclusion

This paper demonstrates that natural-language intent can be translated into dependable swarm behavior only when LLM reasoning is grounded in standardized device abstractions (W3C WoT), mediated through typed MCP tool calls, and constrained by runtime guardrails and helper tools. The empirical comparison of six frontier and lightweight models across four missions provides concrete evidence that current general-purpose LLMs remain unreliable for autonomous swarm control without an explicit execution layer, and that token cost is a poor proxy for capability. The central open question the work leaves is how to make such grounding and guardrailing systematic rather than empirically derived, so that reliability does not depend on per-model tuning of the surrounding execution scaffold.