TACOS: Task Agnostic Coordinator of a Multi-Drone System

Highlights

What are the main findings?

• An LLM-based framework that enables natural language control of multi-UAV systems.
• Separating reasoning and execution improves scalability and robustness in UAV swarms.

What are the implications of the main findings?

• TACOS allows a single operator to seamlessly transition from direct drone-level commands to high-level swarm behaviors, bridging semantic reasoning and low-latency UAV control through structured API execution.
• The proposed Coordinator–Supervisor architecture achieves higher success rates and better parallelization than monolithic or non-reasoning baselines. It supports continuous interaction and can react to dynamic events that affect the swarm or the environment.

Abstract

When a single pilot is responsible for managing a multi-drone system, the task may demand varying levels of autonomy, from direct control of individual UAVs to group-level coordination to fully autonomous swarm behaviors for accomplishing high-level tasks. Enabling such interaction requires a framework that supports multiple modes of shared autonomy. As language models continue to improve in reasoning and planning, they provide a natural foundation for such systems. In this paper, we present TACOS (Task-Agnostic COordinator of a multi-drone System), a unified framework that enables high-level natural language control of multi-UAV systems through a Large Language Model (LLM). TACOS integrates three key capabilities into a single architecture: a one-to-many natural language interface for intuitive user interaction, an intelligent coordinator for translating user intent into structured task plans, and an autonomous agent that executes plans and interacts with the real world. TACOS allows an LLM to interact with a library of executable APIs, bridging semantic reasoning with real-time multi-robot coordination. We demonstrate the system on a real-world multi-drone system and conduct an ablation study to assess the contribution of each module.

1. Introduction

Coordinating multiple Unmanned Aerial Vehicles (UAVs) has become a core challenge in robotics, with applications ranging from surveillance and mapping to disaster response and delivery. Assigning a dedicated pilot to each UAV does not scale with swarm size: it is expensive, inefficient, difficult to coordinate, and prone to human error. As swarm size increases, effective systems must support varying levels of shared autonomy, ranging from direct control of individual UAVs to fully autonomous swarm behaviors guided by high-level mission objectives.

Previous approaches have explored a range of interaction modalities. Some systems use fusion modules that combine voice and gesture recognition to interpret commands [1], while others rely on tablet-based interfaces for manual control [2]. These approaches improve usability but typically focus on structured command inputs rather than high-level semantic task specification. A central challenge is therefore the design of interfaces that allow a single operator to specify tasks at a high level. Recent advances in large language models (LLMs) suggest a promising direction [3,4]: natural language can serve not only as an intuitive interface but also as a mechanism for high-level reasoning and task decomposition.

In this work, we present TACOS (Task-Agnostic COordinator of a multi-drone System), an LLM-powered framework for multi-drone coordination. TACOS bridges high-level natural language instructions and low-level swarm control by adopting a language-to-tools orchestration approach. A language model interprets user intent and generates structured task plans, while safety, trajectory generation, and control are handled by established planning and control modules.

TACOS supports three core capabilities:

• One-to-many natural language interface: users can issue UAV-specific or swarm-level commands in natural language.
• Intelligent coordination: high-level instructions are translated into structured task plans.
• Task management with closed-loop execution: the system monitors swarm state and ensures correct temporal sequencing and execution.

We evaluate TACOS through simulation and real-world experiments with quadrotor platforms, including ablation studies of its architectural components.

The remainder of the paper is organized as follows: Section 2 provides an overview of the literature. Section 3 introduces the problem setup. Section 4 presents the proposed framework, TACOS. Section 5 presents the ablation study performed on the components of the framework. Section 6 and Section 7 report both simulation results and real-world experiments using quadrotor platforms. Section 8 presents the conclusions and discusses future work.

2. Related Work

Multi-UAV systems have a long history of algorithmic solutions for coordination. A central problem is distributed task assignment, for which market-based and consensus-based methods provide scalable task allocation [5,6].

Another line of work studies formal task specification and planning using temporal logic. Linear Temporal Logic (LTL) and Signal Temporal Logic (STL) enable users to specify temporally extended missions and have been applied to multi-robot motion planning and coordination [7,8]. These approaches offer strong correctness guarantees with respect to formal specifications.

Motion coordination has also been extensively studied through formation control methods [9] and decentralized trajectory optimization [10,11,12].

Recent advances in LLMs have enabled new approaches for robot control, task planning, and multi-agent coordination. Prior work in this area can be broadly categorized into LLM-based robot control systems, LLM-driven multi-robot coordination frameworks, and language interfaces for UAV swarm systems.

2.1. LLM-Based Robot Control

Several works explore using LLMs to translate natural language instructions into executable robot behaviors. Ref. [13] proposes generating executable programs from natural language commands by prompting an LLM to synthesize robot control code that integrates perception and control APIs. This approach demonstrates strong generalization across tasks by allowing the LLM to compose reusable functions and control primitives. However, the framework is primarily designed for single-robot systems and focuses on policy generation rather than multi-agent coordination. Ref. [14] focuses on LLM-driven planning and control module for a single robot. Alternatively, Ref. [15] demonstrates how a swarm of robots can employ an LLM in an online fashion to automatically generate executable code and perform previously unseen behaviors. TPML [16] leverages LLMs to generate executable code in both synchronous and asynchronous patterns.

2.2. LLM-Based Multi-Robot Coordination

Another line of work investigates using LLMs for high-level multi-agent reasoning and task allocation. Roco [17] introduces a dialectic collaboration framework in which each robot is represented by an LLM agent that communicates with others to coordinate tasks. Through iterative dialogue, agents generate subtask plans and waypoint goals, which are then validated using environment feedback such as collision checks or inverse kinematics constraints. The validated plans are executed using a centralized motion planner.

LLaMAR [18] addresses long-horizon planning in partially observable multi-agent environments. The framework uses a structured plan–act–correct–verify loop, allowing the LLM to iteratively refine task plans based on environment feedback. This approach improves robustness to uncertainty and planning errors but is primarily evaluated in simulation environments.

Other work examines architectural trade-offs for LLM-based multi-agent planning. For example, Ref. [19] compares different communication structures for LLM-driven robot teams, including centralized, decentralized, and hybrid coordination frameworks. The study highlights scalability challenges associated with multi-agent communication and demonstrates that hybrid approaches can improve planning performance while reducing token usage. LLM2SWARM [20] explores how LLMs can be used to directly synthesize and validate the robot controllers in a swarm scenario. CoELA [21] demonstrates how LLMs can be used in multi-agent cooperation settings by using these technologies to efficiently communicate between agents.

2.3. LLM Interfaces for UAV Swarm Systems

Recent work has also applied LLMs to aerial robotics and swarm systems. FlockGPT [22] proposes guiding UAV formations using natural language instructions by translating linguistic descriptions into geometric shape representations that are executed through flocking control algorithms. This approach enables intuitive control of drone formations but primarily focuses on formation generation rather than general mission coordination.

LEVIOSA [23] presents a system for generating UAV trajectories from natural language instructions using hierarchical prompting and multi-critic evaluation. The framework improves the reliability of language-generated trajectories but focuses mainly on trajectory generation rather than broader swarm-level task management.

Similarly, SwarmGPT [24] enables users to design drone swarm choreographies through natural language commands. The framework includes a safety filtering mechanism that adjusts LLM-generated trajectories to satisfy safety constraints. While effective for choreography applications, the approach is specialized for structured swarm performances rather than general-purpose drone coordination. LAN2CB [25] instead generates executable code from natural language instructions by employing a library of expert behaviors and a predefined structured mission description template. The latter provides the LLM instructions on how to define trigger and finish conditions for each mission.

2.4. Contribution

Table 1. Comparison of TACOS against relevant LLM multi-robot and UAV swarm systems.

System	Topology	Output	Replanning	Safety Layer	Real-World	Eval Scope
TACOS (Ours)	Cent.	API calls	✓	ATOMICA [10]	3 UAVs	Scaling, success
RoCo [17]	Decent.	Plan descr.	✓	RTT motion planner	Mobile manipulator	Collab. manip.
TPML [16]	Cent.	Code gen.	✓	Human cert.	2 UAVs	Mission gen.
SwarmGPT [24]	Cent.	Waypoints/Primitives	Offline	Safety filter	20 UAVs	Choreography
Code as Policies [13]	Cent.	Python code	✗	None	Robot arms	Gen. robot policy code
FlockGPT [22]	Cent.	Python code	✗	None	8 UAVs	UAV flocking

summarizes the key characteristics of existing LLM-based multi-robot and UAV swarm systems. Although existing work demonstrates the promise of LLMs for robot control and multi-agent coordination, several limitations remain. Many approaches focus either on static code generation or simulation-based planning, while others target specific applications such as manipulation or drone formation control. In addition, many frameworks rely on decentralized LLM agents or single-pass planning pipelines, which can introduce scalability challenges or limit runtime adaptability.

TACOS addresses these limitations by introducing a hierarchical LLM-based architecture for real-time multi-drone coordination. The framework separates high-level reasoning and execution monitoring through two distinct modules: a Coordinator, responsible for interpreting user commands and generating structured task plans, and a Supervisor, responsible for executing these plans and monitoring swarm state in a closed loop. This design enables TACOS to support replanning and continuous human–swarm interaction.

3. Problem Setup

We address the problem of centralized, high-level task planning for a multi-UAV system via an intelligent coordinator that interprets high-level user commands expressed in natural language. The coordinator must translate these commands into executable plans for the UAV swarm. The swarm operates in a bounded 3D environment $\mathcal{W}\subseteq {\mathbb{R}}^3$. The environment contains a set of n ellipsoidal obstacles $\mathcal{O}=\{{\mathcal{O}}_1,\dots ,{\mathcal{O}}_n\}$, where each obstacle is defined by its center position and a positive definite matrix specifying its orientation and size. The free space is given by ${\mathcal{W}}_{\mathrm{free}}=\mathcal{W}\setminus {\bigcup }_{i=1}^n{\mathcal{O}}_i$. The environment also includes a set of m task-relevant entities, such as targets or landmarks, denoted by $\mathcal{T}=\{{\mathcal{T}}_1,\dots ,{\mathcal{T}}_m\}$, each representing a 3D coordinate. The state of the world is thus defined as ${\mathcal{S}}_{\mathcal{W}}=(\mathcal{O},\mathcal{T})$.

We consider N quadrotor UAVs, where each UAV has a discrete operational mode, ${\mathcal{S}}_d\in \{\mathit{unavailable},\mathit{idle},\mathit{flying},\mathit{tracking}\}$. The swarm state ${\mathcal{S}}_s$ is defined as ${\mathcal{S}}_s={\left\{({\mathcal{S}}_d^i,p^i,v^i)\right\}}_{i=1}^N$, where $p^i\in {\mathbb{R}}^3$ and $v^i\in {\mathbb{R}}^3$ are the current position and velocity vectors of the i-th drone. Additionally, each UAV is equipped with a predefined set of low-level control primitives, formalized as the action set: $\mathcal{A}=\{\mathtt{arm}\_\mathtt{takeoff}\left(\right),\mathtt{start}\_\mathtt{tracking}\left({\mathcal{T}}_k\right),\mathtt{stop}\_\mathtt{tracking}\left(\right),$$\mathtt{land}\left(\right),\mathtt{goto}(\mathtt{x},\mathtt{y})\}$, which abstract away platform-specific dynamics.

Each action in $\mathcal{A}$ is implemented by a dedicated control algorithm that executes the corresponding behavior, thereby reducing the computational and control workload of the LLM-based framework. In particular,

• goto(x, y) (In the remainder of the paper, a fixed altitude z is used in all experiments; therefore, it is omitted from the notation): Once this command is issued, each drone coordinates using a decentralized trajectory optimization module, ATOMICA [10], which ensures real-time, collision-free motion even when multiple drones share the same goal position.
• $\mathtt{start}\_\mathtt{tracking}\left({\mathcal{T}}_k\right)$ : Each drone implements a position-based target tracking algorithm working on top of the goto(x, y) interface.

The LLM is therefore not required to run at control frequencies of hundreds of hertz. Instead, it delegates actions to reliable low-level control algorithms. This design supports heterogeneous UAV platforms, provided they implement the required action interface. Furthermore, the framework’s capabilities can be easily extended by incorporating additional action primitives, leveraging advances from the wider control and robotics community.

Additionally, we make the following simplifying assumptions:

• Accurate state estimation: In simulation, the swarm state is assumed to be noise-free. In real-world experiments, pose measurements are provided by an external motion capture system.
• Full world-state knowledge: The state of the environment is assumed to be known and available at each time step.
• No explicit perception modeling: Perception is not explicitly simulated. Target detection and task completion are determined either through positional conditions (e.g., reaching a designated location) or through operator acknowledgment.

4. TACOS

The TACOS framework consists of two main language models arranged in a hierarchical architecture: the Coordinator LLM, which receives high-level natural language commands from the user and synthesizes a task plan, and the Supervisor LLM, which sequences and executes the plan based on real-time swarm and environment state. This hierarchy is inspired by the layered guidance and control architectures commonly used in aerospace systems and by Kahneman’s two-system theory [26]. The Coordinator corresponds to a slow, reasoning layer responsible for planning and intent understanding, while the Supervisor functions as a fast execution layer. This separation simplifies context management across the LLMs and enables independent customization or fine-tuning of each model. Each LLM is initialized with a dedicated configuration prompt that defines its specific objectives, behavioral constraints, and output structure. Figure 1 illustrates the modular architecture of TACOS and the interaction flow between user input, the Coordinator, and the Supervisor.

4.1. Coordinator

The Coordinator LLM is responsible for translating high-level user instructions, expressed in natural language, into a structured task plan compatible with the swarm’s control interface. It receives as input the current system state, comprising the swarm state ${\mathcal{S}}_s$, the world state ${\mathcal{S}}_{\mathcal{W}}$, the user’s instruction $\mathcal{I}$, and the partial task plan $\hat{\mathcal{P}}$ that encodes unexecuted subtasks from prior plans. The swarm’s action set $\mathcal{A}$ is encoded into the model’s configuration prompt, as shown in Figure 2.

The Coordinator’s output is structured into the following two components:

• Reasoning$\mathcal{R}$: a natural language explanation of the generated task plan. This explanation supports interpretability. Moreover, prompting the model to explicitly reason improves output quality by leveraging Chain of Thought (COT) mechanisms [27].
• Task plan$\mathcal{P}$: a list of atomic API calls required to fulfill the user request. All temporal dependencies, synchronization constraints, and inter-agent coordination are deferred to the Supervisor module.

To improve the Coordinator’s planning capabilities, we adopt two prompt engineering strategies: In-Context Learning (ICL) and COT. ICL allows the model to infer the task structure from a small number of annotated demonstrations provided in the prompt [28]. In our case, we provide few-shot examples consisting of user requests and their corresponding ideal reasoning and task plans, illustrating the correct behavior expected from the model. An example of ICL in the Coordinator’s Modelfile is shown in Figure 2. The complete set of examples is shown in Listing A2. Expanding the library of available APIs would necessitate a proportionally larger set of examples to adequately demonstrate and capture the expected generalized behavior of the framework across a broader action space.

Additionally, we employ COT prompting, which instructs the model to explicitly reason through its decisions before generating a final task plan. As illustrated in Figure 2, the Coordinator is prompted to emit a structured reasoning block followed by the task plan itself. This improves both the coherence of the plan and the interpretability of the decision process.

To enable TACOS to react to dynamic events, the Coordinator is automatically triggered whenever an event requiring a new task plan occurs, such as when some drones become unavailable or new ones join the swarm. Because only a subset of such events can be automatically detected, TACOS also allows direct user interaction: at any time, the user may query the Coordinator, forcing a new task plan to be generated. In this case, the Supervisor informs the Coordinator of the status of the previous plan via $\hat{\mathcal{P}}$, which records all pending subtasks.

Beyond plan synthesis, the Coordinator also enables high-level swarm control via natural language. It acts as a centralized interface for one-to-many interactions, allowing users to issue commands such as “Split the swarm and surround the target”, which are then translated into structured, machine-executable API calls. Regarding the safety of the generated task plan, Figure 2 details the guidelines provided to the Coordinator, which specify safety constraints such as preventing the assignment of multiple drones to the same target. At the high level, the primary safety mechanism consists of validating the API call structure; if a call is incorrectly constructed, the Coordinator is re-triggered to generate a valid plan. Ultimate safety is managed via delegation, as detailed in Section 3, where each executable action is implemented by a dedicated safe control algorithm.

4.2. Supervisor

The Supervisor LLM is responsible for transforming the Coordinator’s high-level task plan into a temporal sequence of executable actions. It takes as input the reasoning and task plan produced by the Coordinator, the current swarm state ${\mathcal{S}}_s$, and the world state ${\mathcal{S}}_{\mathcal{W}}$. The set of available low-level actions $\mathcal{A}$ is encoded directly into the model’s configuration prompt.

Unlike the Coordinator, which reasons abstractly about intent, the Supervisor operates in a closed-loop execution. At each cycle, it receives updated telemetry from the swarm and the environment and re-evaluates which actions should be issued next. The Supervisor’s cycle duration is chosen empirically based on the characteristic time scale of the mission. In the experiments presented in this paper, the Supervisor was queried at 0.1 Hz. This feedback loop allows the Supervisor to perform temporal sequencing of API calls, respecting dependencies implied by the Coordinator’s plan, and to assign actions to each UAV.

The Supervisor produces a structured output specifying, for each drone, the current task under execution and the action to be issued. To support the coordination between the Supervisor and the Coordinator, TACOS maintains a list of remaining subtasks, denoted by $\hat{\mathcal{P}}$. This structure captures the portion of the task plan that has not yet been executed and is provided to the Coordinator during replanning events, either triggered automatically by TACOS (currently, TACOS triggers a Coordinator replan whenever a drone fails or new drones become available) or requested manually by the user.

4.3. History Management

During a mission, to help the Coordinator understand context and track how the environment changes, the full history of interactions with the user is stored. This includes all past user commands, the corresponding reasoning and task plans, and any updates to the swarm or environment. Keeping this history allows the Coordinator to handle references to earlier commands, e.g., “go back to the last location”, and generate plans that are consistent with past instructions. In contrast, the Supervisor LLM operates with bounded memory. For each task plan, it keeps a temporary record of the commands it has issued and any updates to the swarm or environment. This memory helps it to manage action sequencing, avoid repeating actions, and track progress. Once the current task plan is completed, this memory is cleared, and a new execution cycle begins. This scoped memory model aligns with the Supervisor’s role as a reactive executor operating over finite-horizon plans.

5. Ablation Study

To assess the contribution of each module within the TACOS framework, we perform an ablation study. For each pilot request, we measure the following metrics:

• Success rate: the percentage of trials in which the task was completed as intended.
• Average number of steps (L): the average number of Supervisor cycles per task.

We evaluate system performance under the following conditions:

• TACOS Monolithic (MNL): to evaluate the effect of collapsing high-level reasoning and execution into a single module. In this case, to keep a compact interaction history, we only track executed actions.
• TACOS without reasoning (w/oR): to measure the impact of providing the Coordinator’s reasoning to the Supervisor and whether it improves the Supervisor’s ability to correctly sequence and complete the task.
• TACOS: the full framework, as shown in Figure 1.

5.1. Simulated Environment

The simulation environment, shown in Figure 3, contains 51 known landmarks, denoted as $\mathcal{T}={\left\{{\mathcal{T}}_i\right\}}_{i=1}^{51}$, distributed across five distinct areas: two parking lots containing 10 and 5 parked cars, respectively; a residential neighborhood with 10 villas; a park area with 20 trees; a business district with 4 skyscrapers; and 2 drone takeoff and landing pads. The four skyscrapers are also modeled as static obstacles to be avoided, represented as $\mathcal{O}={\left\{{\mathcal{O}}_i\right\}}_{i=1}^4$. Simulation parameters are adopted from the ATOMICA framework [10], with maximum velocity $v_{\max }=1.7$ m/s and maximum acceleration $a_{\max }=6.2{\mathrm{m}/\mathrm{s}}^2$.

5.2. Model Configuration

For each setting, we performed 50 simulation runs using the open-source gpt-oss:20b (https://ollama.com/library/gpt-oss:20b, accessed on 2 June 2025) model for both the Coordinator and the Supervisor.

For the Coordinator, we set the temperature parameter to 1.0, whereas for the Supervisor, we employ a lower value of 0.4. This distinction in parameter tuning reflects the fundamentally different requirements of their respective roles. The Supervisor is strictly responsible for executing the provided task plan; it must not generate new information, necessitating outputs that are more deterministic. Conversely, the Coordinator is tasked with interpreting potentially broad natural language commands to formulate both a comprehensive task plan and a corresponding reasoning block.

5.3. Mission

The mission is structured into two successive tasks designed to test the basic capabilities of the framework. For each ablation configuration, we evaluated performance with increasing swarm sizes: 6, 12, and 20 drones.

• Task 0:

  Description: all UAVs are instructed to take off.

  -

  Success criteria: the Coordinator successfully generates a task plan containing a takeoff command for every drone, and the Supervisor executes each command without error.

  -

  Prompt:

  *

  User request prompt: “The user requested the following task:

  takeoff. Create a suitable mission plan”.

  *

  Dynamic event prompt: “There has been a change in the swarm state.

  We executed part of the original task plan but the following

  actions are still to be executed: [remaining-task-plan].

  Allocate the missing actions to the available drones.

  Do not reissue actions that have already been executed”

• Task 1:

  -

  Description: the pilot requests to find a suspect hiding in a car. Before the mission is completed, a drone failure is simulated to evaluate TACOS’s response to dynamic events.

  -

  Success criteria: the Coordinator generates a comprehensive task plan assigning each car to at least one drone. Following the simulated dynamic failure, the Coordinator must effectively reassign all unexecuted tasks to the remaining available drones, and the Supervisor must execute these commands in the correct sequence.

  -

  Prompt:

  *

  User request prompt: “The user requested the following task:

  There is a suspect hiding in one of the cars,

  divide the swarm into two groups and inspect the cars as fast as

  possible. Create a suitable mission plan”.

  *

  Dynamic event prompt: “There has been a change in the swarm state.

  We executed part of the original task plan but the following

  actions are still to be executed: [remaining-task-plan].

  Allocate the missing actions to the available drones.

  Do not reissue actions that have already been executed”

5.4. Results

The results are summarized in

Table 2. Success rate of TACOS configurations, 95% CI.

	6 Drones	12 Drones	20 Drones
TACOS MNL	$0.08\pm 0.075$	$0.15\pm 0.138$	$0.38\pm 0.127$
TACOS w/oR	$0.5\pm 0.138$	$0.38\pm 0.134$	$0.94\pm 0.065$
TACOS	$0.65\pm 0.135$	$0.55\pm 0.138$	1.0 − 0.065

and

Table 3. Average number of Supervisor’s cycles, 95% CI.

	6 Drones	12 Drones	20 Drones
TACOS MNL	$4.7\pm 1.5$	$6.72\pm 1.4$	$5.05\pm 0.94$
TACOS w/oR	$3.42\pm 1.8$	$4.57\pm 1.5$	$4.07\pm 1.2$
TACOS	$3.45\pm 1.3$	$2.02\pm 1.3$	$2.02\pm 1.4$

and Figure 4, reporting both the success rate and the average number of steps L, computed over successful trials only. The results for Task 0, i.e., the takeoff task, are not included in Figure 4, as all configurations successfully completed the task in a single iteration with a 100% success rate. In the reported results, any trial that failed to reach the mission objective due to planning dead-ends or repeated command loops was recorded as a failure in the aggregate success rate.

The ablation study highlights the following facts:

• Receiving both the reasoning and the task plan allows the supervisor to infer the correct temporal action sequence. TACOS w/oR has a lower success rate than the full TACOS framework, considering all three swarm sizes.
• Explicitly dividing task planning and execution helps manage missions requiring multiple execution cycles. This is evident from the superior success rate of TACOS with respect to TACOS MNL shown in Figure 4.
• TACOS demonstrates better parallelization capabilities compared with TACOS w/oR. This effect is particularly evident in the number of Supervisor cycles observed with a swarm of six UAVs: TACOS w/oR requires, on average, nearly two additional cycles compared with both the full framework and the monolithic configuration.

In general, we observe that TACOS MNL often issues repeated actions to different drones across iterations, with this behavior worsening as the number of iterations increases. In contrast, TACOS w/oR fails to parallelize tasks, favoring sequential execution. TACOS, on the other hand, does not exhibit these types of failures. It should be noted that, due to the simulated drone failure, the framework cannot complete the task in a single step, even when the number of available drones exceeds the number of targets. Finally, we observed that the Coordinator did not generate invalid API calls (e.g., incorrect function names or parameter mismatches). We attribute this to the minimal syntax and constrained parameter space of the API.

Table 4. Average inference times in seconds.

	6 Drones		12 Drones		20 Drones
	Coord.	Sup.	Coord.	Sup.	Coord.	Sup.
TACOS MNL	8.46 s	–	5.96 s	–	6.31 s	–
TACOS w/oR	8.55 s	4.77 s	8.49 s	5.04 s	7.21 s	5.15 s
TACOS	11.05 s	4.53 s	8.06 s	5.66 s	8.0 s	5.64 s

presents the average inference times (in seconds) recorded during the baseline simulations. For both TACOS w/oR and the full TACOS framework, we report the Coordinator’s inference time followed by that of the Supervisor. For the monolithic version, we provide the inference time of the only model used. The results demonstrate that inference times remain consistent regardless of swarm size or the specific framework version tested. Notably, the monolithic version achieves a lower overall inference time, as it relies on a single LLM rather than a hierarchical dual-model architecture.

5.5. Comparison with Classical Task Assignment

To evaluate the performance of TACOS, we executed a comparison against a baseline non-LLM approach. We conducted the same experiment described in Section 5.3, where the swarm was tasked with inspecting 15 parked cars in an urban environment, and a dynamic failure was introduced.

Algorithm 1 presents the pseudocode for the baseline approach. The procedure begins by initializing the sets of landmarks $\mathcal{T}$, available drones $\mathcal{D}$, obstacles $\mathcal{O}$, and unvisited landmarks ${\mathcal{U}}_t$. The algorithm first ensures all drones have transitioned to a flying state, executing a takeoff command where necessary. It then enters a control loop that persists while ${\mathcal{U}}_t$ is non-empty. In each iteration, we get the list ${\mathcal{D}}_a$ of all the drones $d\in \mathcal{D}$ in flight and not engaged in a visiting task; we then assign each unvisited landmark to the available drones, minimizing the travel distance. Finally, the algorithm evaluates the state of each drone; if the distance to its target landmark is less than $0.3$ m, the landmark is marked as visited, ${\mathcal{U}}_t$ is updated, and the loop continues.

Algorithm 1: Baseline

1: $\mathcal{T},\mathcal{D},\mathcal{O},{\mathcal{U}}_t\leftarrow initialize$ 2: while  $any\left(d\right)$ in $\mathcal{D}$ s.t. $d.status\ne$$flying$ do 3:     $takeoff\left(d\right)$ 4: end while 5: while$len\left({\mathcal{U}}_t\right)>0$do 6:     ${\mathcal{D}}_a=[d\in \mathcal{D}|d.status==flying\wedge isNotVisiting\left(d\right)]$ 7:     $assignVisit({\mathcal{D}}_a,{\mathcal{U}}_t)$ 8:     for d in $\mathcal{D}$ do 9:         if $distance(d.pos,d.target)<0.3$ m then 10:            $stopVisiting\left(d\right)$ 11:            ${\mathcal{U}}_t={\mathcal{U}}_t-d.target$ 12:         end if 13:     end for 14: end while

Table 5. Average distance flown in meters by the swarm.

	6 Drones	12 Drones	20 Drones
Baseline	196.96 m	78.95 m	51.42 m
TACOS MNL	198.26 m	136.84 m	78.55 m
TACOS w/oR	197.73 m	112.57 m	81.23 m
TACOS	197.1 m	105.44 m	70.13 m

presents the results of this simulation. As can be seen, the baseline performs better; as discussed in Section 1, when the scenario and tasks are entirely predefined, a classical algorithm will typically be faster and yield superior performance. However, the primary advantage of TACOS over such specialized algorithms lies in its ability to leverage semantic information to inform task allocation. In this same scenario, a user could initially request a distance-based assignment and later pivot to a different assignment driven by previously unknown priorities. Such dynamic adaptability is largely unattainable with rigidly defined non-LLM approaches, where changes in task allocation priorities need to be manually developed beforehand to be used during mission execution. Finally, due to the inherently modular architecture of TACOS, incorporating this classical baseline as an accessible API would be straightforward, effectively bridging the performance gap observed in this specific use case.

6. Target Search Case Study

This section presents a target search experiment designed to evaluate the performance of TACOS in coordinating a multi-drone system. Specifically, we demonstrate TACOS’s ability to assist a human operator in locating a target within a known environment and subsequently tracking it using multiple drones. We further evaluate the system’s robustness to dynamic events by simulating multiple UAV failures during the mission. While states are formally defined in ${\mathbb{R}}^3$, all experimental evaluations utilize fixed-altitude planar coordination (2.5D), where the altitude z remains constant, and the executable action set is restricted to the 2D plane.

For real-time trajectory generation, TACOS integrates ATOMICA [10], a real-time, distributed, collision-free multi-agent motion planner. ATOMICA serves as the trajectory generation backend for all goto() and start_tracking() actions issued by the Supervisor. The generated trajectories are subject to a maximum velocity of $v_{\max }=2$ m/s and a maximum acceleration $a_{\max }=6.2$ ${\mathrm{m}/\mathrm{s}}^2$.

Experiments have been conducted on a computer running Ubuntu22 LTS using an NVIDIA RTX 6000 GPU (NVIDIA, Santa Clara, CA, USA). Communication between TACOS and the drones is performed using ROS Noetic (https://wiki.ros.org/noetic, accessed on 2 February 2026).

The simulated environment is the one described in Section 5.1. In addition, the simulation includes a moving target vehicle with known position and velocity, representing a moving agent that attempts to evade the swarm during the search task. For all the simulated experiments, we assume perfect low-level trajectory tracking for the quadrotors. The environment is designed to demonstrate how TACOS assists a human operator through an intuitive, natural-language interface, enabling the seamless coordination of large multi-drone systems. The integration of on-board perception and autonomous target detection is left for future work.

Simulation Results

We conducted a series of simulations to evaluate both the capabilities and limitations of TACOS. The mission consists of locating a moving target within the environment and tracking it as it attempts to escape. To assess the ability to handle a dynamic environment, drone failures are intentionally introduced during the simulations, forcing TACOS to replan and reallocate tasks. Videos of the simulation runs are provided in the Supplementary Materials.

We conducted simulations considering swarms of 6, 12, and 20 drones. Due to space limitations, we only report here the interactions obtained with a swarm of 6 drones, which highlight the three core capabilities of the framework (see Section 1). Figure 5 shows the initial interaction in which the operator defines the mission objectives through natural language commands. During the execution of the first task, a target escape maneuver is simulated, and the Coordinator is queried to generate a new plan that initiates target tracking (no perception module is used; global information about all entities is assumed to be available to TACOS and the drones). The resulting task plan, shown in Figure 6, demonstrates that the Coordinator successfully integrates the new tracking request while preserving the pending subtasks from the previous plan. Subsequently, we simulate the failure of two drones, one of which was assigned to track the target. As illustrated in Figure 7, TACOS triggers a replanning phase, reassigning available drones to complete the mission objectives. Leveraging the full history of requests available to the Coordinator, TACOS assigns available drones to each unexecuted task in the partial task plan $\hat{\mathcal{P}}$ and automatically allocates a second drone to the previously requested tracking task, even without an explicit new command. It is interesting to note that, in this instance, the Coordinator chose to leave one drone idle during the inspection phase, dividing the inspection of the 15 cars into three consecutive subtasks executed by five drones each. However, the previously idle drone was later assigned to the tracking task. Indeed, the number of drones assigned by the Coordinator may vary across runs due to the inherent stochasticity of LLMs. This variability in the Coordinator’s behavior can be mitigated by carefully shaping the prompt or by fine-tuning the underlying model. To maintain plug-and-play compatibility with different language models, we did not pursue fine-tuning in this work. Nevertheless, we observed that the framework’s behavior can be effectively guided by providing more specific and constrained natural language instructions to the Coordinator. A key feature of TACOS is its ability to support continuous interaction with the Coordinator, allowing the operator to refine prompts whenever the observed behavior deviates from expectations. For example, when the user issues a new request that interrupts an ongoing task, they can explicitly specify whether the new instruction should take priority over the current one, enabling flexible yet controllable high-level supervision. The demonstration video for all three swarm sizes is available at the following link: https://tinyurl.com/TacosSimulated (accessed on 11 November 2025).

7. Real World Experiment

Flight tests were conducted in an indoor arena equipped with a 12-camera motion capture system tracking markers mounted on the drones. We used three quadrotors running PX4, referred to as Alfa, Bravo, and Charlie. The demonstration environment was a simplified map consisting of a small park, a large park (divided into north and south zones), a villa, and a business district. The mission scenario involved locating a lost dog placed in the small park. Figure 8 illustrates the pilot’s command and TACOS’s response during the interaction, along with the demonstration environment and the trajectories flown by the drones while executing the commands generated by the Supervisor.

Figure 8 highlights the advantages of using TACOS: when the user instructed the system to find the dog, starting from the most likely areas, TACOS inferred, based on semantic reasoning, that parks were more probable locations than the business district. Furthermore, during the initial interaction, TACOS correctly assigned the search task to the closest available drone. In a subsequent interaction, when the user asked to keep monitoring the dog and notify the owner, the system assigned the task to a farther drone (in other instances of the same demonstration, TACOS instead selected the closest drone).

We repeated the demonstration 10 times. The behavior during the first interaction was consistent across all runs. However, when asked to monitor the dog and notify the owner, the system occasionally chose to monitor the dog with two drones and sent the third one to the villa. The demonstration video is available at the following link: https://tinyurl.com/TacosRealWorld (accessed on 11 November 2025).

8. Conclusions

In this work, we explored the use of large language models as interfaces for multi-drone systems. The proposed framework bridges low-level planning and control algorithms with high-level mission execution by enabling natural language interaction between a human operator and a multi-drone system. We demonstrated the system in a simplified, lab-scale search-and-rescue scenario, where the semantic reasoning capabilities of the language model improved the efficiency of the search strategy. Additionally, we conducted an ablation study to evaluate the contribution of each module in the proposed architecture. The proposed framework has several limitations. In particular, it assumes full world-state knowledge, does not include onboard perception, and is limited to short-horizon missions. Nevertheless, we believe TACOS serves as a proof-of-concept demonstration of LLM-based swarm coordination. Future work will focus on integrating onboard perception modules and expanding the available API set. Additionally, to support long-horizon missions where history management could become a bottleneck due to context window limitations, we plan to implement history management strategies such as integrating a Retrieval-Augmented Generation (RAG) architecture to dynamically fetch task-relevant context or employing periodic LLM-driven summarization to prevent token overflow during extended operations.