Network operations teams are being asked to hand real decisions to AI agents. Building an agent that can analyze telemetry is one challenge. Trusting that agent enough to let it act in production is another. That trust gap has slowed adoption of autonomous operations in many enterprises, even as AI models become more capable.
Software engineering addressed a similar trust problem years ago with version control, code review, and staged rollouts. A new set of tools from Selector applies that same discipline to AI agents in network operations. The technology, called Foundry, is a development and runtime environment that lets NetOps teams build, test, version, and govern their own AI agents inside Selector’s platform. Selector develops a NetOps platform that was updated earlier this year to provide a correlated view across branches, colocation facilities, on-premises data centers, and public cloud infrastructure.
“We told you what was wrong with the network, we told you how to find the data, we did all of that,” said the company’s co-founder and CEO. “But what to do, what to fix, how to do the fixing, that was still manual or still built into their playbooks. We believe that’s the next level of simplification we can bring in.”
How the platform works
Foundry treats an agent the same way a team would treat a piece of software, from framework choice through production rollout. That means agents are not opaque prompts hidden in a console. They are versioned assets with review gates, test evidence, and rollback paths.
Framework choice and deterministic design
Foundry agents run on Pydantic AI. The company avoided heavier agent frameworks such as CrewAI in favor of something simpler and more deterministic. Agents are defined as configuration, similar to infrastructure as code, and that configuration drives a common orchestrator with domain-specific code underneath it.
The design choice matters for network operations. Deterministic behavior is easier to audit, reproduce, and explain to change advisory boards. When an agent recommends a routing change or opens a ticket with a cloud provider, engineers need to know why. A configuration-driven agent can be inspected, diffed, and tested in the same way as a Terraform module or a Kubernetes manifest. That aligns with the broader GitOps movement in infrastructure management, where the desired state is stored in Git and automated controllers reconcile drift.
Review and rollback
Customers commit agents to their own Git repository. Changes go through the customer’s existing pull-request workflow. Before an agent reaches production, it is replayed against the customer’s historical incident data and compared against the recorded outcome of each past event. A failed promotion rolls back in a single step.
Incident replay is a particularly important capability. Network teams accumulate years of trouble tickets, postmortems, monitoring alerts, and change records. That data is often used for reporting, but rarely for validating automation. Foundry turns historical incidents into a test suite. If an agent is supposed to detect a circuit degradation, identify the affected provider, and open the right ticket, the replay can show whether it would have done so correctly on past events. If the agent would have misdiagnosed an outage or escalated to the wrong team, the promotion fails.
This approach borrows from software testing and from chaos engineering. It gives network engineers a safe way to evaluate agents against real-world scenarios without waiting for the next production outage. It also creates a feedback loop: as more incidents are recorded, the test suite becomes richer, and teams can measure whether each new agent version improves or regresses.
Guardrails
The company describes two kinds of limits on agent behavior. The first caps cost and token usage, limiting how many model calls an agent can make before it is treated as broken. The second constrains what an agent is allowed to conclude. For example, if an agent is reporting an outage at one cloud provider, it cannot blame a different provider. It cannot hallucinate a cause that contradicts the evidence.
Cost controls are increasingly important as AI agents move from demos to production. An agent that loops through model calls while trying to diagnose a flapping link can burn through a budget quickly. By treating excessive model calls as a failure condition, Foundry forces agents to escalate or stop rather than spin. The conclusion guardrails address a subtler problem: plausible but wrong explanations. In network operations, a wrong root cause can send engineers down the wrong path for hours. Constraining the space of allowed conclusions reduces that risk.
Autonomy
The company says full automation is the goal, but it does not expect that to be the reality yet. “The goal is to be completely non-human in the loop, but I don’t think that’s going to be reality,” the CEO said. “You will get to a state where things will just happen automatically, but it will be a very asymptotic conversion.”
That asymptotic path is familiar from other areas of operations. Teams often start with AI-assisted recommendations, then move to human-approved actions, then to automatic actions for low-risk scenarios. Each stage requires evidence that the agent is reliable. Foundry’s Git-based promotion process is designed to provide that evidence. It does not require a leap of faith; it requires a series of successful replays and controlled production rollouts.
The workflows agents handle
Foundry agents are built around infrastructure support workflows. Handling one today means working through several sequential steps by hand, waiting for each one to finish, and then closing or opening a ticket depending on the outcome. That is work the company describes as manual until now.
“If something happens, you need to be able to check if the underlying provider has maintenance going on,” the CEO explained. “If it’s not maintenance, you need to be able to file a ticket for the provider.”
When a cloud outage hits, an agent first has to determine whether the problem is real—for example, whether a cloud provider is actually down or the connection itself is fine. “This ability to troubleshoot an outage and what could be done, that’s the most common workflow that we expect,” the CEO said.
When an outage happens, an agent activates on its own and issues a plan of execution, followed by periodic status updates while the outage is ongoing. That plan might include checking provider status pages, querying internal telemetry, correlating alerts across regions, and opening or updating a ticket. The agent does not simply answer a question; it runs a process. In network operations, process discipline is often more valuable than raw model intelligence.
Consider a typical multi-cloud incident. An application team reports latency. The network team sees packet loss on a connection to a public cloud region. The cloud provider’s status page may or may not show an issue. An agent can check maintenance windows, compare latency baselines, inspect border gateway protocol metrics, and determine whether the problem is inside the provider’s network, in the enterprise’s own edge, or in the path between them. If the provider is at fault, the agent can open a support ticket with the right severity and include the evidence. If the problem is internal, it can route the incident to the appropriate team. That sequence is repetitive and time-sensitive, which makes it a good fit for automation.
What’s next
The company’s own answer for what comes next centers on agent interoperability. It expects that Selector will not be the only platform agents run on, and that the industry needs standard protocols, such as MCP and A2A, before agents built on different platforms can work with each other.
Interoperability is becoming a central theme in enterprise AI. Network operations teams rarely buy a single platform for everything. They have monitoring tools, ticketing systems, configuration management databases, observability pipelines, and cloud provider consoles. Agents that can communicate across platforms could coordinate handoffs and share context. Without standard protocols, each integration becomes a custom project. MCP and A2A are early attempts to define those protocols, and their adoption will determine how quickly multi-agent workflows become practical.
The company also points to an expansion already underway into monitoring neoclouds, building on a cloud product it recently launched to compete with established observability vendors. Existing data center monitoring tooling is not sufficient as that infrastructure gets built out, and the company expects to have customer results to share within six months.
Neoclouds—specialized cloud providers focused on AI training and inference—present new monitoring challenges. They often combine dense GPU compute, high-speed interconnects, and non-traditional cooling and power designs. Traditional data center monitoring tools may not capture the relevant metrics or may not scale to the pace at which these facilities are built. If agents are going to manage network operations in these environments, they will need data models and integrations that reflect how neoclouds actually work.
Selector’s main point of difference against established rivals, according to the CEO, is that customers can build their own agents instead of working from a fixed set the vendor provides.
“We called it Foundry for a specific reason: You can create things on your own because your data is yours, your workflows are yours,” the CEO said. “We can only guess what your workflows are, what you want to be doing, and we don’t want to curtail your innovation. We don’t want to artificially bound what you want to do.”
That philosophy reflects a broader tension in enterprise software. Vendors can package best practices into prebuilt agents, which are fast to deploy but may not match an organization’s processes. Or they can provide a platform for customers to build their own agents, which offers flexibility but requires more internal expertise. Foundry is a bet that network operations teams want the latter, especially for high-stakes workflows where the cost of a wrong action is measured in downtime and customer impact.
The Git-based workflow is central to that bet. It meets engineers where they already work. It uses pull requests, code review, and version history. It treats agents as infrastructure, not as magic. And it uses incident replay to answer the question that matters most: would this agent have made the right call last time? If the answer is yes across enough historical events, the agent earns the right to act in production.
For now, the company is positioning Foundry as a way to move beyond manual playbooks without abandoning governance. The next phase will depend on how quickly standard protocols mature, how well neocloud monitoring is built out, and whether customers can generate enough clean historical data to make incident replay meaningful. The platform’s success will be measured not by how many agents a team can create, but by how many it can safely promote.
Source:Network World News