From Raspberry Pi agents to AI-assisted network operations, every generation of NetBeez has followed the same principle: if you want to understand network experience, you have to measure it from where users connect.
In 2013, we did not believe network teams needed another tool collecting data from routers and switches.
There were already plenty of those.
What we believed was missing was the user’s perspective.
We saw the gap every time we had to troubleshoot a user complaint or a major network meltdown. The infrastructure tools could tell us that devices were reachable, interfaces were up, and circuits were not saturated. But they could not always tell us whether users could reach the applications they needed or where along the path their experience had started to degrade.
We believed network monitoring needed continuous, end-to-end synthetic testing from multiple observation points. Instead of waiting for somebody to report a problem, small agents placed throughout the network would continuously test the services users depended on.
The idea was straightforward. Deploying it was not.
The Raspberry Pi made the original NetBeez possible
To measure the network from remote offices, we needed to place monitoring agents at those locations.
Today, running software at a branch may not sound unusual. In 2013, however, many remote sites had limited or no virtualization infrastructure. Shipping and maintaining traditional appliances everywhere would have made broad deployment expensive and difficult.
Fortunately, another technology had arrived at exactly the right time. The Raspberry Pi had launched one year earlier, providing a small, inexpensive, and capable single-board computer.
That platform made our idea practical. We could deploy monitoring agents across distributed networks without requiring a server or a traditional appliance at every site.
That became the foundation of NetBeez: simple agents continuously measuring network and application performance from where users were actually working.
The architecture helped network engineers detect problems earlier, preserve evidence about intermittent issues, and troubleshoot with more than a user saying, “The network is slow.”
The Beez needed antennas
As NetBeez deployments grew, customers kept bringing us another difficult problem: Wi-Fi.
Traditional infrastructure monitoring could report that an access point was online, but that did not necessarily describe the experience of a connected client. Signal strength, interference, roaming, channel conditions, and the specific access point selected by a client could all affect performance.
In 2015, we introduced Wi-Fi sensors that connected to the wireless network like any other client and continuously measured the experience from that perspective.
The Beez needed antennas, after all.
This was the same original idea applied to a new observation point. If the problem affects the client, measure from the client’s side.
Then the network moved into people’s homes
The shift to remote work changed the boundaries of the enterprise network.
The office, branch, data center, and cloud still mattered, but the employee’s home Wi-Fi, local internet connection, VPN path, and endpoint became equally important to their ability to work.
We responded by developing Remote Worker Agents for Windows and macOS. These software clients extended continuous testing to employees’ systems and gave IT teams historical evidence about conditions they could not see from inside the corporate network.
But this shift changed more than where NetBeez agents ran. It changed who used the platform and what they needed from it.
NetBeez was no longer used only by network engineers investigating difficult problems. Large service desks and network operations teams began using it to support remote users at scale.
An experienced engineer may be comfortable reviewing individual tests, network paths, interface events, and detailed timelines. An L1 help desk analyst needs a faster answer to a more immediate question: is this likely to be the user’s Wi-Fi, local internet connection, VPN, network path, or application?
Network managers had different needs again. They wanted to understand recurring degradation, compare experience across locations and services, validate whether network changes worked, and communicate improvement over time.
The underlying measurements were still essential, but presenting more data was no longer enough.
Why we decided to rebuild NetBeez
Two years ago, we decided to build the next generation of NetBeez.
We knew this could not be just a new interface placed on top of the existing product. We rebuilt the platform from the backend to the frontend because the job itself had changed.
The original NetBeez helped engineers collect evidence and troubleshoot from the user’s perspective. The next generation also needed to help broader IT teams decide what deserved attention, determine the likely fault domain, coordinate the next action, and verify that the experience improved.
That led us to a simple operating model:
- Detect what needs attention.
- Isolate the likely fault domain.
- Take action.
- Prove that the experience improved.
The new Buzz tab experience reflects that change. Instead of requiring the operator to begin with a long list of tests or agents, it brings together signals from network agents, remote-worker agents, Wi-Fi sensors, targets, tests, and events.
The objective is to show where experience is degrading, how broad the impact appears to be, and where the investigation should begin. Engineers can then move directly into the detailed evidence behind the signal.
This does not mean placing an automatic “root cause” label on every incident. Networks are rarely that simple. It means helping the team narrow the problem and start closer to the likely source.
AI arrived while we were building
During this work, another major technological change took place: the rapid adoption of generative AI.
NetBeez agents generate a large amount of data across offices, remote workers, Wi-Fi networks, VPNs, internet connections, and applications. AI created an opportunity to make that evidence easier for different teams to use.
For an L1 analyst, AI can help investigate a support ticket and prepare a concise, evidence-based summary for escalation or resolution. For an engineer, it can reduce the time spent finding and organizing relevant measurements. It can also make operational tasks, such as creating a monitoring target or tuning alert profiles, accessible through a conversational interface.
But AI should not hide the evidence or turn network operations into a black box.
The tests, events, paths, and timelines still matter. AI should help operators reach and communicate that evidence faster, not ask them to trust an unexplained answer.
What we will demonstrate on October 7
Networking Field Day 41 takes place from October 6 through October 9. NetBeez will present on October 7 from 11:00 a.m. to 12:00 p.m. Pacific Time.
We first presented at Networking Field Day in 2015, and we have returned many times since. It is a fitting place to show how the original idea behind NetBeez has evolved.
During the one-hour presentation, we will demonstrate how the new platform supports the complete workflow.
We will start with Buzz and show how an operator can identify a shared problem rather than investigating users one by one. One scenario will follow remote users experiencing degradation when accessing private applications through a common VPN path.
Another will show a Wi-Fi access point becoming unavailable, forcing a sensor to roam to a more distant access point with a weaker signal. The network remains technically available, but the user experience, such as voice-call quality, degrades. NetBeez will correlate the access-point change, weaker Wi-Fi conditions, and the resulting performance problem.
We will then use AI to investigate the same evidence from the perspective of an L1 operator, prepare a ticket-ready summary, create a monitoring target, and tune alert profiles. We will also show Ad Hoc diagnostics and new ways to work with NetBeez through AI and MCP.
The observation points remain at the center of the platform. What has changed is how the evidence is organized and used.
NetBeez began as a way to help network engineers see what traditional infrastructure monitoring missed. The next generation extends that idea into a platform that service desks, network operations teams, engineers, managers, and IT leaders can use every day, not only after the network is already on fire.
October 7 is the public reveal, ahead of our planned general availability on November 9.
Watch the NetBeez presentation at Networking Field Day 41.
If you want to see how the next generation of NetBeez applies to your own network and users, request an early product tour.
