Inside Itential FlowAI Agent Harness

Introduction

Overview

Every AI agent is a combination of two things: a model that reasons, and a harness that lets it act. Model capability is converging: multiple vendors now offer models with broadly comparable reasoning ability, and the gap between them narrows with each release. That shifts what actually determines whether an agent works well in production. It’s not which model it runs. It’s what’s built around it, the tools it can reach, the context it reasons over, and the governance that constrains what it’s allowed to do.

Infrastructure raises the stakes on that governance more than most domains. A mistake here isn’t caught in a code review. It can take down a service or fail an audit in real time. FlowAI is Itential’s answer to that standard: the agent harness of the Itential Platform, built from four components – Tools, Skills, Context, and Governance – that let a FlowAgent reason through a goal and act on real infrastructure under the same governance as every human and every deterministic workflow already running on the platform.

That governance isn’t new. It’s inherited from more than a decade of production automation use across some of the largest network and infrastructure estates in operation, which is also why it’s a different proposition than building the same thing from scratch.

The Concept

What Is a Agent Harness?

An AI model, on its own, does one thing: it reasons about an input and produces an output, then stops. It doesn’t remember what happened last time, can’t take a next step on its own, and has no built-in sense of a change window, a blast radius, or a compliance requirement.

An agent, in short, is a model plus a harness. Two products can run the identical model and behave completely differently, because the harness, not the model, decides what the agent is actually allowed and able to do.

Most agent harnesses break down into four generic parts, regardless of vendor or platform.

• Tools
  The actions an agent is allowed to call, the interface between its reasoning and the real world.
• Skills
  The encoded expertise for how to approach a given task, so an agent isn’t reasoning a solution from scratch every time.
• Context
  The information an agent reasons over, current state and history, rather than a static prompt.
• Governance
  The set of permissions, rules, and enforcement that determines what an agent can actually do, and who’s accountable when it does it.

Every harness implements these four differently. The rest of this guide covers how FlowAI implements them for infrastructure.

Why It Matters

Why the Agent Harness Matters

Model capability is converging. Several vendors now offer models with broadly comparable reasoning ability, and the gap between them keeps narrowing with each release. That makes the choice of model less and less the thing that determines whether an agent works well in practice.

Infrastructure

Why This Matters More for Infrastructure

A coding agent that makes a mistake gets caught in review, reverted, and redeployed. The harnesses built for coding agents were built inside that tolerance, guardrails added where convenient, because the cost of a mistake was a wasted pull request.

Infrastructure doesn’t get that tolerance. A mistake here doesn’t get caught in review. It can take down a service, open a security gap, or fail an audit, in real time, in production.

A harness built to read a file and run a test was never built to know a change window, a blast radius, or a compliance obligation. That’s a different, harder problem, and it’s the one FlowAI was built to solve.

The Itential Platform

FlowAI Is Itential’s Agent Harness

FlowAI is the agent harness of the Itential Platform. It’s how FlowAgents get built, run, and governed: agents that reason through a goal and act on real infrastructure, with the same governance applied to every action, whether that action came from an agent or a person.

FlowAI isn’t a separate product added on top of the platform, and it isn’t a model. It’s the harness: the layer that takes a model’s reasoning and turns it into a governed, auditable action.

Architecture

The Four Components of FlowAI

Each part does a specific job, and each was proven in production before a single FlowAgent existed. The next four sections take them one at a time.

Tools

With a Model Alone

It can suggest an action, but it has nothing to actually carry it out.

With FlowAI

Every workflow, golden configuration, lifecycle state, automation, API, and gateway service already on the Itential Platform is registered as a callable tool. An agent calls these tools with structured inputs and defined outputs. It never touches infrastructure directly.

That tool library includes 1,000+ open source integrations across network, cloud, ITSM, security, and observability systems, a fully documented REST API covering every platform capability, the Itential MCP Server and FlowMCP Gateway for connecting external LLMs, and CLI, Netconf, and RESTCONF connectivity for devices that don’t expose modern APIs. Configuration compliance and drift detection, Golden Configuration templates, and lifecycle state tracking are all callable the same way an integration or a workflow is. Existing Ansible playbooks, Python scripts, and OpenTofu plans become callable tools too, no rewrite required.

Skills

With a Model Alone

It reasons from scratch every time, with no memory of how your team actually handles a given situation.

With FlowAI

Builder Skills encode repeatable task expertise as structured instructions.

A Skill defines how a network engineer would handle a vulnerability response, an OS upgrade, or a config drift, and the agent follows that expertise rather than improvising a new approach every time it encounters a similar situation. Skills are what keep an agent’s behavior consistent across runs, and consistent with how the team already operates.

Context

With a Model Alone

It reasons over whatever text it’s handed, often stale documentation or an unstructured prompt.

With FlowAI

Agents reason over live infrastructure state.

That means real device inventory, real configuration state, and real ticket history, not a snapshot from whenever someone last wrote it down. Grounding reasoning in current state is what keeps an agent’s decisions relevant to what’s actually true right now, rather than what used to be true.

Governance

With a Model Alone

There’s nothing stopping it from taking an action it was never meant to take.

With FlowAI

Governance runs in three layers, configured at build time and enforced by the platform at runtime.

1. Builder access controls who can create an agent and with which tools. Not every builder gets every capability; a DDI engineer sees DDI adapters, a network engineer sees theirs.
2. Agent permissions lock in, at build time, exactly which workflows, automations, APIs, and services an agent can call. Nothing outside that scope is discoverable or callable later. An agent built to read a device can’t be prompted into changing one.
3. Execution control governs who or what can trigger the agent, from where, and under what conditions, with human-in-the-loop checkpoints available before any irreversible action.

Every action, agent or human, writes to the same immutable audit trail. Itential holds zero data retention on customer infrastructure data and is SOC 2 Type II by default.

Adoption

What Doesn’t Change When You Add FlowAI

For teams already running infrastructure automation, this is usually the first real question: does any of this mean rewriting what’s already built? It doesn’t.

Existing Python scripts, Ansible playbooks, and OpenTofu plans keep running exactly as they do today. Itential connects to git repos as the source of truth and executes what’s already there through Itential Gateway. Governance and audit logging get added on top, nothing gets rebuilt to fit the platform.

The same is true of orchestration workflows. Multi-step, multi-system workflows built in the visual studio, or generated from plain language through Spec-Driven Development, keep running exactly as designed.

Flexibility

Bring Your Own Model

FlowAgents run on any LLM: open weight models like NVIDIA Nemotron, Kimi K2, or Llama hosted entirely on infrastructure you control, proprietary models like Claude, ChatGPT, or Gemini, or a custom model built and fine-tuned in-house. The model is a choice made per agent, not a commitment made for the whole platform.

That works because the model was never where the harness’s value lived. Swapping the model behind an existing FlowAgent is a configuration change, not a rebuild, since the governed path underneath it, Itential Gateway, direct API calls, or platform workflows, never depended on which model was doing the reasoning.

This matters most for teams navigating specific regulatory requirements: DORA, PCI DSS, and SOX in financial services, HIPAA in healthcare, FedRAMP or air-gapped environments in the public sector, GDPR and the EU AI Act for carriers.

Build vs. Buy

Why This Is Hard to Replicate

Itential has run deterministic execution, workflows that perform the same steps the same way every time, for over a decade across some of the largest and most complex network and infrastructure estates in operation. The RBAC model, the audit trail, the secrets handling, the rollback behavior, all of it was proven under real production conditions, at that scale, before FlowAI existed. FlowAI doesn’t build that governance for the first time. It inherits it the moment a FlowAgent takes its first action.

That’s the part worth separating from the pitch: building a harness, in the sense of a loop that calls tools and holds context, is a well-understood engineering problem today. Proving that the governance around it holds up at scale, across a decade of real production incidents, is not something a team can compress into a project timeline. It gets proven the slow way, or it doesn’t get proven at all.

This shows up as two different objections, depending on who’s asking.

A network or infrastructure engineering team usually means: we already have scripts and playbooks that work, why do we need a platform under them.

An AI or platform engineering team usually means something more specific: we can build the agent loop with LangChain, LangChain’s Deep Agents, or Pydantic AI’s harness.

Both are legitimate starting points for the parts that are genuinely reusable. Neither ships with the part that takes the longest to prove out.