Paper deep dive

Toward Agentic Optical Networks: A Vision of LLM Agent-Driven Autonomous Lifecycle Management

Yao Zhang, Shengnan Li, Yuchen Song, Yidi Wang, Yue Pang, Wenbin Chen, Xiaotian Jiang, Xiao Luo, Meixia Fu, Min Zhang, Yongli Zhao, Shanguo Huang, Alan Pak Tao Lau, Danshi Wang

Year: 2026Venue: arXiv preprintArea: cs.NIType: PreprintEmbeddings: 133

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%

Last extracted: 9/29/2026, 1:02:30 PM

Summary

This paper proposes a conceptual roadmap for Agentic Optical Networks (AONs) by integrating Large Language Model (LLM) Agents into the full lifecycle management (LCM) of optical networks. It outlines the evolution from manual operations to AI-empowered frameworks and identifies key challenges such as computational cost, reliability, and multi-task coordination. The core contribution is a hierarchical multi-Agent framework designed to manage planning, deployment, operation, maintenance, upgrade, and decommissioning phases, aiming to achieve lifecycle-level full autonomy.

Entities (8)

Agentic Optical Networks · concept · 98%LLM Agent · technology · 97%Lifecycle Management · process · 96%Hierarchical Multi-Agent Framework · architecture · 95%Network Director · agent-role · 90%Digital Twin · technology · 88%Low-Rank Adaptation · technique · 85%Retrieval-Augmented Generation · technique · 85%

Relation Signals (5)

LLM Agent → enables → Agentic Optical Networks

confidence 95% · integrating LLM Agents throughout the LCM with high-level autonomy... aims to explore the potential for the evolution of optical networks moving from task-level semi-automatic execution toward lifecycle-level full autonomy.

Hierarchical Multi-Agent Framework → manages → Lifecycle Management

confidence 95% · a hierarchical multi-Agent framework, which is specifically developed to manage every phase in LCM of AONs, including planning, deployment, operation, maintenance, upgrade, and decommission

Network Director → coordinates → Administrative Agents

confidence 90% · Hierarchical multi-agent framework... Network Director (Highest level)... Administrative Agents... Division Agents

Digital Twin → supports → LLM Agent

confidence 88% · coupling LLMs with digital twin (DT) platforms, allowing them to perceive dynamic network states and participate in closed-loop decision-making.

RAG → enhances → LLM Agent

confidence 85% · further improvements can be achieved by leveraging advanced techniques such as ... retrieval-augmented generation (RAG)

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:As optical networks continue to expand in scale, complexity, and service diversity, the implementation of automation has become essential for ensuring agility, efficiency, and reliability in lifecycle management (LCM) of optical networks. Large language model (LLM) Agent, distinguished by its progressively sophisticated capabilities in logical reasoning, adaptive decision-making, complex problem solving, and multi-task orchestration, presents great opportunities to advance network automation beyond traditional AI techniques. Nevertheless, the application of LLM Agent in optical networks remains in its early exploratory stage, challenged by the lack of multi-task coordination, high computational demands, data dependence, and reliability concerns. In this paper, we envision a conceptual roadmap toward Agentic Optical Networks (AONs) by integrating LLM Agents throughout the LCM with high-level autonomy. First, we trace the evolution from manual operations to AI-empowered frameworks and distill key technologies in Agent, providing actionable insights into leveraging its strengths for addressing practical network automation challenges. A core contribution of this paper is the proposal of a hierarchical multi-Agent framework, which is specifically developed to manage every phase in LCM of AONs, including planning, deployment, operation, maintenance, upgrade, and decommission, thereby enabling more cohesive and comprehensive automation throughout the entire lifecycle. In addition, future directions and underlying challenges are also discussed at the intersection of LLM and optical networks. By aligning the LLM Agent with the specialized requirements of AONs, this work aims to explore the potential for the evolution of optical networks moving from task-level semi-automatic execution toward lifecycle-level full autonomy.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

130,194 characters extracted from source content.

Expand or collapse full text

Research Article1 Toward Agentic Optical Networks: A Vision of LLM Agent-Driven Autonomous Lifecycle Management YAO ZHANG 1,+ , SHENGNAN LI 1,+ , YUCHEN SONG 1 , YIDI WANG 1 , YUE PANG 2 , WENBIN CHEN 1 , XIAOTIAN JIANG 3 , XIAO LUO 1 , MEIXIA FU 4 , MIN ZHANG 1 , YONGLI ZHAO 1 , SHANGUO HUANG 1 , ALAN PAK TAO LAU 5 , AND DANSHI WANG 1,* 1 State Key Laboratory of Information Photonic and Optical Communication, Beijing University of Posts and Telecommunications, Beijing, 100876, China 2 China Telecom Cloud Network Operating System R&D Center, Beijing, 102299, China 3 State Key Laboratory of Optical Fiber and Cable Manufacture Technology, China Telecom Research Institute, Beijing, China 4 School of Automation and Electrical Engineering, Institute of Industrial Internet, University of Science and Technology Beijing, Beijing, 100083, China 5 Photonics Research Institute, Department of Electrical Engineering, The Hong Kong Polytechnic University, Kowloon, Hong Kong, SAR, China + These authors contributed equally to this work. * danshi_wang@bupt.edu.cn Compiled September 29, 2026 As optical networks continue to expand in scale, complexity, and service diversity, the implementation of automation has become essential for ensuring agility, efficiency, and reliability in lifecycle management (LCM) of optical networks. Large language model (LLM) Agent, distinguished by its progressively sophisticated capabilities in logical reasoning, adaptive decision-making, complex problem solving, and multi-task orchestration, presents great opportunities to advance network automation beyond traditional AI techniques. Nevertheless, the application of LLM Agent in optical networks remains in its early exploratory stage, challenged by the lack of multi-task coordination, high computational demands, data dependence, and reliability concerns. In this paper, we envision a conceptual roadmap toward Agentic Optical Networks (AONs) by integrating LLM Agents throughout the LCM with high-level autonomy. First, we trace the evolution from manual operations to AI-empowered frameworks and distill key technologies in Agent, providing actionable insights into leveraging its strengths for addressing practical network automation challenges. A core contribution of this paper is the proposal of a hierarchical multi-Agent framework, which is specifically developed to manage every phase in LCM of AONs, including planning, deployment, operation, maintenance, upgrade, and decommission, thereby enabling more cohesive and comprehensive automation throughout the entire lifecycle. In addition, future directions and underlying challenges are also discussed at the intersection of LLM and optical networks. By aligning the LLM Agent with the specialized requirements of AONs, this work aims to explore the potential for the evolution of optical networks moving from task-level semi-automatic execution toward lifecycle-level full autonomy. http://dx.doi.org/10.1364/ao.X.X 1. INTRODUCTION The lifecycle management (LCM) of optical networks represents a systematic framework to govern the entire lifespan of optical in- frastructure, involving six critical phases: planning, deployment, and operation, maintenance, upgrade, and decommissioning [1]. Serving as the backbone of modern telecommunications, optical networks are engineered as large-scale complex systems, con- sisting of cross-connected optical fibers, expanding nodes, and massive optical components. Traditional LCM methodologies, constrained by manual interventions and reactive operations, struggle to address complex LCM of modern optical networks, which requires proactive and intelligent governance [2]. Pro- pelled by the breakthroughs in artificial intelligence (AI), the paradigm is currently evolving toward autonomous LCM [3] characterized by closed-loop autonomy. Throughout the evolution of optical networks, AI techniques have progressively contributed distinct capabilities across differ- ent levels of autonomy. Since the 2010s, basic machine learning (ML) methods have facilitated data-driven and efficient solu- tions for tasks primarily involving classification and clustering [4]. Meanwhile, advanced deep learning (DL) techniques have gained significant attention in optical networks [5,6] owing to their powerful learning capabilities, enabling the high-precision modeling of complex nonlinear relationships by mapping input arXiv:2609.32226v1 [cs.NI] 26 Sep 2026 Research Article2 data to desired outputs [7]. However, both ML and DL models are typically tailored for specific tasks and exhibit limited gen- eralization across diverse problem domains. Specifically, it is necessary to retrain or fine-tune separate models for different applications, such as performance prediction, parameter iden- tification, and configuration optimization. Furthermore, these models generally lack the ability to comprehend or analyze the broader network context, which is an essential cognitive func- tion required for adaptive decision-making [8]. As a result, these techniques facilitate foundational levels of automation in optical networks but fall short of supporting high-level automation. Ad- vancing toward fully autonomous optical networks necessitates the integration of more advanced AI techniques with general intelligence, thereby enabling models to understand, reason, and make decisions based on a comprehensive view of network state and operational intent. In recent years, generative AI (GenAI) has experienced rapid advancements [9] marked by the emergence of large language models (LLMs) that exhibit remarkable capabilities in generat- ing coherent text, image, code, and even structured solutions. With powerful reasoning and cognitive capabilities, LLM can handle a wide range of tasks through prompt-based interaction and in-context learning, thereby creating innovative opportuni- ties for AI applications in specialized domains [10]. In optical networks, initial efforts have explored LLM Agents to solve mul- tiple tasks [11–14], including performance optimization, fault diagnosis, resource orchestration, and device control. By lever- aging their reasoning and cognitive capabilities, LLM Agents aim to overcome the fragmentation and scalability limitations of conventional AI solutions, thereby facilitating more integrated, autonomous, and adaptive capabilities for future Agentic Opti- cal Networks (AONs). Predictably, building upon LLM capabilities, the paradigm of optical network is evolving toward Agent-based systems. Never- theless, the application of LLM Agent in optical networks is still in its early exploratory stage. Several key challenges remain to be addressed before its potential can be fully harnessed across the LCM process [15,16]. First, the deployment of Agents faces prac- tical constraints, including the high computational cost, large model sizes, and substantial token consumption, which limit their scalability and adaptability in real-world scenarios. Second, while techniques such as prompt engineering, context engineer- ing, and harness engineering have shown promise in adapting to specific tasks, a universally efficient methodology for optical net- work’s LCM has yet to be established. Third, given the diverse and complex tasks throughout the entire lifecycle of optical net- works, it is difficult for a single monolithic model to fully meet all functional and operational requirements. Therefore, there is a pressing need for a multi-agent collaborative framework to sup- port modular deployment and facilitates coordinated execution across diverse tasks. Furthermore, addressing issues such as hallucination and reliability is essential to ensure safe and trust- worthy automation in network operations. These challenges highlight the necessity of developing Agentic frameworks and elaborating collaborative workflows that are specifically tailored to the LCM of AONs. In this paper, we present a comprehensive roadmap for in- tegrating LLM Agent into the full lifecycle of AONs. The main contributions are as follows: 1) From a network-centric perspec- tive, we review the application of LLMs in optical networks and summarize representative related works, highlighting the poten- tial of LLM Agents to enhance reasoning, decision-making, and automation capabilities. 2) We introduce several core technolo- gies in LLM-driven Agent development, providing the optical network community with guidance on leveraging these capa- bilities for automation tasks. 3) As the main contribution, a hierarchical multi-Agent framework is proposed to implement the autonomous LCM of AONs, including network planning, deployment, operation, maintenance, upgrade, and decommis- sion phases. This organization extends Agent-based automation from individual operational and management tasks toward the full network lifecycle, while providing clear task ownership and modular scalability as network functions and lifecycle re- quirements evolve. 4) Finally, several key challenges at the intersection of LLM Agents and optical networks are outlined. By systematically aligning LLM technologies with the specific demands of AONs, we provide a vision of Agent-enhanced au- tomation throughout the entire lifecycle, paving the way toward fully self-driving optical networks that will underpin the next generation of intelligent connectivity. 2. APPLICATIONS OF LLMS IN OPTICAL NETWORKS Currently, LLMs, as a representative form of GenAI, mark a significant leap forward in natural language processing (NLP), transforming how the language is understood and generated. The rapid advancement of LLM technologies also presents promising opportunities to automate numerous tasks in the field of optical networks [11]. Recent efforts to integrate LLMs into optical networks, as illustrated in Table 1, can be broadly categorized into three progressive stages. In the initial phase, research focused on leveraging LLMs’ capabilities in context understanding and generation to assist in basic log and alarm processing tasks. For instance, AlarmGPT [19] and instruction-tuned LLaMA [20] demonstrated how LLMs could automatically summarize alarms, parse logs, and generate structured outputs, thereby reducing reliance on manual inter- vention. These approaches primarily treated LLM as intelligent text processors embedded in optical network toolchains. As exploration deepened, researchers began incorporating domain- specific knowledge into prompts and utilizing LLMs for work- flow decomposition and task chaining. For example, in quality of transmission (QoT) estimation and network planning tasks, LLMs were employed to involve physical models, analyze simu- lation results, suggest parameter values, in a loop-like manner [21,26]. Fault management tasks also benefited from LLMs’ ability to reason across symptoms and suggest candidate root causes [22]. More recently, with the growing demand for autonomous operation in optical networks, LLMs have begun to take on Agent-like roles. Instead of merely assisting with textual process- ing or isolated task reasoning, they are increasingly integrated into broader network systems, enabling interaction with real- time data, tools, and control environments [12]. One direction involves coupling LLMs with digital twin (DT) platforms, allow- ing them to perceive dynamic network states and participate in closed-loop decision-making. For instance, Sun et al. [13] explored an AI Agent for optical network management, where the LLM interprets simulation outputs and responses opera- tional adjustments. Similarly, Liu et al. [14] demonstrated how LLM-powered Agent could continuously monitor network and adapt responses. These efforts underscore a transition from data interpretation to proactive execution and feedback for complex tasks. Another emerging trend is the integration of LLMs with network control and management interfaces, such as software- Research Article3 Section 1 Introduction •Background •Motivations •Contributions Section 2 Applications of LLM in optical networks (Related Works) Section 3 Technical Foundations of LLM Agent Section 6 Outlook •Hallucination risks •Model selection and deployment Section 4 & 5 LLM Agent for Optical Network Full-lifecycle Management A O N ④Maintenance ⑤Upgrade ⑥Decommission Full-lifecycle of optical network Prompt RAG Pre-train Fine-tune Chain of thought LoRA Access network Metro network Core network DC DC DC Physical-layer optical network Hierarchical multi-agent framework for LCM Agentic AI ... ②Deployment ③Operation ①Planning Network Director (Highest level) Administrative Agents Division Agents (for each lifecycle) AI Experts (in each division) Data base Knowledge library Tool kit Digital twin of optical network (DTON) •Requirement analysis •Topology design •Resource selection •Route planning •Configuration •Initialization •Build DTON •QoT estimation •Monitoring •Inspection •QoT assurance •Dynamic operation ①Planning ②Deployment ③Operation •Alarm definition •Failure diagnose •Solve and repair •Report generation •Demand analysis •Upgrade strategy •Optimization •Validation •Report confirm •Removal/Retention •Service switch •Physical operation ④Maintenance ⑤Upgrade ⑥Decommission ①-③ The construction of LLMs④ -⑨Key technologies for domain enhancement ①Model architecture •Word embedding •Transformer ③Model size •Close/Open-source •Applicability ②Model pre-training •Next-token prediction •Zero-shot/Few-shot ④Fine-tuning •PEFT: LoRA/QLoRA •Domain dataset ⑤Reinforcement •RLHF •Reward model ⑦Prompt engineering •Prompt elements •Prompt techniques ⑥RAG •Knowledge •Compression ⑧AI workflow •Tools •System design ⑨AI Agent •Harness •With DT •Token costs •Long-horizon memory Fig. 1. A comprehensive overview of the structure and key topics covered in this work. defined network (SDN) controllers or network management system (NMS). This includes efforts to map user intents to struc- tured network commands via programmable interfaces [25,36], as well as architectures that integrate LLMs directly into service orchestration pipelines and configuration workflows [23,24]. Further developments have demonstrated frameworks for end- to-end task execution [28], where LLM Agent not only interpret operational goals but also coordinate resource allocation and execute network updates in response to environmental changes. Building upon these single-Agent foundations, recent break- throughs have increasingly shifted towards deploying locally- hosted, open-source LLMs to address data privacy and latency concerns in real-world scenarios. For example, field trials have demonstrated AI Agents powered by local open-source mod- els achieving full LCM in elastic optical networks, executing autonomous service provisioning and failure recovery within minutes [30]. Moreover, structured human expertise has been explicitly integrated into the prompts [31,32] to enhance domain adaptability and reliability of these Agents. As network scenarios become more complex, the paradigm is rapidly evolving from single-Agent assistants to collaborative multi-Agent systems. In these architectures, complex workflows are decomposed and assigned to specialized Agents that com- municate and collaborate to prevent the accumulation of errors [34]. Similarly, multi-Agent frameworks have been applied to specific component-level tuning, such as autonomously con- trol Raman amplifiers [35], or for strategy generation with DT interaction [33]. These multi-Agent strategies, closely aligned with the vision of fully autonomous, intent-driven networks [37,38], represent a transformative leap toward self-operating infrastructures. Overall, these explorations highlight the feasibility of apply- ing LLMs to various network tasks, and showcase the potential of Agent to enhance efficiency, reduce human workload, and Research Article4 Table 1. Representative works integrating LLMs with optical networks ApplicationsCapabilities and scopeMethod TypeRef Framework of LLM-driven optical network LLM applications, challenges, and opportunities for intelligent network operations, prediction, and analysis GPT-based prompt[11] Capabilities and limitations of applying LLMs to optical networksConceptual[15–18] Alarm/Log analysisLLM-enabled professional alarm/log Q&A, analysis, and reasoning GPT-based prompt[19] LLaMA fine-tune[20] QoT estimationLLM-assisted QoT estimation and DT-based multi-task network managementGPT-based prompt[21] Failure managementLLM-based fault analysis and management fused multi-mode dataGPT-based prompt[22] Configuration and controlPractical pipeline for automated configuration in SDN network and testbeds Prompt[23, 24] Qwen fine-tune[25] Simulation assistantSystem simulation and performance evaluation, with natural languageGPT-based prompt[26] Networkoperationsau- tomation LLM-assisted network operation workflows with task automation and tool interac- tion LLaMA fine-tune[13, 27, 28] Field-trial demonstrationField-trials for LLM-assisted lifecycle management with interaction with network management and operational tools Prompt, RAG[12,14,29,30] Performance optimizationIntegrates human expertise to enhance efficiency and reliability in AI AgentAI Agent, GPT-4o[31, 32] Autonomous multi-task col- laboration Multi-Agent collaboration for task decomposition, coordination, and tool callingMulti-Agent framework[33–35] support decision-making in complex, dynamic optical systems. From the perspective of lifecycle coverage, existing studies span individual network functions, selected operational stages, and increasingly multiple lifecycle phases, including recent field- trial demonstrations. In terms of Agent organization and task orchestration, existing approaches range from single LLM-based assistants and task-specific Agents to multi-Agent schemes for task decomposition, coordination, and collaborative execution. Regarding system interaction, prior studies explored integra- tion of LLMs and Agents with DTs, NMSs, and domain-specific tools to different extents. These efforts should be viewed as complementary steps in the evolution of LLM-enabled optical network automation, collectively illustrating a progression from task-level assistance toward increasingly coordinated and au- tonomous network management. From this perspective, rather than replacing existing task- specific or workflow-oriented approaches, this work adopts a lifecycle-oriented perspective and organizes Agent capabilities around the major phases of an optical network. We aim to syn- thesize these developments from a system-level architectural perspective and to further explore how heterogeneous Agent capabilities can be organized with network management sys- tems and domain-specific tools to progress from task-level LLM assistance toward full-lifecycle autonomous management. Mov- ing forward, further improvements can be achieved by leverag- ing advanced techniques such as instruction tuning, reinforce- ment learning (RL), fine-tuning, tool augmentation, retrieval- augmented generation (RAG), and harness engineering, all of which are discussed in the following sections. These techniques offer the promise of building more robust, reliable, and domain- aligned LLM Agents tailored to the unique demands of optical networks. 3. TECHNICAL FOUNDATIONS OF LLM AGENT Building upon the recent advances in LLMs, this section delves into the underlying technical foundations that equip LLM to be Agent to address various complex tasks. We focus on the core ar- chitectures, particularly transformer, as well as the mechanisms that enable LLMs to generalize across domains. This technical overview provides the necessary background for understanding how LLMs can be adapted and applied to autonomous optical network management in subsequent sections. A. The construction of LLM Following the seminal work by Vaswani et al. [39], Transformer- based models have become central to modern NLP and beyond due to their scalable and context-aware modeling capability. In NLP, input text is first divided into discrete units called to- kens, which may correspond to words, subwords, or characters depending on the tokenizer. Each token is then mapped to a dense numerical vector through an embedding layer, providing a continuous representation that can be processed by the neural network. The core innovation of Transformer, self-attention, en- ables each token to dynamically evaluate the relevance of other tokens in the same input sequence and aggregate their infor- mation into a context-aware representation. While multi-head attention performs multiple attention operations in parallel, al- lowing the model to capture different semantic and structural patterns simultaneously [40,41]. The performance and reliabil- ity of LLMs are fundamentally shaped by the data trained on, which must balance linguistic diversity and domain relevance [42]. Large-scale general text sources support broad language understanding, while domain-specific resources, such as optical network logs, standards, protocols, and technical literature, im- prove reasoning in specialized contexts [43]. Data preprocessing, including quality filtering, deduplication, and sensitive infor- mation removal, further enhances representation quality and model alignment with practical usage [44, 45]. Pre-training enables LLMs to learn linguistic structure and reasoning patterns from large unlabeled corpora. Most state- of-the-art LLMs, including GPT [46] and LLaMA [47], adopt autoregressive decoder-only architectures that predict tokens sequentially. As representations propagate through successive layers, they accumulate increasingly contextual information [48]. Importantly, well-pretrained models often exhibit strong zero- shot and few-shot learning abilities [49]. In zero-shot learning, the model performs a task without task-specific examples being provided in the prompt, relying on it pretrained knowledge and the task instruction. In few-shot learning, a small number of task examples are provided in the prompt to guide the model toward Research Article5 Out LLM 1 Tool 2 LLM 3 LLM 2 LLM 4 Tool 1 Exit Exit LLM 5 Fine-tune Domain data/info (a) Fine-tune for domain-specific conditions(b) Reinforcement learning in environment(c) RAG using domain knowledge library query policy model (trainable) outputs reference model (frozen) reward model (frozen) KL r1 r2 r3 ... group computation A1 A2 A3 ... scores (d) Prompt engineering (e) AI workflow using toolkit instruction context input data output indicator prompt CoT d eep reasoning (f) Harness engineering-enhanced AI Agent Model Reasons → decides Control compaction, orchestration, iterationloops Context injection prompts, memory, skills, conversation Persist filesystem, git, progress files Action calls tools, MCPs feedback results Observe & Verify logs, test results writesreads Harness query user answer LLM retrieval Knowledge library Domain toolkit Fig. 2. Key technologies for domain enhancement. (a) Fine-tune (b) Reinforcement learning (c) RAG (d) Prompt engineer (e) AI workflow (f) Harness engineering-enhanced AI Agents. the desired behavior, without updating its parameters. These capabilities allow a single pretrained model to adapt to different tasks through instructions or examples, providing an important foundation for its application to heterogeneous optical-network management tasks. Current pretrained LLMs can be broadly categorized into closed-source and open-source models. Closed-source mod- els such as OpenAI’s GPT, Google’s Gemini, and Anthropic’s Claude, are characterized by extremely large training corpora and parameter scales, providing state-of-the-art general and even domain-specific reasoning capabilities, including advanced cross-modal understanding and generation. They are simple to use and highly effective for solving complex problems. In optical network scenarios, such models are therefore more suit- able for non-sensitive, high-level tasks, for instance, concep- tual architecture design, early-stage algorithm prototyping, or exploratory analysis of network behaviors when real opera- tional data is not involved. Open-source models such as Qwen, DeepSeek, LLaMA, and GLM, support domain customization through fine-tuning and reinforcement learning. These models are particularly suitable for optical network scenarios that re- quire customization and strict data governance, such as building performance estimation assistants, generating device-level con- figurations, supporting troubleshooting assistants, or enabling closed-loop control modules that must run within operator envi- ronments with proprietary data. B. Key technologies of LLM for vertical domain adaptation 1) Fine-tuning for domain task enhancement While pre-trained foundation models exhibit strong general reasoning capabilities, they may lack the specialized knowl- edge required for optical networks, where engineering decisions depend on field monitoring performances, physical-layer con- straints, and device-specific standards, that rarely appear in general pretraining corpora. Therefore, fine-tuning becomes the key mechanism to bridge this gap, by further training models in domain-specific datasets, enabling models to internalize op- tical network concepts, operational patterns, and engineering heuristics [50], as illustrated in Fig. 2 (a). Several fine-tuning strategies support domain adaptation with different computa- tional and data requirements. Full-parameter fine-tuning up- dates the entire model but is resource intensive, whereas partial and parameter-efficient fine-tuning (PEFT) methods [51] offer more practical solutions when labeled data and computational resources are limited. Techniques such as low-rank adaptation (LoRA) and Quantized LoRA (QLoRA) reduce training overhead while maintaining strong adaptation performance [52, 53]. 2) Reinforcement learning for preference alignment After pre-training and fine-tuning, LLMs gain general gener- ation ability and domain adaptability, yet they may still produce factually incorrect or misaligned outputs. RL therefore serves as a critical post-training stage for aligning model behavior with human preferences and task objectives. Reinforcement learning from human feedback (RLHF) [54] improves response quality, safety, and alignment by incorporating human or learned prefer- ence signals into iterative policy optimization, contributing to the success of systems such as ChatGPT and GPT-4 [55]. As a reward-driven learning paradigm, RL is particularly valuable for optical network O&M tasks, where decisions often involve trade-offs rather than deterministic answers. For example, feasi- ble solutions in power optimization or fault recovery may satisfy technical constraints but differ in robustness, operational risk, or service impact. Such engineering preferences are difficult to encode through supervised datasets alone but can be naturally incorporated through reward-based learning [56]. 3) Retrieval-augmented generation (RAG) Although fine-tuning and RL improve domain adaptation and behavioral alignment, LLMs may still generate hallucinated or incomplete responses when tasks require precise technical knowledge or rigorous physical reasoning. In optical networks, many problems, such as interpreting nonlinear interference (NLI) or reasoning under multi-parameter constraints, depend on specialized knowledge that cannot be reliably encoded into model parameters alone. In this case, RAG addresses this limita- tion by grounding model outputs in external knowledge sources, improving response accuracy and relevance [57]. Effective RAG depends less on complex architectures than on a well-structured knowledge foundation capable of providing relevant and reli- Research Article6 able information when needed [58,59]. For optical networks, this requires a structured knowledge library where physical the- ories, engineering guidelines, standards, and operational docu- ments are explicitly organized and retrievable, rather than rely- ing solely on the model’s internal knowledge. To ensure efficient use, knowledge should be carefully categorized, structured, and stored in vector form for fast retrieval. When a task is encoun- tered, relevant knowledge is retrieved and incorporated into the LLM prompt, enabling context-aware and domain-grounded reasoning. 4) Prompt engineering By bridging the gap between user intent and model under- standing [60], whether the model is pre-trained, fine-tuned, or reinforced, leveraging prompt engineering can unlock the full potential of LLMs, particularly in domain-specific applications. A well-constructed prompt typically includes four essential ele- ments [61]: instruction, context, input data, and output indicator. The instruction defines the task clearly and steers the model’s reasoning toward user intents. Context supplements the in- struction with domain knowledge, external data, or operational constraints, to enhance the model’s accuracy. Input data pro- vides task-specific information, enabling the model to handle particular needs effectively. The output indicator specifies the desired format or structure, ensuring usability in downstream workflows. Beyond prompt elements, prompt techniques fur- ther enhance the reasoning and analytical capabilities of LLMs [43]. Chain-of-thought (CoT) prompting supports step-by-step reasoning by decomposing complex problems into sequential subtasks [62]. This capability is particularly valuable in op- tical networks, where many operational tasks are inherently multi-step and cannot be solved reliably through a single direct response. 5) AI Workflow with toolkit To enhance the reliability and efficiency of LLMs in task exe- cution, workflow-based systems have emerged as a foundational paradigm. In this framework, complex tasks are decomposed into well-defined sub-steps, where LLMs operate within pre- designed execution pipelines and interact with external modules through standardized interfaces. Unlike early LLM applications that focused primarily on language generation, workflow sys- tems emphasize task-oriented automation, with the LLM acting as an intelligent coordinator within a structured execution pro- cess. As illustrated in Fig. 2 (e), workflow execution typically involves task decomposition, action planning, execution, and result aggregation, ensuring controllability and reproducibil- ity for stable tasks. Many optical-network operations naturally align with this paradigm. For example, network planning can be decomposed into topology parsing, traffic demand analy- sis, routing and spectrum assignment (RSA), QoT estimation, and configuration generation. Similarly, operational tasks such as fault localization can be structured into sequential stages including alarm and telemetry collection, anomaly correlation analysis, root-cause inference, fault localization, and recovery recommendation generation. By organizing these steps into modular pipelines, workflow can coordinate domain-specific models and computational modules to accomplish complex engi- neering tasks more reliably and systematically. Workflow-based execution is particularly suitable when the task objectives, execu- tion steps, required tools, and decision criteria can be specified in advance. In such cases, deterministic workflows provide ad- vantages in repeatability, efficiency, and controllability, and there is no need to introduce autonomous Agent reasoning beyond the predefined procedure. 6) Harness engineering-enhanced Agent While workflow systems offer strong reliability, their prede- fined structures limit adaptability in dynamic and open-ended environments. To address this limitation, LLM Agents have evolved beyond static tool orchestration toward closed-loop, context-aware, and self-adaptive systems, as illustrated in Fig. 2 (f). An Agent is a self-directed entity that leverages LLMs for planning, reasoning, memory management, and tool invocation, enabling iterative action refinement through environmental feed- back. Rather than replacing domain-specific tools or determinis- tic workflows, an Agent provides a flexible reasoning and orches- tration layer above them. Given a high-level objective, the Agent can determine which information and capabilities are required, select and invoke appropriate tools or workflows, interpret their intermediate results, and adapt the subsequent execution accord- ing to the current context. Compared with workflows, which rely on predefined execution pipelines, Agents dynamically rea- son and adjust their behaviors at runtime, making them better suited for tasks requiring flexibility and adaptation [63]. Recent advances have further expanded the Agent paradigm through harness engineering, which provides a structured framework for orchestrating and operationalizing Agent behavior. Harness engineering further strengthens Agent reliability by organizing context management, tool interaction, persistent memory, observation, verification, and recovery mechanisms. These capabilities support closed-loop execution in which an Agent can evaluate intermediate results, refine its actions, and coordinate with other Agents through multi-Agent or Agent- to-Agent (A2A) collaboration [64,65]. Unlike static workflows, harness-enhanced Agents can dynamically determine task de- composition and execution strategies at runtime, making them well suited for complex optical network O&M scenarios. 4.LLM-CENTRIC FULL-LIFECYCLE MANAGEMENT FOR AGENTIC OPTICAL NETWORK The full LCM of optical networks encompasses multiple phases, including planning, deployment, operation, mainte- nance, upgrade, and decommissioning, typically spanning sev- eral decades, as illustrated in Fig. 3. As the foundational layer of modern communication infrastructure, enhancing the level of autonomy in optical networks is critical for improving the reliability of cross-domain traffic delivery while reducing the operational complexity associated with large-scale network man- agement. In this context, LLMs, with their strong capabilities in intent understanding and logical reasoning, have the potential to support a wide range of O&M tasks. More importantly, LLMs can be envisioned as the cognitive core of AONs, continuously evolving alongside the network and permeating all lifecycle phases. Consequently, future AONs are expected to emerge as unified and intelligent systems, jointly constructed by physical infrastructure, DT, control planes, and multi-Agent systems. To systematically enable LLM-centric LCM in AONs, it is essential to first establish a comprehensive understanding of the tasks and workflows across different lifecycle phases. Ac- cordingly, this section summarizes the major responsibilities of each phase, followed by the proposed hierarchical multi-Agent framework for full-lifecycle automation. A. The full lifecycle of optical networks 1) Planning The planning phase represents the initial stage of the op- tical network lifecycle, which involves defining network re- Research Article7 Fig. 3. Diagrammatic representation of the key tasks corresponding to each phase of the optical network lifecycle, covering plan- ning, deployment, operation, maintenance, upgrade, and decommission. quirements, forecasting future capacity needs, and creating a blueprint for the physical and logical architecture [66]. This phase includes analyzing bandwidth demands, coverage targets, and service types, selecting appropriate technologies, designing fiber routes and redundancy schemes, and planning node place- ment across core, aggregation, and access layers. Equipment selection must balance performance, cost, and supply chain ro- bustness, while operators often adopt multi-vendor strategies to mitigate vendor lock-in and enhance network flexibility. Based on candidate fiber routes and equipment options, optical am- plifiers (OAs) placement and optical transponder units (OTUs) allocation can be jointly optimized with fiber and equipment se- lection. The corresponding decisions may include the locations and quantities of OAs and the allocation, types, and capacities of OTUs, subject to fiber-loss, QoT, cost, reliability, and deployment constraints. Building upon the selected resources, a preliminary network topology is constructed, enabling subsequent performance eval- uation based on both fiber characteristics and device parameters. This evaluation provides the foundation for downstream config- uration tasks, including wavelength planning driven by initial bandwidth demands. The outputs of the planning phase there- fore comprise an optimized resource allocation and deployment scheme, initial configuration parameters for key optical devices, such as OAs, WSSs, and OTUs, as well as a unified IP addressing plan. This phase, often referred to as the Day 0 stage of the opti- cal network lifecycle, establishes the baseline for all subsequent deployment and operational processes. 2) Deployment Once the planning phase is completed, the optical network transitions into the deployment phase, during which the de- signed infrastructure is physically instantiated and initialized for operation. This phase encompasses fiber connectivity es- tablishment, equipment installation and configuration, as well as initial system performance optimization. Building upon the established physical connectivity and baseline configurations, the NMS subsequently assumes control, enabling real-time mon- itoring and data collection to support the construction of DT [3,67]. Based on the acquired network state information, opti- mization algorithms can be applied to validate and refine system performance, ensuring that service requirements are satisfied. Meanwhile, key deployment-stage data, which including fiber parameters, configuration files, begin-of-life (BoL) performance margins, and physical device location information, are system- atically recorded to provide a reliable reference for subsequent operation stages. Upon completion of these processes, the net- work becomes service-ready, marking the transition to the Day 1 stage of the optical network lifecycle. 3) Operation Following deployment, the optical network transitions into the operation phase, during which it continuously carries and manages live IP traffic. This phase is inherently dynamic and long-term [5], involving three tightly coupled functional pro- cesses: adaptive optical channel management, continuous net- work health assessment, and real-time performance optimiza- tion. As service demands evolve over time, optical channels must be dynamically provisioned, adjusted, or released to ac- commodate traffic fluctuations. In parallel, network health is continuously evaluated through the analysis of performance metrics, sensor readings, and device status information. Based on the observed network state, performance optimization mech- anisms are further triggered to maintain service quality [68]. Compared to the planning and deployment phases, the oper- ation phase exhibits significantly higher complexity and persists over a longer period while continuously interacting with live traffic and facing the stringent requirement for ultra-reliable exe- cution, where even minor disruptions may lead to substantial service impact. This necessitates decision-making processes to be not only accurate but also risk-aware and globally coordi- nated. In this context, autonomous operation emerges as a crit- ical enabler, capable of reducing human-induced errors while rapidly adapting to unexpected network conditions through holistic, system-level awareness. 4) Maintenance Research Article8 Maintenance is performed concurrently with the operation phase and represents the most enduring stage of the optical net- work lifecycle, playing a critical role in sustaining long-term net- work reliability and availability. This phase focuses on the timely detection, localization, and mitigation of network faults arising from diverse sources [3,5]. To address such failures, mainte- nance activities rely on a combination of network monitoring and coordinated field operations. In NMS, alarms are generated to facilitate fault analysis and location, after which maintenance personnel collaborate with field technicians to perform recovery actions, including fiber repair and module replacement. The efficiency of fault detection and resolution directly impacts the overall availability and continuity of services in the network. However, in large-scale optical networks, traditional manual maintenance mode faces significant challenges in terms of scal- ability, response time, and knowledge consistency, particularly in the presence of staff turnover and increasingly complex sys- tem configurations. In this context, autonomous maintenance is anticipated to be a key enabler to accelerate fault recovery, reduce operational overhead, and alleviate reliance on human expertise. 5) Upgrade The upgrade phase of optical networks encompasses both technological evolution and network scale expansion, enabling the system to adapt to the long-term growth in service demand and advances in transmission and control capabilities. Such upgrades may involve capacity expansion, equipment replace- ment, spectrum reconfiguration, and updates to control and management functions as network requirements evolve. Despite occupying a relatively small portion of the entire lifecycle, the upgrade phase is inherently high-risk, as any misconfiguration or maloperation may lead to performance degradation and even service disruption in live networks. Consequently, upgrade op- erations require meticulous planning and evaluation, typically involving extensive simulations and performance assessments on the DT platform, and in many cases, physical testing within controlled laboratory environments. In this context, the integra- tion of high-level autonomy with DT technologies is expected to significantly improve both the efficiency and reliability of upgrade processes by enabling predictive analysis, risk-aware decision-making, and pre-deployment validation. 6) Decommission The final phase of the optical network lifecycle is decom- missioning, which marks the systematic retirement of network infrastructure as it becomes obsolete or no longer economically viable. This phase is typically triggered by several factors, in- cluding large-scale technology transitions, progressive system aging, and declining service demand that renders existing sys- tems inefficient [69]. Decommissioning is inherently complex, involving large-scale service migration, resource reclamation, and coordinated asset management across multiple network lay- ers. Among these processes, traffic cutover operations are partic- ularly critical, as they must be executed with minimal disruption to ongoing services. Consequently, ensuring a safe and seam- less transition requires precise planning, real-time monitoring, and tightly coordinated execution. In this context, autonomous network capabilities play a pivotal role by enabling automated service migration, reducing operational risks, and maintaining service continuity throughout the decommissioning process. Across these phases, the network evolves from design and physical realization to long-term operation, evolution, and even- tual retirement. The diversity of objectives, constraints, and operational conditions across the lifecycle motivates a phase- oriented organization of Agent responsibilities, as discussed in the following subsection. B. Hierarchical multi-Agent framework To effectively facilitate the autonomous LCM of optical networks, we propose a hierarchical multi-Agent framework comprising the four levels: 1) a Network Director overseeing global oper- ations, 2) three Administrative Agents providing cross-cutting capabilities for task coordination, memory management, and se- curity support, including Task Coordinator, Memory Container, and Security Manager, 3) six Division Agents responsible for different phases of the network lifecycle, including planning, de- ployment, operation, maintenance, upgrade, and decommission phases, and 4) multiple AI Experts within each division execut- ing specific functions. Each Agent is designed to autonomously execute tasks within its domain while collaborating across layers, ensuring seamless and intelligent optical network management, as depicted in Fig. 4. At the highest level of the framework, the Network Direc- tor serves as the central decision-making entity, orchestrating the entire multi-Agent system. It acts as the primary interface between human operators and the AI Agents, maintaining a global view of network objectives and operational states. It is initially customized with basic knowledge of optical network operation and is responsible for controlling the overall task ex- ecution process of network automation. Rather than directly executing all domain-specific tasks, the Network Director inter- prets high-level intents, allows the system to maintain a unified network-wide objective while delegating specialized tasks to dedicated Agents. At the secondary level, three Administrative Agents support the Network Director: Task Coordinator, Memory Container, and Security Manager, each responsible for a critical aspect of autonomous network governance. These Agents provide cross- cutting capabilities that are shared by multiple lifecycle divisions and therefore are not tied to any particular network phase. The Task Coordinator is responsible for the distribution of tasks across divisions and optimizing the task execution process. The Memory Container functions as a knowledge repository, storing historical data, learned experiences, decision logs, and feedback reports, thereby preserving contextual information across differ- ent lifecycle phases and supporting informed decision-making. The Security Manager ensures network reliability and safety through proactively monitoring anomalies and faults, detecting potential threats, and pre-validating configuration strategies to protect the system from risks. For actions that may affect the physical network, the Security Manager can validate strategies from a global perspective before execution and triggering human confirmation for high-risk operations. Separating these shared functions from individual Division Agents avoids duplicated coordination, memory, and security mechanisms and enables consistent policies and contextual information to be maintained throughout the network lifecycle. At the division level, six Division Agents designed for dif- ferent phases of the optical network: Planning, Deployment, Operation, Maintenance, Upgrade, and Decommission, are re- sponsible for managing the full lifecycle of the optical network. This phase-oriented organization assigns a clear ownership of tasks according to their lifecycle context, since different phases have distinct objectives, constraints, information requirements, and decision processes. Each Division Agent acts as a middle manager that interprets task targets from administrative layers, formulates phase-specific strategies, and orchestrates task ex- Research Article9 Planning Agent Deployment Agent Maintenance Agent Infrastructure Selector Field Engineer Automated Inspector Dynamic Operator Operation Agent Abnormal-data Handler Alarm Handler Performance Tuner Configuration Scheduler User/Operator Task instruction Response Upgrade AgentDecommission Agent Upgrade Planner Retirement Planner Migration Supporter Validation Specialist Network Director Task Coordinator Memory ContainerSecurity Manager Feedback Optical Network Coordinate tasks among divisions Optimize the task execution process ...... Network management system (NMS) Optical Network Storing historical data, learned experiences, decision logs, and feedback reports Detect threats, and ensure security ...... ... ... Fig. 4. Hierarchical multi-Agent framework for optical network full-lifecycle management. The architecture consists of four layers of intelligent Agents. At the top layer, the Network Director Agent interacts with the user/operator, handling both intent input and feedback aggregation from lower layers. The second layer comprises three administrative Agents, each responsible for a major domain of network lifecycle management. The third layer includes primary Agents that oversee the automation of specific lifecycle phases. At the bottom layer, sub-Agents are assigned to execute concrete tasks. Table 2. Representative knowledge, network data, and tools for Agents across different lifecycle phases of AONs. Lifecycle phaseRepresentative knowledge and dataRepresentative tools and interfaces PlanningNetwork topology; traffic demands and forecasts; equipment specifications; deployment constraints; equipment databases; RSA tool; QoT estimation; resource planning; DT platform; Deployment Equipment inventory; device capabilities; configuration tem- plates; installation records; NMS API; device configuration interfaces; commissioning and diagnostic tools; Operationservice statistics; topology and network state; QoT measurements; alarm information; action logs; Real-time telemetry APIs; QoT estimation; RSA tool; DT platform; NMS API; performance-analysis scripts; MaintenanceAlarm rules; historical cases; maintenance records; OTDR traces; equipment state information; troubleshooting procedures; Alarm analysis tools; fault-diagnosis tools; OTDR APIs; DT plat- form; NMS API; recovery and reconfiguration tools; Upgrade Capacity requirements; traffic growth trends; equipment databases; spectrum utilization; upgrade constraints; Capacity optimization tool; RSA tool; QoT estimation; DT plat- form; resource planning; configuration and validation tools; DecommissionService inventory; SLA requirements; equipment and asset records; retirement procedures; QoT and performance verification; service migration tools; NMS API; asset-management systems; configuration tools ecution within its domain. It also validates the outputs of its sub-Agents against task objectives and constraints, forming a local closed loop in which unsatisfactory results are refined or re- executed before being passed to the upper level. These Agents ensure that every lifecycle phase, from initial planning to net- work decommission, is intelligently coordinated and seamlessly integrated into the overall management process. At the expert level, AI Experts operate under the supervision of their respective Division Agents to execute specific sub-tasks efficiently. The Planning Agent focuses on network design, re- source allocation, and feasibility analysis. It can direct the Infras- tructure Selector to choose appropriate components and instruct the Configuration Scheduler to implement initial settings. The Deployment Agent ensures seamless infrastructure rollout, com- manding the Field Engineer for physical installation and the Performance Tuner for system verification and stability testing. The Operation Agent maintains real-time network functionality, with the Automated Inspector executing anomaly detection and the Dynamic Operator managing traffic and resource allocation according to the actual requirements. The Maintenance Agent ensures reliability by directing the Alarm Handler to repair prob- lems, and the Abnormal-data Handler to prevent failures. The Upgrade Agent enhances performance, instructing the Upgrade Planner to implement improvements and the Validation Spe- cialist to verify network stability. The Decommission Agent manages network retirement, overseeing the Retirement Planner for equipment removal and the Service Switcher for seamless data and service transitions. Experts shown here are represen- tative rather than exhaustive; additional task-specific Experts, such as Device Manager and Physical Decommission Agent, can be instantiated according to specific network requirements and may be added as the network evolves. This division-to-expert structure separates lifecycle-level coordination from task-level execution, allowing each Expert to specialize in a specific func- tion and interact with the corresponding models, knowledge bases, and network tools. As a whole, all Agents are capable of inter-Agent communica- tion via A2A protocols [70] and interact synergistically to ensure seamless coordination across the entire network lifecycle. The Planning, Deployment, and Decommission Agents are activated when their corresponding lifecycle phases are initiated: the Plan- ning Agent defines network architecture and resource allocation, the Deployment Agent manages infrastructure rollout and initial setup, and the Decommission Agent oversees retirement and mi- Research Article10 ✓Selectedequipment,fibersegments,amplifiersites ✓Initialparameterconfigurations Planning Agent Parameter Scheduler Infrastructure Selector Goal Equipmentinformation •Vendorandspecification Fibersegmentsresource Amplifiersites •Originanddestination •Location Fibersegmentsselection •Segmentscombination •Latencyandcostcalculation Amplifiersitesselection •Electricpowerevaluation •VendorandSupplychainhealthanalysis •Performanceevaluation •Cost Equipmentselection Parameterconfiguration optimization&QoT estimation Task2:Provideparameterconfigurationsbasedonrequirementsand [equipment,fibersegments,amplifiersites],andevaluateBoLmarginof eachservicechannel. Task1:Select a set of [equipment,fibersegments,amplifiersites] that meets requirements. GenerateasetofinitialparameterconfigurationsandprovideBoLmargin Topologybuild Routingandspectrum assignment BoLmargin We plan to build a new 4-node ring opticalnetwork. Please select appropriate equipment, fiber segments, and amplifier sites based on the following requirements,andprovide equipmentparameterconfigurations. Requirements:thefournodesare[node1,node2,node3,node4];Cbandsystemwitha single-channelrateof400Gb/s;anytwonodeshavedual-routeredundancyprotection,and thelatencymustbelessthan0.5ms;theinitialbandwidthbetweenanytwonodeis2.4Tb/s. Equipment:VendorN,6setsofOTN-Cequipment Fibersegments:Node1->ExpresswayWest->TollStation->...->Node2-> OpticsValleyRoad->...Node3->Informationport->...Node4 Amplifiersites:EastTollStation,Autorepairshop,...,VictoryMall TheoptimalconfigurationsandBoLmarginareasfollows: OTU1-node1-191.4THz,135GBaud,+3dBmTxpower... OA-node1-east:gain21dB... WSS1-node1-MediaChannel:MC1addport1191325191475... BoLmargin:OTU1-node14.5dB,OTU2-node13.6dB... ? Node1 Node2 Node3 Node4 Node1 EastTollStation VictoryMall Expressway West TollStation Fiber segments Opticalamplifiersites ? ? Gain23dB Tilt1.5dB OTU1 Tx+3dBm191.4THz... ① ② ③ ④ ⑤ ⑥ Planned network Which fiber segments and opticalamplifier sites? Which vendor’s equipment and how manysets? What are the configuration values for each parameter of the equipment? ② ③ Name InfrastructureSelector Output the equipment,fibersegmentsandamplifiersites that meets the requirements ParameterScheduler ④ ⑤ Theplanningreportisasfollows: ToolKit Knowledge Library RAG Call Tools I need toprovidetheequipment typeandquantity,specificfiber segmentsandamplifiersites accordingtotherequirements, whileconsideringcostand stability. Equipmentselection:VendorN, 6setsofC-bandOTN... Fibersegmentsselection: Node1->ExpresswayWest->Toll Station->... Amplifiersiteselection: East TollStation... •Cost •Length,fiberloss, rentalcost •Electricpower Goal Equipmentinformation •Vendorandspecification •TypeandCharacteristic Fibersegmentsinformation •Originanddestination Name Toolkit Knowledge Library Out RAG Call Tools I need tobuildthetopologyfirst, thenperformQoTestimation basedonthecharacteristicof equipment,determinethebest RWAscheme,andfinallyprovide BoLmargin. •Length,fiberloss Parameterconfiguration: OTU1-node1-191.4THz,135GBaud... OA-node1-east:gain21dB... WSS1-node1-MediaChannel:MC1... BoLmargin:OTU-1node14.5dB Opticalnetwork tobeplanned •Portrateand interfacetype •Noderelativeposition •Linkbuilding •Latency •SNRconsidered In LLM LLM Out Planning Query infrastructureresourceinfos Memory Action Self-iteration Callresourceselectiontoolsto obtainalistofopticalnetwork infrastructure √ × Goal Achieved? In LLM LLM Planning Query infrastructureresourceinfos Memory Action Self-iteration Obtainasetofinitialequipment parameters,andBoLmargin calculation √ × Goal Achieved? (a) (b) (c) Fig. 5. Schematic of multi-Agent collaboration in the planning phase of the optical network, (a) coordination among Planning Agent, Infrastructure Selector, and Parameter Selector, (b)-(c) functional workflow of the Infrastructure Selector and the Parameter Scheduler: based on the input, the LLM plans the task, retrieves necessary information via RAG from the knowledge base, and invokes tools to carry out a sequence of operations. Once the task is completed and the objective is met, it returns the results to the higher-level Agent. gration. In contrast, the Operation, Maintenance, and Upgrade Agents remain continuously active throughout the network’s operational phase, ensuring real-time monitoring, maintenance, and performance optimization. These three Agents form the core of network management, working closely with the Task Coordinator, Memory Container, and Security Manager to main- tain efficiency, adaptability, and security. For example, when the Operation Agent detects abnormal performance metrics, it first attempts self-correction before escalating the issue to the Task Coordinator, which then assigns the task to the Maintenance Agent for immediate troubleshooting or to the Upgrade Agent for hardware adjustments and system enhancements. Although all these multi-level Agents are powered by LLMs as the core technology, we can flexibly select models of different scales based on task complexity and capability requirements, enabling hierarchical deployment across the cloud, edge, and device. Core control and complex task processing can be han- dled by large models in the cloud, while latency-sensitive and resource-constrained tasks are efficiently executed by relatively small models deployed at the edge or devices, optimizing com- putational resource allocation while ensuring high-level intelli- gence. In practical deployment, each lifecycle Agent is grounded in a combination of domain knowledge, network-state infor- mation, and executable tools. Knowledge and data provide the contextual information required for Agent reasoning, while domain-specific tools provide validated computational, simula- tion, monitoring, and control capabilities. The Agent coordinates these heterogeneous resources according to the task and the cur- rent network state. Representative knowledge sources, network data, and tools for the six lifecycle phases are summarized in Table 2. 5.AUTONOMOUS LIFECYCLE MANAGEMENT OF AGEN- TIC OPTICAL NETWORKS The AONs extend beyond single task automation toward coor- dinated and lifecycle intelligence. In this section, we present the architecture of LLM Agent-driven autonomous LCM of optical networks, encompassing the detailed workflow of the six phases from planning to decommission. Instead of focusing on individ- ual task automation, we emphasize how multiple specialized Research Article11 Agents can be organized and orchestrated to support all stages in a coherent and scalable manner. By introducing how Agent capabilities can be integrated into optical networks, we aim to provide a structured foundation that can inform initial system design and deployment for future AONs. A. Planning phase In the initial planning phase of the optical network lifecycle, the primary task is to perform demand analysis and topology de- sign based on factors such as the operator ’s service development plan, capital investment strategy, and network reliability require- ments. This process determines the fundamental attributes of the new network, including node geographic locations, network capacity, redundancy protection schemes, latency requirements between nodes, and initial bandwidth provisioning. As this process constitutes the top-level design of the network, it in- volves diverse and dynamically changing information elements, and it is necessary to combine information from a knowledge base and utilize various tools for Agents. To address these chal- lenges, based on the above hierarchical multi-Agent framework, it is designed to deploy three Agents for the planning phase. First, the Infrastructure Selector Agent is responsible for select- ing infrastructure resources. Second, the Parameter Scheduler Agent generates configuration parameters. Third, the Planning Agent serves as the orchestrator, coordinating task reception, information integration, and downward command delegation, functioning as a communication bridge within this multi-Agent system. These roles do not imply that every step requires LLM rea- soning. Deterministic database queries, rule-based filtering, QoT estimation, and numerical optimization remain preferable for well-defined inputs and constraints because they provide reli- able and reproducible outputs. The added value of LLM-based Agents lies at the orchestration level, particularly in interpreting high-level or incomplete operator intents, translating contextual preferences into selection criteria and optimization objectives, reasoning over trade-offs among performance, cost, supply- chain robustness, and reliability, and dynamically selecting and sequencing the required tools. Accordingly, the Infrastructure Selector uses LLM reasoning to synthesize heterogeneous in- formation and establish resource-selection priorities, whereas the Parameter Scheduler invokes deterministic tools to generate reproducible configurations and performance estimates. For stable tasks with fixed requirements and predefined workflows, a purely deterministic implementation may be sufficient. Agent- based orchestration becomes valuable when requirements are incomplete or evolving, multiple tools must be coordinated, or intermediate results require the workflow to be adapted. In this phase, Network Director notifies the Task Coordinator to process the user-defined task and assign the optical network planning task to the Planning Agent. Taking a simple four-node ring topology as an example, the collaboration process among these Agents can be illustrated as depicted in Fig. 5 (a). First, the Planning Agent receives key information about the network, including the names of four nodes, the per-wavelength rate of a C-band system, and the requirement for dual-path redundancy protection. Based on these requirements, the Planning Agent del- egates the task of resource selection to the Infrastructure Selector. The workflow of the Infrastructure Selector Agent is depicted in Fig. 5(b). After understanding the Planning Agent’s intent, the Infrastructure Selector retrieves information on fiber seg- ments related to the specified node locations and corresponding amplifier sites using RAG from the infrastructure knowledge base. Meanwhile, it retrieves equipment information that meets user requirements, including vendor names, technical specifica- tions, and pricing. Next, the Infrastructure Selector enters the Action phase and invokes resource-selection and deployment- optimization tools to select equipment and fiber segments and, where multiple candidate solutions are available, to determine the locations and quantities of OAs and the allocation of OTUs. Next, the Infrastructure Selector enters the Action phase, invok- ing resource selection tools to choose from the three categories of resources: equipment, fiber segments, and amplifier sites. Equipment selection must consider multiple criteria such as supply chain robustness, cost, and technical performance, with specific priorities depending on the operator’s strategic prefer- ences. Once a feasible set of resources is selected and deemed to meet user requirements, the Infrastructure Selector sends the result to the Planning Agent. If the selected resources fail to meet expectations, the Infrastructure Selector must iterate on the selection process. Following this, the Planning Agent integrates user require- ments with the selected infrastructure resources and instructs the Parameter Scheduler to generate initial configuration param- eters and estimate BoL margin for service channels. Upon receiv- ing instructions from the Planning Agent, Parameter Scheduler initiates its workflow by retrieving detailed resource informa- tion via RAG from the knowledge base. It then proceeds to invoke a series of tools: first, a topology construction tool used to simulate the four-node ring network, followed by a QoT es- timation tool and device configuration optimization algorithm. These tools determine parameters such as OA gain/tilt and WSS channel attenuation settings. The Parameter Scheduler then completes RSA according to latency and SNR requirements. Fi- nally, the BoL margin of the service channels is obtained. If the margin values meet or exceed the minimum threshold, the Parameter Scheduler submits the generated configuration back to the Planning Agent. After that, Planning Agent consolidates the final planning results into a planning report, which includes a detailed network topology and configuration summary. This report is returned to the Task Coordinator, which guides the subsequent deployment phase. This example illustrates how three Agents can collaborate to efficiently complete infrastructure selection, parameter pre- generation, and performance estimation for the planning phase. It is important to note that all Agents are based on LLM and rely heavily on well-designed prompts and harness engineering to effectively execute planning, action reasoning, RAG queries, tool invocation, and result evaluation. Additionally, to ensure optimal infrastructure selection by the Infrastructure Selector Agent, the completeness and standardization of information in the infrastructure knowledge base is critical. Similarly, for the Parameter Scheduler Agent, beyond knowledge base qual- ity, the accuracy and reliability of tools in the toolset library are equally essential. In this framework, LLM-based Agents act as orchestrators rather than directly replacing deterministic numerical optimizers. They translate planning requirements into objectives and constraints, retrieve candidate resources and uncertainty information, invoke appropriate deterministic or robust optimization tools, and verify and iterate the returned solutions. Robust or rolling-horizon optimization can also be invoked when traffic demand, component aging, failure risks, or resource availability evolve over time. Therefore, OA and OTU deployment optimization can be implemented as a spe- cialized computational module while remaining embedded as a tool-enabled subtask of the planning phase. The resulting de- Research Article12 10101010110101010101010101010 10010111101010101010101010101 01010101011111010101010101010 10101010101010010001111111111 10001010100100101010111001011 01010111100000101001010010100 Pleasecompletetheopticalnetworkdeployment accordingtotheplanningreport. Deployment Agent The fiber splicing between the four nodes has been completed, and allequipmenthave been initialized. Performance Tuner Network performance optimization has been completed. Essential initial information, suchasfiber length, loss, and amplifier gain,BER,has been recorded in the database. Task1:Guide the fiber team to complete the fiber connection and the equipment team to complete installation and initialization according to the planning report. Task2:Perform optical network performance tuningand record the initial network information in the database. Field Engineer Fiberteam Equipmentteam ① ② ⑦ ③ OA Node1 Node2 Node4 Node3 OA Fiber splicing Fieldopticalnetwork Node1 Node2 Node3 Node4 Digital twin •Splicing •Patching •Installation •Initialization Data Config Verification & Feedback Guidance & reporting Externalinteraction platforminterfacetools •Issuanceofopticalfiberconnectioninstructions Fiber platform Parameteroptimization NMS platform •Equipmentmanagementintegration •Configureinitialparameters •Issuanceofequipmentinstallationinstructions Networkinitial datastorage NMS ④ ⑤ ⑧ ⑨ ⑥ Equipment platform •Launchpower •EDFAgain/tilt,WSSchannelVOA Digitaltwininterface •Parameterverification •Performancefeedback Deploymentcompleted Goal ② Name FieldEngineer Guidefiberandequipmentteamtocompletethefieldengineeringaccordingtothe planningreport PerformanceTuner ④ ⑤ In LLM LLM Out Call Tools Ineedtodirectfiberand equipmentteamtocomplete theon-siteinstallation,and thecheckthenetwork connectivity. Planning Fiberplatform:Startfiberconnection Action Goal Equipmentinformation •Vendorandspecification •TypeandCharacteristic Fibersegmentsinformation •Originanddestination Name Parameterconfiguration Tools InfrastructureKnowledge Base In LLM LLM Out RAG Call Tools I need tooptimizetheoptical networkperformanceand recordtheinitialnetwork information Planning Action •Length,fiberloss Parameteroptimization: Launchpower:otu1+3.5dBm... EDFAgain/tilt:OA125.6dB/1.5dB... WSSvoa:[1,2.2,2.0,1.5...] Completeopticalnetworkperformancetuningandinitialdatastorage RAG Equipmentknowledge •Installationmanual •Commandlinemanual Fibersegmentsinformation •Originanddestination •Length,fiberloss Infrastructure Knowledge Base BERquery:otu1BER2.3e-3... ⑧ (a) Memory Queryfiberandequipment resourceinformation. Goal Achieved? Callexternalinteractionplatforminterface toolstoguidefiberandequipmentteams, andmanagedequipment Self-iteration Memory Queryfiberandequipment resourceinformation. Networkinitialdatastorage Callparameterconfigurationtools tooptimizenetworkperformance Goal Achieved? Self-iteration DatabaseinterfaceAPI NMSplatform: Theequipmentis connectedandtheIPaddressis correct... Equipmentplatform:Putonthe shelf,poweron,andinitializethe configuration (b) (c) Fig. 6. Schematic of multi-Agent collaboration in the deployment phase of the optical network, (a) coordination among Deploy- ment Agent, Field Engineer, and Performance Tuner, (b) functional workflow of the Field Engineer, (c) functional workflow of the Performance Tuner. ployment plan is then physically implemented in the subsequent deployment phase. B. Deployment phase In the deployment phase of the optical network lifecycle, the primary objective is to implement the network topology and equipment configurations generated during the planning phase and to perform initial performance tuning. This phase is charac- terized by frequent interactions between the network operation center (NOC) and field engineers, as well as communications between the NMS and physical devices. To efficiently manage this complicated task, three types of AI Agents are assigned to this phase: a top-level Deployment Agent, a Field Engineer Agent responsible for field coordination, and a Performance Tuner Agent responsible for network performance optimization. The Deployment Agent receives deployment tasks from the Task Coordinator, along with the planning report produced by the Planning Agent. Following the typical workflow of the deployment phase, the Deployment Agent first instructs the Field Engineer Agent to carry out on-site tasks such as fiber connection and equipment installation. Here, the Field Engineer Agent can be embodied and equipped by human with mobile terminals, or potentially through robotic systems for assisted or automated operations. Then Deployment Agent assigns the Per- formance Tuner to execute optical network performance tuning and store initial network data. The workflow of Field Engineer is illustrated in Fig. 6 (b). Upon receiving instructions, the Field Engineer can access relevant fiber and equipment informa- tion through RAG, and interacts with the fiber and equipment platform to coordinate with the fiber and equipment teams, re- spectively, for field implementation. Since the Field Engineer can interface directly with human field engineers, the platforms may support multimodal interactions including text, voice, im- age, and video, similar to features provided by modern instant messaging tools. During the fiber connection process, Field En- gineer guides the fiber team to connect fiber segments based on the planning report. Some segments are connected via splicing, while others may require patch cords. It is essential that Field En- gineer instructs the fiber team to use equipment such as optical time domain reflectometer (OTDR) to ensure fiber attenuation and splice loss meet engineering standards. Additionally, using installation manuals retrieved from the equipment knowledge base, Field Engineer guides the equipment team in installing devices at optical amplifier sites and ROADM nodes. This in- cludes completing fiber patching and initializing the equipment to enable proper inter-device communication. Field Engineer may then invoke the NMS to incorporate the equipment into the management system and deploy the OTU and optical equipment configurations generated during planning. Once these steps are completed, the optical channel (OCH) can be established, and the network reaches a near-optimal operational state. At this point, telemetry data, such as network status and transmission Research Article13 Automated Inspector Dynamic Operator Operation Agent Report Automatic inspection target Response Requirement for dynamic adjustment Report/Response Requirement Upper Agents Operation Agent: NMS Dynamic Operator: Operation Agent: Task decomposition: Step 1: Retrieve APIs of NMS for data collection Step 2: Retrieve the algorithm for RWSA of new service Step 3: Retrieve APIs of DTON for simulating the dynamic changes after add/drop Step 4: Evaluate the network performance and analyze feasibility of add/drop Step 5: Retrieve APIs of NMS for configuration Step 6: Check the performance and generate a response Och-3 released, Och-4 added at ... APIs Telementry Adjust configuration and improve performance based on the traffic requirements Re-allocated traffic and network performance In LLM LLM Out Tool Base Knowledge Base •Choices for performance optimization (by priority) →1. power control →2. EDFA configuration →3. Re-route→4. Report cannot opt ... •Steps for service dynamic adjustment 1. Add channels: →RWSA →QoT estimation →config →check → 2. Drop channels: →require →QoT estimation →config →check → •Requires hardware support →Report to upper agents for assistance ... Expertise to solve operational requirements RAG Call Tools Planning Query historical logs and solutions Memory 1. Requirement analysis 2. Performance prediction 3. Configuration Action 1. Plan and rehearsal 2. Feasibility analysis 3. Deploy and response Self-iteration Involve APIs and tools for traffic re-allocation Requirement: “Drop Och-3 on Path (N 1 →N 2 →N 3 ) and establish a new 400Gb/s Och-4 between N 1 and N 4 .” Add channel Drop channel √ × •APIs of NMS •Performance data •Configuration APIs •APIs of DTON •Calculation tools •Power optimization •EDFA configuration •Route algorithm •Spectrum allocation •QoT estimation tools •... How is the network state and does it need to be inspected? ？ [14:32:05] NMS TelemetryService ID: svc-400G-003 Status: ACTIVERoute: NODE-1 → NODE-2 → NODE-3 Central Frequency: 193.25 THz Current GSNR: 20.42 dB [14:32:07] Service Management Request received: DELETE svc-400G-003 [14:32:10] Configuration Manager Service svc-400G-003 removed successfully Spectrum resources released: [193.20, 193.30] THz [14:32:12] Provisioning Request Service ID: svc-400G-004 Selected frequency: 194.10 THz Selected route: NODE-1 → NODE-3 → NODE-4 [14:33:08] QoT Estimation Predicted GSNR: 19.83 dBRequired GSNR: 16.00 dB QoT margin: +3.83 dBStatus: FEASIBLE [14:33:21] NMS Configuration API Provisioning configuration to devices [14:33:31] NMS Telemetry Service ID: svc-400G-004 Status: ACTIVE Route: NODE-1 → NODE-3 → NODE-4 Central Frequency: 194.10 THzCurrent GSNR: 19.67 dB Action trace: Fig. 7. An illustration of multi-Agent collaboration during the operation phase of AONs, along with the functional workflow of the Dynamic Operator and a detailed description of its behavior in a channel adding scenario. performance, can be collected to construct an DT of the deployed physical network, as shown in Fig. 6 (a). Since actual fiber parameters may slightly deviate from those assumed during planning, fine-tuning of device configurations is necessary to achieve optimal power flatness and SNR. These adjustments, performed by the Performance Tuner, can be veri- fied within the DT before being issued to the physical network. The optimization parameters mainly includes launch power pro- file, EDFA gain/tilt, and WSS channel attenuation settings. Once performance metrics converge to their optimal values, the opti- mized configuration is deployed to the network devices. Finally, the fiber parameters, equipment configurations, and transmis- sion performance data are stored in the network initial database, which serves as the starting point of the lifecycle-wide database for subsequent operation and maintenance phases. This phase further demonstrates the critical importance of high-quality knowledge and tool libraries in enabling Agent efficiency and accuracy. For example, the Performance Tuner relies heavily on the accuracy of the DT and the effectiveness of optimization algorithms. Therefore, careful design and contin- uous maintenance of both the knowledge base and toolset are essential throughout the entire network lifecycle. C. Operation phase In the operation phase, the primary focus shifts to ensuring the network’s ongoing stability, efficiency, and reliability, as well as adapting to real-time changes in traffic and condition. This phase is essential for maintaining high-quality service through- out the network’s lifecycle. The Operation Agent plays a central role in managing this phase, orchestrating network tasks, moni- toring optical performance, and taking corrective actions when necessary. Unlike the Planning Agent and Deployment Agent, which operate only at the initial phases of the network’s lifecycle, the Operation division remains continuously active, overseeing the daily functioning of the network and ensuring that it runs smoothly throughout its operational lifetime. To efficiently manage the various tasks required during this phase, the Operation Agent works in close collaboration with two specialized sub-Agents: Dynamic Operator and Automated Inspector. Dynamic Operator is responsible for the continuous adjustment of network parameters to accommodate fluctuations in network traffic, bandwidth demands, and other dynamic vari- ables. This Agent makes real-time decisions to balance network traffic and improve performance, ensuring that each part of the network is operating at peak efficiency. It plays a crucial role in continuously optimizing network performance, ensuring ser- vice quality, and dynamically adjusting network configurations based on evolving demands. One of Dynamic Operator’s primary functions is network performance enhancement to guarantee high-quality service provisioning. It continuously evaluates network performance by analyzing key indicators such as latency, power, SNR, and BER. Based on changes in traffic demand or new service require- ments, it can autonomously adjust network configurations and expand capacity as needed. Through NMS, Dynamic Opera- tor primarily executes software-level adjustments, including launch power optimization, device parameter configuration, and routing adjustments. As illustrated in Fig. 7, a representa- Research Article14 Operation Agent Upper Agents NMS APIs Telementry Perform a daily network operation inspection and report any possible anomalies No event or report anomalies Requirement Response Requirement for dynamic adjustment Automated Inspector Dynamic Operator ？ Report/Response In LLM LLM Out Tool Base Knowledge Base RAG Call Tools •Service performance (Power, SNR, BER, channel/ bandwidth, spectrum utilization, profile flatness ...) •Fiber anomaly (Length, insertion loss, fast fiber loss anomaly, co-trench/co-cable identification ...) •Equipment health (Transceiver, WSS, amplifier ...) •Environmental sensor (Temperature, humidity ...) Monitoring indicators for covert problems Expertise for prediction and resolution •Indicator threshold •Historical decision-making ... •Step-by-step solutions •APIs of NMS •Performance query •Spectrum query •Route query •Device query •Module query •... •Calculation tools •Power flatness •Spectrum utilization •... Planning Query indicator descriptions and solutions Memory Inspection scheduling Action Analyze... and record... Involve APIs and tools to assist in analysis Self-iteration √ × NMS APIs Telementry Operation Agent: Automated Inspector: “Perform once network inspection and report any potential anomalies.” Step 1: Retrieve APIs to query performance indicators in the current network state Step 2: Retrieve tools to detect abnormal power deviations and identify affected elements Step 3: Analyze any abnormal events based on historical logs and expertise Adjust configuration and improve performance based on the report Optimized network performance Report Automatic inspection target Operation Agent: Step 1: Retrieve APIs of NMS for data collection Step 2: Check path switching strategy for optimization, protecting theochtransmission Step 3: Evaluate the network performance and analyze feasibility of the path switching Step 4: Retrieve APIs of NMS for configuration Step 5: Check the performance and generate a response Dynamic Operator: Report results, update memory. Operation Agent: [15:41:05] NMS Telemetry OCH-01: output power min -4.2 dBm OCH-02: output power min -4.6 dBm OCH-03: output power min -5.6 dBm OCH-04: output power min -45.0 dBm OCH-05: output power min -4.7 dBm [15:41:12] Anomaly Detection OCH-04: output power min -45.0 dBm Power level below normal operating range. [15:41:15] AlarmXX-OLA-024: LOS (Loss of Signal) [15:42:07] NMS Telemetry OCH-04: output power min −45.0 dBm Service status: DEGRADED Workingpath: PRIMARY Primarypath: NODE-1 > NODE-3 > NODE-4 Secondary path: NODE-1 > NODE-2 > NODE-4 [15:44:37] QoT Estimation Predicted GSNR after protection switching: 18.92 dB Required GSNR: 16.00 dB QoT margin: +2.92 dB Protection path status: FEASIBLE [15:45:01] NMS Configuration API OCH-04 rerouted to: Secondary path: NODE-1 > NODE-2 > NODE-4 [15:45:16] NMS Telemetry OCH-04: output power min -5.1dBm Service status: ACTIVE Working path: SECONDARY Primary path: NODE-1 > NODE-3 > NODE-4 Secondary path: NODE-1 > NODE-2 > NODE-4 Current GSNR: 18.76 Db Alarm: LOS-CLEARED Action trace: Action trace: “Optimize the configuration and verify the performances.” Fig. 8. Schematic of functional workflow of the Automated Inspector in operation phase, along with a detailed description of its behavior in a network anomaly inspection scenario. tive dynamic add/drop task demonstrates the execution process from an upper-level requirement to concrete network actions. The Operation Agent first decomposes the requirement into API retrieval, RSA, DT-based performance evaluation, and configu- ration verification steps. The Dynamic Operator then invokes the corresponding NMS and computational tools and produces an executable action trace. In the demonstrated case, an existing 400 Gb/s service is released and a new service is provisioned on an alternative path and frequency, followed by GSNR evaluation and NMS configuration. The returned network status confirms that the new service is active and that the required transmission performance is satisfied. During the execution, the Dynamic Operator follows the plan generated by the Operation Agent while checking the returned network state after each action. In the demonstrated trace, NMS telemetry is first retrieved to determine the current service and route state, followed by service release and provisioning re- quests. The resulting configuration status and predicted GSNR are then checked to verify that the modified network remains operational. Finally, the Dynamic Operator returns the execu- tion status and updated network state to the Operation Agent for further coordination. Additionally, Dynamic Operator as- sists in service quality assurance, establishing traffic scheduling and priority management to ensure that network resources are allocated based on predefined service level agreement (SLA), which guarantees the real-time and emergency communications. By enforcing intelligent scheduling policies, Dynamic Operator can maintain the required quality of service (QoS) levels across diverse scenarios. Furthermore, Dynamic Operator supports software and system upgrades, ensuring smooth transitions without service disruption. The Automated Inspector is the real-time monitoring and diagnostics Agent in optical networks, dedicated to ensuring long-term stability through continuous surveillance, predictive maintenance, and environmental awareness. Unlike the Dy- namic Operator, which focuses on active optimization, the In- spector monitors key metrics such as optical power, GSNR, and bandwidth utilization to detect QoT fluctuations and anomalies. Integrated within NMS, it offers centralized visibility and au- tomated reporting. It performs routine inspections on power flatness and spectrum usage to optimize GSNR and spectral efficiency, while also diagnosing physical infrastructure by eval- uating fiber attenuation, equipment health, and identifying po- tential faults. Additionally, it monitors environmental condi- tions like temperature and humidity, enabling proactive risk mitigation and maintaining resilient network operations. Automated Inspector can autonomously analyze anomalies and generate structured reports for further action. Detected issues are categorized and sent to the Operation Agent to de- termine the response strategy. If performance tuning is needed, it delegates execution to the Dynamic Operator for real-time adjustments like power tuning or path reconfiguration. The Op- eration Agent also periodically initiates automated inspections, during which the Inspector retrieves monitoring indicators and methodologies from its knowledge base, invoking tools and APIs for comprehensive checks. As illustrated in Fig. 8, the Au- tomated Inspector receives an inspection request from the Oper- ation Agent, retrieves the required NMS performance indicators and analysis methods, and detects abnormal optical-power con- ditions from the returned telemetry. The action trace shows an abnormal power condition below the normal operating range. The Inspector reports these observations to the Operation Agent, which then determines whether the issue can be resolved within the current operation domain. For the demonstrated case, the Research Article15 Network Management System Database store in Performance data generate influence Alarm-Handler Abnormal-data Handler Maintenance Agent Fault Fiber- failure Device- failure Fiber degradation Fiber interruption Card failure Optical module failure Switch/Router failure Overheating Power- failure Power outage failure Power fluctuate failure Software failure IP Conflict Protocol Mismatch Port Misconfiguration Temperature Tx/Rx power Current Voltage BER SNR Link loss Delay Port Status Bandwidth utilization In LLM LLM Out Tool Kit Knowledge Library RAG Call Tools Planning Query historical logs and solutions Memory 1. Need to query alarms 2. Determine root alarm 3. Provide a conclusion Action 1. Call alarm system 2. root cause analysis 3. Summary output Self-iteration Involve APIs and tools for alarm analysis √ × maintenance personnel Fault diagnosis report Perform alarm diagnosis tasks Alarm information Interface Tools •Query alarm •Query fault •Interaction with other agents Expert experience •Correlation between alarms •Previous processi ng ex amples •Alarm definition •Alarm level •Alarm type •Potential impact Alarm processing tools •Alarm compression •Root alarm analysis algorithm •Provide handli ng s uggestions In LLM LLM Out Tool Kit Knowledge Library RAG Call Tools Planning Query historical logs and solutions Memory 1. Query performance data 2. Process performance data 3. Provide a conclusion Action 1. Call data base 2. Performance analysis 3. Summary output Self-iteration Involve APIs and tools for data analysis √ × Perform data diagnosis tasks Performance indicators information •Definition of performance indicators •T hreshold of performance indicators •Possible impacts of exceeding performance indicators •Performance statistical methods •Performance analysis algorithm •F ault prediction model •Performance prediction model Algorithms & Models In Out The same processing framework as the other two agents Instruction issuance Knowledge Library Expert experience • Previous maintenance cases •Professional Knowledge Handbook Tool Kit •Communicate with other Agents •Check the repair progress Interface Tools RAG Call Tools Interface Tools •Query performance data Fig. 9. Schematic of multi-Agent collaboration in the maintenance phase of the AONs. Faults trigger alarms and cause anomalies in performance indicators, which are detected by the Alarm Handler and Abnormal-data Handler. By correlating alarms with performance data, the Maintenance Agent identifies the fault and assists maintenance personnel in resolution. A fault diagnosis report is generated once the fault is resolved and the system returns to normal. Operation Agent generates a follow-up optimization request and instructs the Dynamic Operator to retrieve the relevant con- figuration interfaces, evaluate the optimization strategy, and apply the resulting adjustment. After configuration, the perfor- mance is re-evaluated and the updated network state is reported back to the Operation Agent. D. Maintenance phase The goal of the maintenance phase is to quickly identify and resolve faults, thereby minimizing service interruptions and reducing economic losses as much as possible. With the continu- ous expansion of optical networks, the number and variety of devices and components are also growing, leading to an increas- ing overall complexity of the network. In the event of a failure, a large number of alarms are triggered and massive abnormal performance data are generated. Under such a complex environ- ment, timely and accurate fault localization and repair becomes critical for ensuring optical network stability. Firstly, we introduce several common types of faults and the key network indicators that are typically affected when a fault occurs, as shown in Fig. 9. First, one of the most com- mon optical network faults are optical fiber failures, including both gradual fiber degradation and abrupt fiber breaks. Degra- dation tends to occur over time and can be detected through specific performance indicators. In contrast, fiber breaks are usually sudden, often resulting from external mechanical forces or environmental changes that alter the fiber’s physical prop- erties and rapidly degrade optical transmission. Second, the software malfunctions arise from incompatibilities between soft- ware and hardware components, leading to issues such as IP con- flicts, protocol mismatches, or port misconfigurations. Third, the equipment malfunctions refer to the performance degradation of devices or modules due to factors such as aging, manufactur- ing defects, or environmental stress. Typical examples include failures in boards, optical modules, or overheating of network components. Fourth, the power failures frequently occur in data centers, which are caused by power outages, voltage instability, or power distribution faults. These faults often lead to abnormal or fluctuating values in key network performance indicators, directly or indirectly impacting QoS. The network indicators we monitor include temperature, voltage, current, optical power, BER, link loss, SNR, delay, port status, bandwidth, and others. Through telemetry, these indicators reflect the real-time network state and help alert maintenance personnel to potential risks. To support this, threshold-based alarms are used to alert operators when performance metrics exceed predefined limits. Although most alarms today are still threshold-driven, the concept is flex- ible and can incorporate multi-dimensional conditions rather than relying solely on single-metric triggers. The overall framework of the maintenance phase and the roles of the involved Agents are depicted in Fig. 10. When a fault occurs, the network management system generates alarms, while the fault may also cause abnormal changes in the perfor- mance data stored in the database. The Maintenance Agent first assigns diagnostic tasks to two specialized Agents: the Alarm Handler and the Abnormal-data Handler. The Alarm Handler retrieves and correlates alarm lists to distinguish root alarms from derived alarms. Meanwhile, the Abnormal-data Handler retrieves telemetry data and examines deviations from normal performance baselines. The two Agents exchange their inter- mediate conclusions and jointly narrow down the fault location and possible root cause. These diagnostic activities are supported by a shared knowl- edge base and tool base. The knowledge base contains alarm definitions and propagation rules, performance baselines and alarm thresholds, device manuals and troubleshooting guides, Research Article16 Network Management System Database store in Performance data Generate alarms Alarm-Handler Abnormal-data Handler Instruct-Agent analyzing call for data send data analyzing call for alarm lists send alarm lists conclusionshare instruction issuance Guide repaire generate thefault handling report confirm confirm Feedback Task distribution Task distribution LinkDown fault (unknown for us) influence Task distribution call for data and get feedback Analyzing and conclusion share call for alarm lists and get feedback Analyzing and conclusion share confirm instruction issuance Repaire confirm generate thefault handling report Knowledge Base Tool Base •Alarm definitions and propagation rules •Performance baselines and alarm thresholds •Device manuals and troubleshooting guides •Historical fault cases and maintenance records •Repair SOPs and safety constraints •Alarm query •Performance telemetry query •Topology and service-impact query •Alarm correlation and anomaly analysis • OTDR and optical-power testing •Work-order and report generation Data Access Tools Diagnosis and Handling Tools Multi-Agent Action Trace [10:02:15] NMS: Link NE-2–NE-3 DOWN [10:02:31] Alarm-Handler: NE-3/Rx: LOS (Critical) Downstream nodes: LOF/AIS alarms detected [10:02:35] Abnormal-data Handler: Rx power: -40.0 dBm (Baseline: -14.7 dBm) Upstream Tx power: +1.6 dBm (Normal) Traffic rate: 100 Gb/s → 0 Gb/s [10:03:02] Shared Conclusion: Possible fiber discontinuity near NE-3 [10:03:22] Instruct-Agent: Issue inspection and repair instructions Fault Handling Report Fault: Link NE-2–NE-3 interruption Root Cause: Lose fiber connector at the NE-3 ODF Evidence • LOS alarm at the receiving port • Rx power dropped to −40.0 dBm • Upstream Tx power remained normal Repair Action: Connector inspected, cleaned, and reconnected Recovery Result • Rx power recovered to −14.8 dBm • LOS/LOF alarms cleared • 100-Gb/s service restored Fig. 10. Illustration of Agent collaboration in a specific fault diagnosis and recovery scenario during the maintenance phase. The figure demonstrates the whole process, including fault triggering, alarm and performance anomaly detection, Agent-driven root cause analysis, on-site repair guidance, and final result consolidation. historical fault cases and maintenance records, and repair SOPs and safety constraints. The tools are divided into two groups. Data access tools provide alarm, performance telemetry, topol- ogy, and service-impact queries. Diagnosis and handling tools support alarm correlation and anomaly analysis, OTDR and optical-power testing, and work-order and report generation. After receiving the diagnostic results, the Maintenance Agent checks the consistency of the conclusions and determines the appropriate repair procedure based on the retrieved manuals, historical cases, and operational constraints. It then sends the fault location and repair instructions to field maintenance per- sonnel. After the repair is completed, the Maintenance Agent co- ordinates with the Alarm Handler and Abnormal-data Handler to verify that the alarms have cleared and that the performance indicators have returned to their normal ranges. Finally, it con- solidates the diagnostic evidence, repair actions, and recovery results into a structured fault-handling report. The conclusion- sharing links in the figure represent inter-Agent communication, which can be implemented through A2A-compatible interfaces. Next, we illustrate the fault localization and recovery process through the representative link-down case shown in Fig. 10. At 10:02:15, the network management system reports that the link between NE-2 and NE-3 is down. The Maintenance Agent responds by assigning diagnostic tasks to the Alarm Handler and Abnormal-data Handler. The Alarm Handler queries the network management system and identifies a critical loss-of- signal (LOS) alarm at the receiving port of NE-3, together with downstream loss-of-frame (LOF) and alarm-indication-signal (AIS) alarms. In parallel, the Abnormal-data Handler retrieves the relevant performance data. It finds that the received opti- cal power has dropped from a baseline of approximately -14.7 dBm to -40.0 dBm, while the upstream transmit power remains normal at approximately +1.6 dBm. The traffic rate has also decreased from 100 Gb/s to zero. By correlating the alarm and performance evidence, the two diagnostic Agents infer that the failure is likely caused by a fiber discontinuity near NE-3. The Maintenance Agent then consults the relevant troubleshooting procedures and issues inspection and repair instructions to the field personnel. The on-site inspection confirms that a loose fiber connector at the NE-3 optical distribution frame (ODF) caused the interruption. The connector is inspected, cleaned, and reconnected. After the repair, the received optical power recovers to approximately -14.8 dBm, the LOS and LOF alarms are cleared, and the 100 Gb/s service is restored. Finally, the Maintenance Agent records the root cause, diagnostic evidence, repair action, and recovery status in a structured fault-handling report. E. Upgrade phase The ever-growing network traffic necessitates continuous up- grades in optical networks. During routine network manage- ment, the Upgrade Agent analyzes real-time data and historical trends to predict capacity saturation at different parts of net- works. When C-band utilization approaches 80%, the Upgrade Agent generate upgrade reports to operator, cross-referencing external context such as SLAs. Meanwhile, the operator is also monitoring such links whose capacity is approaching its limit. To prevent potential failures and accommodate new traffic, the operator can instruct the Upgrade Agent to promote this link to C+L-band transmission, as illustrated in Fig. 11. Research Article17 Upgrade Agent Upgrade Planner Performance Optimizer Validation Specialist ① C-band C-band Freq C-bandL- band ? Upgrade ... ... Node1 Node2 Observation: Traffic between Node 1 and Node 2 continues to grow, more capacity outside the C-band required. Business Manager Requirements: The u pgraded transmission system should cover L-band, ultimate 6THz bandwidth and additional 60 channels are expected, the budget is around 1M. Traffic perception Operator Orders Upgrade to L-band! Ta s k breakdown: 1. Pre-calculate the device performance baseline for the link. 2. Push the baselines toImplementation & Validation Agent for device selection. 3. Push the list to Performance Optimization Agent for configurations and margin. 4.Feedback to Implementation & Validation Agent for possible device list updates. 5.Negotiate the upgrade time window with Business Management Agent, who provides a service priority list. 6. Push upgrade time to Implementation & Validation Agent, guide on-site personnel to install device and configuration. In Planning Devices meet baselines. Giving devices install and configuration guides. Action The gain of EDFA should >18dB. Output power is predefined 1.6dBm/ch. Self-iteration Out ToolKit Equipmentinformation •Vendorandcosts Transponder information •Speed and formats Amplifier sites Equipmentselection •VendorandSupplychain health analysis •Performanceevaluation •Cost and installation guide KnowledgeLibrary Knowledge Library Planning Calculate the performance of the link from the device list. Action Invoke GN model for NLI calculation. ToolKit Topology •Link connection •Spectrum grid •Power range GN/ SRS model Spectrum allocation Three-step optimization device Upgrade time window Service level list New service upload Service migration from C to L-band New business established ? ? ③ ④ ⑤ ② Memory Query upgrade device information RAG Call Tools Memory Upgrade optimization info. RAG Call Tools Self-iteration Fig. 11. Schematic of multi-Agent collaboration in the upgrade phase of the AONs. The figure depicts how the Upgrade Agent predicts capacity saturation and coordinates with sub-Agents, including the Upgrade Planner, Validation Specialist, Performance Optimizer, and Business Manager, to carry out a C-to-C+L band upgrade. It visualizes each Agent’s role in planning, device valida- tion, performance optimization, and scheduling, ensuring a seamless and efficient network upgrade process. Upon receiving the upgrade order, the Upgrade Agent sum- marizes the upgrade requirements, including bandwidth ex- pansion, capacity needs, budget constraints, and other relevant factors. These requirements are then forwarded to the sub-Agent Upgrade Planner, which generates a step-by-step upgrade plan. Each step invokes specialized sub-Agents to execute specific tasks efficiently. In the upgrade from C-band to C+L-band sys- tem, the Upgrade Planner first determines the necessary devices and performance baselines for each device. For example, the output power of an L-band transponder should be around 0 dBm, while the saturation power of an L-band amplifier must exceed 23 dBm. These baselines are then passed to the Vali- dation Specialist, which selects appropriate devices based on its infrastructure knowledge, containing records of available devices of different types, alongside vendor documentation vali- dated against standards like ITU-T. Within the Validation Specialist, a structured decision- making cycle is followed, consisting of planning, action, and the memory to provide necessary information. Once the required devices are selected, the Performance Optimizer is activated to calculate the optimal configurations for the upgraded L-band transmission link. This sub-Agent also follows a similar cycle, where it breaks down the task into sub-steps and formulates a CoT process to determine the best approach. Different actions are selected based on computational tools from the memory, and results are continuously analyzed for further optimization. Moreover, there is self-iteration of derived strategy from the outputs to the inputs. For example, when the L-band devices are selected, the Performance Optimizer can invoke the three-step QoT optimization algorithm [71] to find optimal configurations for the C- and L-band EDFAs. As the C-band transmission per- formance will also be affected by the upgraded L-band devices and traffic, fast optimization tools are necessary to mitigate tran- sient interference during the upgrade. After determining the optimal configurations, all relevant information is transferred to the Business Manager, which sched- ules an appropriate upgrade time window to minimize network disruptions. Additionally, the Business Manager ensures that critical services maintain high performance and that C-band optical performance remains within acceptable limits. It also identifies new services and existing services that need to be migrated to the L-band. Once these steps are completed, the C+L-band transmission system is successfully upgraded, ensur- ing seamless scalability and uninterrupted service delivery. F. Decommission phase With the emergence of new services, advancements in communi- cation technologies, and shifts in communication capacity distri- bution across different nodes, parts of the transmission system may need to be decommissioned, or specific links with mini- mal services may be removed. Taking link decommissioning as an example, potential decommissioning candidates are first identified during the operational phase based on traffic and ser- vice conditions. Once a decommissioning request is initiated, the upper-level orchestration layer activates the Decommission Agent, which then continuously monitors the relevant traffic and service status within the optical network, as illustrated in Fig. 12. For an identified candidate, the Decommission Agent evaluates the SLA and generates a comprehensive report for the operator. This report assesses the necessity and feasibility of decommis- sioning, considering factors such as the importance of remaining services, operational costs, and potential savings from decom- missioning. Once the report is submitted, the operator makes the final decision on whether to proceed with decommissioning. Once the decision is confirmed, the Decommission Agent forwards the decommissioning request to the Retirement Plan- ner, which then breaks down the process into logical, feasible steps, delegating specialized tasks to sub-Agents for efficient Research Article18 Node1 Node2 Node3 Node4 FreqFreq Reduced traffic Link decommission! Decommission Agent Retirement Planner Device Manager Service Switcher Operator Orders Remove the link! Observation:TrafficbetweenNode 1andNode2continuestodecrease, mostcapacityofthislinkiswasted. Requirements:Decommissioning thislinkandswitchtheremained servicestoanotherroute. Traffic perception In Planning I need to develop a decommissioning plan, should find new route, ... Action Find a route meet spectrum allocation, capacity, x. Out ToolKit •Network redundancy •Topology and RSA •Power and electric KnowledgeLibrary Knowledge Library Planning I need to switch remaining services to a new route, considering SLA... Action Decide switch time, service priorities, and interruption time ToolKit ? •QoTprediction •RSA problem •Service level agreement (SLA) •Network plane •QoTpredicter •Latency computer Taskbreakdown: 1.Generateareportonthefeasibilityof linkdecommissionandevaluatethe impactofdecommissiononredundancy. 2.Developadecommissioningplan, includinghardwareremoval,spectrum releaseandfindserviceswitchroutes. 3.Pushthedecommissioningplanto ServiceSwitchAgentforcoordinatethe switchtimewindows. 4.Performserviceswitchingtoalternative route,includingreroutingconfiguration, andverifypost-switchperformance (QoT,latency). 5.PushtoPhysicalDecommissionAgent andperformphysicaloperations, includingfiberdisconnection,device power-off,andassetrecovery. Memory Query decommission information RAG Call Tools Self-iteration Memory Query decommission information Self-iteration Fig. 12. Schematic of multi-Agent collaboration in the decommission phase of the AONs. The figure depicts how the Decommis- sion Agent monitors traffic and initiates decommissioning workflows when link utilization drops. It highlights the roles of the Retirement Planner, Service Switcher, and Device Manager in evaluating SLA impact, rerouting services, coordinating switching windows, and physically decommissioning network elements, ensuring minimal disruption and efficient resource reclamation. execution. First, the Retirement Planner generates a detailed report assessing alternative routing capacity, SLA compliance, and the impact of decommissioning on network redundancy to ensure that decommissioning does not compromise service quality and that sufficient backup routes exist. It then formu- lates a structured decommissioning plan covering hardware removal/retention, spectrum release, and service rerouting. Fol- lowing a structured cycle, planning, action, and self-iteration, the plan is further broken down into sub-tasks using CoT rea- soning. The Agent identifies suitable alternative service routes using network knowledge and computational tools, ensuring these routes provide adequate capacity, available spectrum slots, and compliance with latency constraints. Once the plan is developed, it is pushed to the Service Switcher for implementation. The Service Switcher coordinates the switching time window to ensure minimal network dis- ruption, reroutes services to alternative paths, and conducts post-switch performance validation, including QoT and latency checks. After successful service switching, the process moves to the Device Manager, which executes the physical decommission- ing operations, including fiber disconnection, device power-off, and asset recovery management, such as optical module removal and inventory registration. After the retirement actions and post- decommissioning validation are completed, the Decommission Agent concludes the active decommissioning process and be- comes inactive until another decommissioning task is initiated. Upon completion of these steps, the link decommissioning pro- cess is finalized, ensuring efficient resource optimization while maintaining network stability. 6. OUTLOOK Despite the promising potential of the multi-Agent technique in AON, there are still challenges that needs to be addressed before the full implementation in practice. A. Hallucination risks Hallucination [72,73] refers to cases where LLMs generate fluent and coherent outputs that are factually incorrect, logically in- consistent, or contextually irrelevant. Hallucinations may arise from insufficient domain knowledge during pre-training, noisy data correlations, or inference-stage factors such as ambiguous prompts and limited context windows [74]. This issue poses a major challenge for the reliable deployment of LLM Agents in optical networks, where high accuracy and faithful consis- tency are essential. In optical networks, hallucinations often manifest in the form of incorrect parameter suggestions, nonex- istent device models, or logically flawed configuration schemes [75]. Such errors are particularly critical in tasks such as QoT estimation, failure localization, and control plane automation, where precision and consistency are paramount. Mitigating hal- lucinations requires domain-aware validation and system-level safeguards rather than relying solely on model improvements [76]. In the proposed framework, generated results are first supervised within the corresponding lifecycle division. The Di- vision Agent evaluates the outputs of its subordinate AI Experts against task objectives, network constraints, and expected qual- ity, and triggers refinement and re-execution when necessary. This local closed loop continues until an acceptable result is obtained or a predefined iteration limit is reached, after which unresolved tasks are escalated to the upper level or human op- erators. For actions that may affect the physical network, the Security Manager provides an additional safety gate by check- ing generated configurations or commands against operational and security constraints. Generated decisions should be verified against network state, topology, and operational policies before execution. In particular, DTON can serve as a validation sand- box to evaluate generated strategies and configurations against Research Article19 physical-layer constraints and real-time network conditions be- fore deployment. High-risk or service-affecting actions can fur- ther require human-in-the-loop confirmation before execution. After deployment, network states and service performance are continuously monitored, and corrective actions or rollback to a previously validated configuration can be initiated if unaccept- able outcomes are detected. Besides, hallucination mitigation should be regarded as a joint responsibility of both LLM Agents and deterministic network infrastructures to ensure trustworthy operation. B. Model selection and deployment In practical deployment, the hierarchical multi-Agent frame- work requires that Agents can be adapted to the complexity, la- tency requirement, data sensitivity, and computational demand of individual tasks. High-level Agents, for example, the Net- work Director, are responsible for global objective interpretation, cross-domain information integration, long-horizon planning, task decomposition, and coordination among multiple Agents. Cloud infrastructure can host large models and shared knowl- edge services for computationally intensive tasks. In contrast, Agents for operation, monitoring, security, and other latency- sensitive tasks can be smaller language models, deployed at the edge or locally at network sites, particularly when rapid responses or local processing of operational data are required. A hierarchical escalation mechanism can also be adopted, where a lightweight local model handles routine requests and invokes a more capable remote model only when the task is ambiguous, complex, or high-risk. Moreover, considering that some tasks re- quire faster, more accurate, and complex calculations, we design and recommend using workflows with tools instead of calling LLM to accelerate task implementation and ensure accuracy. C. Token costs Token length constraints present a fundamental limitation for applying LLMs in optical networks, where decision-making often relies on large volumes of structured and unstructured data. Practical tasks may require the model to simultaneously process multi-span transmission parameters, per-channel config- urations, network topologies, historical monitoring records, and real-time telemetry data, leading to rapidly increasing context size and token consumption as network scale grows. This chal- lenge becomes more severe in full LCM tasks, where decisions frequently depend on information accumulated across multiple stages. Addressing this issue requires efficient context man- agement [77], including hierarchical information abstraction, skill-based function calling, retrieval-based context selection, and memory-augmented architectures. In our proposed multi-Agent framework, this issue can be mitigated through the dedicated Memory Container, which serves as an intermediate layer for context compression and management. By leveraging efficient token compression, struc- tured information encoding, and selective retrieval mechanisms, the Memory Container can distill large-scale network data into compact and task-relevant representations, thereby reducing token consumption while maintaining essential global context. The context requirements are also closely coupled with model size and computational resource allocation. D. Long-horizon memory Long-horizon memory and stateful reasoning remain critical challenges for applying LLMs to optical network LCM, where decisions spans extended time horizons, and depend on evolv- ing network states, historical configurations, and accumulated performance data. However, conventional LLMs operate in a largely stateless manner, relying only on the current context window and lacking persistent awareness of prior interactions or long-term system evolution. This limitation is particularly evident in sequential tasks such as fault diagnosis, dynamic reconfiguration, and upgrade planning, where earlier actions di- rectly influence subsequent decisions. Addressing this challenge requires external memory and state management mechanisms, including structured repositories, memory-augmented architec- tures, and DT-assisted synchronization. In our framework, the Memory Container further acts as a persistent state management module that supports storage, update, and retrieval of network state information across different lifecycle stages. By maintain- ing evolving network states, it enables temporally consistent and context-aware reasoning over long operational horizons. In addition, persistent network knowledge and short-term task contexts can be managed separately so that only the in- formation required for the current reasoning step is provided to the LLM. The context requirements are also closely coupled with model size and computational resource allocation, with more demanding or high-priority tasks receiving greater com- puting resources and lightweight tasks being handled by smaller models or edge resources. Such coordinated management of con- text, model scale, and computing resources can reduce context and computational costs while maintaining the responsiveness and reasoning capability required for optical network lifecycle management. 7. CONCLUSION This paper has systematically envisioned the LLM Agent-driven evolution of optical networks toward AONs. First, the technical foundations of LLM and Agent are illustrated, with particular emphasis on domain adaptation techniques and performance evaluation considerations in optical networking scenarios. From a system-level perspective, this work provided a structured de- composition of the optical network lifecycle into six key phases, and analyzed the associated tasks, data requirements, and op- erational constraints in each stage. Based on these insights, we presented a hierarchical multi-Agent framework that orga- nizes heterogeneous Agents across different functional layers, enabling coordinated perception, reasoning, and action. This framework offers a unified perspective for integrating LLM- driven intelligence into optical network management, bridging the gap between high-level decision-making and low-level oper- ational execution. Beyond architectural design, an important takeaway of this work lies in highlighting the role of LLM Agent as a potential enabler of closed-loop, adaptive, and context-aware control in optical networks. By coupling LLM reasoning capabilities with domain knowledge, real-time data, and external tools, Agent sys- tems can move toward more flexible and scalable management strategies compared to conventional pipeline-based solutions. In evolution of optical networks toward AONs, this work aims to present a structured and forward-looking perspective on leverag- ing LLM Agent for the autonomous LCM. Rather than offering a definitive solution, it seeks to outline a conceptual architecture and provide technical insights for researchers and developers to explore the evolving landscape of AONs. It is expected that continued efforts in model development, system integration, and real-world validation will be necessary to fully realize the Research Article20 potential of AONs. FUNDING National Natural Science Foundation of China (62522104 and U24B20133). REFERENCES 1.Y. Song et al., “Lifecycle management of optical networks with dynamic- updating digital twin: a hybrid data-driven and physics-informed ap- proach,” IEEE J. on Sel. Areas Commun. (2025). 2.M. Lam and J. van der Lande, “Quantifying the benefits of optical network automation,” Tech. rep., Analysys Mason (2024). 3.D. Wang et al., “A review of machine learning-based failure manage- ment in optical networks,” Sci. China Inf. Sci. 65, 211302 (2022). 4. R. Gu et al., “Machine learning for intelligent optical networks: A comprehensive survey,” J. Netw. Comput. Appl. 157, 102576 (2020). 5.F. Musumeci et al., “An overview on application of machine learning techniques in optical networks,” IEEE Commun. Surv. & Tutorials 21, 1383–1408 (2018). 6.J. Lu et al., “Performance comparisons between machine learning and analytical models for quality of transmission estimation in wavelength- division-multiplexed systems,” J. Opt. Commun. Netw. 13, B35–B44 (2021). 7.D. Wang and M. Zhang, “Artificial intelligence in optical communi- cations: from machine learning to deep learning,” Front. Commun. Networks 2, 656786 (2021). 8.X. Sui et al., “A review of optical neural networks,” IEEE Access 8, 70773–70783 (2020). 9.Y. Cao et al., “A comprehensive survey of ai-generated content (aigc): A history of generative ai from gan to chatgpt,” arXiv:230304226 (2023). 10.L. Bariah et al., “Large generative ai models for telecom: The next big thing?” IEEE Commun. Mag. 62, 84–90 (2024). 11. D. Wang et al., “When large language models meet optical networks: paving the way for automation,” Electronics. 13, 2529 (2024). 12.Y. Song et al., “Synergistic interplay of large language model and digital twin for autonomous optical networks: Field demonstrations,” IEEE Commun. Mag. (2025). 13. C. Sun et al., “Experimental demonstration of local ai-agents for lifecy- cle management and control automation of optical networks,” J. Opt. Commun. Netw. 17, C82–C92 (2025). 14.X. Liu et al., “First field trial of llm-powered ai agent for lifecycle man- agement of autonomous driving optical networks,” in OFC, (2025), p. Th1A–2. 15. D. Wang et al., “Large language model for optical network automation: Prospects and challenges,” in OFC, (2025), p. Th1A–4. 16.Y. Zhang et al., “Ai agent for autonomous optical networks: architec- tures, technologies, and prospects [invited tutorial],” J. Opt. Commun. Netw. 18, A159–A178 (2026). 17.S. Cruzes, “Revolutionizing optical networks: The integration and im- pact of large language models,” Authorea Prepr. (2024). 18.J. Wang, “Generative ai for network operations,” in OFC, (2025), p. Workshop. 19. Y. Wang et al., “Alarmgpt: an intelligent alarm analyzer for optical networks using a generative pre-trained transformer,” J. Opt. Commun. Netw. 16, 681–694 (2024). 20.Y. Pang et al., “Large language model-based optical network log anal- ysis using llama2 with instruction tuning,” J. Opt. Commun. Netw. 16, 1116–1132 (2024). 21.Y. Zhang et al., “Gpt-enabled digital twin assistant for multi-task coop- erative management in autonomous optical network,” in OFC, (Optica Publishing Group, 2024), p. Th1G–4. 22. Y. Weijie et al., “Spatio-temporal knowledge graph with large language model for comprehensive fault management in optical networks,” in ECOC, (2024), p. W2A–102. 23. N. D. Cicco et al., “Open implementation of a large language model pipeline for automated configuration of software-defined optical net- works,” in ECOC, (2024), p. W3E–1. 24. A. Zhou et al., “Large language model-driven ai agent in sdn con- troller towards intent-based management of optical networks,” in ECOC, (2024), p. W3E–2. 25.C. Wang et al., “Llm-centric transport network configuration manage- ment framework and demonstration,” in OFC, (2025), p. W3E–4. 26.X. Jiang et al., “Opticomm-gpt: a gpt-based versatile research assistant for optical fiber communication systems,” Opt. Express 32, 20776– 20796 (2024). 27.C. Sun et al., “First experimental demonstration of full lifecycle automa- tion of optical network through fine-tuned llm and digital twin,” in ECOC, (2024), p. Th3B–6. 28.A. Abishek et al., “End-to-end transport network digital twins with cloud- native SDN controllers and generative AI,” J. Opt. Commun. Netw. 17, C70–C81 (2025). 29. Y. Zhang et al., “First field-trial demonstration of l4 autonomous optical network for distributed ai training communication: An llm-powered multi-ai-agent solution,” arXiv:250401234 (2025). 30.H. Huang et al., “Field trial of llm-based autonomous network manage- ment with ai-agent in real-time 400g/800g elastic optical network,” in 2025 ECOC, (IEEE, 2025), p. 1–4. 31.Q. Qiu et al., “Expertise-guided llm agent realizing autonomous optical power optimization in field-deployed networks,” in 2025 ECOC, (IEEE, 2025), p. 1–4. 32. Y. Zhang et al., “Design and evaluation of an llm-based agent for qot estimation and performance optimization in optical networks,” IEEE Open J. Commun. Soc. (2025). 33.Y. Hao et al., “Multi-agent llm-powered ai for autonomous optical power commissioning of oms links,” in 2025 ECOC, (IEEE, 2025), p. 1–4. 34.Y. Zhang et al., “Generative ai-driven hierarchical multi-agent frame- work for zero-touch optical networks,” IEEE Commun. Mag. (2025). 35. S. Xiang et al., “Optima: Collaborative multi-agent framework for mod- elling and controlling raman amplifier in intelligent optical networks,” in 2025 ECOC, (IEEE, 2025), p. 1–4. 36.V. Ricard et al., “Applying digital twins to optical networks with cloud- native sdn controllers and generative ai,” in ECOC, (2024), p. M2E–4. 37.H. Arunachalam et al., “Generative ai for optical networking: From design automation to self-operating networks,” in 2026 OFC, (Optica Publishing Group, 2026), p. 1–3. 38.E. Ayush Maheshwari, “Autonomous networks and agentic ai – shaping the future of connectivity,” in 2026 OFC, (Optica Publishing Group, 2026), p. 1–3. 39. A. Vaswani et al., “Attention is all you need,” Adv. neural information processing systems 30 (2017). 40. D. Bahdanau et al., “Neural machine translation by jointly learning to align and translate,” arXiv:14090473 (2014). 41.A. Dosovitskiy et al., “An image is worth 16x16 words: Transformers for image recognition at scale,” arXiv:201011929 (2020). 42. G. Dong et al., “Baichuanseed: Sharing the potential of extensive data collection and deduplication by introducing a competitive large language model baseline,” arXiv:240815079 (2024). 43.W. X. Zhao et al., “A survey of large language models,” arXiv:230318223 1 (2023). 44.G. I. Meadows et al., “Localvaluebench: A collaboratively built and extensible benchmark for evaluating localized value alignment and ethical safety in large language models,” arXiv:240801460 (2024). 45. G. Penedo et al., “The refinedweb dataset for falcon llm: outperforming curated corpora with web data, and web data only,” arXiv:230601116 (2023). 46.A. Radford et al., “Improving language understanding by generative pre-training,” OpenAI Blog (2018). 47.H. Touvron et al., “Llama: Open and efficient foundation language models,” arXiv:230213971 (2023). 48.J. Devlin et al., “Bert: Bidirectional encoder representations from trans- formers,” arXiv:181004805 p. 15 (2018). 49.A. Radford et al., “Language models are unsupervised multitask learn- ers,” OpenAI blog 1, 9 (2019). 50.Z. Han et al., “Parameter-efficient fine-tuning for large models: A comprehensive survey,” arXiv:240314608 (2024). Research Article21 51.L. Wang et al., “Parameter-efficient fine-tuning in large models: A survey of methodologies,” arXiv:241019878 (2024). 52. X. Wang et al., “Lora ensembles for large language model fine-tuning,” arXiv:231000035 (2023). 53.T. Dettmers et al., “Qlora: Efficient finetuning of quantized llms,” Adv. neural information processing systems 36, 10088–10115 (2023). 54. L. Ouyang et al., “Training language models to follow instructions with human feedback,” Adv. neural information processing systems 35, 27730–27744 (2022). 55. J. Achiam et al., “Gpt-4 technical report,” arXiv:230308774 (2023). 56. Y. Liu et al., “Developing a domain-specific llm for optical networks: A reinforcement learning-based fine-tuning framework,” IEEE Transac- tions on Netw. Serv. Manag. 23, 3655–3678 (2026). 57.S. Zhao et al., “Retrieval augmented generation (rag) and beyond: A comprehensive survey on how to make your llms use external data more wisely,” arXiv:240914924 (2024). 58.C. Jeong, “A study on the implementation method of an agent-based advanced rag system using graph,” arXiv:240719994 (2024). 59.A. N. T. Dieu et al., “The enhanced context for ai-generated learning advisors with advanced rag,” in 2024 18th International Conference on Advanced Computing and Analytics (ACOMPA), (2024), p. 94–101. 60.P. Liu et al., “Pre-train, prompt, and predict: A systematic survey of prompting methods in natural language processing,” ACM computing surveys 55, 1–35 (2023). 61.L. Giray, “Prompt engineering with chatgpt: a guide for academic writers,” Annals biomedical engineering 51, 2629–2633 (2023). 62.J. Wei et al., “Chain-of-thought prompting elicits reasoning in large language models,” Adv. neural information processing systems 35, 24824–24837 (2022). 63.F. Amigoni et al., “Anthropic agency: a multiagent system for physiolog- ical processes,” Artif. Intell. Medicine 27, 305–334 (2003). 64. S. Hong et al., “Metagpt: Meta programming for multi-agent collabora- tive framework,” arXiv:230800352 3, 6 (2023). 65.Q. Wu et al., “Autogen: Enabling next-gen llm applications via multi- agent conversations,” in First conference on language modeling, (2024). 66. R. Ramaswami and K. Sivarajan, Optical networks: a practical per- spective (Elsevier, 2001). 67.Q. Zhuge et al., “Building a digital twin for intelligent optical networks [invited tutorial],” J. Opt. Commun. Netw. 15, C242–C262 (2023). 68.Y. Pointurier, “Design of low-margin optical networks,” J. Opt. Commun. Netw. 9, A9–A17 (2016). 69. Y. Takita et al., “Towards seamless service migration in network re- optimization for optically interconnected datacenters,” Opt. Switch. Netw. 23, 241–249 (2017). 70.Google, “Agent2agent (a2a) protocol,” https://github.com/google/A2A (2025). 71. Y. Song et al., “Efficient three-step amplifier configuration algorithm for dynamic c+ l-band links in presence of stimulated raman scattering,” J. Light. Technol. 41, 1445–1453 (2022). 72.H. Ye et al., “Cognitive mirage: A review of hallucinations in large language models,” arXiv:230906794 (2023). 73.L. Huang et al., “A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions,” ACM Transac- tions on Inf. Syst. 43, 1–55 (2025). 74. V. Adlakha et al., “Evaluating correctness and faithfulness of instruction- following models for question answering,” Transactions Assoc. for Com- put. Linguist. 12, 681–699 (2024). 75.X. Wang et al., “Wireless hallucination in generative ai-enabled commu- nications: Concepts, issues, and solutions,” arXiv:250306149 (2025). 76.S. Tonmoy et al., “A comprehensive survey of hallucination mitigation techniques in large language models,” arXiv:240101313 6 (2024). 77.Z. Zhang et al., “A survey on the memory mechanism of large language model-based agents,” ACM Transactions on Inf. Syst. 43, 1–47 (2025).

Instant research discovery