{"slug": "selector-brings-git-based-workflows-and-incident-replay-to-network-ai-agents", "title": "Selector brings Git-based workflows and incident replay to network AI agents", "summary": "Selector launched Foundry, a development and runtime environment that lets network operations teams build, test, version, and govern their own AI agents inside the company's NetOps platform. Foundry agents run on Pydantic AI, are committed to customers' own Git repositories for pull-request review, and are replayed against historical incident data before production, with a single-step rollback on failed promotion; guardrails cap cost and token usage and constrain what an agent may conclude. \"The goal is to be completely non-human in the loop, but I don't think that's going to be reality,\" said Nitin Kumar, co-founder and CEO of Selector.", "body_md": "Network operations teams are being asked to hand real decisions to AI agents. Trusting an agent enough [to let it act in production](https://www.networkworld.com/article/4225341/80-of-network-pros-are-ok-with-giving-ai-an-autonomous-role-in-network-operations.html) is a different problem than building one.\n\nSoftware engineering solved a similar trust problem years ago, with version control, code review, and staged rollouts. Selector is applying that same discipline to AI agents in network operations with a new technology called Foundry.\n\nSelector 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](https://www.networkworld.com/article/4174736/selector-targets-the-network-visibility-gap-in-multi-cloud-infrastructure.html).\n\n“We told you what was wrong with the network, we told you how to find the data, we did all of that,” [Nitin Kumar](https://www.linkedin.com/in/nitinnitp/), co-founder and CEO of Selector, told *Network World*. “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.”\n\nFoundry treats an agent the same way a team would treat a piece of software, from framework choice through production rollout.\n\n**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.\n\n**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.\n\n**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.\n\n**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.”\n\nFoundry 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.\n\n“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.”\n\nWhen 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.\n\nWhen 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.\n\nKumar’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.\n\nHe 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.\n\nSelector’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.\n\n“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.”", "url": "https://wpnews.pro/news/selector-brings-git-based-workflows-and-incident-replay-to-network-ai-agents", "canonical_source": "https://www.networkworld.com/article/4225614/selector-brings-git-based-workflows-and-incident-replay-to-network-ai-agents.html", "published_at": "2026-09-23 14:52:45+00:00", "updated_at": "2026-09-23 14:58:00.629523+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "artificial-intelligence"], "entities": ["Selector", "Foundry", "Nitin Kumar", "Pydantic AI", "CrewAI", "AWS", "GCP", "Network World"], "alternates": {"html": "https://wpnews.pro/news/selector-brings-git-based-workflows-and-incident-replay-to-network-ai-agents", "markdown": "https://wpnews.pro/news/selector-brings-git-based-workflows-and-incident-replay-to-network-ai-agents.md", "text": "https://wpnews.pro/news/selector-brings-git-based-workflows-and-incident-replay-to-network-ai-agents.txt", "jsonld": "https://wpnews.pro/news/selector-brings-git-based-workflows-and-incident-replay-to-network-ai-agents.jsonld"}}