Network AI Agents Face a Trust Gap
Network operations teams are being asked to hand real decisions to AI agents. The challenge is not building an agent that can answer questions or generate a plausible diagnosis. The harder problem is trusting an agent enough to let it act in production. That distinction is becoming central as enterprises move from AI pilots to operational deployment. Software engineering solved a similar trust problem years ago with version control, code review, staged rollouts, and rollback mechanisms. Those practices allowed teams to change code quickly without risking the entire system. Now Selector is applying that same discipline to AI agents in network operations with a new technology called Foundry.
What Selector Foundry Does
Selector Foundry is a development and runtime environment that lets network operations teams build, test, version, and govern their own AI agents inside the company'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. The goal is to extend that visibility into action. Instead of stopping at telling operators what is wrong and where to find data, Foundry aims to help them decide what to do, what to fix, and how to fix it.
Nitin Kumar, co-founder and CEO of Selector, explained the gap. “We told you what was wrong with the network, we told you how to find the data, we did all of that,” Kumar said. “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 approach affects several layers of the agent lifecycle.
Framework
Foundry agents run on Pydantic AI. Kumar said Selector 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 choice reflects a broader preference for predictability in network operations, where nondeterministic behavior can be costly and difficult to audit.
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. This incident replay is a key differentiator. It gives teams evidence that an agent would have handled past incidents correctly before it is allowed to handle live ones. It also creates a feedback loop: as incident data grows, the test set becomes richer and more representative of production conditions.
Guardrails
Kumar described 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. “If you’re reporting an AWS outage, you cannot blame a GCP. You cannot hallucinate and do that,” Kumar said. The first guardrail is operational and financial: it prevents runaway agents from burning through API budgets or creating loops. The second is epistemic: it prevents agents from making claims that are inconsistent with the available evidence. Together they define a safe operating envelope for agents that are still learning to act in complex environments.
Autonomy
Kumar said full automation is the goal. He does not expect that to be the reality, at least not yet. “The goal is to be completely non-human in the loop, but I don’t think that’s going to be reality,” Kumar said. “You will get to a state where things will just happen automatically, but it will be a very asymptotic conversion.” That view is pragmatic. Network operations involve high-stakes decisions, legacy systems, and regulatory constraints. Even when agents can act, teams may want approval gates, audit trails, and the ability to intervene. Foundry’s design supports that gradual transition rather than forcing a binary choice between manual work and full autonomy.
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’s work Kumar described as manual until now.
“If something happens, you need to be able to check if the underlying provider has maintenance going on,” Kumar 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 such as AWS 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,” Kumar 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 sequence may sound simple, but it involves multiple systems, tickets, providers, and timelines. An agent must correlate signals, distinguish between provider-side and customer-side faults, check maintenance windows, escalate appropriately, and keep stakeholders informed. Doing that manually is time-consuming and error-prone. Doing it automatically requires more than a large language model; it requires orchestration, domain-specific code, and guardrails that keep the agent on track.
Why Git-Based Workflows Matter for Agents
Version control is not just a developer convenience. For AI agents, it provides accountability. When an agent’s configuration is stored in Git, every change has an author, a timestamp, and a reason. Pull requests create a review checkpoint. Rollbacks provide a safety net. This is especially important in network operations, where a single misconfiguration can cascade across services. By treating agents as code, Foundry allows existing engineering practices to apply to AI behavior. Teams can diff changes, discuss them, test them, and promote them. They can also maintain separate environments for development, testing, and production.
Incident replay adds another layer. Instead of relying on synthetic tests or hypothetical scenarios, teams can evaluate an agent against real incidents that already occurred. If an agent would have made the wrong call during a past outage, that failure is caught before the agent is promoted. If it would have made the right call, that success is documented. Over time, the historical incident set becomes a regression suite for agent behavior. This is a practical way to build trust without waiting for live failures.
Guardrails Beyond Cost Control
The guardrails described by Kumar address two common fears about AI agents. The first fear is that agents will consume too many resources. Token limits and cost caps prevent an agent from spiraling into endless model calls. The second fear is that agents will hallucinate or make illogical claims. Constraining what an agent is allowed to conclude reduces that risk. For example, an agent should not attribute an AWS outage to GCP. That kind of error erodes trust and can send operators down the wrong path. By defining boundaries around conclusions, Foundry keeps agents useful without letting them become unreliable narrators.
These guardrails also make agents easier to audit. If an agent is limited to certain conclusions, its reasoning can be checked against those limits. If it exceeds cost thresholds, it can be stopped and inspected. This is similar to how production systems use circuit breakers, rate limits, and validation rules. Applying those patterns to AI agents is a natural evolution.
Interoperability and What Comes Next
Kumar’s own answer for what comes next centers on agent interoperability. He said 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. That is a significant point. Enterprises rarely standardize on a single vendor. If agents are locked into one platform, their usefulness is limited. Standards for agent-to-agent communication and tool access could allow agents from different systems to collaborate, hand off tasks, and share context. MCP, or Model Context Protocol, and A2A, or Agent-to-Agent, are early efforts in that direction.
He also pointed to an expansion already underway into monitoring neoclouds, building on a cloud product Selector recently launched to compete with vendors such as Datadog. Kumar said existing data center monitoring tooling is not sufficient as that infrastructure gets built out, and he expects to have customer results to share within six months. Neoclouds are specialized cloud providers designed for AI workloads, often with high-performance GPUs and specialized networking. Monitoring them requires visibility into new layers of infrastructure, including GPU clusters, interconnects, and orchestration systems. Foundry agents could play a role in diagnosing issues across those environments.
Competitive Differentiation
Selector’s main point of difference against established rivals, Kumar said, 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,” Kumar 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 trend in enterprise AI. Vendors are moving from packaged AI features to platforms that let customers build and customize agents. The challenge is balancing flexibility with safety. Foundry attempts to do that by combining Git-based workflows, incident replay, guardrails, and a configuration-driven architecture. Whether that combination is enough to earn trust in production will depend on customer results, especially in complex outage scenarios where the cost of failure is high.
For network operations teams, the appeal is clear: agents that can act, but under controls that resemble the ones used for software. The promise is not just automation, but governed automation. The next phase will test whether that promise holds up when real incidents occur, when providers fail, and when the network does something no one expected.
Source: Network World News