Two Sentences, One Governed Change: Adding Change Management to a Live FlowAgent

On a recent Itential webinar, I built a FlowAgent from a blank project using tools we already had, then added a full change management process to it with two sentences of prompt guidance. No rebuild. What follows is what actually happened, tool by tool, so you can see exactly where the reasoning stopped and the execution started.

Starting From Nothing

Inside the Itential Platform‘s agent projects section, we created a new project for application infrastructure provisioning. A project is a container for FlowAgents. Most teams organize projects around a use case, sometimes with several FlowAgents inside one project handling related actions. Itential’s own F5 project, for example, splits creation, modification, and deletion of load balancer VIPs into separate FlowAgents rather than one FlowAgent trying to do all three.

For this build, one FlowAgent was enough. And by default, a project a builder creates is private to them; nobody else on the team sees it until the builder chooses to share it, the same instinct as not pushing code to a shared branch until it’s ready.

Giving the FlowAgent Context: Instructions, Then Tools

A FlowAgent needs the same two things you would hand a colleague if you delegated the task: instructions and tools.

Instructions came first, as a prompt, written in Markdown, covering the inputs the FlowAgent needs (app name, region, template, requester), the naming standard to enforce, the network allocation to request from Infoblox, and the exact steps to follow: confirm the region is supported, get human approval before creating anything, allocate the subnet, create the VPC, launch the instance, confirm deployment, report back.

Tools came next: an existing script already used for VPC and EC2 instance creation, and a native Infoblox API. Both were tools the team already had. Nothing was rebuilt to make this FlowAgent work.

This is the part worth sitting with. The FlowAgent didn’t get new infrastructure access. It got the same APIs and scripts a person would use to do this by hand, wired up through explicit tool association rather than letting the model guess at what’s available.

When It Broke, It Fixed Itself, Within Limits

Midway through the run, a step failed. The subnet allocation call had been given a value in slash notation (a CIDR-style prefix) when the underlying API actually needed a plain integer for network size, a mismatch the vendor’s own API spec didn’t make explicit. The FlowAgent recognized the failure, corrected the value, and retried the call itself. No human intervened.

That kind of self-correction is exactly what makes teams nervous the first time they see it, and exactly why retry behavior isn’t left open-ended. The builder sets the ceiling: retry a tool call up to a defined number of times, and on the final failure, stop and take a specific fallback action, such as exiting and opening an incident ticket rather than continuing to guess. Self-healing and unbounded improvisation are not the same thing, and the platform is built to keep them separate.

The Busywork the FlowAgent Absorbed Without Being Asked

Nobody wrote a Jinja template. Nobody specified HTML formatting or a color scheme for the human-in-the-loop approval screen. The only instruction given was to present the request in a way an approver could act on, and, separately, a note to use Itential-branded colors. From that, the FlowAgent generated a formatted, styled approval view on its own, pulling in the fields that mattered for a decision-maker to see.

That is the same category of work as the payload formatting: data transformation, presentation, and formatting logic that used to require a script, a workflow step, or a Jinja template someone maintained by hand. None of it touches infrastructure. All of it used to be tactical busywork somebody had to build and keep updated every time a new service came online.

Then, Live: Adding Change Management

Here’s the part that actually matters for anyone deciding whether FlowAgents are safe to run against real infrastructure. With the FlowAgent already working, we added governance to it without touching the original build.

Two new steps went into the existing FlowAgent, live:

• Step 2A: create a ServiceNow change request, with all parameters for the request and approver information.
• Step 6A: update that same change request once deployment is confirmed, recording the provisioning results and assets.

Both steps used native ServiceNow tools already available in the platform, the same create-change-request and update-change-request calls documented straight from ServiceNow’s API spec. Because ServiceNow’s generic API needed sharper instructions to behave the way this workflow required, in the same way the Infoblox subnet field needed a decorator earlier, both tools were wrapped in a decorator: a layer that teaches the FlowAgent exactly what a tool expects, correcting for a vendor spec that’s ambiguous or generic, without touching the vendor’s underlying API.

Total prompt guidance required for both steps: two sentences.

As Karan put it, watching it happen: “It only took two sentences and tool association, and it started doing more than what I do today.”

What the Consumer Never Saw

This is the detail that separates a good demo from a production-credible one: nothing changed for whoever requests the FlowAgent’s work. Same inputs. Same request. The only thing that changed sits entirely on the back end, where every run now lands a ServiceNow change record alongside the infrastructure change itself.

Nobody told the FlowAgent what to name that change record either. Left to its own judgment, it produced a self-documenting title and description straight from the job’s context: what was provisioned, for what purpose, in which region. Open the ticket and the provisioning details, validation results, and plan steps are already there, without a human writing a change summary after the fact.

That’s an audit trail that builds itself while the work happens, not one bolted on afterward.

Agents Don’t Replace What You’ve Built, They Just Take the Variable Work