Struggling With Network Automation? Here’s Your Roadmap

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, they 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, 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 that agents will somehow make sense of your messy data. You need to build a first-principles foundation around intent, 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 a reliable, predictable, scalable network automation roadmap (no matter which tools you use). But first, the case for using the NAF Framework as your baseline.

4 Reasons to Adopt the NAF Framework

1. It’s Tool Agnostic

We’re not here to shove any one platform down your throat. You know what works best for your teams, for your budgets, for your compliance needs, and what will get past all the questions from procurement.

We’re here to 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.

This is a not-so-subtle plug to come to Network Automation Forum’s AutoCon next year. We had a great time at AutoCon 5.

3. It’s Not a Strict Guideline

Obviously, we hope you read this blog, and other NAF Framework material, but you don’t need to be hanging on every word.

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.

That way, 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.

Note: If you’d rather watch than read, here’s my full talk from SwiNOG 2026:

1. Intent

What: The expected state of your network. Aka, what you would need to rebuild your network if you had to tomorrow.

That includes config, topology, and services, but it also includes 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

It should also include metadata to support effective governance, offer version control, create a consistent, unified view of your desired state. See how you can easily get started with Infrahub Skills, an open-source AI skills package.

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 just got a blueprint with no contractor to do the work.

Must-Haves:

• Can interact with any supported network write interface

It 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.

Some 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 (and more often than not, there need to be some tweaks).

Must-Haves:

• Programmatic access to observability data
• Historical data persistence

It 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 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

It 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 front end 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 DM-ing your most senior engineer.

Must-Haves:

• Robust authentication and authorization capabilities

It might support read and write interactions and will probably look different based on the needs of the end user.

Example of NAF Framework Applied to a Network Automation Problem

Say you are 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:

• Use Infrahub (Intent) to define the desired subnet, VLAN, and routing.
• Use Ansible Automation Platform (Orchestration) to send that definition to the executor for deployment.
• Use Ansible (Executor) to render configs on each device, pushing via NETCONF to each of the 50 routers.
• Use gNMic, SuzieQ, and Kentik (Collector) to gather device telemetry, network state, and flow data.
• Use Prometheus, SuzieQ, and Kentik (Observability) to surface the new state of the network, detect any drift (metric mismatches, state changes, anomalies), and alert your team to those gaps.
• Use AAP (Orchestration) to make some corrected actions, aka re-run Ansible (Executor) on the failing site.
• Use Grafana (Presentation) to show a compliance dashboard for every site.

If you look a bit closer, you’ll notice that it’s actually a loop, starting from intent, then going to orchestration, then execution, then collection and observability. And 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. And 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.

If you want a more technical dive into the Framework, I encourage you to watch or download some of the presentations my colleagues and I have been doing on the NAF Framework. Or shoot me a DM, I’m happy to chat.