Application to Telco AN Part 3 — Self-healing, Self-optimization, and the Learning Loop
Telco × Agentic AI / Part 11
June 2026 / Author: Hiroyuki Hikino
🎧 Click here to listen to the audio version
If you would like to grasp the overall picture through audio before reading the main text, please click here.
You can listen simply by pressing the play button.
This article represents my personal views and does not represent my affiliated organization.
Introduction: The "Final Mountain" to Realizing L4
In Parts 9 and 10, I demonstrated that closed-loop design can be applied to the two tasks of incident response and service deployment.
What is the final condition for Autonomous Networks (AN) L4 that remains at this point?
It is Self-healing and Self-optimization.
This is the long-held ambition of the industry, repeatedly raised by 3GPP, TM Forum, and ETSI in discussions on L4/L5.
Detecting signs of failure before humans notice and changing configurations
Autonomously optimizing parameters in response to KPI degradation
Accumulating successful responses as organizational knowledge and applying them to future events
In this installment, I will argue that these cannot be achieved with the tools introduced up to Part 8 alone, and that the Learning Loop, which I only mentioned by name in Part 6, plays a decisive role here.
With this, the three application scenarios of Act 1 will be complete.
Self-healing is not "Rapid Incident Response"
First, I want to correctly extract the concept of self-healing from industry terminology.
Self-healing is often confused with "speeding up incident response."
However, the two are qualitatively different.
| Item | Incident Response (Part 9) | Self-healing |
|---|---|---|
| Trigger | Manifested alert | Signs/Subtle deviations |
| Main Task | Recovery | Proactive changes to configuration, capacity, or routing |
| Definition of Success | Restoring service | Failure does not manifest |
| Required Capability | Observation + Judgment + Execution | Observation + Learning + Judgment + Execution |
For self-healing to be established, accumulating experience from past events is essential.
Unless knowledge such as "In the past, when there were similar signs, we responded this way and the result was that" is extracted from outside the organization (individual minds or siloed Excel files) and brought inside the organization (reusable knowledge assets), self-healing will not function.
This is where the Learning Loop comes into play.
Learning Loop — A Design of 4-Layer Memory
When I spoke abstractly about the Agentic AI Runtime framework in Part 6, I mentioned the Learning Loop but did not delve into it.
Here, I will organize it by dividing it into four layers.
The essence of the Learning Loop is a mechanism that elevates Episodic Memory (individual logs) into Procedural Memory (reusable procedures)—.
What happens in the field when this is in place?
First occurrence: The agent deals with the issue through trial and error (time-consuming)
A verification agent extracts the successful procedure in a standardizable format
Stored in Procedural Memory, making it reusable under similar conditions
Subsequent occurrences: The agent instantly recalls and applies past success patterns
As an organization, the state of “never solving the same problem twice” is finally established here.
Why did existing OSS/BSS fail to achieve this?
The question, “Isn't this what we've been trying to do for the past 20 years?” is a natural one.
In fact, TM Forum's Knowledge-Based autonomous operations, Self-Organizing Networks (SON), AIOps, and CMDB-based automation—all have spoken of this ideal.
However, examples where it truly functioned as self-healing in the field are extremely limited.
The reason is simply that they only possessed Episodic and Semantic layers out of the four.
Logs are accumulated (Episodic)
Knowledge bases are maintained (Semantic)
However, there is no mechanism to standardize “successful procedures” as organizational knowledge (Procedural)
And, “what the organization must not do” (Constitutional) cannot be explicitly passed to the AI
As a result, the AI remained a knowledge search engine and could not step into autonomous execution.
This is where the design as an Agentic AI Runtime makes a difference.
Realigning the tools we have gathered in parts 6, 7, 7.5, and 8:
Procedural Memory: Copilot Workspace / Logic Apps / Opal Workflow templates
Constitutional Memory: Purview / Entra Policies / Intune Compliance
Episodic / Semantic: Azure Monitor / App Insights / AI Search / Cosmos DB
In other words, having a 4-tier memory architecture as a product is itself a structural feature of the Microsoft stack.
This also serves as a foundation for Part 12 (Why Microsoft).
Self-Optimization — KPIs and Closed Loop
Another facet of self-healing is self-optimization.
In 5G RAN (Radio Access Network) and core network traffic engineering, the optimization of KPIs (throughput, latency, packet loss, connection success rate) is an endless operational task.
Conventionally, this involved:
Changing parameters using vendor-specific tools
Checking KPIs a week later to verify the effect
Rolling out to all cells if good, or reverting if bad
This cycle relies on specialized, person-dependent skills
If we overlay this onto the closed-loop model from Part 8:
Observation agent detects KPI degradation (or room for improvement)
Decision agent retrieves similar cases from Procedural Memory
Execution agent tentatively changes parameters in a limited number of cells
Verification agent continuously monitors KPI changes
Automatically expands the scope if good, or rolls back if bad
Writes the results back to Procedural Memory
This state where the "Observe → Decide → Execute → Learn → Re-observe" loop itself continues to run is the essential requirement of TM Forum L4.
Furthermore, to move beyond L4 into L5 (cross-domain), Procedural Memory must be reused across domains.
From here on, we enter the discussion area of Act 2.
Integration of 3 Scenarios — AN as a "Swarm of Closed Loops"
In parts 9 through 11, we laid out three scenarios.
Incident Response (Restore)
Service Deployment (Create)
Self-Healing/Self-Optimization (Maintain/Nurture)
These are divided into separate teams as functions of an operations organization.
However, in terms of structure, they are all variations of the same closed-loop.
| Scenario | Trigger | Primary Loop in Operation |
|---|---|---|
| Incident Response | Alert | Observe → Decide → Act → Verify |
| Service Deployment | Order/Contract Change | Decide → Act → Verify (Observation is a precondition) |
| Self-Healing/Optimization | Precursor/Degradation | Observe → Learn → Decide → Act → Learn |
The conclusion of this series is that these three can be placed on the same Runtime.
From here on, the industry is required to shift its thinking from "separate tools for each scenario" to a single Runtime independent of the scenario.
Next time: Why Microsoft — The Theory of Structural Advantage
So far, we have covered the tools for the execution layer and their application to business operations.
However, we have not yet answered the biggest question.
"Why can Microsoft handle this? Why not other clouds or other vendors?"
Next time, I will answer this question not with sentiment, but with structural theory.
I will present a table of the five conditions required for the execution layer and which vendors can meet them.
I will also include comparisons with similar historical strategies (VMware SDDC, Salesforce Customer 360).
From here on, this will be the most challenging installment of this series.
Notes (reposted)
This article represents my personal views and does not represent my affiliated organization.
For 3GPP / TM Forum / ETSI standards and concepts, please check the official specifications of each organization.
Terms such as "self-healing," "self-optimization," "SON," and "AIOps" are described as general concepts widely used in the industry.
Series Index
Part 1: The Wall of Autonomous Operations — Why We Get Stuck at L3
Part 2: Conditions for Reaching AN Level 4 — The Three-Layer Structure of Observation, Decision, and Execution
Part 3: The Void of the Execution Layer — Why the Entire Industry Is Stuck
Part 4: Head, Hands, and Control — The Three Elements Required for the Execution Layer
Part 5: The Three-Element Matrix — Re-evaluating Existing Approaches
Part 6: The New Horizon of Agentic AI Runtime
Part 7: Windows 365 for Agent — The 'Execution Layer Foundation' the Industry Has Been Waiting For Has Emerged
Extra Edition (Part 7.5): 95% Are Caused by Human Error — The New Main Battlefield of Agent IDs
Part 8: Project Opal — The Uncharted Territory of the Orchestration Layer
Part 9: Application to Telco AN Part 1 — Closed-Loop Fault Management
Part 10: Application to Telco AN Part 2 — Service Deployment and the Barrier of Vendor GUIs
Part 11: Application to Telco AN Part 3 — Self-Healing, Self-Optimization, and the Learning Loop (This Article)
Part 12: Why Microsoft — The Theory of Structural Advantage
Part 13: Supplementary Discussion 1 — Connecting the TM Forum AN Framework with This Series
Part 14: Supplementary Discussion 2 — The Wall of Control, Its True Height
Part 15: Supplementary Discussion 3 — The Wall of Observation — From Substrate Observability to Outcome Observability
Part 16: Supplementary Discussion 4 — The Wall of Defense — Detection and Structural Defense Are Different Jobs
Part 17 (Final): The Execution Layer of Autonomous Networks, and Beyond — Act 1 Summary and Connection to Act 2
This article: approx. 4,600 characters / 14-minute read
Author: Hiroyuki Hikino
20 years in the telecommunications industry. 3G/4G/5G mobile core network design / Former Cisco network engineer / Currently at Microsoft (personal views) / Representative of Diestaday LLC
Please feel free to share your opinions or questions in the article comments or on LinkedIn.
If you resonate with this series, please 'like' and follow on note, and repost on LinkedIn.