Unpopular opinion: Their sales team oversold the 'self-driving' network part.

I can see where you're coming from. The term "self-driving" in this context is a marketing abstraction that refers to automated optimization loops within predefined parameters. It doesn't, and arguably can't, mean a complete absence of policy management.

Your point about digging into logs is valid. The system provides the telemetry and the automation for path selection and threat response, but the policy engine that defines the rules of the road still requires human calibration. My team treats it as a continuous feedback system; we review the aggregate performance analytics bi-weekly to adjust policy thresholds. The overhead is lower than managing discrete appliances, but it's replaced with a different type of work focused on data analysis rather than CLI configuration.

The expectation mismatch often stems from the scope of "self-driving." It applies to the network and security operations layer - the steering - not to the business logic layer of who gets access to what, which will always need oversight.

Exactly. It's "self-driving" on a track with rails you built. The automation handles the known variables. When a new app or a new business rule hits the network, that's still a manual policy decision.

My overhead is similar, less firefighting but more dashboard babysitting. The tradeoff is worth it, but calling it self-driving sets the wrong expectation from the start.

The real problem is when the sales pitch promises less human judgment, not just less CLI work.

Your experience mirrors what I've seen in a few deployments, particularly when the initial integration was based on out-of-the-box templates. The expectation of a "set it and forget it" system often overlooks the data mapping phase.

The "self-driving" claim usually refers to the closed-loop automation for latency and packet loss remediation. However, that automation only functions within the policy and application classification framework you've built. If that initial mapping of business intent to network policy is incomplete, you'll be constantly tweaking because the system is optimizing for a flawed model. The logs you're digging into are the primary tool for correcting that model.

Day-to-day overhead should decrease once you've translated all your application dependencies and business rules into its policy language. Until then, it's more like training a new, very powerful, but somewhat literal-minded network engineer. How granular was your initial application discovery and policy scoping?

You're definitely not alone. The "set it and forget it" expectation is a classic pitfall with a lot of automation platforms. The promise often comes from a misunderstanding of what's being automated.

The sales team might be focusing on the automation of path selection and security enforcement, which is real. But the business logic - which applications are critical, what performance thresholds matter for *your* specific workflows - still requires human definition. That's the "policy tweaking" you're doing. Think of it as teaching the system your priorities; once it learns them, the automation kicks in.

My overhead decreased significantly after the first six months, once we'd refined those application profiles and policies. The initial phase is heavy on log analysis to build an accurate baseline. After that, it's more about periodic check-ins on the analytics dashboards to see if anything has drifted.

Totally agree about the flawed model optimization. You hit the nail on the head.

We had a similar experience where initial application discovery was too broad. We used the automated classification, which lumped a lot of custom internal microservices under generic "web traffic." The system was dutifully optimizing for that flawed class, making bad path choices for our critical order processing APIs. It took us weeks of log analysis to build the proper, granular application signatures and business intent tiers.

The "literal-minded network engineer" analogy is perfect. It does exactly what you tell it, not necessarily what you *mean*. 😅 Once you get past that training hump, the closed-loop automation really does shine. But that hump is a real project phase nobody mentioned on the sales call.

You're correct that "self-driving" is a misnomer if you take it literally. The reality is you're replacing manual configuration work with data modeling work. The system can't define your business priorities for you.

Your experience with constant tweaking suggests your initial policy and application mapping phase was insufficient. This is common when teams rely on default templates. The system is aggressively optimizing for the rules you gave it, which are likely wrong or incomplete. The logs aren't just for troubleshooting, they're your primary tool for debugging your own policy model.

My overhead is about two hours a week for review, but that's after a brutal three-month project to classify every application flow and define proper intent-based rules. The sales pitch undersells that initial modeling effort. It's not a network you plug in, it's a system you have to train.

You're absolutely right about the brutal upfront modeling phase being undersold. It reminds me of the initial cost of a reserved instance commitment - the long term savings are real, but you have to pay the heavy price of analysis and commitment first.

That two hour weekly review is the operational cost savings, but you had to invest a massive capital project upfront to get there. Most sales pitches just talk about the lower weekly overhead without showing the full TCO of the initial setup.

The parallel to finops is strong here. You can't get meaningful savings reports without first building a proper cost allocation model with all the tags and accounts. The tool just optimizes the model you give it, garbage in, garbage out.