From Intent to Infrastructure: The Case for Agentic Operations with a Deterministic Floor

Every few months the network automation community finds a new way to have the same argument: are AI agents the future, or are deterministic workflows still the right answer? Teams pick sides. Vendors pick sides. The debate generates heat and not much else.

The organizations actually moving fast on this aren’t having that debate. They’ve stopped treating agentic and deterministic as competing philosophies and started treating them as two deployment options inside the same platform – each with a clear use case, with a governed path between them.

That’s the architecture FlowAI is built around. The choice between agentic and deterministic shouldn’t be made once, at the platform level, for everything. It should be made per use case, by the team closest to the problem, with the tools to execute either way.

That’s what this post is about.

The Problem With How We’ve Been Automating

For years, network automation meant workflows. Define the steps. Map the conditions. Handle the exceptions. Build the logic. Test it. Promote it. And then – critically – hope the world doesn’t change, because if it does, your workflow is now a liability pretending to be an asset.

Workflows are powerful. They’re also brittle in a way that rarely gets acknowledged. They encode the understanding of the engineer who built them, at the moment they built them, against the environment that existed then. When a new device vendor enters the picture, when an API response format shifts, when an edge case appears that nobody anticipated – the workflow either breaks or, worse, runs to completion on bad assumptions and you find out later.

This isn’t an argument against deterministic automation. It’s an argument for being honest about what it costs.

The cost of determinism is adaptability. You get predictability and auditability. You give up the ability to reason about new situations in real time. For a long time, that was the only trade available. You couldn’t have both.

FlowAI Changes the Trade

FlowAI is the framework that makes it possible to have both. It’s not a standalone product – it’s the agentic intelligence layer embedded in the Itential Platform that gives your teams access to reasoning, planning, and adaptive execution alongside the deterministic orchestration the platform has always delivered.

The application layer where your teams work is FlowAgent Builder. This is where you construct FlowAgents: define what tools they have access to, set their reasoning boundaries, shape their behavior with system prompts, and run them against real tasks. Think of FlowAgent Builder as the environment where you turn intent into a working, testable, deployable agent.

And the tools those agents work with aren’t open-ended. FlowAgent Builder operates against the Itential Platform’s adapter and integration framework – the same multi-vendor connectivity layer that powers your existing workflows. A FlowAgent calling a Cisco device, an Arista switch, an F5, a Palo Alto, a ServiceNow instance, or a NetBox is going through the same governed, credentialed, RBAC-controlled integration layer your team already trusts. The agent isn’t going rogue against your infrastructure. It’s working within the same boundaries as everything else on the platform.

That’s what makes FlowAI practical in enterprise environments – not just technically interesting.

What a FlowAgent Actually Does

Give a FlowAgent a goal – triage this incident, validate this device state before the change window, provision this resource across these systems – and it works through the problem using the tools it has access to. It decides which commands to run, in what order, based on what it finds. If the first check reveals something unexpected, it adjusts. If a tool returns an error, it reasons about what that means and tries a different path.

This is fundamentally different from a workflow that hits an unhandled exception and stops.

FlowAgents adapt. They handle variability. They apply context. They absorb the kind of real-world messiness that automation engineers spend months trying to enumerate and encode – and they do it at inference time, not design time.

A wireless engineer describing a triage process to FlowAgent Builder and running it against real conditions in a test environment isn’t building a prototype. They’re potentially building a production agent – one that handles the full range of conditions their domain expertise would have addressed anyway, without requiring them to learn workflow development syntax.

That’s the first path: build a FlowAgent, run it in production, let it reason and adapt.

For use cases where the environment changes faster than a workflow can be updated, or where the range of possible states is too broad to enumerate statically, this is often the right architecture and the right endpoint – not a step on the way to something else.

The Second Path: Spec-Driven Development

For some use cases, you reach a point where the variability is low, the process is well-understood, and the FlowAgent has demonstrated that it handles the task consistently. At that point, running an LLM on every execution starts to look like overhead: token cost, inference latency, non-determinism you no longer need.

This is where spec-driven development comes in – and it’s the part of the FlowAI story most people haven’t heard yet.

When a FlowAgent has been validated against a use case – when the team has run it, reviewed its reasoning, and confirmed it’s handling the task correctly – you can export that agent’s definition: its tools, its system prompt, its behavior. That export is lightweight. It captures the intent and the tool call pattern the agent has established.

That definition becomes the input to spec-driven development. The Itential Platform takes the agent’s validated behavior and generates a spec file – a structured specification of what the automation should do, which tools it should call, in what sequence, with what conditions. From there, the platform’s workflow generation capability turns that spec into a fully deterministic Itential workflow automatically.

No drag-and-drop canvas work. No manually writing task logic from scratch. No negotiating between what the domain expert knows and what the workflow developer can build. The FlowAgent did the reasoning. Spec-driven development codified it. The workflow is the output.

The workflow that emerges is:

• Deterministic – it does exactly what was specified, every time, with no LLM inference at execution time
• Auditable – full job history, change management integration, the same audit trail as any other Itential workflow
• Cheaper to run at scale – zero token cost per execution
• Qualified for production – it goes through your standard workflow promotion pipeline, the same process your governance team already approves

The FlowAgent is the architect. Spec-driven development is the contractor. The workflow is what gets built.

This is the unlock most enterprises haven’t seen yet: spec-driven development is how organizations with strict AI governance – the ones whose policies forbid LLMs in the decision path of a production change – can still capture agentic reasoning and ship it as something their qualification process already accepts. The AI never touches production. The workflow does.

That’s not a workaround. That’s a deployment pattern.

Choosing the Right Path Per Use Case

FlowAI doesn’t pretend the tradeoffs don’t exist. What it gives you is the flexibility to navigate them – per use case, by the team closest to the problem.

• Stable, well-understood, high-volume use case? Build the FlowAgent to validate the logic, then use spec-driven development to generate the deterministic workflow. Run the workflow. Token cost: zero. Predictability: complete.
• Dynamic or variable use case where the environment changes faster than a workflow can be updated? Run the FlowAgent directly. Let it reason and adapt. Accept the inference cost because the adaptability is worth it.
• Governance program prohibits AI action in production? Build and validate the FlowAgent in dev and QA. Use spec-driven development to generate the workflow. Qualify the workflow through your existing process. The AI never touches production. The workflow does.
• Use case falls in between? The platform supports hybrid patterns – workflows that invoke FlowAgents at decision points, or FlowAgents that hand off to deterministic workflows once they’ve resolved uncertainty.

The choice is yours to make, per use case, with the tools to execute either path inside the same platform.

Governed By Design

The phrase isn’t marketing. It describes the architecture.

Every FlowAgent operates within the tool set that has been explicitly approved and configured in FlowAgent Builder. The adapters it calls, the credentials it uses, the actions it can take – all governed by the same RBAC and service account controls that govern your existing workflows on the Itential Platform. You don’t create a new access surface when you deploy a FlowAgent. You extend the same governed surface you already manage.

FlowMCP Gateway and FlowMCP Server extend this governance in both directions. FlowMCP Gateway lets your FlowAgents consume tools from external MCP (Model Context Protocol) servers – pulling capabilities from third-party platforms into the FlowAI framework without standing up separate integration infrastructure. FlowMCP Server exposes Itential capabilities northbound to external agents – so when an observability platform’s agent, a Copilot agent, or any other external orchestrator needs to take action on infrastructure, it calls through a scoped, RBAC-governed Itential interface, not an uncontrolled API endpoint.

One integration layer. Governed access in both directions. Every agent – yours or external – operating within the boundaries you’ve defined.

This matters more than it sounds. Most enterprises adopting AI in operations are about to discover that they’ve created agent sprawl: agents in their observability platform, agents in their ITSM, agents from their cloud providers, agents inside copilots, agents their domain teams built locally. Every one of those agents will eventually need to take action on infrastructure.

The question isn’t whether that happens. It’s whether it happens through one governed surface – or through whatever path the agent finds.

The Question We Should Be Asking

The organizations that navigate the next phase of network automation well won’t be the ones who picked a side in the deterministic-vs-agentic debate. They’ll be the ones who built both capabilities – in the same platform, with the same governance model, using the same integration layer – and deployed each where it actually makes sense.

FlowAI is the framework that makes that possible. FlowAgent Builder is where your teams do the work. Spec-driven development is the path between agentic and deterministic when you want it. The Itential Platform is what ties it together with the governance, audit, and multi-vendor reach that enterprise infrastructure demands.

The question isn’t whether to add AI to your network operations. That decision is already being made around you.

The question is whether you do it with a platform that lets you control how much intelligence runs where – or whether you figure that out after the fact.

Where to Go From Here

If you’re sitting between an AIOps investment that finds problems and a workflow practice that fixes them too slowly, you already know what the gap costs. Here’s how to start closing it.

See FlowAI in action. The fastest way to understand the agentic-and-deterministic model is to watch a FlowAgent reason through a real task and then watch spec-driven development convert it into a qualified workflow. Request a walkthrough – we’ll run it against a use case that matches your environment.

Read the operating model. Spec-driven development is documented end-to-end in the Itential SDD learning hub – the five phases, the governance model, the role-by-role implications. Start here.

Build something. Itential Builder Skills are available now in the Anthropic Marketplace and the public Itential GitHub repo. One install delivers a library of agentic skills, FlowAgent builders, and a platform plugin – with example specs you can run today. github.com/itential/builder-skills.

Talk to the team. If you’re navigating an AI governance program, an AIOps investment, or both – and you’re trying to figure out what the action layer should look like – that’s the conversation we want to have. Get in touch.

The deterministic-vs-agentic debate will keep generating posts. The teams quietly building both, in the same platform, with the same governance, are the ones who’ll be running production agentic operations a year from now.

Pick the platform that lets you choose, per use case. Then get to work.