What happens when a decision-making agent says no to a network change.
I built a multi-agent system to configure a network. Gave it reasoning models, configuration tools, a testing framework, and a specialized model to decide whether the work should proceed.
Then I hit Run, started recording, and watched Jev reject the result.
Three validation checks had failed. Jev called for rollback. The recovery needed operator attention. That is in the video too.
I could have shown only the successful run. But if we’re going to talk about agents making infrastructure changes, I want to see what happens when the answer is no.
When I worked with Antares, the attraction was a model built for a specific task: finding weaknesses in code. I could put that capability to work alongside other models that fixed the code and reported the result.
Jev got my attention for a similar reason. TypeSafe calls it a System One model. It evaluates state and returns structured decisions with probabilities, rather than generating a conversational answer. That is the part I wanted to test on a network change.
I already had models that could investigate a topology, reason through a configuration, and produce a plan. I wanted a separate evaluation of whether the evidence supported moving forward, whether the proposed change should be approved, and whether the result should be accepted.
Those are different questions. I gave Jev a place at each of those checkpoints.
The lab started with two routers and two switches in Cisco Modeling Labs. Management connectivity worked. There was no BGP overlay, no OSPF underlay, no VLAN setup, and none of the subinterfaces needed for the topology I wanted.
The goal was to build that network, verify it, and report what happened.
Claude Opus coordinated the work. An investigator and planner running Sonnet collected device state and proposed the changes. An executor and validator, also using Sonnet, applied configurations and tested the result. A locally hosted Gemma model handled the final communications.
Jev evaluated the evidence and the work as it moved through that process. It did not write the router configurations. It did not push them. It assessed the inputs I gave it and returned decisions the coordinator could act on.
I also limited the tools before any of this ran. The investigator had show commands. The executor had pyATS configuration capabilities, including configuration diffs.
If the investigator decided it wanted to configure a router, it did not have the tool to do it. That boundary was part of the build.
FlowAI is the agent harness of the Itential Platform. The model registry lets me bring my own models and choose which one each FlowAgent uses based on the job I’m asking it to do. In this build, I used Opus to coordinate, Sonnet to investigate, plan, execute, and validate, and a locally hosted Gemma model to handle communications.
I don’t need the same model doing all of that work. I can match the model to the task, including where it runs and what it costs, while FlowAI provides the tool access, agent coordination, and execution records around it.
Jev adds another specialized capability through MCP: evaluating whether the work should proceed and whether the result should be accepted.
There’s an architectural detail here that I want to be clear about, especially if you watched the Antares walkthrough.
Claude and my local Gemma model were configured through the FlowAI model registry. Gemma ran through Ollama in my local Docker environment. The Claude models were accessed through their cloud service.
Jev took a different path. I wrote a TypeSafe Jev Model Context Protocol (MCP) wrapper and connected it through Itential Gateway. The coordinator called Jev as a tool.
So this build combined registered models with a specialized decision API exposed through MCP. Cloud services, local models, and network tools all had roles in the same operation.
That gives me room to experiment with a new model based on what it actually does and the interface it provides. In this case, I wanted Jev evaluating decisions inside a system I was already building with FlowAI.
The investigator gathered the baseline from all four devices. Jev reviewed the evidence. The planner generated proposed configurations and a verification plan. Jev reviewed those proposals too.
Then the plan came to me in Work Center. I could inspect the commands, the checks we expected to run, and Jev’s assessments before approving execution.
After approval, the executor applied the configurations. It collected fresh device state and ran the tests.
Some early pings failed. Later pings succeeded as the network settled. But the execution result still included three failed checks out of 14, and the coordinator submitted that result to Jev.
Jev rejected it and initiated the rollback path.
The recovery was incomplete and needed operator attention. I’m keeping that distinction in the story because requesting rollback and completing recovery are two separate outcomes. The run did not earn a success label just because it had a rollback plan.
I sent the result back to my build agent and worked through another attempt. This took time. Resetting the lab took time. Reviewing why Jev disliked the evidence took time. You see some of that in the recording.
That is useful information if you’re planning to build one of these yourself.
In the successful human-in-the-loop run, Jev approved the plan after 30 named plan checks passed. Work Center presented the configurations, rollback plan, validation expectations, and the decision scores for review.
That made my job as the network engineer more informed. I could look at what was about to change and how it would be tested, with another assessment already attached.
I approved it. The executor applied the changes across the switches and routers, collected the results, and sent them back for evaluation. Jev accepted the outcome, and Gemma prepared the report.
The confidence scores were useful context. They were not a substitute for checking the commands or a guarantee that a change would succeed. The actual device evidence and test results still mattered.
Next, I reset the environment and launched the other operating mode. This time there was no Work Center approval task waiting for me.
The coordinator called the planner. Jev evaluated the plan. The executor configured and tested the devices. Jev evaluated the results. The reporter closed out the run.
All 30 named plan checks passed. All 15 named result checks passed. The result was accepted, with no rollback required.
Fifteen minutes. Four devices taken from management access to a configured lab with BGP, OSPF, VLANs, subinterfaces, and Layer 2 settings, with testing included.
That is the result of this lab run. It also came after the failed attempt you saw earlier. Both belong in the walkthrough if you want to understand what I built.
The other part I wanted to show was the build process. I used Codex with Itential Builder Skills to describe the system I wanted: the model roles, the gateway tools, the operating modes, and the evidence I expected it to retain.
The brief included preserving management access, freezing the approved commands, verifying results, and creating both a Work Center approval mode and a mode without that human step.
From there, I used Itential’s Spec-Driven Development approach to specify, build, publish, and verify the assets. I read back the definitions and used the execution evidence to work through problems.
The build was agentic, and the system it produced was agentic. I still had engineering work to do: define the requirements, inspect the behavior, and feed failures back into the build.
Right now, the coordinator calls Jev as a tool. A next version could give decision-making its own dedicated agent, with the coordinator handing it evidence and receiving a decision back. I haven’t built that version in this walkthrough, but I want to explore the separation.
For now, the interesting result is already on camera. A specialized decision model participated in a real lab change, rejected an outcome with failed checks, and later accepted successful runs with and without a human approval task.
Watch the walkthrough for the architecture, the device evidence, the Work Center review, and the failure as well as the success.
Then tell me where you would put a decision model in your own operations. Reviewing a proposed change? Evaluating post-checks? Deciding when the work needs a person?
Bring that use case to the VibeOps Forum. I want to see what we can build next.
See how Itential connects AI reasoning to governed execution across your entire infrastructure.