1 Introduction↩︎

The next generation of 6G promises to be AI-native, embedding machine learning (ML) across every layer, function, and interface [1]. While this vision offers unprecedented capabilities, from semantic communications to intent-driven operations, it also introduces operational complexity that exceeds current network management approaches. As ML software proliferates throughout network functions (NFs), maintaining performance at scale while managing interdependencies becomes a critical challenge.

This paper argues that achieving autonomous AI-native operations at scale requires autonomous network management where the management plane can generate new automation software, validate its correctness, and modify its own operational structure during runtime. We term this form of autonomy “autogenic" and present autogenic network management as an architectural approach for realizing Agentic AI in 6G networks, where LAM-based agents autonomously make decisions, generate solutions, and evolve system behavior in response to operational requirements.

In this article, we present the architectural foundations, design principles, and a research roadmap for autogenic network management systems. Our work directly addresses the architectural challenges identified by standards bodies for agent-based network management, providing a reference architecture compatible with TM Forum’s autonomous network framework and ETSI’s experiential networked intelligence vision.

1.1 How Do AI-Native Networks “Think”?↩︎

In a future 6G system, artificial intelligence is expected to be pervasive. ML models, adaptive controllers, and data-driven optimization routines will operate across all layers and interfaces. The air interface will incorporate AI-native mechanisms for detection, scheduling, and other core Radio Access Network (RAN) operations. LAMs will coordinate functions across the network [1], [2].

This level of AI integration introduces a new class of operational challenges. For example, electricity over-consumption in the network can impact sustainability targets and increase operational expenditure. Addressing such conditions through manual diagnostics becomes impractical at scale. Instead, operators will require management systems that accept high-level intents, such as sustainability objectives, and translate them into appropriate corrective strategies without explicit procedural instructions.

In the electricity over-consumption scenario, the management system responds to increased electricity use by formulating an investigation objective and analyzing electricity consumption trends across the RAN. Correlation with key performance indicators reveals that the ML model used for Medium Access Control (MAC) scheduling has experienced drift. As a result, the scheduler selects suboptimal transmission decisions that increase retransmissions and keep radios active for longer intervals. This condition was not captured during design or initial validation; the network identifies the underlying cause through its own runtime analysis.

Having identified model drift as the cause, the network must address it. Retraining the MAC scheduler is dynamic and may require the system to self-architect its training pipeline, adopt new data sources, or design novel feature-extraction routines. It must self-program data collection, federate across domains, and self-program the training procedure by orchestrating resources and tuning algorithms. After training a new model, the network must self-reflect by validating the model, running safety checks, and monitoring for unintended consequences.

In AI-native 6G networks, this detect \(\rightarrow\) diagnose \(\rightarrow\) retrain \(\rightarrow\) validate \(\rightarrow\) deploy \(\rightarrow\) monitor cycle should continuously repeat across many network, operational, and service domains [3]. Manual intervention and human oversight do not scale, as the complexity and pace of change exceed human operational capacity. A trusted autonomous management system must manage this lifecycle at scale and will be essential for 6G success.

1.2 Strategic Business Drivers↩︎

6G enables revenue streams that are not feasible today. For example, immersive extended reality requires ultra-low latency and high reliability, while industrial automation requires precise timing and deterministic communications for safety-sensitive operations. These applications create new market segments and premium service tiers. At the same time, AI-native networks should lower infrastructure costs because data-driven ML software runs on commodity hardware. Additional savings in software infrastructure come from automated generation of data-driven ML-based algorithms during network operations, eliminating the cost of manual algorithm design.

In AI-native networks, data-driven automation must be created within the network itself, as that is where the operational data resides. As networks continue to scale and diversify, the cost of human oversight, troubleshooting, and configuration becomes unsustainable, making autonomous operation essential for managing operational expenses. Network management standards reflect these business drivers. Standards bodies are now considering automation architectures in which LAM-driven automation underpins next-generation network management [2] with a shared architectural language and LAM-based agents as its foundational components[3]–[5].

1.3 The Hidden Challenges↩︎

The AI-native network vision promises networks that are more efficient, responsive, and capable of supporting new services. As the industry moves from theory to deployment, practical challenges emerge. The complexity and scale of 6G requirements reveal limitations that are both technical and systemic.

Hidden problems stem from the proliferation of ML software. Unlike traditional software, ML software erodes modular boundaries and creates entangled dependencies through data, features, and feedback loops. Risks such as the Changing Anything Changes Everything (CACE) principle, where seemingly minor changes to one ML model can unexpectedly degrade performance across the entire system due to hidden interdependencies, accumulate quietly and often surface only after deployment and at scale [6].

As more of the responsibility for maintaining the performance of ML models moves into network operations, the Mobile Network Operators (MNOs) must change their operational practices to include more in-network software creation, validation, and testing. This is where the need for a new type of management plane becomes apparent, prompting us to propose the Autogenic network management system.

1.4 Key Concepts↩︎

The key to scalable AI-native autonomous networks lies in the capability emerging from LAM research. We define the architectural concepts here and explain how they build upon each other.

• Autonomous networks are networks that can perceive their environment, make decisions, and take actions to achieve predefined operational goals with minimal human intervention. They operate recursively through many autonomous systems spanning network, operational, and service domains, individually progressing through maturity levels (L0-L5) based on their degree of independence from human oversight [3].

• Agents are software entities that act autonomously or semi-autonomously to perform tasks, make decisions, and interact with other agents or systems [2]. In network management, LAM-based agents can interpret intent, generate procedural knowledge at runtime, and coordinate resources to drive autonomous adaptation [5]. The guided and recursive components introduced in this paper represent two implementation approaches to Agentic AI, differing in their degree of autonomous decision-making and validation.

• Autogenic systems represent a novel architectural pattern. These systems can generate their own goals, executable behaviors, and structural control logic through four capabilities: self-orienting (generating new objectives), self-programming (synthesizing new behaviors), self-reflection (evaluating reasoning processes), and self-architecting (transforming system structure). We introduce autogenic systems as a general concept applicable to any software-centric domain but demonstrate their specific application to network management.

• LAM-enabled Self-evolving networks apply the autogenic systems pattern to network management. They are networks whose management plane implements autogenic capabilities through LAMs, enabling software components and behaviors to evolve during runtime in response to changing requirements, traffic patterns, and environmental conditions. This differs from the pre-LAM self-evolving network concept [7], which focused on ML-driven network optimization and resource management without the capability to generate new goals or modify the system architecture during runtime.

2 AI Component Spectrum and LAM-Enabled Autonomy↩︎

To realize the full benefits of automation, networks must operate at L3+ autonomy levels [3] (Fig. 1), where network management handles most operational situations. Achieving this through manually developed, design-time software is costly and difficult to scale.

Although AI-native networks improve resource optimization and event prediction, ML components alone do not create, maintain, or evolve the management software required for network operation. However, managing model lifecycles, performance drift, and cross-domain dependencies demands continuous software evolution. Autogenic network management addresses this challenge by shifting software creation into network operations, enabling the management plane to generate and evolve automation at runtime (Fig. 2).

LAMs enable this approach through self-programming, generating procedural logic and predicting its execution [8]. While LAMs are partial autogenic systems, an autogenic architecture provides the autonomy required to scale management of AI-native networks. We therefore advocate integrating LAMs within an architecture that makes the overall system autogenic. Combining LAMs with autogenic capabilities yields LAM-enabled self-evolving networks, in which management-plane software components and behaviors evolve at runtime.

This view of the management plane is reflected in recent standards efforts [1]–[5], which recognize both the strengths of ML for domain-specific optimization and the challenges of increasing system complexity. 3GPP defines AI-native 6G requirements [1], ETSI investigates AI agents for next-generation network slicing [2], and TM Forum advances agent-based architectures for L4+ autonomous networks [3]–[5]. Collectively, these efforts point toward LAM-enabled network management that extends beyond predefined optimization to runtime self-evolution.

2.1 The Spectrum of AI Components in AI-Native Networks↩︎

AI-native networks will be built with a spectrum of component types, each with different capabilities for processing, adaptation, and evolution, as illustrated in Fig. 1. The figure shows how AI component types relate to management-plane autonomy and data-plane AI-nativeness.

Programmed, learning, guided, and recursive components align with autonomy levels L0-L5 in the management plane. They also correspond to increasing degrees of self-evolving capabilities: hard-coded → AI-assisted → agentic → autogenic. At the same time, the data plane evolves from non-AI to AI-native behavior across network generations (1G–6G and beyond). The figure highlights that autonomy growth in the management plane and AI-nativeness growth in the data plane progress together, with guided and recursive components enabling agentic and autogenic behavior, respectively. The AI component types are detailed below.

Programmed components are the primary means by which networks are built today. They are designed, implemented, and deployed entirely by humans, who define all operational logic in advance. They execute procedural logic specified at design time, providing deterministic but non-adaptive behavior. These components enable the most basic, i.e., L0-L1 network autonomy.

Learning components implement ML-based predictions. Humans train and validate the models, while the models execute autonomously within their trained tasks, such as traffic prediction, anomaly detection, or resource optimization. In AI-native 6G networks, these components enable L2–L3 autonomy through automated pattern detection for specific ML tasks [3]. However, they cannot interpret intent or generate new behaviors, which are required for L4 autonomy.

Based on recent advances in LAMs, we also recognize two emerging types of components. Unlike programmed or learning components, which have fixed logic or adapt within predefined ML tasks, these components have strong self-programming capabilities.

Guided components are LAM-based semi-autonomous agents with self-programming capabilities. They require human-in-the-loop oversight where operators supervise workflows, validate generated code, and intervene in exceptions. Guided components interpret intent and generate new code, enabling operators to create programmed components during network operations. However, humans remain part of the automation creation process, reviewing and approving generated components. The runtime code generation capability provided by guided components is key to enabling the TM Forum L4 autonomy vision at scale [3].

Recursive components are advanced LAM-based agents with self-programming and self-reflection capabilities. Self-reflection enables them to evaluate their own outputs, detect errors, and improve their code autonomously. Unlike guided components, recursive components can create new components and validate them without human approval. This eliminates the human bottleneck in scaling network management automation.

Autogenic architectures use recursive components to enable self-orienting and self-architecting capabilities, extending autonomy beyond L4 (Section 3). Only guided and recursive components qualify as agents because self-programming allows them to interpret intent and generate behaviors at runtime. Current systems primarily rely on guided components with human oversight, but are expected to evolve toward recursive components capable of autonomously creating and validating automation with minimal supervision.

2.2 Evolution Between Levels of Network Automation↩︎

Fig. 2 contrasts pervasive AI deployment at L2–L3 with networks of AI agents at L4–L5+. The key architectural shift is from orchestrating fixed components to generating new components at runtime. LAM-enabled self-evolving networks extend automation by enabling software agents to adapt, generate, and evolve management components with minimal human intervention. In the medium term, operators will rely on guided components to reach L4 autonomy, while in the longer term, recursive components will enable L5 and L5+ autonomy.

The LAM-enabled self-evolving networks perspective highlights a shift in standardization from defining functionality to enabling evolution. Instead of specifying fixed behaviors, standards would define how agents, both guided and recursive, generate and validate new behaviors during operation. Progressing toward L5 and beyond requires standardized autogenic architectures in which recursive components can formulate goals, synthesize implementations, and self-validate with reduced human supervision.

3 Autogenic Network Management↩︎

As 6G networks progress toward a higher level of autonomy, the ability to adapt, learn, and improve during operation becomes necessary. This section outlines the architectural shift to autogenic network management, required for networks to operate intelligently and to evolve over time. Autogenic network management leverages guided and recursive components (as discussed in Section 2.1) to achieve self-orienting and self-architecting capabilities. The reference architecture of the proposed autogenic network management system, as shown in Fig. 3, illustrates how organizing recursive components within specific subsystems creates these system-level capabilities.

3.1 Why “Autogenic”?↩︎

We use the term “autogenic” to emphasize the generative capability that distinguishes autogenic network management from the current view of autonomous networks. The term refers to systems that can generate their own actions, introduce adaptations, and evolve.

3.2 Autogenic Capabilities↩︎

Autogenic systems comprise four core capabilities that enable self-evolution, as follows.

1. Self-programming: The system synthesizes new behaviors autonomously. Rather than only tuning parameters or reconfiguring programmed and learning components, self-programming allows the system to generate procedural logic and realize novel objectives or redefine objectives in response to unexpected conditions.

2. Self-reflection: The system evaluates its own reasoning processes and decision frameworks. Beyond measuring performance against fixed criteria, self-reflection also examines and adapts the criteria, enabling more robust adaptation.

3. Self-orienting: The system generates new objectives rather than only selecting from predefined goals. Where conventional systems optimize and adapt within fixed objectives and constraints, self-orienting systems redefine objectives and create new objectives when required.

4. Self-architecting: The system modifies its core architecture and integrates new functionality at runtime. This includes synthesizing interface adaptors, modifying protocols, and restructuring internal components to meet novel requirements.

3.3 Reference Architecture of the Autogenic System↩︎

In Section 2.1, we have introduced four component types in AI-native networks. In this section, we establish different subsystems within autogenic system and show how they interact.

The architecture exposes a dual scope of operation: external and internal. The external scope of operations is handled by a managed system, while the internal scope of operations is handled by the managing system. The managed system is the Execution subsystem, which delivers services to external users. The other six subsystems comprise the managing system: Monitoring collects telemetry, Analysis detects patterns and anomalies, Planning generates adaptation strategies and synthesizes new behaviors, Control enforces decisions and applies changes. The Peering subsystem enables federated autonomy through coordination with external systems, while the Management subsystem governs system evolution, setting long-term goals and validating structural and behavioral changes.

The Planning and Control subsystems extend traditional management beyond AADE (Awareness, Analysis, Decision-making, Execution) loops [3] by governing the managing system itself. They generate, evolve, and retire components while maintaining structural cohesion. The Supporting platform represents the hardware and software on which the AI-native network and its management run.

Having a reference architecture provides several benefits. First, it shows how component-level capabilities (self-programming, self-reflection) can compose into system-level capabilities (self-orienting, self-architecting). Second, functional separation enables reasoning about safety, security, trust, and verification within specific subsystems rather than across the entire system. Third, the architecture groups components by their time scales, allowing subsystems to operate independently and synchronize through well-defined coordination mechanisms.

The Execution subsystem operates at service delivery speeds, requiring deterministic behavior from programmed and learning components. The Monitoring, Analysis, Planning, and Control subsystems operate at adaptation time scales, implementing AADE loops that reason about system state. The Management subsystem operates at evolution time scales, where new components are generated to change the system.

This organization maps AI capabilities to architectural responsibilities. Self-programming is realized in Planning and Management through the synthesis of adaptation strategies, behaviors, and components. Self-reflection is supported by Analysis and Control through state evaluation, action validation, and outcome monitoring. Self-orienting and self-architecting are primarily governed by Management, which oversees objectives, component relationships, and structural evolution.

3.4 Enabling Self-Orienting and Self-Architecting Capabilities↩︎

The reference architecture enables self-orienting and self-architecting by deploying recursive components within the managing system.

Self-orienting emerges when recursive components in Planning and Management subsystems use self-programming to synthesize new objective functions based on observed network behavior. Rather than selecting from predefined goals, these components generate novel operational objectives when environmental conditions or requirements change.

Self-architecting occurs through the Management subsystem, where recursive components modify the system’s structural organization. Using self-programming, these components can synthesize interface adaptors, restructure component relationships, and integrate new functionality at runtime. The dual-scope principle is critical here: the Management subsystem applies these capabilities not only to the managed system (the AI-native network) but also to the managing systems themselves, enabling open-ended architectural evolution.

These capabilities represent an active research frontier. While today’s prototypes demonstrate goal generation and structural modification in constrained domains, achieving reliable self-orienting and self-architecting in production networks requires advances in all four autogenic capabilities and safety frameworks (as discussed in Section 5).

Current LAMs approximate recursive behavior through iterative code generation and testing [8], but lack formal correctness guarantees. Guided components address this limitation through human-in-the-loop validation, providing safety while retaining self-programming capabilities. The proposed architecture supports a gradual transition from guided to recursive components as verification frameworks mature.

7pt

3.5 Design Principles↩︎

Six principles guide autogenic system design:

1. Minimal Viable Complexity: Use the simplest component type needed for each subsystem.

2. Dual-Scope Management: Separate service delivery from adaptation and evolution.

3. Reuse Over Reinvention: Build on proven operational components.

4. Self-Contained Resilience: Implement appropriate resilience mechanisms for each complexity level.

5. Fallback Readiness: Enable safe degradation when recursive components are unavailable.

6. Component-Only Construction: Build all subsystems from modular components.

3.6 Autogenic Management of 6G AI-Native Networks↩︎

In 6G networks, the RAN and Core Network (CN) are the managed systems. The subsystems drive adaptation, optimization, and resilience across RAN and CN components. The management system implements AADE loops for the Execution subsystem, improving network efficiency and reducing infrastructure costs through continuous optimization. The Management system applies autogenic capabilities to itself, improving automation software creation and reducing operational costs by minimizing human intervention.

4 Network Operator Perspective↩︎

This section demonstrates autogenic network management through operational scenarios that 6G networks must support. We examine one of these scenarios- fault management, in detail, to show how agents coordinate to resolve network issues autonomously.

4.1 Operational Scenarios↩︎

Table 1 lists 11 high-value scenarios identified by TM Forum that define the operational scope of autonomous networks [4]. Fig. [figures:high-value-scenarios-usecase-diagram] shows the relationships between the scenarios. While the scenarios were defined in the context of L4 autonomy with guided components, they still remain valid for higher levels of autonomy envisioned in this paper.

True autonomy means that each scenario depends on agents that interpret intent, coordinate resources, and adapt to changing conditions. Today, these agents are guided components with human-in-the-loop oversight. Future deployments could use recursive components for greater autonomy.

4.2 Use Case: Fault Management↩︎

Returning to the electricity over-consumption example (Section 1.1), we examine how autogenic network management uses agents to handle MAC scheduler drift, which is causing the excessive energy use (Fig. 5). The operator observes elevated electricity usage and expresses this concern through an intent such as “Reduce excessive RAN energy consumption while preserving service quality", specifying the desired outcome without prescribing how to achieve it.

The fault management workflow begins when the Intent Handler, which is also the Planning agent, receives this intent, translates the high-level sustainability concern into a specific operational objective (self-orients), and plans what to do. In response, the Management system dynamically creates specialized agents (self-architects) and synthesizes the agent structure required for this fault scenario (self-programs).

Fig. 5 shows the ordered workflow of agent actions and their interactions:

• The Planner (Intent Handler) interprets fault intents and initiates the remediation workflow.

• The Analyst diagnoses service degradation through anomaly detection, root-cause analysis, and error identification.

• The Executor applies remediation actions, manages configuration changes, and monitors recovery progress.

• The Coordinator synchronizes change management and feedback activities across agents and network domains.

• The Critic validates remediation outcomes, confirms service restoration, and generates feedback for continuous improvement.

The workflow unfolds in phases. During intent interpretation and telemetry collection, the Planner agent initiates continuous monitoring of network health. The Analyst agent then performs root cause analysis and error detection to identify the fault. For change management and remediation, the Executor and Coordinator agents collaborate to implement tailored remediation actions. The Executor agent tracks repairs in real time to confirm services meet baseline requirements. Finally, the Critic and Coordinator agents evaluate outcomes and generate feedback that informs future fault management strategies (self-reflects), enabling the system to learn and adapt over time.

As this use case is only one of 11 high-value scenarios (as described in Table 1 and Fig. [figures:high-value-scenarios-usecase-diagram]) and represents an idealized resolution, the range of agents implies that network management must support a diverse set of agents, each with specialized roles and responsibilities. It is unrealistic to expect a single vendor to supply all software for agents to carry out complex tasks and collaborate. Interoperability between vendors to enable autogenic capabilities will require standards to define common interfaces or other operational principles between agents and their environment.

4.3 Transitioning from Guided to Recursive Components↩︎

The fault management scenario (Fig. 5) demonstrates how guided components operate today. The Planner interprets intent and generates remediation plans using self-programming capabilities. However, humans remain in the loop. Operators validate the generated procedural logic before deployment, review configuration changes, and approve the remediation strategy. This human oversight provides safety boundaries but creates a bottleneck when handling multiple simultaneous faults across network domains.

The transition to recursive components can be achieved through solution banking. Validated solutions generated by guided components are stored in a trusted repository, allowing recurring fault scenarios to be handled autonomously based on proven solution patterns. Novel faults still require human oversight, but as the repository grows and validation mechanisms mature, the system accumulates reliable recovery strategies and progressively shifts from guided to recursive operation.

5 Challenges and Research Roadmap↩︎

Recursive components are an active research frontier. The transition from guided to recursive components requires advances in the four autogenic capabilities.

5.1 Architectural Challenges and Research Directions↩︎

Realizing autogenic network management requires fundamental changes to network software architecture and advances in AI capabilities. At the architectural level, the primary challenge is redesigning network software to support agent-based operation, where autonomous components reason about system state, generate actions, and validate their outcomes at runtime.

A key architectural enabler is the use of digital twins as safe environments for evaluating autonomously generated control strategies. While digital twins reduce operational risk, their cost motivates the concept of a digital twin factory. This is a special type of agent within the management subsystem (Fig. 3) that uses LAMs to interpret semantic models and automatically synthesize models and middleware required to acquire network data. The digital twin factory enables a flexible approach to define models of network resources and services, which can lead to search strategies to find high-fidelity digital twins for production networks even as configurations, workloads, and control logic evolve.

A second architectural and security challenge lies in interface design. Autogenic management requires interfaces through which agents interact with network functions, yet poorly designed interfaces can amplify the risk of unsafe or unintended behavior. The research direction here is to define interfaces that are intentionally simple and constrained, making them difficult to misuse. Such interfaces rely on formal specifications that bound permissible operations, regulate resource access, and restrict valid state transitions. By enforcing these constraints, the verification burden shifts from analyzing arbitrary agent-generated logic to checking compliance with well-defined protocol specifications. From a security perspective, these constraints reduce the potential impact of erroneous agent-generated actions by requiring authorization, validation, and rollback mechanisms before changes affect production network functions. This is particularly important for recursive components, which may generate or modify operational logic with reduced human supervision.

These architectural considerations raise a key standardization challenge: defining interface abstractions that are expressive enough to support autonomous management while remaining sufficiently constrained to preserve safety and operational correctness. However, architecture alone is insufficient. Progress also depends on advances in AI capabilities, many of which are already being explored in adjacent research domains but not yet integrated into network management. The following subsection reviews state-of-the-art AI techniques that exhibit these autogenic capabilities, highlighting both their promise and limitations for supporting autogenic network management.

5.2 State of the Art in AI Capabilities for Autogenic Systems↩︎

Recent advances in AI research demonstrate partial realizations of the capabilities required for autogenic network management. We organize the state of the art around four core autogenic functions: self-programming, self-reflection, self-architecting, and self-orienting.

Self-programming has advanced through generative AI, particularly Large Language Models (LLMs) such as Claude [8], which can synthesize code from natural-language intent to automate tasks with limited human input. FunSearch [9] further combines LLMs with evolutionary algorithms to discover novel solutions, moving toward open-ended creation. However, reliability and domain adaptation remain open challenges.

Self-reflection supports safer autonomy by letting systems evaluate and improve their outputs. As an example, the CRITIC framework [10] combines LLMs with external verification tools to enhance reasoning and reduce errors. Reflexion [11] shows agents using episodic memory and self-generated critiques to improve decision-making without retraining. Despite these advances, LLMs alone do not provide sufficient self-reflection; external feedback and robust evaluation still remain essential.

Self-architecting enables systems to modify internal structure and logic. Neural Architecture Search (NAS) [12] enabled automated model design, while EvoMAC [13] extends architectural evolution to multi-agent systems through dynamic reorganization. Although these approaches support runtime adaptation, architectural changes can disrupt functionality and therefore require rigorous safety frameworks.

Self-orienting shifts systems from executing predefined goals to generating objectives. The Darwin Gödel Machine [14] demonstrates open-ended evolution through emergent goal generation, while the Self-Taught Optimizer (STOP) [15] uses language models as meta-optimizers to discover improvement strategies. However, autonomous goal-setting raises alignment, stability, and safety concerns, requiring mechanisms that keep objectives consistent with human values.

6 Conclusions and Future Work↩︎

AI-native 6G networks require management systems capable of generating and evolving automation at runtime. We presented autogenic network management as the foundation for LAM-enabled self-evolving networks. Our proposed seven-subsystem architecture shows how programmed, learning, guided, and recursive components can be organized to realize system-level capabilities: self-orienting, self-programming, self-reflection, and self-architecting.

The architecture shows a realistic, standards-compatible deployment path. Operators can begin with guided components that use human-in-the-loop validation to create automation software safely. Solution banking enables a gradual transition toward recursive components as validated solutions accumulate and confidence in specific patterns grows. This staged approach manages risk while delivering the self-programming benefits needed for L4 autonomy.

Realizing autogenic systems requires progress on multiple fronts. Future work should strengthen the role of digital twins as safe testing environments where autonomously generated actions can be evaluated before deployment in production networks. Building on this, digital twin factories should be explored as management-plane agents that synthesize, update, and select appropriate twins for evolving network conditions. A second direction is the design of constrained, standards-compatible agent interfaces that define permissible operations, resource-access boundaries, valid state transitions, and rollback mechanisms. Finally, recursive components require stronger self-reflection and self-architecting capabilities, supported by external validators, trusted solution repositories, and large-scale validation across RAN, Core Network, and cross-domain service scenarios. These challenges represent active research areas where progress is visible, but significant work remains.

Biographies↩︎

References↩︎