By shifting to an automation model that relies on an authoritative 'network source of truth,' Intel scaled its network, reduced outages, and changed how its engineering teams operate.
At large enterprises with thousands of network devices supporting global operations, network automation is no longer optional.
Early automation efforts at Intel were born out of necessity. A small team at the multinational semiconductor company relied on screen scraping and scripts to keep the network running, but by 2019, that approach had reached its limits. The introduction of a new network platform with APIs marked a turning point—not just technically, but also culturally.
The shift required rethinking how networks were designed, operated, and staffed. At the time, only “one and a half people” were focused on automation, says Greg Botts, a senior network engineer who has spent more than 18 years with Intel. Botts has been instrumental in steering Intel’s automation evolution over the last six years, moving the organization from manual workflows to a data-driven automation model built for resilience and scale.
“Network automation isn’t just about technology,” Botts says. “It’s about scale, standardization, and making the most of limited headcount.”
Open standards and a network source of truth
The pressure to automate intensified as Intel’s network footprint expanded while staffing levels declined. “In 2019, we had 20 network engineers managing just over 3,000 devices,” Botts explains. “By 2025, it was 13 engineers managing 5,500 devices. That shift—you have to automate to keep up.”
Manual configuration efforts couldn’t scale. Standardization became essential not only to support growth but also to reduce operational risk. “Too many devices to copy-paste configs. Automate or die,” Botts says.
After years of maintaining heavily customized vendor tools—and more than 60 supporting servers—Intel reached another inflection point. The cost and technical debt were no longer sustainable.
The team began searching for an off-the-shelf platform built around open standards and centralized management. They ultimately selected the open-source version of Nautobot, created and maintained by Network to Code, to serve as a network source of truth and automation foundation. Migration required scripting and cleanup to transform existing device data into usable, structured network data—but it laid the groundwork for a more disciplined model.
A network source of truth is a centrally located, authoritative repository of operations data that’s been validated and consolidated. It can document network intent and provide programmatic access to data for network automation tools and other systems, according to Enterprise Management Associates (EMA).
“Network automation tools need to reference an authoritative set of network data to make sure that the changes they make reflect what you want the network to look like and do,” said Shamus McGillicuddy, research director for the network management practice at EMA, during a recent webinar.
For Intel, the philosophical shift was as important as the platform choice. “Start with your network data,” Botts says. “Everything else should be a byproduct of the data.”
Instead of updating documentation after changes were made, Intel reversed the process. All changes now begin in the source of truth and are pushed to the network via automation. CLI-driven copy-and-paste workflows are no longer part of normal operations.
Reducing outages by changing the operating model
The results were measurable. Before the shift six years ago, Intel averaged 12 to 15 major incidents per year. Since adopting a data-first automation model, that number has dropped dramatically. In this automation effort, Intel focused on two internal networks: one for design and one for enterprise. “Over the last four years, the chip design data center network had zero major incidents,” Botts says. “The enterprise data center network had one.”
That aligns with what organizations see when automation is anchored in authoritative data, according to EMA’s McGillicuddy. “A network source of truth documents and maintains the intended state of the network,” McGillicuddy said. “With open APIs and an extensible data model, it becomes foundational for automation, validation, and operations.”
Breaking silos and evolving skill sets
Intel’s automation strategy also reshaped the team itself. Rather than hiring a separate group of automation specialists, the company focused on upskilling existing network engineers with increased automation skills. “You don’t need a team of unicorns,” that are skilled in both networking engineering and development, dubbed NetDevOps, Botts says. “We want to organically merge our existing team, and they’re hungry for it.”
Abstraction played a key role. “To the developer, the network is abstracted,” Botts says. “To the network engineer, the development is abstracted.”
The shared data model can also break down organizational silos going forward. Security, WAN, and other teams can now consume the same network data, improving collaboration and consistency across the enterprise network.
Focus, incremental wins, and what’s next
Botts’ advice for other enterprises is practical and pragmatic: Don’t design your network and automation system at the same time. Establish a clear network model first, focus on immediate use cases, and build incrementally. Staffing models must also align with operational goals because implementing automation without adequate support can create new risks.
Looking ahead, Intel is focusing on deeper validation, zero-drift compliance, and AI-assisted operations. “Now that the data is solid,” Botts says, “the table is set for AI to make things even better.”
Intel’s experience underscores a bigger lesson for enterprise IT: Automation done right doesn’t replace expertise, it enhances it. By grounding automation in authoritative data and disciplined processes, network teams can reduce risk, scale operations, and spend more time solving the problems that matter most.
