In theory, AIOps sounds great. Tell an agent what to do and BOOM—your network builds and fixes itself.
But we’re nowhere near that yet. Unless they’re assigned a super narrow task, agents hallucinate and break. At the same time, the pressure to use AI isn’t letting up. So people keep building “assistants” no one trusts and pilots never end up reaching production.
If you’ve been around network automation for a while, this story might seem familiar because it’s exactly what happened when people tried to scale automation. They jumped in headfirst, trying to automate what humans do, layering tools on top of bad data, and found themselves perpetually stuck at one-off automations.
The teams that succeeded in the long run took a different approach. They modeled intent, structured their data, and built a proper deployment stack. Most importantly, they left automation for last.
The same will be true for AIOps. You can’t rush in and hope agents will somehow make sense of your messy data. You need to build a first-principles foundation around intent, ” target=”_blank”>version control, and validation.
But you don’t have to invent a whole new strategy. A group of us in the NAF community have already developed a blueprint for you to start from.
Below, we outline the six foundational elements to reliable, predictable, scalable network automation no matter which tools you use. But first, let’s make the case for why you should use the NAF Framework as your baseline.
4 reasons to adopt the NAF framework
1. The NAF framework is tool-agnostic.
The framework doesn’t push you towards any particular tools. Only you know what works best for your team, your budgets, your compliance needs—and what will get past all the questions from procurement.
But the framework can help you figure out what kinds of tools you might need for network automation and how they might fit with other tools you already have. As you can see here, it’s possible for products to map completely or partially to one or multiple blocks.
2. It’s continuously updated.
Our industry is constantly changing, which means this framework is necessarily in flux. New network automation best practices will arise and we intend to adjust this framework in tandem.
3. It’s not a strict guideline.
You don’t need to use all six blocks, nor do you have to implement them in a certain order. Just do what’s required for your use case.
4.it’s not just for network automation engineers.
While the NAF Framework is most helpful for automation architects, software engineers, and network reliability engineers, it’s designed to be accessible to people who consume the outputs of network automation too.
With a shared understanding of what everyone is working towards, network ops, network architects, and engineering managers know what to ask for, how to ask for it, and what’s truly realistic.
6 foundations of the NAF framework
Now that you know what the NAF Framework offers, here’s what’s actually in it.
1. Intent
What: The expected state of your network. Put another way, it’s what you would need to rebuild your network from scratch if you had to.
That includes configurations, topology, and services but also business and operational expectations (visual diagrams, for example) and asset inventory data.
Why: Without a clean record of what your network is supposed to be, you can’t control what gets deployed, validate that it’s right, or recover from a mistake.
As AI agents start consuming and writing to your source of truth on their own, the stakes go even higher. An agent that doesn’t know what’s current or accurate will guess (and that’s probably going to be expensive).
Must-haves:
- Structured, queryable data
- A well-documented API
- Create, read, update, and delete operations
Your intent function should also include metadata to support effective governance, offer version control, and create a consistent, unified view of your desired state.
2. Executor
What: Pushes your intended state to production. It interacts with network devices to apply these changes.
Why: The executor is what turns intent into reality. Without it, you’ve got a blueprint with no contractor to do the work.
Must-haves:
- Can interact with any supported network write interface
The executor should also give you the option to dry-run any operation before applying and support any network operation that alters network state (not just config management).
3. Observability
What: The state of your network right now.
Observability data sources include:
- Logs
- Traces
- Flows
- Packet captures
- Configs
- Probes
- Metrics
Why: Without observability, you trust that everything you’ve deployed is doing exactly what you think it’s doing. (But more often than not, there need to be some tweaks).
Must-haves:
- Programmatic access to observability data
- Historical data persistence
The observability function should also generate events when there are discrepancies, expose relevant insights about the current state of the network, normalize data into a vendor-agnostic model, and come with a query language so you can extract critical data.
4. Collector
What: Retrieves the state of your devices. Think of it as a real-time pulse check on your network.
Why: Without a reliable collector, every other block is operating on data that might already be stale.
Must-haves:
- Ability to retrieve live data with read interfaces (push and pull)
5. Orchestrator
What: Coordinates all the other blocks. It knows when to execute something, how to handle failures, and can manage multi-step workflows.
Orchestration is where most companies have felt comfortable starting to apply AI. They’ve gone from writing a Python script to running a pre-defined Ansible workflow to a pub/sub event-driven system. Soon, many are hoping to move to a fully agentic system.
Why: Without orchestration, every block is doing its own thing in isolation. You’d have to cobble together brittle scripts to pass state between tools, crossing your fingers nothing fails halfway.
Must-haves:
- Enable coordination of processes across various building blocks
Orchestration should also follow an event-driven approach for execution, include logging and traceability of past and current workflows, give you the option to schedule your workflows, allow for reverse execution, and have native dry-run functionality.
6. Presentation
What: A frontend display of your automation platform.
Why: Network automation generates outputs that need to be consumed by people and systems outside of your automation team. The presentation layer makes those outputs accessible to audiences who don’t need to understand the backend of your stack. It lets application teams self-serve, allows you to integrate CI/CD pipelines, and helps you give auditors answers without tapping your most senior engineer.
Must-haves:
- Robust authentication and authorization capabilities
The presentation layer might support read and write interactions and will look different based on the needs of your end users.
Example of NAF framework applied to a network automation problem
Say you’re tasked with rolling out a new subnet across 50 branch sites. You need to validate the config on every device and automatically detect and remediate any site that drifts out of compliance.
To apply the Framework, you might:
- Intent: Use Infrahub to define the desired subnet, VLAN, and routing.
- Orchestration: Use Ansible Automation Platform to send that definition to the executor for deployment.
- Executor: Use Ansible to render configs on each device, pushing via NETCONF to each of the 50 routers.
- Collector: Use gNMic, SuzieQ, and Kentik to gather device telemetry, network state, and flow data.
- Observability: Use Prometheus, SuzieQ, and Kentik to surface the new state of the network, detect any drift (metric mismatches, state changes, anomalies), and alert your team to those gaps.
- Orchestration: Use AAP to make some corrected actions, aka re-run Ansible on the failing site.
- Presentation: Use Grafana to show a compliance dashboard for every site.
If you look a bit closer, you’ll notice that the process is actually a loop, starting from intent, going to orchestration, then execution, collection, and observability. Remediation happens in a loop too: back to orchestration, execution, collection, and observability.
Future-proof your network automation
At this point, automation isn’t optional. You just can’t run a multi-domain VPN network without automation. As workloads scale faster than headcount, AI is going to be part of how it runs, whether you’re ready or not.
So why not start making small changes now? The same foundations that make automation reliable (clean intent data, structured observability, traceable orchestration) are the ones agents need too.
To dig deeper into the Framework and stay up-to-date with developments, this groups of presentations from AutoCon 5 are a great place to start:
- NAF Framework Deep Dive With Christian Addell and Damien Garros
- NAF Framework Update With Claudia de Luna
- NAF Framework Use Cases With Claudia de Luna
- Applying the NAF Framework to Real-Life Projects With Christian Drefke
