Blog

Companies want agents doing real work on their networks. They also know what a bad network change can cost. Before they hand over control, they need confidence that the work is right, that it follows their operating rules, and that they can verify the outcome.
Gluware’s Agentic Framework is built to earn that trust in stages. In July, agents started with the safest job: helping engineers build automation. Today, they move onto the live network, assessing real exposure without changing anything and fixing what they find when customers are ready. And for the first time, customers can build agents of their own. Every step rests on the same foundation, Proof of Agentic Trust, so the confidence earned at one step carries into the next.

In April, NIST changed how the National Vulnerability Database works. It now enriches only CVEs in CISA’s Known Exploited Vulnerabilities catalog, CVEs that affect federal government software, and CVEs in critical software as defined under Executive Order 14028. Everything else is marked “Lowest Priority” and is not scheduled for enrichment, including the backlog from before March 1. NIST cites volume as the reason, since submissions grew 263% between 2020 and 2025.

Every hospital security team knows the number by heart: thousands of connected medical devices, running dozens of different operating systems and firmware versions, many of them impossible to take offline without disrupting patient care. Internet of Medical Things (IoMT) devices, including infusion pumps, imaging systems, patient monitors, and the workstations that run them, have become one of the largest and least visible attack surfaces in healthcare. Unlike a laptop or a server, you can’t just push a patch to a ventilator and hope for the best.

Titan AI is Gluware’s agentic capability for network automation, helping engineers automate more accurately and extending that skill beyond a small circle of experts. It runs on Gluware’s Proof of Agentic Trust framework, pairing agentic reasoning with independent, deterministic validation so outcomes are accurate, not just plausible. We spoke with a network leader at a large enterprise that operates in a regulated industry, about how his team uses it.

Network automation has traditionally been built from the bottom up. An engineer finds a
repetitive task, writes a script or playbook to automate it, and then moves on to the next
opportunity. As the practice matures, individual scripts become workflows, workflows become
platforms, and more of the network comes under automation

For more than twenty years, the networking industry has expected network automation to
become mainstream.
The technology has advanced steadily, commercial platforms have matured, APIs are more
common. Open source has lowered the barrier to getting started, and AI is generating even
greater interest in automating network operations

For years, network patching has lived in the background. Security teams published advisories. Infrastructure teams scheduled maintenance windows. Some organizations stayed reasonably current. Many did not. Most accepted a certain amount of risk because the volume of patches was manageable and the operational cost of deploying them across large brownfield networks was enormous.

If you have ever seen a network organization with an SD-WAN controller running one part of the network, an intent platform in another, Ansible playbooks for a few workflows, and a great deal of CLI and ad-hoc scripting in between, you are not looking at an anomalous automation situation.

You are looking at the mainstream enterprise network.

Network automation built around intent, where the network is managed through policy rather than manual device-by-device instructions, is recognized as “the way to do automation” for any modern IT organization.

But how you get there depends entirely on where you start. And the two starting points are so different that they define almost everything about how hard the journey is, how long it takes, and what it costs.