Can We Rely on Language Models to Orchestrate Services across the Edge-Cloud Continuum?

1

Can We Rely on Language Models to Orchestrate Services across the Edge–Cloud Continuum?

arXiv:2610.40477v1 [cs.DC] 29 Oct 2026

Zhenghao Wu, Ruihai Dong, Reza Farahani, Hamed Haddadi, Omer Rana, and Hadi Tabatabaee Malazi

a useful recommendation may still be infeasible, unauthorized, unexecuted, or unverified. The question therefore shifts from whether LMs can generate plausible orchestration outputs to when LM-enabled service orchestration can be relied upon, which depends on the supported decision, the authority and assurance boundary around action, and the empirical evidence behind the claimed system effect. Existing surveys cover closely related domains, including continuum orchestration, LM-enabled network and service management, AIOps, and agentic operations. Kokkonen et al. [4] provide a broad account of orchestration across the device–edge–cloud continuum, emphasizing autonomy and intelligence in continuum orchestration. Boateng et al. [5] survey LLM-enabled communication, network, and service management across mobile, vehicular, cloud-based, and fog/edge-based network environments. Zhang et al. [6] examine LLM-based AIOps across data sources, tasks, methods, and evaluation, whereas Bilal et al. [7] analyze agentic NetOps and AIOps through architectures, autonomy, operational control, assurance, evaluation, safety, and security. These surveys organize the literature primarily by continuum paradigm, network or AIOps task, LM application, or operational agent. Although they examine autonomy, assurance, I. I NTRODUCTION Delivering dependable services across the edge–cloud and evaluation, the orchestration decision itself is not their continuum requires coordinated decisions about where primary unit for relating continuum-specific constraints to LM workloads execute, how resources are allocated, and how responsibility, downstream authority, and empirical evidence. services adapt at runtime. These decisions are coupled: a We adopt the LM-enabled service-orchestration decision as the placement that satisfies a latency objective can become unit of comparison, tracing managed state, constraints, and unsuitable as workload or connectivity changes, while a local feasible actions through LM participation, downstream control, adaptation may affect dependent services elsewhere in the and evaluated outcomes. This distinguishes deployment context continuum [1]. Therefore, orchestration must translate high- from decision-relevant continuum constraints and reveals where level objectives into operational changes while considering empirical evaluation falls short of the claimed orchestration heterogeneous resources, distributed state, and changing capability. Table I summarizes the comparison. This framing leads to three research questions. constraints. This translation layer provides a natural entry point for language models (LMs) in orchestration. • RQ1: Which orchestration decisions do LMs support? LMs can interpret natural-language objectives and This question identifies the orchestration problems, heterogeneous operational data, and they can also reason, plan, decision variables, and continuum constraints represented and interact with managed systems [1]–[3]. Once their outputs in the literature. influence orchestration, model capability alone is insufficient: • RQ2: How are LM responsibility, operational

Abstract—Service orchestration across the edge–cloud continuum increasingly uses language models (LMs) to translate intents and operational evidence into scheduling, configuration, diagnosis, and remediation decisions. Yet, useful model outputs do not by themselves establish dependable orchestration: reliability also depends on where the LM enters the decision process, what authority it is granted, how actions are constrained, and what system-level evidence supports the claimed effect. Existing surveys provide limited synthesis of the links between continuumspecific orchestration decisions, LM responsibility, operational authority, assurance controls, and supporting empirical evidence. We systematically review 39 primary studies and develop a fivedimensional analytical framework for connecting system context, orchestration decisions, LM agency, operational safeguards, and evaluation evidence. The synthesis reveals predominantly hybrid designs in which LMs support interpretation, candidate generation, and mitigation planning, while downstream components commonly retain feasibility enforcement and execution authority. Bounded closed-loop remediation is emerging, but continuum-specific constraints remain unevenly represented in decision formulations, and production-scale evidence across heterogeneous edge–cloud environments remains limited. These findings suggest that reliance on LM-enabled orchestration depends on aligning decision constraints, operational authority, safeguards, and evaluation evidence with the claimed system effect.

Zhenghao Wu, Ruihai Dong, and Hadi Tabatabaee Malazi are with the School of Computer Science, University College Dublin, Ireland. E-mail: Zhenghao.Wu@ucdconnect.ie, {Ruihai.Dong, Hadi.TabatabaeeMalazi}@ucd.ie Reza Farahani is with the Distributed Systems Group (DSG), TU Wien, Austria. E-mail: R.Farahani@dsg.tuwien.ac.at Hamed Haddadi is with the Department of Computer Science, University of Oxford, UK. E-mail: hamed.haddadi@cs.ox.ac.uk Omer Rana is with the School of Computer Science and Informatics, Cardiff University, UK. E-mail: RanaOF@cardiff.ac.uk (Corresponding author: Hadi Tabatabaee Malazi.)

authority, and assurance controls distributed across the orchestration decision path? This question traces LM decision roles and downstream handoffs, including which components validate, constrain, authorize, or execute consequential actions. • RQ3: What empirical evidence supports the claimed effects and operational maturity of LM-enabled orchestration? This question examines the evaluated

2

TABLE I P OSITIONING OF THIS SURVEY AGAINST CLOSELY RELATED SURVEYS . Context Survey Kokkonen et al. [4] Boateng et al. [5] Zhang et al. [6] Bilal et al. [7] This survey

RQ1: Orchestration decisions

RQ2: LM integration

RQ3

Cross-cutting

Edge–cloud Resource / Config. / Resilience / External Roles / Operational Evaluation Sustainability continuum workload policy operations workflow authority assurance evidence Security / SDG ✓ ✓ △ △ ✓

✓ ✓ — — ✓

△ ✓ △ ✓ ✓

△ ✓ ✓ ✓ ✓

△ △ — — ✓

— △ △ ✓ ✓

△ △ — ✓ ✓

— △ ✓ ✓ ✓

△ ✓ — ✓ ✓

△ — — — ✓

Legend: ✓ = used as a dedicated analytical dimension across the survey; △ = discussed substantively but only within selected tasks, examples, or subsections; — = not treated as a substantive analytical dimension. Note: “External workflow” means a service or deployment workflow managed by the orchestration system, not an internal multi-agent or reasoning workflow.

endpoint and whether it supports the decision or system outcome implied by the claim.

future research directions (§VII) and conclusion (§VIII). II. BACKGROUND Edge–cloud orchestration coordinates heterogeneous services and infrastructure through decisions that affect workload placement, resource allocation, configuration, policy, workflow progression, and recovery state. Figure 1 summarizes the decision chain and SPACE dimensions this survey uses to compare decision context, LM responsibility, operational authority, assurance mechanisms, and supporting evidence.

We answer these questions through a systematic mapping of 39 primary studies, organized using the five-dimensional SPACE framework: System Context, Problem and Decision, LM Agency, Control and Assurance, and Evidence and Maturity. The synthesis reveals predominantly hybrid designs in which LMs support semantic interpretation, candidate generation, and mitigation planning, while downstream components commonly retain feasibility enforcement, authorization, and privileged A. Orchestration Scope execution. Emerging closed-loop remediation remains bounded The edge–cloud continuum joins execution environments by action, resource, and execution scopes. Evaluations span that differ in compute capacity, latency, connectivity, artifact validity, decision quality, executed interventions, and locality, observability, administrative control, and exposure verified recovery, supporting different levels of claimed to changing workloads. Orchestration manages services, orchestration capability. workloads, resources, configurations, policies, workflow states, The survey makes the following contributions: and failure-recovery states across these environments; therefore, 1) We use the LM-enabled service-orchestration decision a feasible placement or adaptation can shift as network and as our unit of analysis, linking formulation, managed resource conditions evolve [1]. state, LM participation, operational authority, assurance We use LM as an umbrella term encompassing both large boundaries, and evidence supporting claimed effects. and compact models used in edge–cloud orchestration, whether 2) Applying this perspective, we show when edge– deployed locally, at the edge, in the cloud, or accessed as an cloud continuum conditions merely provide deployment external service. Rather than treating the LM as an end-tocontext and when they actively shape orchestration end system replacement, we position it as a participant in a decisions, examining how managed states, decision broader orchestration pipeline. Our scope includes LM outputs constraints, feasible actions, and state transitions that either materially shape orchestration choices or supply differ across resource/workload, configuration/policy, decision-relevant information used to formulate, select, validate, resilience/operations, and workflow orchestration. or revise such choices. This survey excludes generic model 3) We distinguish LM responsibility from operational deployment and isolated monitoring or summarization without authority by tracing who selects, authorizes, and executes an identifiable orchestration role. consequential actions, whether independent safeguards constrain them, and how post-action recovery is handled. B. Decision Chain We conceptualize orchestration as a unified functional chain: 4) We assess whether reported evaluations support claimed orchestration capabilities, distinguishing artifact validity, Observe/Ground → Interpret/Formulate → Generate/Plan → decision quality, executed interventions, and verified Validate → Select → Authorize → Act → Monitor/Recover. Although implementations may merge, skip, revisit, or recovery under stated operating conditions. 5) We identify security and sustainability gaps in LM- parallelize these steps, the chain allows us to isolate distinctions enabled orchestration, including the distinction between that architectural labels often obscure. LM participation is decision-enabling when the model security-oriented uses and the security of the LM-mediated orchestration process itself, incomplete accounting of LM produces evidence, interpretations, objectives, explanations, and control overheads, and limited evidence on carbon or candidate sets for selection by a human operator or nonLM decision component. It is decision-direct when the model intensity and hardware lifetime. The remainder of this survey presents the background specifies an action, plan, policy, or critical parameter as the (§II) and methodology (§III), followed by the three research proposed orchestration decision. We then distinguish this questions on orchestration decisions (§IV), LM agency and decision responsibility from operational authority by recording assurance (§V), and evaluation evidence (§VI), and finally the whether the output is selected for action, authorized, executed, or verified after execution.

3

System context

End devices

Continuum conditions

capacity

Decision chain

Observe / Ground

latency

Edge nodes connectivity

Interpret / Formulate

Generate / Plan

locality

telemetry access

Validate

Select

Cloud infrastructure policy constraints

Authorize

resource availability

Act

Planning

(a) Context and decision process

Monitor / Recover

Research Questions RQ1–RQ3 Search Strategy 8 task + 2 supplementary queries

Stages may merge, be skipped, revisited, or run in parallel.

Database Retrieval 1,808 records

(b) SPACE analytical framework

Evidence extraction

RQ1: System Context + Problem and Decision

LM Agency

Control and Assurance

RQ2: LM Agency + Control and Assurance

Deduplication 1,443 retained (-365)

Evidence and Maturity RQ3: Evidence and Maturity

Fig. 1. Decision chain, SPACE, and their mapping to the research questions.

C. SPACE Framework To provide a common basis for comparing heterogeneous implementations, SPACE organizes the synthesis along five dimensions: System Context, Problem and Decision, LM Agency, Control and Assurance, and Evidence and Maturity. These dimensions specify where decisions arise, which system states can change, how responsibility is distributed, which controls constrain progression toward action, and what empirical evidence supports each claim. The three research questions map directly onto this framework. RQ1 characterizes the system contexts and orchestration decision problems captured by System Context and Problem and Decision. RQ2 examines how responsibility, authority, and safeguards are distributed along the decision path, linking LM Agency with Control and Assurance. RQ3 evaluates Evidence and Maturity by asking whether reported environments, empirical endpoints, comparators, and outcomes support the claimed orchestration effects.

Conduct

Problem and Decision

Reporting

System Context

Desk Screening 1,200 retained (-243) LLM-assisted Screening 421 candidates (-779) Full-text Eligibility Assessment

Forward/backward Snowballing

Full-text assessment + snowballing 41 candidate studies

Deduplication + Screening

Included Studies 39 primary studies

Excluded 2 magazine articles

Structured Evidence Extraction + Comparative Synthesis

Fig. 2. Study identification, screening, inclusion, and synthesis workflow.

We then screened the remaining 1,200 records using two separately prompted assessments with the same model, deepseek-v4-flash (preview), with temperature 0 and structured JSON output. Each assessment received the available bibliographic metadata, title, and abstract and applied the same scope criteria; the second assessment did not receive III. S URVEY M ETHODOLOGY the first assessment’s decision. The two assessments agreed that The survey followed three stages: planning, conduct, and 449 records were potentially eligible and disagreed on eligibility reporting, covering search design, study identification and for 85 records (7.1% of the screened set). Records advanced screening, and evidence extraction and synthesis. Figure 2 to full-text assessment only when both assessments judged summarizes the workflow, inspired by PRISMA 2020 [8]. them potentially eligible with confidence ≥ 0.8, supplied valid textual evidence supporting the LM role and orchestration relevance, and raised no unresolved publication-type ambiguity. A. Study Selection This joint advancement rule produced 421 candidates for fullWe used Semantic Scholar as the primary retrieval source text assessment. and considered publications from 2023 through July 2026. The 421 candidates were then manually assessed at full text Venue and source metadata were cross-checked against publisher records, including IEEE Xplore and the ACM against the stated scope criteria. Eligibility was determined from Digital Library. The search used eight primary query families the reported operational role of the LM and supporting full-text covering orchestration, scheduling, placement/offloading, evidence rather than keyword occurrence alone. We included scaling, resource management, remediation, intent/policy state-changing orchestration decisions as well as diagnosis translation, and zero-touch operations, supplemented by and decision-support functions when they explicitly informed, two query families for execution safety and diagnosis- constrained, or evaluated incident management, remediation, to-remediation handoffs. Appendix A reports the search configuration, resource management, or another orchestration date, query families, screening settings, decision labels, and process. We excluded generic monitoring, summarization, model deployment, and language tasks without an identifiable operational selection criteria. The search returned 1,808 records. Deduplication reduced orchestration role. this set to 1,443, and deterministic desk screening removed We then applied forward and backward citation snowballing records outside the publication window, records without to eligible studies. Newly identified records were deduplicated a language-model component, records without a systems and screened using the same scope criteria. Full-text assessment or operations context, and records clearly unrelated to and snowballing produced 41 candidate studies; two nonorchestration, remediation, configuration, placement, resource empirical magazine articles were excluded, leaving 39 primary management, or service management, leaving 1,200 records. studies.

4

Device

Edge

Cloud

Access network

Decision context

Resource & workload scheduling Workload

T1

T2

T3

T4

Before

After

Edge 1 Edge 2

Edge 1 Edge 2

T1 T2

T3

Reallocate

T1 T4

Core / transport network

Capacity · latency · connectivity · locality · observation scope

Configuration & policy

Resilience & operations

autoscale: true

Before

After

Before

Apply policy

T2 T3

api

db

T2 moved · T4 placed

Autoscale off

Workflow orchestration

Database availability

Autoscale on

api

Recover

cache worker

Unavailable

Multi-cloud storage

After

db

Before

After

Create A Create B

Create A Create B

Complete B Replicate

Replicate

Waiting for B

Replication enabled

cache worker

Available

Fig. 3. Orchestration decision families and their managed state transitions under edge–cloud constraints.

B. Evidence Extraction and Synthesis For each included study, we extracted a common set of fields describing the orchestration problem and system context, the LM’s operational role and downstream handoffs, decision authority and safeguards, and the evaluation setting, endpoints, comparators, and reported outcomes. A common extraction structure was necessary because the reviewed studies use different terminology and often combine several decision stages within the same system. When a study included materially different decision paths, execution modes, or approval conditions, we retained them separately rather than collapsing them into a single study-level description. We used an LM-assisted process to identify relevant passages in the full text and populate the corresponding evidence fields. These records served as an indexing and comparison aid for the qualitative synthesis, not as an independently analyzed quantitative dataset. Evidence used in the manuscript, figures, and comparative tables was manually checked against the corresponding source material, and ambiguous classifications were resolved through author discussion. The extracted evidence was compared across studies to identify recurring decision patterns, responsibility boundaries, assurance mechanisms, evaluation practices, and gaps in reported evidence. IV. O RCHESTRATION D ECISIONS Edge–cloud orchestration problems differ by the managed state they affect, how changes to that state are formulated as decisions, and which operational constraints bound feasible action. RQ1 organizes this decision space into four recurring domains: resource and workload scheduling, configuration and policy generation, resilience and operations, and workflow orchestration (Table II). Across these domains, we compare the managed entity, decision variable, constraints, and resulting state transition. We also distinguish how directly the LM output shapes the transition, from structuring objectives and candidate spaces to proposing operational actions. A. Decision Problems 1) Resource and workload orchestration assigns tasks to computing resources. LMs enter these allocation problems by translating placement preferences, generating candidate assignments, and constructing optimization rewards. At the representational end, LMs translate semantic

placement requirements into scheduler-readable preferences or objectives [9]. A second pattern uses the LM to shape the search process. A lightweight LM [10] can generate scheduling candidates from task and virtual-machine states for selection by a Deep Q-Network. L2D2 [12] generates and refines reward functions from environmental feedback for D3QN optimization. A further pattern brings the LM closer to the allocation choice by generating candidate schedules or workload–resource mappings from runtime state. LLMSched [11] combines cluster utilization, task dependencies, and service-level requirements to generate candidate assignments, then refines them via Integer Linear Programming under resource constraints. These problem formulations reveal a recurring division of responsibility between semantic reasoning and constrained optimization. LM outputs can progressively move from describing how an allocation should be evaluated to proposing where a workload should be executed. However, capacity, dependency, and admissibility constraints commonly remain external to the model. Resource orchestration thus spans a spectrum of LM influence over allocation decisions rather than a binary distinction between advisory and direct scheduling. 2) Configuration and policy generation differs primarily in how far LM output travels toward operational use. At one end, LMs analyze existing infrastructure definitions to identify vulnerabilities or misconfigurations and provide remediation guidance to human-facing development workflows [28], [29]. A second group generates explicit, machine-readable artifacts, such as Kubernetes manifests or infrastructure configurations, that specify a target state but still undergo refinement or validation before operational use [15], [21]. Further along this spectrum, generated configurations and policies are integrated with downstream system components. In federated learning, LM-produced task configurations and model architectures are consumed by the parameter server to run the distributed training process [17]. In transient IoT environments, generated access-control policies feed the policy and auto-configuration mechanisms that determine device permissions [19], while cloud-native security policy generation produces service-mesh policies intended for direct enforcement [20]. Across these studies, the principal distinction lies in how directly the LM output is coupled to the managed state. Outputs range from recommendations that require human interpretation, through machine-readable artifacts that specify the intended configuration, to artifacts directly consumed by downstream orchestration or enforcement components.

5

TABLE II O RCHESTRATION DECISION LANDSCAPE IDENTIFIED IN RQ1. Decision domain

Managed decision

Typical LM contribution

Representative systems

Resource and workload

Placement, allocation, routing, offloading, or scheduling of tasks, services, workloads, and flows under resource and service constraints.

Interpret placement preferences; generate candidate assignments or optimization rewards; in some systems, directly propose an allocation.

Semantic Soft Affinity [9]; LLM-assisted RL [10]; LLMSched [11]; L2D2 [12]; DIRA-LDT [13]; adaptive drone offloading [14].

Configuration and policy

Generation or modification of deployment configurations, task parameters, access-control policies, and security artifacts consumed by downstream management or enforcement components.

Translate intent into machine-readable artifacts; generate or refine configurations and policies; incorporate validation feedback.

Kubernetes manifest generation [15]; intent-based Kubernetes configuration [16]; Web FL [17]; AgentHAB [18]; CollabIoT [19]; LLM2policy [20]; cloud-security orchestration [21].

Resilience and operations

Diagnosis of degraded states, formulation or execution of corrective actions, and assessment of the resulting recovery state.

Synthesize diagnostic evidence; generate mitigation plans or repair artifacts; participate in bounded remediation and recovery loops.

AIOpsLab [2]; AIM [22]; low-parameter Kubernetes self-healing [23]; E2E-REME [24]; ARM [3]; LINEADAPTER [25]; LLM-Bayesian RCA [26].

Workflow orchestration

Ordering and coordination of external deployment or service operations, including dependencies, execution progress, and recovery positions.

Decompose intent into dependent operations and formulate workflow structure, while downstream mechanisms control execution and recovery.

IBSM [27].

Validation and refinement cut across these forms rather than form a separate stage; they may constrain artifacts before human adoption or automated use. 3) Resilience and operations spans a longer decision path, from fault interpretation to system recovery. A substantial group of systems concentrates on narrowing the recovery problem by detecting anomalies, classifying faults, localizing likely causes, reconstructing failure paths, or synthesizing heterogeneous diagnostic evidence [25], [26], [30]–[33]. These outputs can materially shape incident response, but they remain upstream of the state-changing decision. Other studies move from diagnosis toward the recovery action itself. Mitigation-oriented approaches generate recovery plans or repair artifacts that can subsequently be checked or executed [22], [23]. Closed-loop formulations [3], [24] go further by connecting diagnosis to corrective action and then observing whether the intervention restored the required system state. Resilience-oriented systems therefore progress from diagnostic evidence through mitigation formulation to executable, verified recovery. This progression is more informative than grouping all RCA and remediation systems under a single automation label. 4) Workflow orchestration appears in fewer studies and should be defined narrowly. It remains analytically distinct because the managed state is the progress of an external task or deployment workflow rather than resource assignment, configuration state, or recovery status. This includes workflow dependencies, execution order, and recovery position. Intent-based multi-cloud storage management [27] illustrates this distinction by translating user intent into a structured deployment workflow whose execution and recovery are managed across dependent storage operations. B. System Contexts The preceding decision families do not operate in a neutral environment: the same orchestration problem can change substantially depending on where state is observed, where decisions are interpreted, and where actions take effect. In highly distributed edge–cloud settings, telemetry location, decision placement, network partitioning, and administrative boundaries often force systems to decouple state aggregation,

policy validation, and proxy enforcement across different physical or logical nodes [11], [19], [27]. System context determines how much of the operating environment becomes part of the orchestration decision. We compare it through four linked questions: what is observed, which observations enter the decision context, where the resulting action can take effect, and whether its outcome is fed back into subsequent decisions. Continuum-oriented systems can span several of these boundaries. IntentContinuum, for example, combines application performance with compute and network state and can respond through both resource and network adaptations [1]. As supporting evaluation infrastructure, AIOpsLab similarly exposes heterogeneous operational observations together with state-changing interfaces through a common agent–cloud boundary [2]. The relevant distinction is therefore not how many edge, cloud, or network components appear in the architecture, but how much of their state and control surface actually participates in the decision. Physical and temporal conditions further differentiate these contexts. Edge-native formulations incorporate device capacity, communication conditions, or energy state into the feasible action space; in drone offloading [14], such conditions affect the choice among local execution, edge offloading, and deferred execution. Runtime systems also differ in whether context is used once or remains connected to subsequent control decisions. ARM [3] couples remediation with post-action observation and reassessment, allowing updated system state to influence continued intervention. C. Connections to Classical Optimization Problems The orchestration problems identified in RQ1 expose reusable structures from established optimization and planning problems, but the connection is more useful as a source of solution patterns than as a one-to-one reformulation. Table III therefore links each orchestration task to a classical analog and to LM-assisted approaches that may be transferred from adjacent optimization research. These analogs suggest three transferable patterns: using LMs to translate natural-language specifications into optimization formulations, searching for candidate heuristics under external objectives, and generating plans for checking by model-based verifiers. Such approaches would retain established optimization machinery while using

6

TABLE III C LASSICAL PROBLEM ANALOGUES AND TRANSFERABLE LM– OPTIMIZATION OPPORTUNITIES FOR EDGE – CLOUD ORCHESTRATION . Orchestration task

Classical analogue

Service placement

Capacitated facility location; generalized assignment

Workload scheduling / offloading Configuration / policy

Remediation

Workflow orchestration

Transferable LM–optimization pattern

Edge–cloud research opportunity

Translate semantic objectives and hard/soft requirements into solver-ready variables, constraints, and objectives. Multidimensional bin packing; Generate or evolve scheduling heuristics, scoring rules, or candidate actions and evaluate them with an online scheduling external solver, simulator, or objective function. Constraint satisfaction; Generate formal constraints or candidate constraint programming configurations and use an external verifier to reject conflicts and provide feedback for iterative repair. Constrained sequential Generate candidate recovery plans while model-based planning; stochastic shortest checks, simulation, or runtime feedback assess path preconditions, side effects, and goal satisfaction. Precedence-constrained Derive task graphs, precedence relations, and candidate scheduling; plans from high-level intent, while a scheduler or resource-constrained project verifier retains control over feasible execution. scheduling

LMs to construct or adapt the representations on which solvers and verifiers operate. Transferring these patterns to edge–cloud orchestration introduces additional requirements. Problem formulations must evolve with heterogeneous resources, changing network conditions, distributed observations, service dependencies, and execution feedback. The resulting research opportunity is therefore to couple semantic LM reasoning with optimization components whose feasibility criteria remain explicit and whose models can be revised as operational state changes. Service placement, scheduling, configuration, remediation, and workflow control provide different instances of this broader generate-formalize-verify-adapt pattern. D. Lessons Learned Three principal patterns characterize the decision and context landscape. First, LM-based orchestration is predominantly hybrid in formulation. Across resource scheduling, configuration, and resilience, LMs are concentrated in semantic formulation, heuristic or candidate generation, and mitigation planning, while hard constraints, validation, enforcement, and execution commonly remain with downstream system components. This places LMs primarily at the interface between heterogeneous or unstructured information and structured operational mechanisms. Second, continuum awareness depends on decision constraints, not deployment topology. LLMSched [11] uses cluster utilization, task dependencies, and service requirements to guide allocation, whereas drone offloading [14] considers device and communication conditions when choosing local execution, edge offloading, or deferral. IntentContinuum [1] further couples application, compute, and network state to resource or network adaptation. These examples distinguish deployment context from continuum conditions that shape feasible actions and subsequent state transitions. Finally, system context is reported unevenly. Studies commonly identify managed resources and deployment topology, but often omit the observation, timing, actuation, and feedback conditions needed to distinguish episodic artifact generation from environment-aware runtime adaptation or sustained closed-loop control.

Continuously reformulate placement as capacity, latency, service dependencies, and failure-domain conditions change, while externally checking feasibility against live topology. Adapt scheduling logic to workload shifts, heterogeneous resources, SLOs, migration cost, and energy state without placing an LM on every latency-critical decision path. Move from static syntax checking toward state-aware generate–verify–repair loops over live resources, permissions, dependencies, and policy interactions. Plan under partial observability and action risk while accounting for recovery cost, failed interventions, rollback, fallback, and changing system state. Support dynamic replanning across sites after partial failures while preserving dependencies, resource constraints, checkpoints, and recovery state.

V. LM ROLES , AUTHORITY, AND A SSURANCE RQ2 examines how LM contributions are translated into operational control. We first distinguish the LM’s decision responsibility, then trace the handoffs through which its outputs pass downstream. We then examine which consequential rights the LM is granted and which remain with optimizers, validators, executors, policy mechanisms, or operators, before analyzing safeguards that constrain state-changing actions. Table IV maps these distinctions onto the orchestration decision chain. A. LM Roles LM participation differs first in whether the model shapes a downstream decision or specifies the action itself. We distinguish decision-enabling roles, in which the LM structures evidence, formulates objectives, or generates candidates for downstream selection, from decision-direct roles, in which the LM specifies a proposed action, plan, policy, or key operational parameter. Either role may be one-shot or closed-loop: postaction observations can be incorporated into subsequent diagnosis, planning, or remediation. Role therefore describes decision responsibility rather than the authority to select, authorize, or execute the resulting action. Decision-enabling roles appear in optimization-oriented systems [10]–[12] and diagnostic workflows. LMs may formulate causal hypotheses [36], interpret narrowed evidence [31], [37], or reason over profiling data [38], code [32], classifier outputs [39], and multimodal observations [33]. Monitoring-oriented systems can remain upstream: LEMON [34] uses LMs to interpret monitoring intents and synthesize telemetry-backed responses, while the evaluated workflow excludes state-changing actuation. Even extensive internal autonomy, including hierarchical planning [40], recursive reasoning, memory [41], or multiagent coordination [40], [42], may still terminate in information or recommendations rather than infrastructure change. Decision-direct roles occur when the LM specifies corrective or reconfiguration actions, as in intent-driven resource adaptation [1], bounded infrastructure remediation [3], or generated recovery plans [24]. Some systems keep the LM in the feedback loop, using execution outcomes or updated system state to revise subsequent remediation [3], [23], [24]. This

7

System inputs

LM decision roles

Downstream control & checks

Forward (artifact / action) Returned status (informational)

Decision-enabling Decision inputs

Objectives & constraints

Telemetry

Evidence

Topology

Check format

LM

Candidates

Decision-direct

Check permissions

Authorize Downstream selector

Action

Scope boundary Interfaces · actions · resources

Actuate

Check feasibility Action / parameters

Policies

Managed system

Human / policy Check outcome

Block

(optional)

Monitor / recover

feedback (optional)

Fig. 4. LM decision roles and handoffs to operational control. TABLE IV LM RESPONSIBILITY AND DOWNSTREAM CONTROL ACROSS THE ORCHESTRATION DECISION CHAIN . Stage

Functional contribution

Downstream control

Representative systems

Observe/Ground

Acquire or assemble decision-relevant intent, telemetry, system state, history, or retrieved evidence. Translate intent or evidence into a decision representation, objective, preference, diagnosis, or structured task. Produce candidate actions, schedules, configurations, policies, rewards, or remediation plans. Check structural, semantic, constraint, policy, or execution properties and return acceptance or refinement feedback. Choose an action or artifact from generated or feasible alternatives.

Grounded state becomes input to interpretation, diagnosis, or planning; observation itself does not determine an action.

LEMON [34]; IntentContinuum [1]; E2E-REME [24]; ARM [3].

A downstream planner, optimizer, or executor still determines how the representation affects the managed state.

Semantic Soft Affinity [9]; Web FL [17].

Candidates may still require validation, selection, authorization, or execution by another component.

LLMSched [11]; LLM-assisted RL [10]; AgentHAB [18]; AIM [22].

Validation may block or redirect an output but does not itself imply authorization to execute it.

AgentHAB [18]; LLMSched [11]; AIOpsLab [2]; CollabIoT [19].

The selected option may still require policy or human authorization before actuation.

Permit a selected action within an approved resource, tool, or risk scope. Apply an authorized configuration, policy, playbook, or management operation to the target system. Assess post-action state and support retry, replanning, fallback, rollback, checkpoint recovery, or escalation.

Authorization defines whether and under what scope an executor may perform the state change. Privileged actuation may remain with an orchestrator, tool interface, policy plane, or other executor rather than the LM itself. Observed outcomes determine whether the loop terminates, revises the action, or transfers control to another recovery mechanism.

LLM-assisted RL [10]; LLMSched [11]; DIRA-LDT [13]; adaptive drone offloading [14]. ARM [3]; TAR [35].

Interpret/Formulate

Generate/Plan

Validate

Select

Authorize Act

Monitor/Recover

extends decision participation across successive state changes, not authority by itself. Implementation choices do not map directly onto these roles. The corpus includes hosted foundation models [9], [22], fine-tuned compact models [16], [25], [34], and locally deployed low-parameter models [23], with adaptation ranging from prompting [15] and retrieval [18] to task-specific finetuning [25]. These choices affect latency, privacy, cost, and deployability more directly than operational authority: a local model [23] may participate in remediation, while a larger hosted model [22] may remain advisory. B. Handoffs Handoffs identify where LM outputs pass to downstream components without necessarily transferring decision authority. We classify them by two features: what is transferred and which downstream decision or execution functions remain to be performed. Decision-shaping handoffs transfer objectives, evidence, or candidates; control-artifact handoffs transfer an operational configuration or policy; and execution handoffs transfer an intended action to a privileged executor. These patterns locate the control boundary rather than define a monotonic autonomy scale.

AIOpsLab [2]; ARM [3]; E2E-REME [24]; CollabIoT [19]. E2E-REME [24]; ARM [3]; IntentContinuum [1]; IBSM [27].

Decision-shaping handoffs leave the consequential choice downstream. LLMSched transfers candidate schedules to an optimization stage [11], lightweight LLM-assisted RL supplies candidate actions to a DQN [10], and L2D2 [12] provides an LM-designed reward function for subsequent reinforcement learning. In each case, the LM constrains or reshapes the decision space, while a non-LM mechanism retains final selection or feasibility enforcement. Control-artifact handoffs move closer to operation: LM output specifies a configuration or policy, but downstream components still determine how it enters the managed system. Generated OpenHAB [18] rules pass to validation, CollabIoT [19] policies to configuration and enforcement mechanisms, LLM2policy [20] artifacts to service-mesh policy control, Sigma rules to SIEM [21] processing, and federatedlearning configurations to the parameter server [17]. In these cases, the recipient determines whether the artifact is validated, adopted, translated, or enforced. Execution handoffs move closest to state change: the LM specifies the intended action, while a separate orchestrator, tool interface, or executor performs privileged actuation [1], [3], [23], [24]. Handoff structure reveals how much consequential responsibility remains downstream and links LM roles to operational authority.

8

C. Authority Profiles Authority concerns which consequential rights the LM actually has. We distinguish action selection, authorization, privileged actuation, and post-action recovery, while treating tool, resource, and action scope as boundaries on those rights. An LM may therefore produce an operationally complete schedule, policy, or remediation plan while final selection, approval, execution, or recovery remains elsewhere. At the advisory end, the LM influences a decision without controlling the resulting state transition. Semantic soft-affinity parsing [9] contributes structured preferences to scheduler scoring, while LLMSched [11] delegates feasibility enforcement and constrained selection to an optimization stage. Between advisory influence and bounded execution, a second pattern allows LM-generated or LM-selected actions to progress toward execution while retaining a separate control boundary. AIOpsLab [2] places an orchestrator between agent requests and privileged infrastructure operations, and low-parameter Kubernetes self-healing [23] separates LMgenerated remediation from the component that applies it. AIM [22] extends mitigation planning to executable playbooks in a controlled testbed, while retaining a human-in-the-loop operational model. At the higher-authority end, execution is implemented through explicit operational bounds. ARM [3] permits the agent to select and invoke infrastructure actions through a scoped management interface, while E2E-REME [24] links remediation generation to execution and verification within a defined recovery workflow. In both cases, state-changing responsibility is exercised within defined action, resource, and execution scopes. Authority can also vary by action risk. TAR [35] automates lower-risk responses through SOAR and cloud APIs while routing higher-risk threats to security experts. A Dual-LM drone architecture [14] similarly separates initial action generation from risk-constrained finalization. Authority is therefore not captured by labels such as “agentic” or “autonomous”; the decisive distinction is which consequential rights are actually transferred, under what operational boundaries, and for which classes of actions.

an ILP-based refinement stage [11], while LLM-assisted RL supplies candidate actions to a downstream DQN [10]. Semantic Soft Affinity integrates interpreted preferences with schedulerside scoring [9], and DIRA-LDT [13] evaluates recommended allocations against resource and latency constraints before execution. Across these designs, assurance depends on whether the downstream mechanism merely influences selection or enforces an explicit feasibility condition that can reject an LM-proposed choice. Execution assurance concerns the transition from an accepted action to privileged system change. ARM [3] exposes infrastructure operations through scoped tool interfaces, with safeguards and human approval configurable per action. TAR [35] makes the boundary risk-dependent: lower-risk responses can proceed through SOAR and cloud APIs, whereas higher-risk cases are retained for expert investigation. Aabirrouche et al. [21] provide a complementary predeployment pattern in which generated security artifacts are validated before activation. Together, these systems illustrate interface restriction, action-specific approval, and pre-execution validation as distinct forms of execution assurance. Outcome and recovery assurance extends control beyond actuation. ARM [3] evaluates post-intervention metrics before concluding recovery, IntentContinuum [1] continues monitoring whether the target intent is restored, and IBSM [27] retains execution checkpoints for workflow recovery. E2E-REME [24] similarly couples execution with verification and refinement. Post-action monitoring confirms whether the intended state is reached, whereas check-pointing or iterative refinement supports continued recovery when it is not. These mechanisms distinguish successful actuation from successful recovery: an action may execute correctly without restoring the intended operating condition. Evaluator independence and blocking power cut across these four assurance targets. Self-refinement or verification by the same or another LM may improve consistency, but it is not equivalent to a programmatic validator, solver, policy mechanism, runtime oracle, or human reviewer that establishes an external acceptance condition. The operational significance of a check further depends on whether it can prevent, redirect, or reverse the corresponding action.

D. Operational Assurance Operational assurance concerns both what property is checked and how the check constrains progression toward state change. We distinguish four assurance targets: representation validity, decision validity, execution safety, and outcome/recovery validity. Representation assurance is most visible in configurationoriented systems. Generated Kubernetes manifests are evaluated for deployability [15], while AgentHAB [18] uses parserbased syntax checking within an iterative generation loop. CollabIoT [19] combines structured-output validation with semantic checking and a programmatic attribute validator that queries the current policy and device state. Decision assurance becomes more consequential when LM outputs participate directly in allocation or action selection. LLMSched passes LM-generated scheduling candidates to

E. Lessons Learned Three findings emerge from the authority analysis. First, LM responsibility generally extends further than LM authority: models interpret evidence, formulate objectives, generate candidates, and in some cases specify actions, while final selection, authorization, or privileged execution often remains downstream. Second, this separation is enforced through different control boundaries—optimizers and schedulers in resource management, validators and policy mechanisms in configuration, and tool interfaces or human gates in remediation [3], [9], [11], [19], [35]. Third, operational authority is granular, not agent-wide: it depends on action scope, risk, and permissions for consequential operations. Agent count or planning depth is therefore not a proxy for infrastructure authority. Across the reviewed studies, the highest-authority

9

Evaluation setting

Evaluation design

Environment

Test conditions

Offline

Simulation

Emulation

Testbed

Claim–evidence alignment

LM contribution LM-enabled

Data source

Baseline

Data from production systems

Diagnostic support

Same input

Component ablation

Measurement

Deployment

Production actuation

Evidence

Claim Workloads & fault scenarios

Latency

Resource use

Energy use

Failure / recovery rates

Artifact validity

Artifact checks

Decision feasibility

Constraint checks

Execution success

State change

Outcome / recovery

Target-condition checks

Fig. 5. Evaluation and deployment settings, study design, and reported orchestration outcomes.

profile supported by the evidence is bounded control within explicit tool, action, and recovery scopes. VI. E VALUATION E VIDENCE

Outcome/recovery validity

AIM

Execution safety

A. Evidence Maturity Evidence maturity has two independent dimensions: the evaluation environment (offline or simulation, controlled execution, or operational deployment) and the endpoint reached, from artifact or decision quality to state change and postaction outcome. Production-derived data strengthen diagnostic provenance, whereas actuation evidence requires evaluated state changes. Workload scale, duration, dynamics, and fault provenance further bound the claims. Many decision-oriented studies provide strong task-local evidence in simulation or bounded experimental settings. L2D2 [12] reports improved energy efficiency for multi-UAV MEC scheduling, LLMSched [11] evaluates scheduling gains on production-derived cluster traces, and Web FL [17] measures communication and computational improvements for automated federated-learning tasks. These experiments establish local decision quality or efficiency within the evaluated formulation, with claim scope defined by the tested topology, workload distribution, action space, and execution duration. Controlled execution environments extend evidence to concrete system interfaces and state changes. CollabIoT [19] evaluates policy-driven device configuration on an IoT testbed, Semantic Soft Affinity [9] integrates LM-derived preferences with a Kubernetes/OpenShift scheduling path, and ARM [3] executes remediation actions on a controlled cloud–edge K3S environment. Such studies provide stronger evidence for operational integration because generated or selected actions reach the managed system under explicit resource, workload, fault, and action vocabularies. At the operational end, evidence is concentrated in diagnostic and decision-support systems. RCACopilot [30] evaluates RCA on Microsoft incident data and reports long-term production use of its diagnostic information collection component.

Representation validity

E2E-REME

CollabIoT

"Unobserved"

Semantic affinity

Decision validity

TAR

DIRA-LDT

Approval / riskrouted execution

System-mediated bounded execution

LLMSched

RQ3 examines what orchestration effects the reported evaluations establish, under which operating conditions, and with what attribution to the LM-enabled design. Figure 5 organizes this assessment into evaluation setting, evaluation design, and claim-evidence alignment. We then examine security and sustainability evidence as cross-cutting concerns.

ARM

K8s manifest

Web FL

Advisory

Closed-loop bounded execution

Broad autonomous control

Operational evidence without autonomous orchestration control RCACopilot

ErrorPrism

Offline / simulation

Legends

LM / No external check reported

AlertGuardian Controlled execution LM + External validation

DragonCrawl/uHavoc Production data / deployment LM + External enforcement

Fig. 6. Matrix of authority, assurance, and evidence in LM-enabled orchestration.

ErrorPrism [37] reports production deployment for error-path reconstruction, while AlertGuardian [43] reports deployment or pilot use at different stages of its alert-management pipeline. Marcano et al. [44] provide a different form of operational evidence through production-scale resilience validation with fault injection restricted to isolated test traffic. These studies support operational diagnosis, decision support, or resilience validation without necessarily extending the evaluated endpoint to autonomous infrastructure actuation. B. Claim-Evidence Alignment Claim–evidence alignment depends on the evaluated endpoint. Figure 6 illustrates representative control profiles and assessed properties, not mutually exclusive system classes or reliability guarantees: approval gates, execution mediation, and feedback may coexist. Configuration studies illustrate how evidence can progress beyond artifact validity. Kubernetes manifest generation [15] primarily evaluates whether LM-produced artifacts are correct and deployable. LLM2policy [20] extends the endpoint with policy-level tests and attack simulation, while CollabIoT [19] evaluates generated policies together with runtime configuration and enforcement on an IoT testbed. The supported claim therefore depends less on the artifact type itself than on how far the evaluation follows that artifact into the managed system. Scheduling studies extend the endpoint into the decision path. Semantic Soft Affinity [9] evaluates both interpretation accuracy and resulting placement behavior through an integrated scheduler prototype. LLMSched [11] evaluates LM-generated candidates after downstream constraint enforcement and further uses component ablations to isolate contributions within

10

its hybrid LM–optimization design. Together, these designs substantiate bounded allocation decisions under the evaluated workloads and constraint models. Closed-loop remediation requires post-action evidence covering failed, partial, and successful outcomes. ARM [3] evaluates whether selected interventions restore service conditions, while E2E-REME [24] executes generated playbooks and verifies post-repair state. AIM [22] explicitly distinguishes task completion from recovery: generated playbooks achieve a 71.9% task-completion rate, whereas binary remediation success is 25%. Together, these results show that action completion and system recovery are distinct evaluation endpoints. Evidence strength also depends on what the comparison isolates and where the cost boundary is drawn. In hybrid systems, end-to-end gains may arise from the LM together with retrieval, optimization, validation, or execution components; component ablations, such as those reported for LLMSched, provide stronger attribution than system-level baselines alone [11]. Cost measurements likewise cover different portions of the control path: CollabIoT [19] reports configuration and enforcement overheads, LLM2policy [20] measures policygeneration and update latency, and LEMON [34] decomposes response latency across individual pipeline stages and the end-to-end workflow. Operational deployment therefore does not remove the need to distinguish diagnostic support from actuation evidence [30], [37], [43]. Claim–evidence alignment therefore depends jointly on endpoint reach, attribution, failure and recovery behavior, and the measured cost boundary. C. Security Evidence

TABLE V A LIGNMENT OF REPORTED ORCHESTRATION OBJECTIVES WITH SELECTED UN SDG TARGETS . SDG target

Reported evidence

Main gap

7.3 Energy efficiency

Energy-aware scheduling and allocation Fault mitigation, self-healing, and recovery verification Efficient resource use, communication, and computation No direct material or hardware-lifecycle evidence identified

Net energy savings after LM and control overhead Coverage of diverse faults and operating conditions Measured energy or environmental benefits

9.1 Infrastructure resilience 9.4 Resource-use efficiency 12.2 Natural-resource efficiency

Hardware lifetime and material footprint

query generation partly to reduce indirect prompt-injection risk. The reviewed evaluations predominantly test whether security artifacts or responses are correct and effective; adversarial testing of malicious intents, poisoned telemetry or retrieved context, agent or tool hijacking, privilege escalation through generated actions, and information leakage is rarely reported. Security evidence should therefore distinguish using LMs to secure an orchestrated system from establishing the security of LM-enabled orchestration itself; evidence for the former does not establish the latter. D. Sustainability Evidence and SDG Alignment The reviewed studies connect most clearly to UN Sustainable Development Goal (SDG) targets on energy efficiency, resilient infrastructure, and resource-use efficiency (Table V). Reported evidence includes energy-aware scheduling [12], verified recovery [3], [24], and communication or computational savings [17]. These results establish benefits within the evaluated workload or control process. Assessing net sustainability, however, requires accounting for LM inference, validation, retries, and communication alongside those benefits. Carbon intensity and hardware-lifecycle effects are rarely measured. We therefore distinguish alignment with an SDG objective from demonstrated environmental benefit and use the missing measures to identify evaluation priorities.

Security introduces a further distinction: using LMs for security-oriented orchestration is different from showing that the LM-enabled orchestration process is itself secure. For the former, several studies evaluate security tasks beyond language-level output quality. Infrastructure as Code (IaC) and Kubernetes studies assess vulnerability or misconfiguration detection and remediation quality [28], [29]. CollabIoT [19] evaluates generated access-control policies together with runtime enforcement and associated overheads, E. Lessons Learned while LLM2policy [20] deploys generated service-mesh Three findings characterize the evaluation landscape. policies, tests their structural and operational validity, and First, most studies evaluate artifact and decision quality, uses attack simulations to assess whether unauthorized while a smaller subset verifies post-action recovery. interactions are blocked. Cloud-security orchestration [21] Second, environmental realism and endpoint reach vary further validates generated security and detection rules in independently: production studies substantiate diagnosis and contained environments, and TAR [35] evaluates threat alert management [30], [37], [43], whereas controlled testbeds classification and risk-dependent response, automating lower- evaluate bounded actuation or recovery [3], [19], [24]. risk cases while escalating higher-risk threats. These evaluations Third, the strongest actuation evidence establishes scoped substantiate security-oriented orchestration within the tested operational control within tested workload, fault, tool, and policy classes, threat scenarios, enforcement mechanisms, and topology envelopes. Across RQ1–RQ3, SPACE reveals that execution environments. assurance is shaped by the managed decision rather than A different question is whether the LM-enabled orchestration by autonomy level alone. Scheduling candidates undergo mechanism is itself evaluated as a security-sensitive control constraint-based feasibility checks [11], generated policies surface. Few evaluations examine this control path directly. pass through validation and enforcement [19], [20], and Some systems reduce exposure through bounded interfaces, remediation outcomes require post-action recovery checks [3], external policy enforcement, or risk-dependent human [24]. These requirements also depend on continuum conditions: escalation; LEMON [34] also explicitly avoids executable ARM shows that limited edge capacity restricts available

11

remedies and can prevent full baseline restoration [3]. Dependable orchestration therefore requires aligning decision constraints and operating context (RQ1), LM responsibility and downstream controls (RQ2), and evidence for the claimed system effect (RQ3). VII. F UTURE R ESEARCH D IRECTIONS Section IV identifies limited incorporation of continuum dynamics into orchestration decisions. The unresolved problem is maintaining feasible placement, offloading, and workflow execution when resource and network observations are delayed or incomplete. The research should thus investigate intent-toconstraint compilation coupled with robust optimization under uncertainty in resource capacity and communication delay. Generated constraints must preserve intent semantics, while independent feasibility checks account for service dependencies, locality, migration overhead, and workflow recovery state. The central question is how observation age and replanning frequency affect constraint violations and SLO satisfaction. The bounded interpretation and candidate-selection roles identified in Section V-A raise a second problem: deciding when generative inference is necessary within the control path. JEV’s lower decision latency and declining accuracy on wider contracts [45] expose a tradeoff between decision speed and joint semantic correctness. NetLLM [46] demonstrates task-specific output heads for networking decisions. Future architectures could combine such specialization with typed decision models and generative planning for complex requests. Extending model routing [47] requires calibrated estimates of joint decision error, action risk, queue occupancy, and remaining deadline slack. Research must thus establish which decision stages can be specialized while preserving correct, on-time service completion. Sections V-D and VI-C expose an assurance gap between validating an output and controlling its effects. A checked action can become infeasible before execution, while malicious operational context can induce a well-formed but unauthorized request. The research should thus investigate action contracts with explicit preconditions, permission scopes, and postconditions, bound to state versions or resource reservations. Independent runtime monitors should verify effects and initiate compensation or escalation after partial execution. Evaluation must test concurrent controller interference, network partitions, and prompt injection through their resulting unauthorized state changes and recovery failures. Future research should also investigate parameter-efficient adaptation approaches like QLoRA [48] and executiongrounded reinforcement fine-tuning [24] for orchestrationspecific models. Training should use verified state-actionoutcome trajectories, with rewards reflecting sustained SLO satisfaction, successful recovery, and intervention cost. Key challenges thus include credit assignment under delayed feedback and partial execution, and generalization across unseen fault combinations, topologies, and connectivity conditions. Evaluation should measure cumulative SLO violations, recovery persistence, and total orchestration cost and energy, including inference, validation, retries, communication,

and amortized model adaptation. Component ablations should isolate the contributions of the model, verifier, and execution controller. VIII. C ONCLUSION This survey examined LM-enabled service orchestration across the edge–cloud continuum using the orchestration decision as the unit of analysis, linking managed state and continuum constraints to LM responsibility, operational authority, assurance, and empirical evidence. This perspective distinguishes deployment context from decision-relevant continuum conditions, action specification from authority to execute, and successful actuation from verified recovery. The reviewed literature reveals a predominantly hybrid design space in which LMs interpret intents, generate candidates, or propose corrective actions, while downstream components commonly retain feasibility enforcement and privileged control. Although bounded closed-loop remediation systems are emerging, production-scale evidence of closed-loop control across heterogeneous edge–cloud environments remains limited. These findings suggest that reliance on LM-enabled orchestration depends on aligning decision formulation, operational authority, safeguards, and evaluation endpoints with the claimed system effect, rather than on agent autonomy alone. R EFERENCES [1] N. Akbari, J. Grundy, A. Cheema, and A. N. Toosi, “IntentContinuum: Using LLMs to Support Intent-Based Computing Across the Compute Continuum,” in Proc. IEEE Int. Conf. on Web Services (ICWS), 2025, pp. 573–583. [2] M. Shetty, Y. Chen, G. Somashekar, M. Ma, Y. Simmhan, X. Zhang, J. Mace, D. Vandevoorde, P. Las-Casas, S. M. Gupta, S. Nath, C. Bansal, and S. Rajmohan, “Building AI Agents for Autonomous Clouds: Challenges and Design Principles,” in Proc. ACM Symp. on Cloud Comput., 2024, pp. 99–110. [3] V. Avgerinos, K. Ramantas, L. Alonso, and C. Verikoukis, “ARM: Autonomous Remediation and Management With LLM Agents for IntentDriven Control,” IEEE Internet Things J., vol. 13, no. 9, pp. 18 305– 18 315, 2026. [4] H. Kokkonen, L. Lovén, N. H. Motlagh, A. Kumar, J. Partala, T. Nguyen, V. C. Pujol, P. Kostakos, T. Leppänen, A. González-Gil, E. Sola, I. Angulo, M. Liyanage, M. Bennis, S. Tarkoma, S. Dustdar, S. Pirttikangas, and J. Riekki, “Autonomy and intelligence in the computing continuum: Challenges, enablers, and future directions for orchestration,” arXiv preprint arXiv:2205.01423, 2022, v3, revised 17 February 2023. [5] G. O. Boateng, H. Sami, A. Alagha, H. Elmekki, A. Hammoud, R. Mizouni, A. Mourad, H. Otrok, J. Bentahar, S. Muhaidat, C. Talhi, Z. Dziong, and M. Guizani, “A survey on large language models for communication, network, and service management: Application insights, challenges, and future directions,” IEEE Communications Surveys & Tutorials, vol. 28, pp. 527–566, 2026. [6] L. Zhang, T. Jia, M. Jia, Y. Wu, A. Liu, Y. Yang, Z. Wu, X. Hu, P. Yu, and Y. Li, “A survey of AIOps in the era of large language models,” ACM Computing Surveys, vol. 58, no. 2, pp. 1–35, 2025. [7] M. Bilal, J. Crowcroft, R. Wang, X. Xu, and S. Dustdar, “Large language models for agentic NetOps and AIOps: Architectures, evaluation, and safety,” Computer Science Review, vol. 63, p. 101075, 2027. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S1574013726001838 [8] M. J. Page, J. E. McKenzie, P. M. Bossuyt, I. Boutron, T. C. Hoffmann, C. D. Mulrow, L. Shamseer, J. M. Tetzlaff, E. A. Akl, S. E. Brennan, R. Chou, J. Glanville, J. M. Grimshaw, A. Hróbjartsson, M. M. Lalu, T. Li, E. W. Loder, E. Mayo-Wilson, S. McDonald, L. A. McGuinness, L. A. Stewart, J. Thomas, A. C. Tricco, V. A. Welch, P. Whiting, and D. Moher, “The prisma 2020 statement: an updated guideline for reporting systematic reviews,” BMJ, vol. 372, p. n71, 2021.

12

[9] L. Sliwko and J. Mizeria-Pietraszko, “Cluster Workload Allocation: Semantic Soft Affinity Using Natural Language Processing,” IEEE Access, vol. 14, pp. 28 054–28 074, 2026. [10] X. Tang, F. Liu, D. Xu, J. Jiang, Q. Tang, B. Wang, Q. Wu, and C. L. Philip Chen, “LLM-Assisted Reinforcement Learning: Leveraging Lightweight Large Language Model Capabilities for Efficient Task Scheduling in Multi-Cloud Environment,” IEEE Trans. Consum. Electron., vol. 71, no. 2, pp. 5631–5644, 2025. [11] G. Ding, S. Yang, H. Lin, Z. Chen, and J. S. Yang, “LLM-Driven Adaptive Cloud Resource Scheduling: Bridging Reasoning Intelligence With Optimization Guarantees,” IEEE Open J. Comput. Soc., vol. 7, pp. 560–573, 2026. [12] K. Lv, S. Huang, Y. Yao, W. Jiang, and Z. Feng, “Large Language ModelEmpowered Energy-Efficient Multi-UAV-Assisted MEC Heterogeneous Networks,” IEEE Trans. Cogn. Commun. Netw., vol. 12, pp. 5281–5294, 2026. [13] P. Garcia, E. Oribes, I. Lopes Junior, B. Marques De Souza, A. Crestani, A. Lorenzon, M. Luizelli, P. Severo De Souza, and F. Rossi, “LLM-Based Adaptive Digital Twin Allocation for Microservice Workloads:,” in Proc. Int. Conf. on Cloud Comput. and Services Sci., 2025, pp. 61–71. [14] Q. Zhang and F. Machida, “AI Agent-based Adaptive Task Offloading for Autonomous Drones in Dynamic Environments,” in Proc. IEEE/IFIP Int. Conf. on Dependable Syst. and Netw.: Suppl. Vol. (DSN-S), 2025, pp. 239–241. [15] N. Kratzke and A. Drews, “Don’t Train, Just Prompt: Towards a Prompt Engineering Approach for a More Generative Container Orchestration Management:,” in Proc. Int. Conf. on Cloud Comput. and Services Sci., 2024, pp. 248–256. [16] A. Sacco, C. Zilli, and G. Marchetto, “Intent-Based Kubernetes Configuration via LLMs: Current Trends and Open Challenges,” in Proc. IEEE Conf. on Local Comput. Netw. (LCN), 2025, pp. 1–7. [17] C. Mawela, C. B. Issaid, and M. Bennis, “A Web-Based Solution for Federated Learning With LLM-Based Automation,” IEEE Internet Things J., vol. 12, no. 12, pp. 19 488–19 503, 2025. [18] R. Reginold and M. H. Alalfi, “AgentHAB: Automating OpenHAB Rule Generation with Multi-Agent Policy and Validation,” in Proc. IEEE Int. Conf. on Softw. Anal., Evol. and Reengineering (SANER), 2026, pp. 1–6. [19] H. Shastri, W. Hanafy, L. Wu, D. Irwin, M. Srivastava, and P. Shenoy, “LLM-Driven Auto Configuration for Transient IoT Device Collaboration,” in Proc. ACM/IEEE Symp. on Edge Comput., 2025, pp. 1–17. [20] X. Chen, Y. Zhang, H. Liu, X. Wang, C. Li, and B. Tu, “End-to-End Security Policy Automation with Multi-LLM Agents in Cloud-Native Systems,” in Proc. IEEE Int. Conf. on Trust, Secur. and Privacy in Comput. and Commun. (TrustCom), 2025, pp. 175–183. [21] H. Aabirrouche, E. Caron, and R. Messaoud, “Towards AI-Driven Framework of Automating Cloud Security Orchestration:,” in Proc. Int. Conf. on Inf. Syst. Secur. and Privacy, 2026, pp. 345–353. [22] K. Sarda, H. Ji, A. M. Zaki, I. Watts, L. Shwartz, and M. Litoiu, “Leveraging LLMs for Alert Summarization and Mitigation Plan Generation,” in Proc. ACM Int. Conf. on the Found. of Softw. Eng., 2026, pp. 840–850. [23] Y. Wiesinger, M. Engelhardt, and R. Laas, “Leveraging Low-Parameter LLMs for Self-Healing in Kubernetes-Based Container Orchestration,” in Proc. Int. Conf. on Softw. Eng. for Adapt. and Self-Manag. Syst., 2026, pp. 194–206. [24] L. Zhang, Y. Zhai, T. Jia, M. He, C. Duan, Z. Liu, B. Ding, and Y. Li, “E2E-REME: Towards End-to-End Microservices Auto-Remediation via Experience-Simulation Reinforcement Fine-Tuning,” in Proc. ACM Int. Conf. on the Found. of Softw. Eng., 2026, pp. 322–333. [25] X. Liu, W. Bao, Y. Zhang, Y. Li, R. Ranjan, and D. N. Jha, “LINEADAPTER: Parameter-Efficient Fine-Tuning for Log Anomaly Detection and Root Cause Analysis,” in Proc. IEEE Int. Conf. on Parallel and Distrib. Syst. (ICPADS), 2025, pp. 1–8. [26] D. F. Pedroso, L. Almeida, L. E. G. Pulcinelli, W. A. A. Aisawa, I. Dutra, and S. M. Bruschi, “Anomaly Detection and Root Cause Analysis in Cloud-Native Environments Using Large Language Models and Bayesian Networks,” IEEE Access, vol. 13, pp. 77 550–77 564, 2025. [27] J. Zheng, G. Tao, S. Qin, D. Wang, and Z. Ma, “Intent-Based Multi-Cloud Storage Management Powered by a Fine-Tuned Large Language Model,” IEEE Access, vol. 13, pp. 72 736–72 753, 2025. [28] D. Toprani and V. K. Madisetti, “LLM Agentic Workflow for Automated Vulnerability Detection and Remediation in Infrastructure-as-Code,” IEEE Access, vol. 13, pp. 69 175–69 181, 2025. [29] M. A. Ghorab and M. A. Saied, “Towards Secure Cloud-Native Computing: Unveiling Kubernetes Misconfigurations with Large Language Models,” in Proc. IEEE Int. Conf. on Cloud Comput. (CLOUD), 2025, pp. 86–96.

[30] Y. Chen, H. Xie, M. Ma, Y. Kang, X. Gao, L. Shi, Y. Cao, X. Gao, H. Fan, M. Wen, J. Zeng, S. Ghosh, X. Zhang, C. Zhang, Q. Lin, S. Rajmohan, D. Zhang, and T. Xu, “Automatic Root Cause Analysis via Large Language Models for Cloud Incidents,” in Proc. Eur. Conf. on Comput. Syst., 2024, pp. 674–688. [31] Z. Li, N. Wang, J. Liu, Y. Zhang, F. Tong, Z. Chen, C. Li, M. Liu, X. Zhang, Y. Wu, T. Jia, and Y. Li, “MagmaScope: Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure,” in Proc. IEEE/ACM Int. Conf. on Softw. Eng.: Softw. Eng. in Pract., 2026, pp. 635–646. [32] Y. Li, Y. Wu, J. Liu, Z. Jiang, Z. Chen, G. Yu, and M. R. Lyu, “COCA: Generative Root Cause Analysis for Distributed Systems with Code Knowledge,” in Proc. IEEE/ACM Int. Conf. on Softw. Eng. (ICSE), 2025, pp. 1346–1358. [33] X. Zhang, Q. Wang, M. Li, Y. Yuan, M. Xiao, F. Zhuang, and D. Yu, “TAMO:Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent With Multi-Modality Observation Data in Cloud-Native Systems,” IEEE Trans. Services Comput., vol. 18, no. 6, pp. 4221–4233, 2025. [34] M. Götz, H. Baghban, P. Dazzi, and O. Rana, “LEMON: LLM-Enabled Monitoring for Microservices Orchestration,” IEEE Trans. Services Comput., vol. 19, no. 3, pp. 2232–2245, 2026. [35] T. Hu, S. Zhuang, Z. Guo, J. Sun, Y. Liu, W. Ma, H. Wang, L. Zhao, and X. Zhang, “A Novel LLM Approach of Cybersecurity Threat Analysis and Response,” in Proc. Int. Conf. on Internetware, 2025, pp. 13–23. [36] L. Tang, E. Kou, W. Wang, and Q. Chen, “A Root Cause Analysis Framework for IoT Based on Dynamic Causal Graphs Assisted by LLMs,” IEEE Internet Things J., vol. 12, no. 16, pp. 34 563–34 581, 2025. [37] J. Pu, Y. Li, Z. Chen, J. Liu, Z. Jiang, J. Chen, R. Shi, Z. Zheng, and T. Zhang, “ErrorPrism: Reconstructing Error Propagation Paths in Cloud Service Systems,” arXiv preprint arXiv:2509.26463, 2025. [Online]. Available: https://arxiv.org/abs/2509.26463 [38] S. Ye, G. Tan, W. Yang, and P. Chen, “ProfRCA: LLM-Enabled FineGrained Root Cause Analysis with Continuous Profiling Data,” in Proc. IEEE Int. Conf. on Softw. Anal., Evol. and Reengineering (SANER), 2026, pp. 945–956. [39] Y. Han, Q. Du, Y. Huang, J. Wu, F. Tian, and C. He, “The Potential of One-Shot Failure Root Cause Analysis: Collaboration of the Large Language Model and Small Classifier,” in Proc. IEEE/ACM Int. Conf. on Autom. Softw. Eng., 2024, pp. 931–943. [40] Y. Gao, Z. Cai, and B. Yang, “Rcaflow: A workflow-informed hierarchical planning multi-agent system for root cause analysis,” in Proc. AAAI/IAAI/EAAI, vol. 40, no. 1, 2026, pp. 300–308. [41] L. Zhang, T. Jia, Y. Zhai, L. Pan, C. Duan, M. He, M. Jia, and Y. Li, “Agentic Memory Enhanced Recursive Reasoning for Root Cause Localization in Microservices,” in Proc. IEEE/ACM Int. Conf. on Softw. Eng.: Softw. Eng. in Pract., 2026, pp. 58–69. [42] K. Parthasarathy, K. Vaidhyanathan, R. Dhar, V. Krishnamachari, A. Kakran, S. Akshathala, S. Arun, A. Karan, B. Muhammed, S. Dubey, and M. Veerubhotla, “Engineering LLM Powered Multi-Agent Framework for Autonomous CloudOps,” in Proc. IEEE/ACM Int. Conf. on AI Eng.: Softw. Eng. for AI (CAIN), 2025, pp. 201–211. [43] G. Yu, G. Mai, R. Wang, R. Li, P. Chen, L. Pan, and R. Xu, “AlertGuardian: Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems,” in Proc. IEEE/ACM Int. Conf. on Autom. Softw. Eng. (ASE), 2025, pp. 1–12. [44] J. Marcano, A. Samant, K. Song, L. Chen, K. Mikowicz, T. Smyth, M. Zhang, A. Zamani, A. Bravo Rovirosa, S. Puligadda, S. Prodduturi, and M. Bansal, “Scaling Mobile Chaos Testing with AI-Driven Test Execution,” in Proc. IEEE/ACM Int. Conf. on Softw. Eng.: Softw. Eng. in Pract., 2026, pp. 601–611. [45] D. Li, X. Wang, H. Gong, R. Lang, and G. Yu, “Replacing Large Language Models with JEV Decision Models for Low-latency Edge Service Orchestration,” arXiv preprint arXiv:2609.22753, 2026. [46] D. Wu, X. Wang, Y. Qiao, Z. Wang, J. Jiang, S. Cui, and F. Wang, “NetLLM: Adapting Large Language Models for Networking,” in Proc. of the ACM SIGCOMM 2024 Conf., 2024, pp. 661–678. [47] I. Ong, A. Almahairi, V. Wu, W.-L. Chiang, T. Wu, J. E. Gonzalez, M. Kadous, and I. Stoica, “RouteLLM: Learning to route llms from preference data,” in Int. Conf. on Learning Representations, 2025, pp. 34 433–34 448. [48] T. Dettmers, A. Pagnoni, A. Holtzman, and L. Zettlemoyer, “Qlora: Efficient finetuning of quantized llms,” Advances in Neural Information Processing Systems, vol. 36, pp. 10 088–10 115, 2023.

13

A PPENDIX

This appendix records the retrieval, screening, and extraction settings used in the archived search run. The search was conducted programmatically on 26 July 2026 using the Semantic Scholar API as the primary retrieval source and covered publications from 2023 through July 2026. Table VI lists the query families and their task-specific terms. These were combined with LM-related expressions, such as ”large language model”, LLM, language/LLM agent, and agentic AI, as well as relevant cloud–edge–IoT system-context terms. The placement/offloading and resource management queries also used -diffusion -GAN -CVAE -VAE to reduce retrieval of generative AI studies without language-model involvement. The retrieved records totaled 1,808 before deduplication and 1,443 after deduplication.

TABLE VI Q UERY FAMILIES FOR CORPUS RETRIEVAL . Query family

Type

Task-specific terms

Orchestration core Scheduling Placement/offloading Autoscaling Resource management Fault remediation Intent/policy Agentic zero-touch Execution safety Anomaly-to-remediation

Primary Primary Primary Primary Primary Primary Primary Primary Supplementary Supplementary

resource/service/network/policy orchestration; orchestrator; zero-touch management task, workflow, resource, or job scheduling service/function/container placement; task/computation offloading autoscaling; SLA management; load balancing resource allocation; resource management fault diagnosis; RCA; remediation; self-healing; incident response; corrective action intent-driven/based; intent translation; policy generation/orchestration zero-touch; autonomous network/orchestration; network/service orchestration verification; validation; closed-loop/feedback loop; execution or corrective action anomaly detection combined with RCA, remediation, troubleshooting, repair, or incident response

The deterministic desk screening used fixed metadata and lexical criteria rather than LM-generated judgments. Records were screened for the publication period, evidence of a language-model component, a systems or operations context, and relevance to the operational scope defined in Section III. Records in which the LM was merely a workload being trained, served, deployed, or scheduled were treated as out-of-scope signals. Missing metadata, including a missing abstract, was not by itself used as an automatic exclusion criterion. The resulting 1,200 records entered semantic screening.

TABLE VII LM- ASSISTED SCREENING AND EXTRACTION SETTINGS . Item

Setting

Screening model Assessments Generation Input Decision labels Required evidence Strong candidate

deepseek-v4-flash(preview) Two assessments using distinct prompts with the same model; the second did not receive the first decision temperature=0; structured JSON output Title, year, venue, publication type, fields of study, and abstract primary_include, related_work, exclude, uncertain Quoted LM-role and orchestration evidence from the supplied title or abstract Both assessments returned primary_include, each with confidence ≥ 0.80, valid supporting evidence, and no unresolved publication-type ambiguity RQ extraction used deepseek-v4-flash; substantive fields were associated with short source spans and source locations

Full-text extraction

The two screening prompts applied the same scope criteria but elicited separate assessments of each record. Each assessment assigned an operational-relevance label, while strong-candidate decisions required supporting textual evidence. The prompts distinguished substantive LM participation in orchestration from incidental mentions or LM-as-workload studies, allowing uncertain classifications when the available evidence was insufficient. The 421 records satisfying the strong-candidate rule subsequently underwent manual full-text eligibility assessment as described in Section III. For the comparative synthesis, LM-assisted extraction was used to identify and structure relevant full-text evidence according to the SPACE dimensions. The extracted records supported cross-study comparison, while evidence reported in the manuscript, figures, and comparative tables was manually verified against the corresponding primary studies. Ambiguous classifications were resolved through author discussion.

14

TABLE VIII O PERATIONAL STUDY- SELECTION CRITERIA . Criterion

Operational rule

Publication period Model role

Publications from 2023 through July 2026. An LM or language agent must substantively contribute to planning, policy generation, decision-making, diagnosis, remediation, execution, or another identifiable orchestration function. Mere LM mentions, or LM-as-workload studies, are excluded. Cloud, edge, IoT, cloud-native, distributed, or mobile-network infrastructure, including Kubernetes, microservices, serverless, MEC, O-RAN, 5G/6G, and zero-touch environments. The study must address an identifiable orchestration or operational process, including scheduling, placement/offloading, scaling, resource management, intent/policy translation, diagnosis, incident response, remediation, or self-healing. Concrete methods, systems, prototypes, implementations, experiments, evaluations, or case studies with sufficient information to establish the LM’s operational role.

System context Operational relevance

Study evidence

Related documents

• Can We Rely on Language Models to Orchestrate Services across the Edge-Cloud Continuum?#1492085
• Large Language Models over Networks: Collaborative Intelligence under Resource Constraints#1399855
• The Illusion of Local Privacy: Confidentiality Boundary Failures in Consumer LLM Serving Systems#1012707
• The Illusion of Local Privacy: Confidentiality Boundary Failures in Consumer LLM Serving Systems#965336
• Agentic Large Language Models#1297807