Main site

Telecom AI agent · Network remediation

Self-Healing Network Remediation AI Agent

Detect the fault, diagnose it within the configured scope, and propose a change with its blast radius and its reversion plan — then hold, because applying it is a network engineer's decision.

Typical delivery
4–6 weeks
Deployment
Your stack
Change approval
Peer-reviewed
After launch
Agent Care

What this agent does

Proposes the change, does not apply it

In

  1. 01

    Telemetry, alarms and configuration state arrive from supported assurance and orchestration.

  2. 02

    Element names, alarm codes and timestamps are normalised, and each signal keeps the path it arrived on.

Reason

  1. 03

    A fault hypothesis is formed inside the domain and the elements the agent has been scoped to.

  2. 04

    The carrier's change rules, maintenance windows and freeze periods are applied to whatever is proposed.

  3. 05

    Blast radius is computed for the proposed change — the elements, services and paths it would touch.

Decide

  1. 06

    911, 988 and special-facility paths sit outside the action space, as an exclusion rather than a setting.

  2. 07

    The proposal is routed to a named network engineer for peer review and authorisation.

Out

  1. 08

    The state it read, the change it wrote, the review and the authorisation are retained against the incident.

  2. 09

    Write actions run only inside the approval boundaries agreed during implementation.

Product statement

The agent proposes a change; a network engineer peer-reviews and authorises it, and the carrier stays the party answerable to its regulator.

Example workflow

One fault, alarm to authorised change

  1. 1Fault detectedAssurance alarms, performance counters, probes or ticket intake
  2. 2State assembledTopology, running configuration, recent changes and the freeze calendar, each with its source
  3. 3Change proposedChange, blast radius, reversion, confidence
  4. 4Controls appliedScope checks, the 911-path exclusion, the blast-radius limit, freeze-window checks and confidence threshold

No human action required

Stages 1 to 4 run unaided and change nothing — the agent is proposing, and the engineer's lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the duty network engineer to authorise.

Low confidence

Adds a second engineer's peer review first.

Change approval

The change is held with the state it was written against, its blast radius and the confidence.

Authorise · Amend · Send to change board

Authorised — staged for application

  1. 6Change applied in stagesOnly where write access and the change process allow it
  2. 7Outcome evaluatedService-level recovery, reversions, escalations and post-change incidents

Amendments

Every engineer amendment is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Anything on a 911, 988 or special-facility path.
    • Applying any change to the production network.
    • Any change beyond the configured blast radius.
    • Acting in a declared incident without the commander.

  • Automation boundary

    Agent acts unaided

    • ✓Detect a fault and correlate the alarms it raised.
    • ✓Diagnose within the domain and the elements it has been scoped to.
    • ✓Propose a change with its blast radius and its reversion plan.
    • ✓Hold the proposal for a named engineer, with the evidence attached.

    Any write happens inside the boundaries agreed at implementation, never ahead of authorisation.

    • Reverting a change outside the bounded scope.
    • Declaring the fault cleared or the service restored.
    • Changes crossing into a partner or third-party domain.
  • Changes to its own thresholds, scope or radius limits.

Example output

One proposed change, annotated

Everything the agent proposes is attached to the state it was read from.

Remediation output · single proposal

Illustrative example
Element
Edge router, metro ring
Proposed action
Restore the ring-facing link weighting to its peer-reviewed value
Blast radius
Single metro ring
State written against
Reviewed baseline
Confidence
88%
Reversion
Prepared, not guaranteed

As received

Taken from the assurance feed and the configuration baseline — nothing on this side is written by the agent.

Evidence used

  • Alarm correlation
  • Topology and dependency
  • Recent change record

Why this change

It restores a value the change record shows was reviewed — the line the engineer weighs.

What the score decides

Below the configured threshold the proposal picks up a second engineer's review before.

Action

AuthoriseAmendSend to change board

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every detected fault

From the assurance feed

03Diagnosis

Propose against the state

Draw on topology, the configuration baseline and the change record the carrier already keeps.

01Approved path

A change is still a change

Routine remediations arrive already written, with their blast radius computed.

02Human review

Send review to the risky changes

Wide-radius and low-confidence proposals are marked, so the engineer's review starts where the exposure is.

04

Build an evidence trail

The proposed change, its blast radius and the engineer who approved it stay on the record.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Assurance and fault management

    • IBM Netcool
    • Nokia NSP
    • Ericsson EIAP
    • Huawei iMaster

  • Orchestration

    • ONAP
    • Ansible Automation
    • Cisco NSO
    • Terraform

  • Inventory and topology

    • NetBox
    • Nokia NIM
    • Cramer
    • Granite

Agent

Self-healing network remediation

  • Reads the state
  • Proposes the change
  • Holds for approval

  • Change and incident

    • ServiceNow
    • Jira
    • BMC Remedy
    • change calendars

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the network

The controls sit inside one another. What none of them catches is set out below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modePull the agent back to detect-and-propose when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, scope and blast-radius configuration changes.Track
L4Change traceabilityRecord the state read, the proposal, the review, the authorisation and what followed.Record
L3Engineer approvalHold changes for a named engineer; it governs application, not whether the change is right.Gate
L2Blast-radius limitsTest each proposal against the configured scope, the 911 exclusion and the radius limit; a failure returns it.Restrict
L1Confidence thresholdsRoute low-confidence proposals to a second engineer before authorisation is asked for.Require review
Model coreChange proposed — action, blast radius, reversion plan and confidence
L1 – L2
Test whether a change may stand
L3
Puts the application in an engineer's hands
L4 – L5
Keep the change and the state it was written against
L6
Narrows to detect-and-propose when signals degrade

How Nestack evaluates it

Evaluate the remediation workflow — not only the change that was applied.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the change the network takes

  1. E1Final-output evaluationDid the applied change produce the service-level recovery it predicted?
  2. E2Step-level evaluationDid the agent read the right topology, baseline and change record?
  3. E3Tool evaluationDid it read and write the correct element and the correct parameter?
  4. E4Confidence calibrationDo low-confidence proposals actually attract more engineer amendments?
  5. E5Slice evaluationHow does performance change across specific fault classes?
  6. E6Business outcomeHow many changes were reverted, escalated or followed by a second incident?

Floor — the state the network is left in

Failure modes

Where each failure originates in the agent

Seven ways a change goes wrong, placed by stage.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • YR-03

      Single-pipeline telemetry

      State read from one monitoring path that was itself degraded.

    Stage gathers

    Alarms, topology, configuration baseline and change record

  2. 02 · Reasoning

    2 modes

    • YR-04

      Cascade mistaken for cause

      The loudest downstream symptom is diagnosed as the fault.

    • YR-06

      Conflicting closed loops

      Two concurrent loops act against each other's remedy.

    Stage proposes

    Action, blast radius, reversion plan and confidence

  3. 03 · Tool / write

    2 modes

    • YR-02

      Blast radius understated

      The change reaches elements the estimate did not include.

    • YR-05

      Reversion leaves a third state

      A partly applied change is reverted into neither state.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • YR-01

      Recovery load after the fix

      Reversion completes while the service is still failing.

    Stage returns

    The change the engineer authorises and

  5. 05 · Change / Version

    1 mode

    • YR-07

      Silent scope regression

      A model or rule change widens what the agent will propose.

    Stage tracks

    Model, prompt, scope rules and radius config

  • Sev-1 · applied outside the boundary
  • Sev-2 · a wrong change reaches the network
  • Sev-3 · telemetry degrades, proposal routes to review
See the complete Telecom failure-mode catalogue

Affected slices

A healthy total can hide one fault class

Base rates are not shared: each fault class carries its own, and one aggregate amendment rate quietly averages them together. Nestack reports the amendment rate by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Core and control-plane faults9.6%3.5×Review
Cross-domain transport faults5.8%2.1×Review
RAN cell-level degradation4.1%1.5×Watch
Single-element access faults2.5%0.9×Normal

Bar: amendment-rate lift vs. single-element access baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

The loop closes on a case, not a cause

The cycle ends when a case exists in the suite, not when the miss was discussed. That suite is what the next change proposed to the network is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Amendment rate rises in a fault class.

  2. 02

    Diagnose

    Not the loudest alarm — an engineer reads the state, the change record and the proposals until the cause narrows to one.

  3. 03

    Improve

    Changes carry a version and the incidents that prompted them.

  4. 04

    Verify

    Release is held until the affected cases pass.

  5. 05

    Learn

    The case is kept permanently, and the change rules move with it.

  6. Learn → Detect

    The return edge. The next detection is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, remediation workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Remediation workflow discovery and boundary definition.Week 1
  2. 02Assurance and orchestration assessment.Week 1, Week 2
  3. 03Change-process, blast-radius and 911-exclusion mapping.Week 1, Week 2
  4. 04Telemetry ingestion and normalisation.Week 2
  5. 05Diagnosis logic and state binding.Week 2, Week 3
  6. 06Confidence scoring and proposal routing.Week 3
  7. 07Engineer approval workflow.Week 3, Week 4
  8. 08Orchestration and change-system integration.Week 5
  9. 09Blast-radius and rollback cases.Week 4, Week 5
  10. 10Guardrails and approval controls.Week 4
  11. 11Change-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne domain, one regionProductionProduction change processAdvancedMultiple domains / vendors
Introduced at Pilot
Proposals against your state and rules✓✓✓
Engineer approval✓✓✓
Proposal-quality baseline✓✓✓
Introduced at Production
Reporting by domain and element—✓✓
Change-system workflow integration—✓✓
Authorised change execution—✓✓
Orchestration-stack integration—✓✓
Introduced at Advanced
Multi-vendor change policies——✓
Multi-stage change approvals——✓
High change volume——✓
Multi-domain change controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, change volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your change process and its approval chain

    Change-process mapping and boundary definition

    Week 1

  2. 02Representative faults and the changes that cleared them

    Diagnosis baseline, state binding and blast-radius modelling

    Week 2

  3. 03Your topology, baseline configuration and freeze calendar

    Blast-radius, freeze-window and 911-exclusion mapping

    Week 1

  4. 04Access to assurance, inventory and orchestration APIs

    Assurance and orchestration assessment, then integration setup

    Week 2

  5. 05Changes you would not want applied

    Rollback cases and failure-mode testing

    Week 4

  6. 06What a change may never touch on its own

    Confidence scoring, scope limits, guardrails and approval controls

    Week 3

  7. 07Named network engineers to review proposals

    Engineer approval workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

The bands follow the actual work, which is why the fifth week doubles rather than pads.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Remediation workflow discovery, change mapping and the automation boundary

W2Assurance and orchestration integration, and the diagnosis baseline

W3Proposal workflow, confidence logic and approval controls

W4Evaluation suite, blast-radius checks and failure-mode testing

W5Orchestration integration, pilot changes and targeted corrections

W6One change window run under network engineering, then handover

Reading the band
A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6
The window closes validation and Agent Care owns the running agent.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Telecom AI agent

Build a remediation agent around your change process.

Show us your assurance stack, your change process and your freeze calendar. The engineer who signs a change today still signs it after this ships — we map the boundary around that signature.

Typical delivery
4–6 weeks
Deployment
Your assurance stack
Change approval
Peer-reviewed
After launch
Agent Care available

Nestack Agents · Self-healing network remediation

AGT-TL-09 · Agent Care available after launch

Build a remediation agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your network

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.