Introduction
Unplanned network downtime now costs the average enterprise $14,056 per minute.
If you run a large-enterprise environment, that number is even higher: $23,750 per minute (BigPanda/EMA, 2024). Most network leaders already know the number. What fewer know is where the minutes actually go.
EMA asked network operations teams what contributes most to MTTR in Network Management Megatrends 2024. The answer was surprising, as it had nothing to do with tooling gaps or monitoring coverage. It was team engagement, communication, and collaboration.
The biggest cost driver? The part no one has automated.
A 3 AM BGP reset that your Day Two team picks up, diagnoses, and escalates to Day One because the fix requires a change window. Day One escalates to Day Zero at the ninety-minute mark because the root cause is architectural. Three teams. Three context transfers. The incident resolves at hour four.
If we get all the right teams to talk, we can figure it out within an hour or two. The problem is finding the schedules [across] different time zones… It can take us a week to go back and forth between everybody.
— IT Manager, Global Technology Manufacturer
Nobody told your Day Two team their job description changed. But it did. The question is what your Day Two team is for now, and whether your org structure reflects the answer.
SECTION 1
The Day Zero, Day One, Day Two Model Today
Most enterprise network organizations already describe their teams in these terms.
- Day Zero: Designs the network. The architects who define topology, set policy, and establish design intent.
- Day One: Implements the changes. The engineers who execute change windows, deploy new services, push configurations.
- Day Two: Runs the environment. The team that monitors, diagnoses, and responds.
This model, rooted in Cisco’s NSO work and now standard shorthand across enterprise networking, describes how the work is divided. Cisco’s NSO defined those stages by what happens to a device — provisioning, activation, steady-state operations. This piece applies the same framework to what happens to the team. But the work itself is changing.
When an Agentic NetOps platform enters the environment, the division of labor holds. Day Zero still designs, Day One still changes, Day Two still operates. But what each team is designing, changing, and operating is fundamentally different. That difference is what this piece is about.
SECTION 2
Day Two: From Firefighters to Operators
Day Two’s identity is built around response. The best Day Two engineers are the ones who get to the incident fastest, who have seen enough patterns to diagnose in minutes, who can hold the context of a complex environment in their heads at 3 AM. That identity — responder, firefighter, the person whose number you call — is what the team has been hired for, measured against, and recognized for.
It’s also the identity that Agentic NetOps is reassigning.
Our routing has gotten exponentially more complex… the troubleshooting aspect has gotten out of hand.
— Automation Engineer, Large Insurance Group
The complexity grows. The monitoring tells you what broke, not why.
Right now we have SolarWinds… it tells you what went down but doesn’t necessarily tell you why this connectivity failed.
— Sr. Network Engineer, Large Health System
The reallocation of time is measurable. At one large North American utility:
58%
of network tickets automated
17,000
engineer hours reclaimed annually
Some organizations look at these numbers and see a headcount argument. That’s the wrong read. Some agentic NOC frameworks describe the end state as a ‘NOCless’ or ‘dark NOC,’ an environment where manual intervention is minimized or eliminated. That is not the transformation this piece is describing, and it’s not what the data from mature Agentic NetOps deployments actually shows.
Gartner’s 2026 research tells the story directly: the organizations that improve ROI from agentic AI are amplifying people, not replacing them. They’re investing in the skills, roles, and operating models that allow humans to guide and scale autonomous systems.
So what are the utility’s Day Two engineers doing with those 17,000 hours? The time concentrates in three areas.
1. Operational Validation
The platform resolves the known incident. The Day Two engineer reviews the resolution log to confirm the platform’s reasoning was sound, catch the edge case it missed, and decide whether the resolution pattern should be codified or flagged for review. The work requires understanding the platform’s logic well enough to know when it’s wrong.
2. Pattern Identification
The incidents the platform cannot resolve automatically are, by definition, the novel ones. Day Two engineers now spend their analytical time on genuinely new problems. Failures that do not match known patterns, configurations that expose architectural assumptions no one has tested, behaviors that require experienced judgment rather than runbook execution. The platform filters out the noise. What remains is the interesting work.
3. Knowledge Codification
When a Day Two engineer solves a novel incident, that resolution does not disappear into a Confluence page that no one reads. In a mature Agentic NetOps environment, that resolution becomes a new pattern the platform can recognize and act on. Day Two engineers are increasingly the people who teach the platform what it does not yet know. That is a different kind of expertise than the one on the job description. And it’s more valuable, not less.
I’d rather not want anyone from the network team to actually [intervene]. They should be there if something goes wrong — but instead of dozens of people, I’m okay with two or three very senior engineers and the tools doing everything.
— CTO, Municipal Technology Organization
That is not a smaller team — it is a different kind of team, one where senior engineers set the boundaries the tools operate within.
The friction point in this transformation is real: Day Two teams aren’t being told any of this. Their on-call schedules still describe firefighters. Their KPIs still count tickets resolved per shift. Their managers still present them to the organization as the team that handles incidents. None of those descriptions are wrong yet. But they will be. The organizational model is changing faster than the org chart.
There’s a gap between what the team is actually doing in a mature deployment and what the organization thinks it’s for. And that’s where the transformation either succeeds or stalls.
SECTION 3
Day One: From Change Executors to Change Architects
The Day One team’s operating model is also changing faster than the organization’s understanding of what Day One does. Nobody is announcing this, either.
On the surface, the changes still happen. Change windows still run. Day One engineers still push configurations, deploy services, and validate that the environment reflects what it’s supposed to reflect. The work looks the same from the outside. What has changed is the nature of the question Day One has to answer.
Before Agentic NetOps: ‘Did the change succeed?’ After: ‘Does the change intent exist in the platform, and will the platform enforce it?’ That’s a different question that requires different thinking.
Consider what this looks like in practice. A change window that used to require three engineers coordinating in real time, each holding a piece of context the others need, now runs with platform validation built in. The Day One engineer designed the intent. The platform executed it. The change succeeded because the platform knew exactly what ‘success’ meant before the window opened.
At a major North American financial institution, that shift produced a 100% change success rate.
The number matters less than the mechanism: when the platform knows the intent, it enforces the intent. Day One’s job is to make sure the platform knows.
Configuration and change management failure is the cause of 45% of networking and connectivity outages (Uptime Institute, 2023). When change intent only lives in someone’s head, changes fail. The Day One transformation moves from change execution to change architecture: designing intent into the platform before the window, rather than carrying it in memory through it.
Identical expertise. New application.
Day One engineers who used to hold the full context of a change in their heads are now encoding that context in a form the platform can act on at 3 AM without a phone call. That is a higher-leverage version of the same skill. But the org chart hasn’t caught up to it yet.
SECTION 4
Day Zero: From Architects to Platform Stewards
Day Zero’s transformation is the quietest of the three.
Which also makes it the most easily overlooked until it’s too late.
Day Zero architects have always held knowledge that doesn’t fit in documentation. The design decisions live in the heads of three or four people who have been with the organization long enough to remember:
Why this topology?
Why this routing policy?
What the intent was when this BGP community was defined?
We’re also looking for a better way to store our tribal knowledge, like a knowledge repository.
— Director of IT Enterprise Operations, Large Health System
When those people leave, the knowledge leaves with them. The network continues to operate according to decisions no one can explain.
Agentic NetOps changes where the knowledge lives.
In a mature deployment, the digital twin acts as a repository of design intent, not just a network map. The decisions Day Zero made, encoded in a form the platform can act on. That encoding is Day Zero’s new primary output: the platform’s full understanding of the design.
A BGP community definition that used to exist in a lead architect’s mental model — ‘this community signals transit traffic for this peering relationship, don’t touch it during maintenance windows’ — now lives in the digital twin, where the platform can enforce it automatically and the next engineer who joins the team can read it. Tribal knowledge becomes operational context.
We’re trying to take out the intellectual property [locked in our senior engineers] so the team can start seeing and figuring it out for themselves.
— Sr. Infrastructure Engineer, Community Bank
Gartner’s 2026 I&O research frames this shift clearly: the role of infrastructure and operations teams is moving from ‘operators who do tasks’ to ‘leaders who supervise systems.’
For Day Zero, that means the platform stewardship role is not a lesser version of network architecture. It is the version that scales.
Day Zero engineers are now responsible for keeping the platform’s context layer current. They ensure that, as the network changes, the intent encoded in the digital twin reflects the intent in the architects’ heads. When the platform makes a decision at 3 AM, it applies that encoded context. Day Zero owns the accuracy of that context, building a scalable network architecture.
Together, the three arcs are interdependent.
Day Zero encodes the design intent.
Day One architects changes against that intent.
Day Two validates that the platform’s execution matches it.
You cannot transform Day Two in isolation without changing what Day One escalates to them or what Day Zero has encoded for the platform to act on.
SECTION 5
The Coordination Dividend
Let’s revisit the 3 AM BGP reset from the beginning of the piece with a mature Agentic NetOps platform in place.
The platform detects the route advertisement anomaly at 2:47 AM. Within sixty seconds, it has pulled the service path map, run the diagnostic suite, and matched the failure pattern to a resolution it has executed before. That happens before the page has been generated, before the on-call schedule has been consulted, before anyone has even opened a laptop.
The fix runs at the 3-minute mark. The link restores. The log is written.
At 8:15 AM, the Day Two engineer reviews the overnight log. She sees the resolution and checks the platform’s reasoning. She notices something: a related configuration drift on an adjacent device that the platform flagged but did not automatically resolve. It was correct to do so, because it falls outside the boundary the team set for autonomous action. She escalates that one finding to Day One. That is this week’s change.
Day One never received an escalation at 3 AM. The change they process in the morning is proactive architecture, not emergency remediation. Day Zero’s design intent, encoded in the platform three months ago during a routine update session, is doing exactly what it was designed to do.
This is what the coordination dividend looks like in practice. What a large North American utility’s environment looks like today. The incident that used to cost four hours and three teams now costs three minutes and a morning review. With this new organizational model, the coordination tax is paid once at design time, not charged again at every incident.
SECTION 6
Five Questions Your Org Should Be Able to Answer
Most network organizations are somewhere in the midst of the transition. Few have completed it. Here are five questions that reveal exactly where you are and where the gaps are. This can shape the conversation that needs to happen with your team leads before the platform goes live.
1. Can your Day Two engineers describe what they do differently than they did eighteen months ago?
If the honest answer is ‘not much,’ the platform has been deployed but the operating model has not been redesigned. Your Day Two team is running the same incident response process alongside the platform manually, rather than through it. The platform runs. The team keeps running the same playbook. The ROI never materializes — not because the technology failed, but because the operating model didn’t change around it.
2. Does your Day One team’s change process include a step for encoding change intent in the platform — before the change window opens?
Does change management end with ‘did the change succeed?’ rather than ‘does the platform know what we intended?’ If so, the Day One transformation hasn’t started yet. The platform is executing changes, not learning from them. The 45% of networking outages caused by configuration and change management failure (Uptime Institute, 2023) happen in environments where change intent lives in someone’s head rather than somewhere the platform can enforce it.
3. When a Day Zero architect makes a design decision, where does that decision live?
In Most Orgs
With a Mature
Agentic NetOps Platform
- In a Visio file
- In a Confluence page
- In someone’s head
- In a digital twin
The answers on the left describe an organization where the platform’s context layer is outdated the moment it is documented. The answer on the right defines what platform stewardship looks like. It requires a new habit from your architects and a clear assignment of ownership. Neither happens automatically when the platform is deployed.
SECTION 7
Conclusion
How does your team’s Day Zero / Day One / Day Two structure map to the Agentic NetOps transformation?
Request a complimentary Agentic NetOps Adoption Readiness Assessment — a structured 30-minute conversation with a NetBrain architect that maps your team’s current operating model to the Day Zero / Day One / Day Two framework.