Here at AutoCon4 in Austin, everyone’s buzzing about automation pipelines, intent-based workflows, Python wizardry, and how fast we can get configs onto boxes. It’s exciting—and honestly, it’s progress.

But there’s a giant blind spot in the conversation: You can’t automate your way out of a visibility gap.

Not today. Not ever.

The Network Automation Forum (NAF) Framework spells this out clearly: If your strategy starts with “push,” you’re already skipping the part that determines whether your automation is going to work or wreck something.

Automation gets all the headlines.

Network observability is the headline.

Let’s break this down.

1. The intent versus reality gap (where automation dreams die)

The NAF Framework differentiates between two worlds:

  • Intended state. Your source of truth. Your IP address management. Your Git repository. What you wish the network looked like.
  • Operational state. What’s actually happening on the wire—telemetry, flows, path performance, routing logic, latency fingerprints, and the real experience of your packets.

Automation is the mechanism trying to force those two worlds together. But if you’re pushing changes without truly understanding the operational state, you’re just hoping the network behaves the way you think it does.

Hope is not a strategy.

Observability is.

2. Observability offers the brakes, the steering, and the dashboard

This begs the question: “How do we scale network automation reliably?”

Automation is the Ferrari.

Observability represents your windshield, brakes, side mirrors, lane detection, and collision avoidance system.

Would you do 100 mph blindfolded?

Of course not. Yet network operations teams do this every day when they automate without observability.

A mature observability practice enables teams to master network configuration management. With these capabilities, teams can establish the most important safety mechanics in the NAF framework:

Pre-change validation

Before a single line of config is pushed, observability answers:

  • Is the device healthy?
  • Is traffic stable?
  • Are users already experiencing something out of the ordinary?

If anything is off, automation stops. Outage avoided.

Post-change verification

Observability doesn’t just verify if the interface came up. It confirms these key factors:

  • Did BGP converge as expected?
  • Did the path change?
  • Did experience degrade?

Scripts can’t tell you this. Observability can.

Closed-loop automation

This is the real end game:

Drift detection → automated correction → validated outcomes.

You cannot close that loop without granular, trusted, time-series data. Automation isn’t the brain here.

Observability is the nervous system.

3. Stop celebrating “green lights”

Low-maturity teams state:

“Hey, the device is up!”

They then wonder, “Why does automation keep breaking things?”

High-maturity teams (the ones ready for automation) seek to answer this question:

“Is the network behaving exactly as intended?”

To achieve this maturity, traditional SNMP polling and ICMP pings don’t cut it.

CLI scraping doesn’t cut it.

A stack of vendor dashboards doesn’t cut it.

Automation requires clean, structured, and queryable data—the kind your scripts and pipelines can trust.

That means gNMI, streaming telemetry, structured logs, and real experience data.

Here’s the truth: Your network data has to be as API-ready as your automation.

4. The verdict (and it’s a wake-up call)

If you don’t trust your automation, the issue isn’t your code—it’s your visibility.

If your team still debates “why automation keeps breaking things,” it’s because the network is telling you a story you simply can’t hear.

The NAF Framework makes it undeniable:

Automation and observability are not separate domains. They are a shared dependency.

You cannot build a self-driving network if the car can’t see the road.

You cannot scale change when you can’t measure impact.

You cannot “shift left” if your data stays in the dark.

The takeaway

Before you write another playbook, build another pipeline, or stand up another controller, ask yourself this question:

Do I trust my data enough to let a machine act on it?

If the answer is no, you don’t have an automation problem—you have an observability problem.

Build your eyes before you build your hands.

That’s how you evolve from automated chaos to automated confidence.

If you want the link between automation and observability spelled out in architectural form, check out the Network Automation Forum Reference Framework. This resource provides the blueprint for building a network that isn’t just automated—but automated reliably.