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 an 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.

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. A FlowAgent calls these tools with structured inputs and defined outputs. It never touches infrastructure directly.

Effectively everything already running on the Itential Platform is exposable as a tool: every workflow, every Itential Gateway service, including the Python scripts and Ansible playbooks Gateway exposes, every API, and every automation. Nothing needs to be rebuilt or wrapped separately to become callable; if it already runs on the platform, an agent can call it. That 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 callable the same way. Existing Ansible playbooks, Python scripts, and OpenTofu plans become callable tools too, no rewrite required.

• Bounded blast radius.
  The worst case an agent can do is knowable in advance, because its reachable actions were fixed before deployment.
• Full audit traceability.
  Every action ties back to a tool an architect explicitly sanctioned, not one the agent acquired on the fly.
• Predictable reasoning cost.
  Tool surface area is fixed, so context size and token cost don’t grow unpredictably mid-execution.
• A clean approval chain.
  “Who approved this” always has an answer, because approval happened at build time, not implicitly at runtime.

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

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 a FlowAgent follows that expertise rather than improvising a new approach every time it encounters a similar situation. Skills are what keep a FlowAgent’s behavior consistent across runs, and consistent with how the team already operates.

A DDI engineer’s Skill for allocating IP space looks nothing like a security engineer’s Skill for vulnerability triage, each encodes what that specific role already knows how to do, not a generic instruction set applied across the board.

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.

That context is powered by the same systems already tracking that state for deterministic automation: Configuration Manager for compliance posture and drift, Lifecycle Manager for resource and configuration state over time. An agent isn’t querying a separate AI-only data layer. It’s reading the same state your workflows already treat as ground truth. Context reaches the agent through the same read-only tool calls as everything else, live device, config, and ticket state is pulled on demand at reasoning time, never pre-cached or stale.

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.

Worth separating two things that get discussed as one: what’s fixed, platform-wide infrastructure you inherit, RBAC model, audit trail, secrets handling, rollback behavior, and what’s configured per agent, persona, tool scope, and autonomy threshold. The first is built once and applies to everything. The second is decided fresh every time someone builds a new FlowAgent.

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.

This is also where build-time tool sanctioning and runtime governance meet: the tools an agent can call were fixed before deployment, and every call it makes against that fixed set is what the audit trail, approval gates, and RBAC layers above are actually enforcing.

How It Runs

From Goal to Governed Action

A FlowAgent moves through five stages every time it runs, all on the same engine, all under the same enforcement.

• Define
  FlowAgent Builder is where an agent’s persona and reasoning style get set, how it approaches a goal, not just what it can touch. Tool scope is explicit: nothing outside what’s defined is discoverable or callable, ever. Autonomy thresholds and human-in-the-loop requirements are set per operation type here too, fully autonomous below a defined risk level, approval-gated above it. All of it locked in before the agent ever runs.
• Context
  The FlowAgent connects to live infrastructure state and any relevant Skills. Reasoning happens over real device state, real config, real ticket history.
• Reason
  The FlowAgent runs an observe-reason-act loop: check current state, reason through the goal, select the right tool, and act, adapting to conditions without leaving the scope it was built with.
• Execute
  Every action routes through the platform’s governed execution engine. Pre-checks validate conditions before a change goes out; post-checks confirm the result after. RBAC and approval gates apply exactly as they would to a human-triggered change.
• Visibility
  Every reasoning step, tool call, and action is logged with full attribution. The complete execution trail is exportable, the same as any other action on the platform.

Take the incident-triage pattern from FlowAgents in Production.

A ServiceNow incident opens.

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.