PaperlayerView exact revision on arXiv

Source-linked AI summary

Multi-agent LLMs on the Cloud-Edge-IoT Continuum: A Systematic Mapping Study on Architectures, Deployment, and Evaluation

Mahyar Tourchi Moghaddam, Tiziano Santilli, Leo Wilhelm Lierse, Sebastian Werner, Francesco Daghero

arXiv:2610.28702v1cs.SE

TL;DR

The cloud-edge-IoT intersection of multi-agent LLM systems has not been mapped systematically, despite differing choices about placement and oversight. This study maps 45 primary studies; it finds recurring architecture and deployment patterns, but evaluation comparability remains an obstacle.

  • Problem

    Existing work lacks a continuum-aware map of how multi-agent LLM roles, models, tools, memory, policies, and migration are distributed across device, edge, and cloud tiers.

    Source: §1 · p. 3

  • Method

    The authors systematically mapped 45 primary studies, classifying architecture, deployment, application domain, and evaluation practice and recording evaluation and artifact availability.

    Source: §1 · p. 3, §9 · p. 17

  • Results

    Five architecture families and six deployment mechanisms recur, while 29 of 45 studies evaluate on physical hardware, mostly with open models below 8B parameters on device and edge tiers.

    Source: §9 · p. 17

  • Takeaways & Limitations

    Evaluation comparability is the main obstacle: studies use different workloads, hardware, network conditions, and metrics, and only six release artifacts.

    Source: §9 · p. 17

    The 45-study mapping is a snapshot of literature through March 2026 and may not generalize beyond continuum settings.

    Source: §8 · p. 17

Abstract

from arXiv · show

LLM applications are increasingly built as systems of cooperating components rather than as single prompt-response pipelines. IoT applications add constraints of their own, because sensing, reasoning, control, and actuation are spread across devices, edge nodes, and cloud services to meet latency, privacy, and bandwidth requirements. How multi-agent LLM systems are organized and deployed across this cloud-edge-IoT continuum has not been mapped systematically. We therefore conducted a systematic mapping study. From 831 records retrieved up to March 2026, we selected 45 primary studies and classified each one by architecture family, deployment pattern, application domain, and evaluation practice. We also recorded how each system was evaluated and whether its code or data are public. Five architecture families recur in the corpus. Specialized agent teams run next to sensors, planners delegate subtasks to workers, and small local models cooperate with large cloud models. A fourth group federates model adaptation across devices, and a large fifth group builds the supporting infrastructure for offloading, communication, memory, and serving. Deployment relies on six recurring patterns, ranging from local-only execution to control loops gated by policy checks or human approval. Twenty-four of the 45 studies target IoT, industrial, smart-home, healthcare, vehicular, or robotics settings, and 29 evaluate on physical hardware, where open models below 8B parameters dominate. Based on the mapping, we list the reporting items needed to make future evaluations comparable, give deployment guidance for common IoT constraints, and identify open problems.

1. Introduction

Multi-agent LLM systems and cloud-edge-IoT deployments are developing in parallel, but existing reviews do not map how agents, models, tools, and memory are distributed across the continuum. This study maps that intersection and records architecture, deployment, application, and evaluation practices.

1. Introduction

  • Multi-agent LLM systems cooperate through specialized components, while IoT deployments distribute intelligence across devices, edge tiers, and cloud services.Continuum deployments reflect latency, bandwidth, privacy, offline-reliability, and local-processing considerations.Source: §1 · pp. 2–3
  • The mapping asks how systems are organized and deployed, which IoT problems they address, how they are evaluated, and what challenges remain.The questions include placement, offloading, synchronization, fallback, migration, benchmarking, state, security, oversight, and reproducibility.Source: §1 · p. 3
  • The study classifies 45 primary studies and records their architecture, deployment, domain, evaluation, and artifact availability.Its contributions include a taxonomy, evaluation records, an account of ties to IoT and cyber-physical settings, and reporting and deployment guidance.Source: §1 · p. 3

2. Related Surveys and Positioning

  • Existing reviews examine multi-agent coordination, single-model edge deployment, or continuum infrastructure, but leave their cloud-edge-IoT intersection open.The study compares architecture and runtime placement separately, records evaluation and artifact availability, and derives a reporting checklist and deployment guidance.Source: §2 · p. 4

3. Research Methodology

The study follows a systematic mapping protocol, searching full text and using snowballing to identify relevant work through March 2026. It extracts and codes study characteristics, while documenting judgment in classification and the limits of formal validation and cross-study result pooling.

Research Methodology

  • Full-text searching and backward and forward snowballing were used to reduce the chance of missing relevant systems described with different terminology.The authors checked that three adjacent-terminology systems were reachable by snowballing, but state that this cannot remove the risk of missed multi-component systems.Source: §3 · p. 5
  • The search and staged selection retained 45 primary studies from 831 deduplicated records, including two snowballed records retained as a protocol deviation.The two records were kept because three federated-family system papers build directly on them; excluding them changes no family, pattern, or reported gap.Source: §3 · pp. 4–5
  • A shared extraction form records system context, roles, models, hardware, placement, adaptation, state, governance, and evaluation.Coding combines predefined dimensions with inductively identified mechanisms, including role specialization, task decomposition, and governance-gated control.Source: §3 · pp. 5–6
  • Architecture assignments use one main-contribution family with second-author checks, while deployment and evaluation retain multiple codes when applicable.Five studies have two deployment codes, and 28 have two or more evaluation codes.Source: §3 · p. 6
  • The mapping reports frequencies and co-occurrences rather than pooling performance results, because studies use different tasks, datasets, hardware, network conditions, and metrics.The authors state that no external benchmark exists to formally validate the classification.Source: §3 · pp. 6–7

4. Architecture Families (RQ1)

Five architectural families organize how multi-agent LLM systems divide work and adapt across the cloud-edge-IoT continuum; their roles and runtime placement are distinct questions. The largest family supplies supporting infrastructure rather than agent teams.

Infrastructure

  • The largest family builds offloading, communication, memory, scheduling, and serving infrastructure on which the other four families depend.Its studies range from local tools and policy enforcement to cloud serving and vehicular offloading.Source: §4 · pp. 7–8

Edge-resident teams

  • Edge-resident teams specialize roles around sensor pipelines, physical concerns, or expert small models, but their roles are fixed at design time.The studies place these systems near data to align role boundaries with privacy zones, sensor layout, and local latency budgets.Source: §4 · p. 7

Planner-worker orchestration

  • Planner-worker systems keep strategic planning in high-level agents and delegate bounded execution to narrowly scoped workers, tools, or resource tiers.The pattern supports cloud-scale planning alongside edge-local execution.Source: §4 · p. 7

Hybrid local-small and cloud-large collaboration

  • Hybrid systems combine small local models with heavier remote reasoning and specify explicit handoff rules rather than relying only on local or cloud execution.Some systems instead escalate to specialized tools, or use local processing before cloud retrieval or advice.Source: §4 · pp. 7–8

Federated and collaborative adaptation

  • Federated and collaborative adaptation distributes model adaptation across devices; this family is small, but uniquely makes post-deployment adaptation part of the architecture.Three system papers build on techniques described by two supporting studies.Source: §4 · p. 8

Reference model

  • The reference model assigns sensing, actuation, privacy filtering, and compact models to devices; coordination to edge/MEC; and heavyweight planning and lifecycle tasks to cloud.Filtered observations and summaries move upward, while policies, models, and workflows move downward; governance, audit, observability, and protocol security span all layers.Source: §4 · p. 8, Figure 2 · p. 9

Strength of support

  • Evaluation support varies by family: all seven edge-resident systems and eight of ten hybrid systems use hardware, while planner-worker support is weaker.Three of five federated studies use physical edge clusters, and only [P17] releases artifacts among its three system papers; infrastructure studies range from production traces to simulation.Source: §4 · p. 9
  • Privacy is rarely measured directly, and no mapped study reorganizes its agent team at runtime.Only [P27] and [P31] report direct privacy measurements, and they omit latency and cost figures needed to judge protection costs.Source: §4 · p. 9

5. Deployment Patterns (RQ2)

The deployment taxonomy classifies runtime mechanisms separately from architectural organization, including where work runs and at what granularity it is routed. Across patterns, the mapping identifies under-tested triggers, privacy outcomes, and continuity conditions.

Taxonomy scope

  • Deployment patterns may overlap, and work can be routed at request, subtask, dialogue-turn, memory-access, or trainable-parameter granularity.Two studies do not specify component placement or contribute a deployment mechanism.Source: §5 · pp. 9–10

Local-only execution and local actuation

  • Local-only execution keeps reasoning and actuation on the device or local edge, but only [P27] measures a privacy outcome within this pattern.Other privacy, safety, and trust results concern safety or trust rather than leakage or disclosure.Source: §5 · p. 10

Edge-first with selective cloud escalation

  • Edge-first systems selectively escalate whole requests, subtasks, or transformed data to cloud models, while [P20] escalates to specialized tools instead.Recurring triggers include task complexity, model confidence, data sensitivity, and latency criticality.Source: §5 · p. 10

Hierarchical edge/MEC/cloud orchestration

  • Hierarchical orchestration distributes roles and subtasks across tiers, from network management to smart manufacturing, vehicular functions, and pathfinding.Cloud request routing and GPU autoscaling can adapt together; task-information transport can also affect performance independently of model placement.Source: §5 · pp. 10–11

Federated and collaborative adaptation

  • Three studies deploy federated reporting, agent workloads on a heterogeneous edge cluster, or collaborative fine-tuning among nearby devices.The fine-tuning method in [P44] and design-space mapping in [P45] supply supporting techniques.Source: §5 · p. 11

State continuity, communication, and migration

  • Only three studies address state continuity, communication, and migration through protocol security analysis, shadowing for agent reachability, or intent-indexed distributed memory.These mechanisms matter to mobile and industrial IoT, but none tests continuity under motivating conditions such as handover or intermittent uplinks.Source: §5 · p. 11

Governance-gated closed loops

  • Governance-gated loops check policies, risks, capabilities, or expected gains before action, a pattern relevant to regulated or high-risk IoT.Examples include access-control enforcement, outsourcing checks, digital-twin validation, and bandwidth-aware sensor fusion.Source: §5 · p. 11

Deployment weaknesses

  • Escalation triggers are not compared across studies, local data retention is rarely measured for privacy, and continuity mechanisms lack tests under motivating network conditions.The corpus leaves unknown which escalation signal is most reliable and how continuity behaves during handover, intermittent uplinks, or NAT rebinding.Source: §5 · p. 11

6. Evaluation Practices (RQ3)

The 45-study corpus combines substantial physical evaluation with diverse outcomes, but evaluations rarely share benchmarks or conditions. Local and edge deployments commonly use small open models, while artifact availability and cross-study comparability remain limited.

Corpus profile

  • 29 of 45 studies (64%) evaluate on physical devices, prototypes, or hardware testbeds; only six publish code or data.Twelve studies rely only on simulation or dataset experiments, two are conceptual, and 24 address IoT-related domains.Source: §6 · p. 11, Table 5 · p. 12

Models and hardware

  • Open models below 8B parameters dominate device and edge tiers, while GPT-4-class commercial models are the most frequent cloud choice.Qwen, Llama, Phi, Gemma, and Mistral variants from 0.5B to 8B carry most local reasoning; cloud evaluations use GPT-4-class models in roughly half the corpus.Source: §6 · p. 12

Application domains

  • 24 of 45 studies address IoT, industrial, smart-home, healthcare, vehicular, or robotics settings, but studies rarely reuse shared benchmarks.General agent benchmarks exist, yet they do not model continuum conditions such as network partitions, migration cost, or privacy-preserving preprocessing.Source: §6 · p. 12, Table 6 · p. 12

Evaluation outcomes

  • Latency and efficiency commonly appear together, while task success often lacks latency, cost, privacy, or resilience context.State continuity is the most isolated outcome family; few studies report memory, migration, reachability, cache reuse, or robustness outcomes.Source: §6 · p. 12, Table 7 · p. 13

Reported results

  • Reported gains use study-specific baselines and cannot be compared across papers because baselines, hardware, and workloads differ.Examples include [P17] reporting 75% less network bandwidth, 45% lower end-to-end latency, and 61% less energy per inference than a naive deployment; these are not cross-study comparisons.Source: §6 · p. 13
  • Privacy and governance evaluations cover safety, policy compliance, policy generation, anonymization, and protocol security, but their results rarely include standard latency or cost numbers.Other evaluations jointly report quality with latency, cost, or bandwidth, making trade-offs more visible than isolated scores.Source: §6 · pp. 12–13

7. Open Challenges (RQ4)

The mapping identifies research-practice gaps in benchmarking, state continuity, protocol security, federated lifecycle management, oversight, and artifact availability. It proposes a benchmark profile and reporting checklist, alongside deployment guidance for common IoT constraints.

Benchmark fragmentation

  • Benchmark fragmentation prevents ranking studies: even offloading evaluations use different environments, optimization goals, baselines, and outcome sets.A useful shared benchmark would combine agent tasks with bandwidth, round-trip time, memory synchronization policy, and local privacy transformations.Source: §7 · p. 14

State continuity

  • Only three studies make reachability, memory consistency, or migration their main concern, despite their relevance to mobile, vehicular, and industrial deployments.Most architecture papers assume better connectivity than their target settings can offer.Source: §7 · p. 14

Protocol and tool security

  • Protocol and tool security remains under-evaluated: only [P22] systematically analyzes agent communication protocols, and adversarial evaluation is rare.The corpus also lacks security analyses of edge-resident teams, despite privacy being a main motivation for them.Source: §7 · p. 14

Federated lifecycle management

  • Federated lifecycle guidance is missing on when to federate, handling heterogeneous edge hardware, evaluating update drift, and aligning fine-tuning with governance.Three studies show collaborative edge adaptation works [P14, P17, P33].Source: §7 · pp. 14–15

Human oversight and traceability

  • Studies with human-in-the-loop assistance, explanation, or policy traceability do not establish what should be explainable at each tier or how cross-layer decisions should be audited.Relevant architectures include [P8, P13, P19, P21, P27, P38].Source: §7 · p. 15

Artifact availability

  • Six of 45 studies publish code or data, limiting remeasurement under changed models, hardware, or network conditions and leaving few reference implementations for a shared benchmark.The artifact evaluation of [P25] shows release is practical.Source: §7 · p. 15

Benchmark and reporting

  • The proposed benchmark controls task, continuum, state, governance and security profiles, plus a fixed set of outcomes; it has not yet been implemented.The same variables can be reported now for comparison and later used to configure a shared harness; only six studies release artifacts to build on.Source: §7 · p. 15, Figure 4 · p. 15

Deployment guidance

  • The study provides deployment guidance pairing common IoT constraints with patterns, example studies, and reported or acknowledged costs.Examples are drawn from physical or production evaluations wherever possible, and deployment rows can be combined.Source: §7 · pp. 15–16, Table 9 · p. 16

8. Threats to Validity

The authors identify threats from search terminology, judgment in coding, heterogeneous evaluations, the young and modest corpus, and interpretation-dependent mapping. They describe protocol checks and sensitivity evidence while bounding conclusions to the mapped studies.

Construct validity

  • The search may miss multi-component systems described without agent vocabulary, so corpus coverage cannot be assumed complete in that direction.The search omits bare terms such as multi-agent and IoT; coverage depends on papers using an agent term somewhere in full text.Source: §8 · p. 16

Internal validity

  • Selection, extraction, and classification involve judgment, and borderline cases may be assigned differently despite protocol checks and second-author review.The authors did not compute an inter-rater agreement statistic, though complete coding is published for re-coding.Source: §8 · p. 16

Conclusion validity

  • Because workloads, datasets, hardware, network conditions, and metrics differ, the authors make no cross-study performance comparisons or claims that one architecture outperforms another.The taxonomy is one reasonable structure for these 45 studies, not the only possible classification.Source: §8 · p. 16

External validity

  • The 45-study corpus is a snapshot of literature through March 2026, and findings may not carry over beyond continuum settings.Most primary studies appeared in 2025 and 2026, and 24 of 45 concern IoT or related settings.Source: §8 · p. 17

Reliability

  • The protocol, search strings, selection log, extraction sheet, and classifications are archived, but researchers may still differ on borderline cases.The authors expect the overall structure to remain stable, and report that a sensitivity check supports this for snowballed studies.Source: §8 · p. 17

9. Conclusion

This mapping study classifies 45 primary studies on multi-agent LLM systems across the cloud-edge-IoT continuum, identifying recurring architectures, deployment mechanisms, application settings, and evaluation practices. It finds comparability remains a central obstacle and offers taxonomy, records, and guidance to support IoT deployment decisions.

9. Conclusion

  • The study classified 45 primary studies selected from 831 records retrieved up to March 2026 by architecture, deployment, application domain, and evaluation practice.It also recorded how each system was evaluated.Source: §9 · p. 17
  • Five architectural families and six deployment mechanisms recur across the mapped studies, with more than half targeting IoT-related applications.The 45 studies include 29 physical-hardware evaluations, mostly using open models below 8B parameters on device and edge tiers.Source: §9 · p. 17
  • Comparability is the main obstacle: studies use different workloads, hardware, network conditions, and metrics, while only six release artifacts.Privacy motivates many designs but is directly measured in only two studies; a shared reporting form is proposed as a step authors can take now.Source: §9 · p. 17
  • The taxonomy, study-level records, and deployment guidance are intended to help IoT researchers and practitioners decide how to divide responsibilities and govern systems.The archived protocol and data can be checked and extended.Source: §9 · p. 17

Data Availability

The study’s supporting materials are publicly available through a Zenodo replication archive. The archive provides materials for reproducing study selection and checking classifications and analysis.

Data Availability

  • The Zenodo replication archive publicly provides the review protocol, search strings, selection log, coded extraction sheet, study overview, mapping table, and supplementary materials.The link is given as https://doi.org/10.5281/zenodo. 20631424.Source: Data Availability · p. 17
  • The archive contains information required to reproduce the study selection and verify the reported classifications.Source: Data Availability · p. 17
  • The archived materials also allow inspection of the data behind the taxonomy and analysis.Source: Data Availability · p. 17

CRediT Authorship Contribution Statement

The authors list individual contributions spanning conceptualization, investigation, data curation, validation, writing, and project oversight. Moghaddam is credited with the broadest set of roles.

CRediT Authorship Contribution Statement

Declaration of the Use of Generative AI

The authors used Grammarly and Claude for language editing, LaTeX table formatting, and checks. They state that the research decisions and conclusions remained their own and that authors reviewed AI-edited text.

Declaration of the Use of Generative AI

Primary Studies of the Mapping

The listed primary studies cover agent systems across edge sensing, industrial automation, networking, healthcare, mobility, and supporting infrastructure. Their titles also show recurring attention to orchestration, offloading, privacy, and memory.

Primary Studies of the Mapping

  • Edge-oriented studies address activity summarization, expert SLMs for industrial IoT, smart-home reasoning, and medical advising [P3] [P15] [P11] [P31].The titles also include edge agents for sensor environments and lightweight edge-agent frameworks [P1] [P15].Source: Primary Studies of the Mapping · pp. 19–20
  • Studies address task offloading for collaborative inference of LLM agents at the network edge [P4], forecast-aware auto-scaling for LLM serving on cloud data centers [P32], and distributed memory management for multi-agent systems [P36].Other titles concern cloud-edge collaborative service architecture [P39] and distributed regional agent management with LLMs [P29].Source: Primary Studies of the Mapping · pp. 19–20
  • The cited titles cover explainable cyberthreat mitigation and state analytics [P19], online multi-agent pathfinding [P29], smart manufacturing [P13], and semantic corner-case detection [P43].Source: Primary Studies of the Mapping · pp. 19–20

A. Overview of the Primary Studies

The appendix presents an overview of the 45 included studies, their coding across study dimensions, and a glossary of paper-specific technical terms.

A. Overview of the Primary Studies

  • Table 10 provides an overview of the 45 primary studies included in the mapping.The supplied caption identifies the table’s scope but does not specify its columns.Source: Table 10 · p. 20

B. Coding of the Primary Studies

  • The coding records architecture, deployment, domain, evaluation families, setting, baseline reporting, and public artifacts for the primary studies.Table 11 defines five architecture families, six deployment codes, five domain codes, and five evaluation families; it notes two snowballed supporting records.Source: Table 11 · p. 22, B. Coding of the Primary Studies · p. 23

C. Glossary of Terms and Acronyms

  • The glossary gives concise, domain-specific meanings for terms including offloading, planner–worker orchestration, state continuity, and substrate-oriented control.It also defines multi-agent LLM systems and other terms used in the paper’s agentic-AI and continuum-computing context.Source: C. Glossary of Terms and Acronyms · pp. 23, 25, Table 12 · p. 24

Related papers

Loading 2610.28702v1…