How to move from observability and digital twins to safe network autonomy—with service assurance, deterministic validation, and explicit operating boundaries.
The last two posts in this series looked at observability and network digital twins. Observability asks: can we prove what the network is doing? A digital twin asks: can we model what the network will do before we touch production? Closed-loop networking asks the next, harder question: when the system sees a problem or an opportunity, should it be allowed to act?
The tempting answer is “yes, automate it.” The safer answer is “only after the loop earns trust.” Network automation becomes dangerous when it moves faster than evidence, faster than validation, or faster than accountability. A closed loop should not be a shortcut around operations. It should be a disciplined operating model where intent, telemetry, service assurance, policy validation, and human guardrails work together.
This article treats closed-loop networking as a practical engineering topic, not as a slogan. It explains where loops are useful today, where they remain risky, and how to design autonomy that improves reliability without turning production into an uncontrolled experiment.
1) Closed-loop networking: the useful definition
A closed loop is a control system. It observes state, compares that state with an expected outcome, decides whether a correction is needed, applies a correction, and verifies whether the correction worked. ETSI ZSM describes closed-loop automation using monitoring, analysis, decision, and execution stages, with knowledge as a supporting component. The terminology varies by framework, but the engineering idea is stable: observe, decide, act, and verify inside explicit boundaries.
In network terms, the loop may adjust routing policy, SD-WAN path preference, QoS treatment, capacity placement, firewall posture, service-chain selection, or incident escalation. The important word is outcome. Closed-loop networking is not “run this command automatically.” It is “keep this service within its intended behaviour while respecting constraints.”
Closed-loop control (conceptual) 1. Observe: collect telemetry, events, topology, service state 2. Interpret: correlate symptoms to intent, dependency, and likely cause 3. Decide: choose recommendation or action inside constraints 4. Validate: test against policy, risk, digital twin, and approvals 5. Act: apply change in a bounded scope 6. Verify: prove the service improved and no invariant broke 7. Learn: update confidence, rules, models, and runbooks
Most failures happen because one of these steps is weak. A loop that observes poorly acts on bad evidence. A loop that validates poorly can make a correct diagnosis and still apply the wrong fix. A loop that learns without governance can gradually optimise itself into a corner. The loop is only as safe as the weakest stage.
2) Intent is not a command, and that is the whole point
Intent-based networking matters because it separates the desired outcome from the implementation details. RFC 9315 frames intent as a form of policy that gives guidance to a network that can otherwise operate without constant human intervention. That is a useful distinction: “prefer ISP-A for voice unless jitter exceeds 20 ms for more than 90 seconds” is closer to intent than “set this next-hop now.”
Good intent is declarative, measurable, and constrained. It tells the system what must remain true, what trade-offs are acceptable, and which invariants must never be violated. Poor intent is a vague wish: “make the network better,” “optimise performance,” or “reduce cost.” Those statements are not safe enough for automation because they leave the system to invent the missing policy.
Practical rule: do not automate against a goal you cannot measure, and do not measure a goal without defining the boundaries that protect the business.
- Outcome: what service behaviour should remain true?
- Metric: which telemetry proves the outcome is healthy or unhealthy?
- Constraint: what must not be broken while fixing the problem?
- Scope: which site, tenant, VRF, peer, class, app, or user group is eligible for action?
- Authority: may the loop recommend, stage, execute with approval, or execute autonomously?
RFC 9316’s classification work is useful here because not all intent has the same risk profile. A reporting intent (“show me whether the service meets policy”) is not the same as a deployment intent (“change the routing and security path to restore policy”). Treating all intent as equal is how automation projects overreach.
3) The trust ladder: recommend, assist, approve, automate
The safest way to deploy closed-loop networking is not to jump from dashboards to full automation. It is to climb a trust ladder. Each rung adds autonomy only after the previous rung proves itself.
- Observe-only: the system correlates events and shows likely causes, but it does not recommend change.
- Recommend: the system proposes a remediation with evidence, confidence, and expected impact.
- Assist: the system prepares the change plan, validation checks, rollback steps, and maintenance notes.
- Approve-and-apply: the human approves the action; the system applies it safely and verifies the result.
- Autonomous within bounds: the system applies low-risk, well-tested actions automatically inside a tight safety envelope.
- Autonomous with escalation: the system handles routine events, but stops when confidence, blast radius, or policy risk exceeds defined limits.
This ladder avoids the most dangerous form of automation adoption: automating the action before automating the proof. Before a loop changes production, it should demonstrate that it can detect the condition correctly, recommend the right remediation, predict the likely impact, and verify the result repeatedly.
3b) The autonomy boundary: separate recommendation from authority
The cleanest closed-loop designs separate three functions: analysis, decision authority, and execution. A system may be allowed to analyse broadly, recommend cautiously, and execute narrowly. That separation prevents an observability tool, an AI assistant, or an orchestrator from quietly becoming an unbounded production actor.
- Analysis can be broad: correlate logs, telemetry, topology, route state, tickets, changes, and historical incidents.
- Recommendation should be evidence-based: include the suspected cause, confidence, expected impact, blast radius, and rollback.
- Execution must be constrained: only pre-approved actions, in pre-defined scopes, with rate limits and verification.
This distinction keeps human accountability intact. The system can accelerate diagnosis and prepare the change, but the organisation still defines what the loop is allowed to do.
4) Safety envelopes: the most important design artifact
Closed-loop automation needs a safety envelope. The envelope defines what the loop may do, where it may do it, how quickly it may act, what evidence it requires, and when it must stop. Without this envelope, the optimisation goal can become dangerous.
Imagine an SD-WAN loop that detects packet loss and moves traffic away from an impaired path. That sounds safe until every branch moves to the same alternate path and congests it. Imagine a BGP loop that withdraws a route after detecting a black-hole. That may help, but it may also move traffic through a firewall path that is not sized for the shift. Imagine a firewall loop that blocks “suspicious” traffic, only to break a fragile business application during month-end processing.
- Blast-radius limit: one site, one tenant, one VRF, one peer, one application class, or one policy domain at a time unless explicitly approved.
- Rate limit: no repeated changes faster than the network can converge and the monitoring can prove outcome.
- Confidence threshold: require higher confidence as blast radius, security impact, or business criticality increases.
- Rollback condition: if the metric does not improve, or a protected metric worsens, revert automatically or escalate.
- Protected invariants: never violate segmentation policy, compliance boundaries, route-leak controls, capacity reservations, or maintenance freezes.
- Change journal: every loop action records who/what authorised it, input evidence, policy version, executed change, verification result, and rollback status.
A safety envelope is not paperwork. It is the operating contract between automation and production.
5) Telemetry is the loop’s nervous system
Closed-loop systems depend on telemetry, but more telemetry does not automatically mean better decisions. A useful telemetry design maps directly to intent. If the intent is voice quality, collect loss, jitter, latency, path choice, queue drops, codec behaviour where visible, and user-impact evidence. If the intent is BGP safety, collect prefix counts, route origin changes, policy hit counters, RPKI state, update rates, and peer session events.
Telemetry also needs freshness and confidence metadata. A decision engine should know whether a signal is current, stale, partial, inferred, or conflicting. Without that metadata, a loop may act on a symptom that has already cleared or ignore a condition that has moved to another part of the network.
- State telemetry: routes, adjacencies, sessions, tunnels, interfaces, queue state, endpoint location.
- Performance telemetry: loss, latency, jitter, drops, saturation, retransmissions, SLA probes, synthetic transactions.
- Event telemetry: faults, syslog, controller events, policy deployments, topology changes, provider notices.
- Service telemetry: application response, user experience, service health, dependency state.
- Change telemetry: who changed what, when, by which pipeline, with which approval and rollback plan.
A closed loop should degrade gracefully when telemetry is incomplete. If the evidence is weak, the loop should recommend or escalate—not act blindly.
5.1 Telemetry quality gates
A loop should know the quality of its own evidence. Missing samples, delayed telemetry, clock skew, stale topology, and inconsistent labels can all produce confident but wrong automation. Before the loop acts, it should validate that the data is fresh enough, complete enough, and correlated to the right service.
- Freshness: is the data current enough for the action being considered?
- Completeness: are all required domains reporting, or is the loop seeing only part of the system?
- Identity: do telemetry labels map cleanly to service, tenant, site, policy, and device identity?
- Clock alignment: can events be ordered reliably across controllers, devices, and clouds?
6) Service assurance: close the loop around the service, not the box
The strongest closed loops operate around services, not individual devices. RFC 9417’s service-assurance architecture is useful because it decomposes a service into subservices, then assures those subservices through measurable objectives. That mindset prevents a common operational mistake: every box looks healthy, yet the service is broken.
A corporate example: Microsoft 365 access may depend on branch Wi-Fi, access switching, SD-WAN path choice, DNS, SSE policy, identity, and SaaS reachability. A service-provider example: a customer VPN may depend on PE health, IGP reachability, label/SR state, BGP VPN routes, QoS treatment, and underlay capacity. A loop that sees only one domain can optimise one component while damaging the end-to-end service.
RFC 9418 adds a YANG data model for service assurance, which matters because closed loops need structured service state, not just ad-hoc metrics. You do not have to implement that exact model to benefit from the principle: model the service, model the dependencies, then close the loop around the service outcome.
- Service objective: what user or customer experience must hold?
- Subservice map: which domains contribute to that outcome?
- Evidence: which metrics prove each subservice is healthy?
- Action scope: which domain may the loop change, and which domains are read-only?
- Verification: how does the loop prove the whole service improved?
7) Digital twins: the rehearsal stage before production action
A network digital twin becomes especially valuable when connected to closed-loop operations. It gives the loop a rehearsal stage. Before applying a route-policy change, the system can model reachability. Before moving an SD-WAN class to a different path, it can check capacity and dependency. Before inserting a firewall path, it can test symmetry and expected latency budget.
The twin does not need perfect fidelity to be useful. It needs fit-for-purpose fidelity. A BGP policy twin must model prefixes, communities, AS-path logic, route targets, and import/export rules. A QoS twin must understand classes, queues, policers, shapers, and bottlenecks. A segmentation twin must understand VRFs, contracts, firewall policy, identity groups, and application flows.
- Pre-check: does the proposed action violate policy, reachability, capacity, or compliance constraints?
- What-if: what changes in best path, next-hop, route-target import/export, tunnel selection, or service-chain traversal?
- Blast-radius estimate: which sites, prefixes, tenants, users, or applications may be affected?
- Rollback validation: can the system return to the previous state if the action fails?
Closed-loop systems should not treat the digital twin as an oracle. They should treat it as one evidence source, with confidence and known blind spots. If the twin is stale or incomplete, the action should downgrade from automatic to assisted or recommended.
A twin is not an oracle. It is a bounded model with known assumptions. Closed-loop designs should record model freshness, unsupported behaviours, confidence level, and what the twin did not simulate before using its output as a gate.
8) Policy translation: where intent becomes risk
The translation from intent to configuration is where most hidden risk lives. “Prefer low-latency path for trading traffic” may translate into BGP local preference, SR policy binding, SD-WAN app-aware routing, QoS queue changes, or service-chain selection. Each translation has side effects.
A safe translator produces both the change and the explanation. It should show the target objects, generated policies, dependency assumptions, expected state, validation commands or API checks, and rollback. If the generated change cannot be explained, the system is not ready to apply it unattended.
Intent translation output (minimum useful form) Intent: Keep Payment-App traffic on private path unless loss > 1% for 3 minutes. Generated policy: - Match application signature / prefixes / identity group - Prefer private WAN path A - Fail to private WAN path B only after sustained loss threshold - Never use generic internet breakout - Preserve inspection through Payment-FW service-chain Validation: - Confirm app classification hit count - Confirm path A/B health - Confirm firewall symmetry - Confirm no route leak to guest/IoT segments - Confirm rollback restores original preference
This is also why natural-language interfaces require discipline. Natural language can be a useful input, but the actual intent must become structured, testable, and bounded before anything touches production.
9) Multi-domain loops: prevent local optimisation from becoming global damage
Modern networks contain multiple control domains: WAN, data centre, cloud, security, identity, transport, wireless, and application delivery. Each domain can have its own loop. The WAN loop wants to avoid packet loss. The security loop wants to block suspicious flows. The cloud loop wants to optimise cost. The data-centre loop wants to rebalance workloads. The problem is obvious: a local win can become an end-to-end loss.
Closed-loop design therefore needs coordination. At minimum, domains must exchange intent, constraints, current actions, and confidence. A WAN loop should not move traffic into a cloud path if the security domain is draining that path. A capacity loop should not move workloads into a site that the transport domain has marked degraded. A security loop should not quarantine a path that carries a critical recovery workflow without escalating.
- Shared invariants: segmentation, compliance, safety, sovereignty, and business-critical access rules apply across all loops.
- Action registry: domains publish active remediations so other loops do not fight them.
- Conflict detection: if two loops propose incompatible actions, escalate to a coordinator or human approver.
- Priority rules: life-safety, security containment, revenue-critical apps, and broad availability need explicit precedence.
Multi-domain coordination is not optional once automation becomes active. Without it, each loop becomes rational locally and irrational collectively.
10) AI and agents: useful assistants, risky operators
AI and agent-based operations are moving quickly into the networking conversation. They can help summarise incidents, correlate symptoms, generate candidate policies, explain diffs, write validation checks, and prepare remediation plans. Used carefully, they reduce operator load and make complex systems easier to understand.
The danger appears when generated reasoning becomes generated action. An AI system may produce a plausible explanation that is incomplete, outdated, or wrong. It may optimise for the metric it sees and ignore the service dependency it does not see. It may also produce a change that is syntactically valid and semantically dangerous.
- Use AI for synthesis: summarise events, propose hypotheses, explain policy diffs, and prepare runbooks.
- Use deterministic checks for gates: route-leak tests, reachability proofs, compliance checks, schema validation, and capacity limits should not be intuition-based.
- Keep provenance: record which data, model, prompt, tool, and policy version informed the recommendation.
- Restrict authority: agents can recommend broadly, but should act only within narrow, tested, low-risk envelopes.
- Plan for adversarial inputs: protect automation systems from poisoned telemetry, misleading tickets, prompt injection through logs, and unauthorised tool access.
AI belongs in the loop, but not as an unbounded root operator. The safest pattern is AI-assisted diagnosis and deterministic enforcement: let the agent accelerate understanding, then let explicit policy and validation gates decide whether action is allowed.
11) Practical use cases that are ready before “full autonomy”
The best closed-loop use cases are narrow, high-value, measurable, and reversible. Do not start with “automate the whole network.” Start with one loop where the condition is clear, the action is safe, and the verification is obvious.
11.1 SD-WAN brownout remediation
The loop detects sustained loss/jitter on a path, moves a specific application class to an alternate underlay, verifies user-experience improvement, and moves back only after stable recovery. The safety envelope prevents mass fleet shifts and avoids proxy/security paths that are not approved for real-time traffic.
11.2 BGP route-leak containment
The loop detects an unexpected prefix-count spike, invalid origin state, or export-policy anomaly. It does not immediately rewrite global policy. It applies a pre-approved emergency filter or disables a specific export path, then alerts humans with evidence and rollback context.
11.3 EVPN tenant protection
The loop watches MAC/IP churn, unexpected route-target imports, and multihoming state. If one leaf or tenant starts generating instability, the loop limits blast radius and surfaces the likely source before churn spreads through the fabric.
11.4 DDoS or abuse response
The loop detects attack signatures or volumetric deviation, applies traffic diversion or blackhole communities according to pre-approved policy, verifies collateral damage, and expires the action automatically unless an analyst extends it.
11.5 Energy-aware routing or capacity optimisation
The loop recommends moving traffic or services to reduce energy usage during safe periods. This is a recommendation-first use case because cost and sustainability optimisation must not silently violate latency, redundancy, or compliance expectations.
11.6 Certificate, DNS, and identity-adjacent remediation
Some service incidents sit at the edge of “network” and “platform”: expiring certificates, stale DNS records, identity provider reachability, resolver failure, or captive-portal misbehaviour. These loops should start as recommendation-only because the blast radius can be surprising, but they are excellent candidates for automation-assisted diagnosis and pre-built change plans.
11.7 Capacity and class-of-service protection
A bounded loop can protect premium traffic classes when telemetry shows congestion building. The safest version does not invent new QoS policy on the fly. It enforces pre-approved actions: shift bulk replication windows, rate-limit non-critical backup flows, move lower-priority traffic to alternate paths, or escalate before protected classes breach thresholds.
12) Change pipelines: closed loop does not mean no change control
A closed loop still needs a change pipeline. The pipeline may be faster and more automated than a traditional CAB process, but it must retain the core safety functions: review, validation, staging, rollback, and evidence. In mature environments, the pipeline itself becomes part of the loop.
- Pre-approved actions: low-risk remediations that have been tested and approved in advance.
- Canary scope: first apply to a single site, edge, tenant, or path before expanding.
- Post-check contracts: action is successful only if protected metrics remain inside bounds.
- Automatic expiry: temporary remediation should expire or revalidate, not live forever as hidden state.
- Audit trail: record trigger, evidence, decision, approver (if any), applied change, verification, and rollback result.
This discipline also protects the organisation culturally. Engineers will not trust closed-loop systems if they cannot understand what changed and why. Auditability is not bureaucracy; it is how automation earns trust.
13) Implementation roadmap: build trust before autonomy
A practical adoption roadmap looks like this:
- Phase 1 — Instrument: collect telemetry tied to service intent, not just device health.
- Phase 2 — Correlate: map services to topology, routes, policies, dependencies, and recent changes.
- Phase 3 — Recommend: generate candidate remediations with confidence, blast-radius estimate, and rollback.
- Phase 4 — Validate: use policy checks, labs, digital twins, or simulation to test recommendations before action.
- Phase 5 — Approve-and-apply: let humans approve while the system handles execution and verification.
- Phase 6 — Automate bounded loops: allow automatic action only for low-risk, reversible, well-observed cases.
- Phase 7 — Expand carefully: add domains only when coordination, conflict detection, and governance are ready.
The roadmap deliberately slows down the jump to autonomy. That is not anti-automation. It is how you make automation durable. Systems that earn trust in narrow domains can expand. Systems that surprise operators get disabled.
13b) Acceptance criteria: when a loop is ready to act
Before a loop receives execution authority, require evidence that it behaves safely over time. Treat this like production readiness, not a demo.
- Detection accuracy: the loop identifies the correct condition consistently and avoids noisy false positives.
- Action correctness: recommendations match approved runbooks and do not violate invariants.
- Reversibility: every automated action has a verified rollback or a safe stop condition.
- Human trust: operators understand why the loop acts and can override or pause it quickly.
- Auditability: every decision can be reconstructed after the fact.
If these criteria are not met, the loop can still be valuable. Keep it in recommend or assist mode until the evidence improves.
14) Anti-patterns: how closed-loop projects fail
- Metric myopia: the loop optimises one metric (loss, cost, utilisation) while violating user experience or security intent.
- Unbounded scope: the loop can change too many sites, paths, or policies at once.
- Hidden state: temporary remediations become permanent undocumented production behaviour.
- Model worship: the digital twin is treated as always correct even when telemetry or inventory is stale.
- No stop condition: the loop keeps trying new actions after confidence has dropped.
- No human explanation: operators see the result but not the reasoning, evidence, or rollback path.
Every one of these anti-patterns is preventable. They are not technology failures; they are design failures.
Automation credential sprawl: every controller, agent, and workflow needs least-privilege access. A closed-loop platform with broad credentials becomes a high-value target. Strong identity, scoped tokens, approval gates, and audit logs are part of the network design, not an afterthought.
15) Checklist: is your loop safe enough to act?
- Intent: is the desired outcome specific, measurable, and bounded?
- Evidence: does telemetry prove both the problem and the expected improvement?
- Constraints: are security, compliance, capacity, and business rules encoded as hard guardrails?
- Validation: can the proposed change be checked before production action?
- Blast radius: is the first action limited to the smallest useful scope?
- Rollback: is rollback automatic or at least prepared and verified?
- Coordination: will another loop or domain fight this action?
- Audit: can you explain who/what acted, why, with what evidence, and what happened afterwards?
- Stop rule: does the loop know when not to act?
If the answer to any of these is weak, keep the loop in recommend or assist mode. There is nothing wrong with supervised automation. In many networks, supervised automation is the most responsible destination for a long time.
16) Closing: autonomy is earned, not enabled
Closed-loop networking is not a feature you switch on. It is an operational capability built from observability, service assurance, policy modelling, digital twins, change control, and governance. Each layer earns the right to automate a little more.
The future of network operations is not humans typing every command by hand, and it is not machines changing production without accountability. The useful future sits between those extremes: humans define intent and boundaries; systems observe continuously, reason quickly, validate rigorously, act narrowly, verify honestly, and escalate when uncertainty rises.
That is closed-loop networking without blind trust. Not zero humans. Not zero risk. Just better evidence, smaller blast radius, and automation that understands the difference between action and responsibility.
References and standards anchors
- RFC 9315 — Intent-Based Networking: Concepts and Definitions
- RFC 9316 — Intent Classification
- RFC 9417 — Service Assurance for Intent-Based Networking Architecture
- RFC 9418 — A YANG Data Model for Service Assurance
- RFC 9232 — Network Telemetry Framework
- IRTF NMRG Internet-Draft — Use Cases and Practices for Intent-Based Networking (active Internet-Draft; use as evolving guidance, not a final standard)
- IRTF NMRG Internet-Draft — Network Digital Twin Concepts and Reference Architecture (active Internet-Draft; useful context for validation and rehearsal stages)
- ETSI ISG ZSM — Zero touch network and Service Management
- ETSI GR ZSM 017 — Closed-Loop Automation Security Aspects
- TM Forum — Autonomous Networks Mission
Eduardo Wnorowski is a systems architect, technologist, and Director. With over 30 years of experience in IT and consulting, he helps organizations maintain stable and secure environments through proactive auditing, optimization, and strategic guidance.
LinkedIn Profile