Smart Adaptive Computing Across the Continuum: LLMs in IoT-Edge-Cloud Resource Management
arXiv:2609.09348v1 [cs.DC] 8 Sep 2026
Antonino Vaccarella1,2 1
, Lanpei Li1,2 , Vincenzo Lomonaco3 Massimo Coppola1
, and
Institute of Information Science and Technologies “Alessandro Faedo” (ISTI), National Research Council of Italy (CNR), 56124 Pisa, Italy 2 Department of Computer Science, University of Pisa, 56127 Pisa, Italy 3 Department of AI, Data and Decision Sciences, LUISS University, 00197 Rome, Italy [email protected], [email protected] {lanpei.li, massimo.coppola}@isti.cnr.it
Abstract. Managing resources across IoT, edge, and cloud layers calls for continuous, context-aware decisions under constraints that rarely stay fixed. Deep reinforcement learning (DRL) handles this class of problems well, and large language models (LLMs) are increasingly used to augment DRL pipelines, yet the architectural relationship between the two is seldom made explicit. We build on Wang et al.’s taxonomy [15] of Continuum Orchestration Systems employing DRL techniques and extend it with two further dimensions. The AI Augmentation Paradigm measures how LLMs are exploited, while the Feedback channel captures whether and through which system path the execution feedback returns to the LLM in order to close the MAPE control loop [6] at the LLM Orchestration layer. We apply this taxonomy to six recent system architectures and find a common gap, as none combines full LLM orchestration with full agent-layer feedback in a Cloud Continuum setting. We relate this gap to a missing cross-tier feedback abstraction, bridging the incommensurable per-tier signals and the LLM Orchestrator. Keywords: Cloud Continuum · Resource Management · Agentic AI · Large Language Models · Deep Reinforcement Learning · Control Loop
This version of the contribution has been accepted for publication, after peer review but is not the Version of Record and does not reflect post-acceptance improvements, or any corrections. The work was presented at the 6th workshop on Flexible Resource and Application Management on the Edge (FRAME) 2026, co-located with the 32nd International European Conference on Parallel and Distributed Computing – Euro-Par 2026. The Version of Record will appear in the workshop proceedings volume(s) of Euro-Par 2026. Use of this Accepted Version is subject to the publisher’s Accepted Manuscript terms of use https://www.springernature.com/gp/ open-research/policies/accepted-manuscript-terms.
2
1
A. Vaccarella et al.
Introduction
Modern services no longer run only in homogeneous cloud data centers; operating them across a Cloud Continuum that spans IoT gateways, edge servers, and cloud instances requires continuous decisions about placement, scheduling, scaling, and traffic routing under constraints that shift with load patterns, user mobility, network conditions, and hardware availability. Resource management in the Cloud Continuum is therefore a multi-objective control problem: the system must balance performance and efficiency with policy-level requirements such as user intent, locality rules, and security constraints. Deep reinforcement learning (DRL, or just RL in our context) is well suited to this setting for two reasons. First, it is designed to optimise sequences of decisions over time, which matches the inherently temporal nature of resource management: placement, scheduling, and routing choices made at one instant affect the state of the system at the next. Second, it requires no a priori model of system dynamics, meaning the agent learns directly from interaction with the environment rather than from a hand-crafted mathematical model of how resources behave — an important advantage when the Cloud Continuum is too complex or dynamic to model explicitly. Wang et al. [15] document this trend across more than 100 papers through a two-dimensional taxonomy that separates control scope (SARL vs. MARL) from training paradigm (standard vs. federated). Existing work shows that DRL and MARL are strong tools for fast, local, and adaptive control. However, they do not solve the full orchestration problem in next-generation Cloud Continuum systems. Their policies are often hard for operators to understand, depend heavily on the reward functions and state representations used during training, and struggle with constraints expressed as natural-language intents, compliance rules, or evolving security requirements. This suggests that DRL should be supported by a higher-level reasoning layer. LLM-based agentic systems can provide this layer by interpreting operator intents, reasoning over policy and context, explaining decisions, calling tools, and coordinating specialised agents. In the Cloud Continuum, the role of LLMs is therefore not to replace fast DRL/MARL controllers, but to provide explainable, policy-aware, and adaptive orchestration above them. Recent systems point toward this direction. IntentContinuum [1] uses an LLM for intent-driven resource management across the compute continuum; works such as [5], SALLMA [2] and AgentEdge [4] study LLM-based multi-agent orchestration. There is a shift from isolated LLM decisions to agentic systems that use delegation, tools, and orchestration feedback. These works also raise important design questions: whether LLMs act as direct decision-makers, orchestrators delegating to downstream agents, or closed-loop orchestrators, and whether their integration with DRL results in a genuine feedback loop or merely a one-shot handoff. How do these choices affect resource management across Cloud Continuum? Wang et al. [15] observe that large language models are beginning to appear alongside DRL in network optimisation, but the architectural relationship between the two remains underspecified.
Smart Adaptive Computing Across the Continuum
3
Our contribution in this paper is to address that gap by extending their taxonomy with two further dimensions. The AI Augmentation Paradigm captures whether the LLM delegates execution to autonomous downstream agents, yielding three levels (LLM0–2) from pure DRL to LLM orchestrator systems. The F dimension captures the kind of feedback channel through which execution data returns to the LLM. We apply the extended taxonomy to six recent works to identify existing architectural patterns and highlight gaps in the literature. The works we analyzed so far use the LLM in different roles within the system architecture. From both a system and a functional viewpoint, an LLM processing human input is quite different from a true LLM orchestrator. The kind of control loop that is designed within the system conditions the actual capability of the LLM as a true orchestrator, thus the F dimension is truly relevant in classifying current and future systems. In Sect. 2 we briefly summarize the issues of dynamic resource orchestration for Clouds and Continuum platforms. Sect. 3 discusses the abstract architecture and the classification of LLM-enabled Orchestration solutions. Sect. 4 analyzes the surveyed works with respect to the proposed taxonomy. Sect. 5 and 6 respectively focus on what are today’s gaps and issues in designing such systems, and identify a key need for a mediator functionality bridging the LLM/agents gap. Sect. 7 summarizes our conclusions and future work plans.
2
Cloud Continuum Orchestration
The paradigm of Cloud computing, where all types of computing resources and services are automatically located, negotiated, acquired and orchestrated ondemand, has been evolving from the “simple” management of data-center based services toward including a family of geographically widespread computing devices that help close the proximity gap toward the users and the data sources. Continuum computing platforms are the result of including such a range of devices: data-center based ones, local cloud-like resources, vehicle-based, IoT, and mobile devices, with recent research tapping into esoteric devices like satellitebased ones. The typical constraints of the Cloud orchestration problem are made more complex by the Continuum conditions: we need to manage a multilayer distributed platform, taking into account resource heterogeneity both across the platform layers and within the layers. Multi-tenancy as well as data privacy and locality constraints are pervasive. Applications exhibit uneven dynamic workload and dynamic user behaviour, prompting for autonomic-style, real-time reaction and planning as opposed to steady state system modeling. Orchestration on Continuum platforms implies a dynamic, multi-factor optimization problem with complex, sometimes unstructured constraints. Examples of such constraints are the interpretation of user intent, and the need to cope with security constraints derived from classified vulnerabilities (CVEs) that have to be combined with the configuration of computing, networking and storage devices in order to mitigate vulnerabilities and shield from supply-chain attacks.
4
A. Vaccarella et al.
Several research approaches have been pursued to deal with complex, multifactor optimization and orchestration, including linear and non-linear optimization based ones, model based ones and heuristic approaches. Recent works have addressed the need to react quickly and adapt to complex, unanticipated behavior by resorting to Reinforcement Learning (RL)-augmented agents. Wang et al. [15] survey a large corpus of works exploiting RL agents for Continuum Orchestration, covering both Single and Multiple RL Agents approaches (SARL vs MARL). However, it can be argued that some important features are still impractical or beyond the reach for RL systems, notably as intricate security constraints (those trying to prevent CVE exploitation and supply-chain attacks) and natural language user interaction are sought for. LLMs seem to be able to address these limitations, as [15] already identifies their use as a next research direction for Continuum Orchestration. They organise their taxonomy of DRLbased Cloud Continuum resource management systems along two dimensions: Control Scope separates Single-Agent Reinforcement Learning (SARL) from Multi-Agent RL (MARL). SARL uses one global policy, such as DQN, PPO, A3C. MARL uses multiple agents that are either trained independently or employ the same model1 . Training Paradigm separates standard training, where data can be shared and is possibly centralized for the training, from federated training, where learning is coordinated through model update methods such as Federated Averaging (FedAvg), or gossip techniques, without ever centralising or sharing the raw data. This bidimensional taxonomy captures how DRL controllers are organized and trained. It does not, however, describe the architectural role of an LLM when language model components are added to the control loop.
3
Generic architecture and AI Augmentation Paradigm
In a nutshell, the Orchestrator in Cloud and Continuum platforms is the component solving the problem of devising a good allocation plan for one or more distributed applications over the set of resources within the platform, as well as initiating the actions required by the plan. As the needs of the applications and the availability of the devices will evolve over time, dynamic orchestration is typically needed in the Continuum [14]. Since our work is at the crossroad of AI and Distributed Computing, we shall underline that in the AI field an Orchestrator coordinates multiple AI entities (e.g. RL agents or distinct LLM agents) to accomplish a coordinated task. While both definitions may apply in some of the papers we discuss, for clarity we will always use the former one. Fig. 1 illustrates a generic architecture for Continuum LLM-based orchestration. We see the abstract form of such systems in (Figure 1a), where the layer of controlled execution systems is labeled Environments and two conceptual layers 1
For example, in Centralised Training with Decentralised Execution (CTDE) methods, agents share global information during training to coordinate learning but act solely on their own local observations once deployed. Representative CTDE methods include VDN [13], QMIX [11], and MADDPG [8].
Smart Adaptive Computing Across the Continuum
5
Orchestration Layer
···
LLM1
LLMx structured feedback
structured feedback
directives / subgoals
LLM Orchestrator Analyse & Plan
Agentic Layer
Ag1
Ag2
···
Agy
Mediator
structured feedback
Agent1
obs. / rewards
actions
Agent2
···
Agentn obs. / rewards
actions
Environments
Env1
directives / subgoals
···
Envz
(a) Generalised architecture
Env1
Env2
···
Envn
(b) Example of concrete architecture
Fig. 1. (a) Generalised two-layer architecture (x LLMs, y agents, z environments). (b) Example of architecture (LLM2 type) with one orchestrator, n agents, and n environments.
are defined above it: an Orchestration Layer housing one or more LLMs that analyse, plan, and issue directives or subgoals; and an Agentic Layer comprising one or more specialised agents that receive those directives, act within their environments, and return structured feedback upward. The cardinalities x, y, z of the layers do not need to match with each other, and the actual interaction graph among the entities is not specified. A concrete instantiation of the abstract architecture is shown in Fig. 1b, where the Orchestration layer is a single-LLM orchestrator, coordinating n agents in a 1-to-1 relationship with n controlled environments. Here the centralized LLM issues subgoals while agents interact with the environments and return observations and data as feedback. Control loops towards the LLM — A control system is a closed-loop one when the controller’s decisions are updated from execution feedback, as opposed to being open-loop control where no feedback is assumed. In autonomic computing, the reference structure of control loops is the Monitor–Analyse–Plan–Execute (MAPE) cycle [6]. For LLM-augmented DRL systems, although an open-loop control style is possible, a closed control loop allows the system to refine its reactions, achieving dynamic adaptation [16]. The key questions become then what kind of feedback is there, how is it generated and from/to where in the system does the feedback travel. Our goal in this work is to analyze the overall SW architecture of Continuum orchestration, so we will not focus on the specific internal architecture of the LLM-augmented modules. We focus instead on the control loops that bring information to the topmost layer of the system in Fig. 1a, providing feedback to an LLM-augmented controller that is (part of) the Continuum orchestrator to help refine its reactions. We distinguish orchestration control loops by the way they collect information, e.g., (i) from the controlled systems, through adapter interfaces but without any processing, (ii) from the agent layer, letting the agents collect, filter and struc-
6
A. Vaccarella et al.
ture the feedback, (iii) from both the controlled systems and the agents, but exploiting dedicated agent(s)/service(s) for information filtering and processing. Dimension F — Feedback channel. We identify four choices (F0–F3) for the channel returning execution information to the LLM, resting on two criteria: (a) whether feedback from the real execution platform reaches the LLM at all after agents have acted, and (b) who mediates it. F0 — None. No feedback from the real environment reaches the LLM after execution. Internal mechanisms within the orchestrator — critics, offline simulators, self-consistency checks — operate on virtual or pre-execution data and are not considered environmental feedback. F1 — Platform. Environment data reaches the LLM directly, or through a deterministic non-autonomous wrapper, from execution-platform APIs: Kubernetes event streams, SDN controller statistics, monitoring dashboards. No autonomous agent mediates this data before it arrives. F2 — Sub-agent. Feedback is produced and routed by executing downstream sub-agents rather than drawn directly from platform APIs. The LLM receives a processed view of execution outcomes, filtered and structured by agents whose primary function is carrying out tasks, not reporting on them. F3 — Dedicated mediator. A component dedicated exclusively to evaluation — distinct from any executing agent — receives raw platform and agent output and distils it into structured feedback for the orchestrator: reward signals, performance scores, alignment assessments. Our viewpoint is that the adoption of multiple LLMs, actor-critic approaches, and simulation-based validation within the orchestrator does not form a closedloop for control from this viewpoint, as these solutions employ virtual feedback from within the Orchestrator itself. Local feedback from execution to the RL agents is not considered either, unless it is explicitly forwarded to the LLM. LLM integration — The depth of LLM integration is captured by a single structural question: does the LLM delegate execution to autonomous downstream agents? Three levels result. LLM0 — DRL Only. No LLM component is present. Covers all of [15]. LLM1 — Direct LLM Actor. The LLM is the sole autonomous decisionmaker: it receives context, produces decisions, and enacts them through APIs, tools, and components. No autonomous downstream agents affect these goals. LLM2 — LLM Orchestrator. The LLM delegates task execution to a layer of autonomous downstream agents (RL-based, LLM-based, or hybrid). It assigns objectives or subgoals but does not directly act on the environment: agents execute independently within their assigned scope. Whether and how execution outcomes reach back to the LLM is captured by dimension F (Fig. 1).
Smart Adaptive Computing Across the Continuum
4
7
Extending the Taxonomy towards Upcoming LLM Approaches
Our extended taxonomy keeps Wang et al.’s [15] two axes Control Scope and Training Paradigm and adds two further ones, namely the AI Augmentation Paradigm (LLM) and the Feedback Channel (F) as defined in Sect. 3. Table 1 shows the resulting density map along the first three dimensions. Control scope captures the multiplicity of autonomous decision-making entities, while the LLM level states their kind. At LLM0, these correspond to SARL and MARL in the original DRL taxonomy. At LLM1–LLM2, the controller may be anything (e.g., a LLM, a RL agent), hence the broader SA/MA labels. This presentation is an architectural taxonomy, not a performance ranking. Its purpose is to show what combinations already exist and what parts of the design space remain underexplored. As we can see, LLM1–LLM2 extend into largely unpopulated territory; within this space, the LLM2-MA row concentrates the most significant structural gaps, which are examined in Section 5. None of the LLM-based works employ federated learning, so all recent papers we classify fall within the standard (non-federated) column of the taxonomy: the LLM is never trained, and only the three LLM2 systems train downstream RL agents. Three sit at LLM1, three at LLM2; of the latter, only two close the feedback loop at the orchestration level, as we show in Table 2 about the interplay of the LLM level with the F dimension. Each paper in the following is discussed also in relation to Fig. 1a, tracing what components occupy the Orchestration Layer, whether an autonomous Agentic Layer is present, and how — or whether — execution outcomes are fed back to the LLM. LLM1×F0 : LLM without platform feedback. AgentEdge [4] automates edgecloud resource management through a sequential chain of four specialised LLM Table 1. Density map of the Control Scope, Training Paradigm, and AI Augmentation Paradigm dimensions of the taxonomy. dense cell; sparse; empty Std-SA
Std-MA
Fed-SA
Fed-MA
LLM0
>50 works
>30 works
∼12 works
∼8 works
LLM1
[1]
[2] [4]
—
—
LLM2
—
[5] [9] [10]
N/A
—
Table 2. Classification of the six works by LLM level and feedback dimension F. Cells marked N/A are structurally impossible (F2/F3 require downstream agents, so LLM2). F0
F1
F2
F3
LLM1
[4]
[1] [2]
N/A
N/A
LLM2
[5]
—
[10]
[9]
8
A. Vaccarella et al.
agents — Intent, Observability, Planning, and Infrastructure Action — each implemented as an independent model call whose output feeds the next stage. All four stages reside in the Orchestration Layer, so the Agentic Layer is absent; the system is therefore LLM1, regardless of the number of model calls. The Planning stage runs an ActSimCrit loop entirely on virtual state — proposing, simulating on an offline infrastructure model, and critiquing until the plan passes an LLM-based quality check — before the Infrastructure Action Agent executes on live infrastructure. At that point no signal travels back up the chain, leaving the Orchestration Layer without any post-execution information (F0). LLM1×F1 : LLM with direct platform feedback. Despite targeting different problems, IntentContinuum [1] and SALLMA [2] share the same spot in our classification. IntentContinuum monitors SLO compliance in a Kubernetes cluster. On each violation, Management and Orchestrator (MANO) polls three platform APIs — Kubernetes, ONOS, and sFlow-RT — and packages the result as a structured JSON payload for GPT-4o, which diagnoses the root cause and selects a corrective action. GPT-4o alone occupies the Orchestration Layer; MANO is a deterministic dispatcher, not an autonomous agent, so the Agentic Layer is empty (LLM1). Feedback reaches the model directly from platform APIs, with no autonomous mediator between environment and orchestrator (F1). SALLMA is a general-purpose reference architecture for intent-driven AI workflows. An Intent Management Agent parses operator requests; a Workflow Management Agent decomposes them into a cognitive workflow executed inside Kubernetes-managed containers via LangChain, invoking specialised LLM instances with access to RAG stores and persistent memory. All components operate under the Workflow Management Agent’s direct authority and pursue no independently assigned goals, so the entire pipeline sits in the Orchestration Layer (LLM1). Execution results are written to a passive SQL/NoSQL Knowledge Layer from which the Workflow Management Agent reads; a passive store does not mediate feedback autonomously, placing the channel at the same platform level as IntentContinuum (F1). LLM2×F0 : LLM and Agents, no direct platform feedback. Habib et al. [5] target intent-based 5G Open Radio Access Network (RAN) automation. ALBERT [7] classifies operator intents via few-shot prompting; a Transformer predictor validates them against a traffic forecast; the validated goal is then handed off to a hierarchical DQN (h-DQN) that orchestrates five DRL RAN applications. ALBERT and the Transformer sit in the Orchestration Layer, while the h-DQN and its applications form the Agentic Layer, making this an LLM2 system. The delegation, however, is a one-shot handoff followed by executing an HRL algorithm. As agent-layer outcomes never return to the LLM, this system is an open-loop orchestrator (F0). LLM2×F2 : LLM with Agents providing platform feedback. CyberOps-Bots [10] targets autonomous cyber-resilience in cloud networks. A Qwen3-8B orchestrator plans multi-step defence responses via ReAct [16] and dispatches four types
Smart Adaptive Computing Across the Continuum
9
of heterogeneous RL agents — Fortify, Recover, Purge, and Block — deploying multiple instances dynamically across six network subnets (LLM2). Qwen3-8B is the single occupant of the Orchestration Layer; the four RL agents populate the Agentic Layer; the network regions are the Environments. After each action, a Perception module converts the updated network state to natural language, logs it in Short-Term Memory, and injects it into the LLM’s context on the next planning cycle. The feedback is real and post-execution, but the only mediator is the executing agent tier itself, which places the system as of F2 type. LLM2×F3 : LLM, Agents and Mediated Platform Feedback. AURA [9] couples Claude Sonnet 4 with RL agents deployed at individual cellular base stations (LLM2). The LLM generates subgoals and reward-shaping parameters; agents accept or reject this guidance through a trust mechanism. Claude Sonnet and the Centralised Alignment Controller (CAC) sit in the Orchestration Layer; the RL agents at base stations form the Agentic Layer; the base stations are the Environments. After each cycle, agents report actions and outcomes to the CAC, which computes a delayed structured reward in [−1, +1] — assessing network efficiency, fairness, and adaptability — and returns it to the LLM. What sets AURA apart from CyberOps-Bots is the role of the CAC: it never issues commands to base stations and is architecturally separate from the agents it assesses, its sole function being evaluation. That separation — a dedicated mediator distinct from the executing tier — is precisely what qualifies the channel as F3. AURA operates within a single tier of cellular base stations, without multi-tier heterogeneity or Cloud Continuum scope.
5
Gap Analysis and Research Directions
Based on the classification presented in the previous section, key gaps and some trends emerge in the limited amount of current literature: (i) Control loops towards the LLM are rare. Four out of the six classified works provide the LLM with no post-execution environmental feedback (AgentEdge, Habib et al.) or only with platform-level signals (IntentContinuum, SALLMA). Only AURA (F3) and CyberOps-Bots (F2) close the agent-layer feedback loop, both using the LLM as a full orchestrator (LLM2 class). (ii) Current LLM2 systems with agent-layer feedback do not address the Cloud Continuum. AURA and CyberOps-Bots demonstrate that this architectural pattern is viable, but both remain confined to a single deployment tier. The challenge of Continuum platforms remains unaddressed in many key aspects, like multi-tier compute heterogeneity, containerised workload placement, SLO management, resource tenancy, cost models, and SDN-based traffic routing. Structured post-execution feedback has emerged only in single-tier domains, where the feedback signal has a natural, well-defined form that Cloud Continuum platforms do not provide. (iii) No work combines LLM orchestration (LLM2) with federated training of the agent layer, but data privacy and locality improvements are
10
A. Vaccarella et al.
already needed. Closing the feedback loop raises a data-privacy concern that promotes federated learning techniques. While no current system yet classifies as LLM2×MA×Federated, two of the works look for improved locality exploitation. AgentEdge identifies federated orchestration protocols as a primary future direction, and CyberOps-Bots explicitly names LLM centralization as its primary scalability concern. We expect that the combination of choices LLM2×MA×Federated will soon be explored, but filling the voids in our classification will require addressing at least three engineering challenges still absent from the surveyed literature. Latency mismatch. Directly deploying LLMs for fine-grained, real-time control remains infeasible due to their computational overhead and latency [9]. Inserting the LLM on the critical path would stall the control loop; the gap must therefore be absorbed structurally — for instance, by having the LLM operate asynchronously on episode summaries while quicker, local agents continue under the last issued subgoal or reward-shaping signal. Cost of LLM involvement. The cost here is monetary: each orchestration step is a billed API call. AURA, for instance, drives its orchestrator with Claude Sonnet 4 [9], priced at $3/$15 per million input/output tokens (see https://platform.claude.com/docs/en/about-claude/pricing). At a per-step prompt of, say, 10,000 input and 1,000 output tokens, one call and one cycle cost about $0.05, but the total cost scales with control frequency and the number of agents, easily reaching hundreds of dollars per day. A thresholdtriggered policy consults the LLM only when feedback deviates beyond a defined margin from the current directive, otherwise leaving the agents running under the last directive. Cutting the number of paid calls this way is a recognised approach to lowering LLM inference cost [3], and may allow extended open-loop stretches without significant performance loss. Feedback abstraction. Execution outcomes must be compressed into a promptsized representation that carries enough information to revise a directive [12]. In single-tier domains agents typically operate over a largely homogeneous KPI space; in the Cloud Continuum, by contrast, IoT, edge, and cloud agents tend to expose heterogeneous and often incommensurable metrics, and, to the best of our knowledge, a cross-tier feedback abstraction that unifies them has not yet been established.
6
Toward Closed-Loop LLM Orchestration in the Cloud Continuum
Across the surveyed systems, the LLM plays the same role regardless of structural differences: it is restricted to interpretation, planning, and cross-layer reasoning, while resource control remains with RL policies or with deterministic platform components. Three patterns recur. In a semantic front-end, the LLM compiles operator intent into a machine-executable goal and then hands execution off (IntentContinuum, Habib et al.). In a workflow pipeline, several LLM stages
Smart Adaptive Computing Across the Continuum
11
produce a structured deployment plan (SALLMA, AgentEdge). In a strategic orchestrator, the LLM issues subgoals or reward-shaping signals and revises them as agents report back (AURA, CyberOps-Bots). Only this third pattern keeps the model coupled to a delegated agent layer after the first directive, so it is the only one that can support an agent-mediated control loop at the orchestration level (F2/F3). This is why every F2/F3 system in our survey is an LLM2 orchestrator, while no front-end or pipeline goes beyond F1. The same observation accounts for the gap identified in Section 5: no LLM2 system with F2 or F3 feedback addresses the Cloud Continuum. The three obstacles share a single cause: a strategic orchestrator cannot yet operate across the Continuum because nothing translates the heterogeneous per-tier signals into a unified feedback abstraction the model can act on. AURA and CyberOps-Bots each build such an abstraction within a single tier, but neither needs one that spans the Continuum. Our generic reference architecture in Fig. 1 includes such a cross-tier feedback abstraction as a Mediator component. As a layer of tier-specialised RL agents is supervised by the orchestration layer, each agent trained on its own metrics and actions, one or more mediator instances collect the diverse outcomes. The mediator extends the role of AURA’s Centralised Alignment Controller from a single-tier feedback provider to a cross-tier one: it ingests heterogeneous per-tier signals and produces a structured representation that pairs performance scores with the per-tier context the orchestrator needs to revise its directives. Without this abstraction, incommensurable per-tier signals would leave the orchestrator unable to determine which tier or policy requires adjustment; the cross-tier mediator is therefore the structural prerequisite for closing the loop across the Continuum. Like the CAC in AURA, it is kept apart from the agents it evaluates, and that separation places the channel at F3.
7
Conclusion
This paper addressed a relationship that the DRL literature on Continuum resource management had left implicit: the architectural role an LLM assumes once it joins a control loop that DRL and MARL agents already populate. We extended the taxonomy of Wang et al. [15] with two further dimensions capturing the AI Augmentation Paradigm and the Feedback Channel, the latter stating whether and through which component the execution feedback returns to the orchestrator. When applied to six recent systems, the taxonomy isolated a specific gap. Closed-loop orchestration exists only within a single resource tier, while intent-driven Continuum management exists only as open-loop control or with platform-level feedback. Joining the two approaches in a multi-agent LLM orchestrator closing the loop across IoT, edge, and cloud is still untried. This reflects a missing feedback abstraction rather than a settled negative result. The components of closed-loop Continuum orchestration are individually available, yet none of the surveyed systems combines them across the heterogeneity that defines the Continuum. Two research targets follow. The primary
12
A. Vaccarella et al.
— closing the feedback loop in the LLM2-MA-Standard Cloud Continuum cell — was formally characterized: a mediator function is needed to reconcile heterogeneous signal sources towards the LLM. The secondary aim, which we regard as future work, is to extend the taxonomy to future LLM orchestrators using new solutions, e.g., an agent layer with distributed, federated or continual learning. Acknowledgments. This research was partially supported by the FIS2 Grant from the Italian Ministry of University and Research (MUR), Grant No. FIS2023-03382, under the project “Continual, Decentralized Compositionality for Sustainable Artificial Intelligence” with Prof. Vincenzo Lomonaco serving as Principal Investigator (PI).
References 1. Akbari, N., Grundy, J., Cheema, A., Toosi, A.N.: IntentContinuum: Using LLMs to Support Intent-Based Computing Across the Compute Continuum. In: 2025 IEEE International Conference on Web Services (ICWS). pp. 573–583 (Jul 2025). https://doi.org/10.1109/ICWS67624.2025.00079, ISSN: 2836-3868 2. Becattini, M., Verdecchia, R., Vicario, E.: SALLMA: A Software Architecture for LLM-Based Multi-Agent Systems. In: 2025 IEEE/ACM International Workshop New Trends in Software Architecture (SATrends). pp. 5–8 (Apr 2025). https: //doi.org/10.1109/SATrends66715.2025.00006 3. Chen, L., Zaharia, M., Zou, J.: Frugalgpt: How to use large language models while reducing cost and improving performance. arXiv preprint arXiv:2305.05176 (2023) 4. Gort, B., Kibalya, G.M., Antonopoulos, A.: AgentEdge: Agentic AI for Service Orchestration in the Edge-Cloud Continuum. TechRxiv 2025(0812) (2025). https: //doi.org/10.36227/techrxiv.175503000.00051702/v1 5. Habib, M.A., Iturria Rivera, P.E., et al.: LLM-Based Intent Processing and Network Optimization Using Attention-Based Hierarchical Reinforcement Learning. In: 2025 IEEE Wireless Communications and Networking Conference (WCNC). pp. 1–6 (Mar 2025), DOI: 10.1109/WCNC61545.2025.10978505, ISSN: 1558-2612 6. Kephart, J.O., Chess, D.M.: The vision of autonomic computing. IEEE Computer 36(1), 41–50 (Jan 2003) 7. Lan, Z., Chen, M., Goodman, S., Gimpel, K., Sharma, P., Soricut, R.: Albert: A lite bert for self-supervised learning of language representations. CoRR abs/1909.11942 (2019), https://arxiv.org/abs/1909.11942 8. Lowe, R., Wu, Y., Tamar, A., et al.: Multi-agent actor-critic for mixed cooperativecompetitive environments. In: Advances in Neural Information Processing Systems 30 (NeurIPS 2017). pp. 6382–6393 (2017), ISBN: 9781510860964 9. Nourzad, N., Zong, M., Krishnamachari, B.: AURA: Adaptive Unified Reasoning and Automation with LLM-Guided MARL for NextG Cellular Networks (Oct 2025). https://doi.org/10.48550/arXiv.2511.17506 10. Peng, Y., Hu, H., Li, F., Cao, X., Jiang, Y., Tang, J., Nan, G., Liu, Y.: Enhancing Cloud Network Resilience via a Robust LLM-Empowered Multi-Agent Reinforcement Learning Framework (Jan 2026), https://arxiv.org/abs/2601.07122v1 11. Rashid, T., Samvelyan, M., et al.: QMIX: Monotonic value function factorisation for deep multi-agent reinforcement learning. In: Proc. of the 35th Intl. Conf. on Machine Learning (ICML 2018). Proceedings of Machine Learning Research, vol. 80, pp. 4295–4304. PMLR, Stockholm, Sweden (2018)
Smart Adaptive Computing Across the Continuum
13
12. Shinn, N., Cassano, F., et al.: Reflexion: language agents with verbal reinforcement learning. In: Advances in Neural Information Processing Systems. vol. 36, pp. 8634– 8652. Curran Associates, Inc. (2023), ISBN: 9781713899921 13. Sunehag, P., Lever, G., et al.: Value-decomposition networks for cooperative multiagent learning based on team reward. In: Proc. of the 17th Intl. Conf. on Autonomous Agents and MultiAgent Systems. pp. 2085–2087. Intl. Foundation for Autonomous Agents and Multiagent Systems, Stockholm, Sweden (July 2018) 14. Ullah, A., Kiss, T., Kovács, J., Tusa, F., Deslauriers, J., Dagdeviren, H., Arjun, R., Hamzeh, H.: Orchestration in the Cloud-to-Things compute continuum: taxonomy, survey and future directions. Journal of Cloud Computing 12(1), 135 (Sep 2023). https://doi.org/10.1186/s13677-023-00516-5 15. Wang, Z., et al.: Deep Reinforcement Learning for Resource Management in IoTEdge-Cloud Computing Continuum: A Taxonomy and Future Directions (2026), https://www.buyya.com/papers/DRL-RM-Continuum2026.pdf, under review 16. Yao, S., Zhao, J., et al.: ReAct: Synergizing Reasoning and Acting in Language Models (Mar 2023), DOI: 10.48550/arXiv.2210.03629