When I wrote about joining Itential and the shift from traditional network automation to true orchestration, I was speaking from conviction – a belief that there had to be a better way to operationalize our networks. I talked about moving beyond scripts and duct-taped integrations toward something more elegant, more scalable, more human.

But belief is one thing. Seeing it work is another.

What I’m about to share isn’t a vision statement or a roadmap promise. It’s a war story from the trenches – one where I went from platform newbie to production-ready network automation in less time than it takes to grab coffee.

And it fundamentally changed how I think about what’s possible.

The FlowAI Agent Builder doesn’t open with a code editor or a YAML configuration file. It starts with a simple question: What is this agent supposed to be?

The first field is the System Prompt – the foundational DNA of your agent. This is where you define its role, personality, expertise, and boundaries. Not in JSON schemas or class definitions, but in the same language you’d use to describe the job to a human engineer.

I wrote:

That’s it. No inheritance trees. No method signatures. Just a clear declaration of purpose.

Next came the User Prompts – the instructions for what the agent should do when invoked. Again, plain English:

• Validate all interfaces on the target device
• Detect errors, packet drops, flapping conditions, and statistical anomalies
• Generate a comprehensive health report with actionable insights

No flowcharts. No if-then-else logic. No regex patterns to maintain.

I was describing what I wanted, not how to code it.

This might seem like a small shift, but it’s actually tectonic. For decades, network automation has meant translating business intent into programming logic – a lossy, error-prone, expertise-heavy process. FlowAI inverts that model. The platform itself becomes the translator, and I stay focused on the outcome.

Then came the moment that really showcased the platform’s elegance: integrating pyATS MCP (Model Context Protocol).

Full disclosure – I wrote that MCP myself, so I know exactly what it’s capable of. But here’s the critical insight that FlowAI surfaced:

I didn’t expose every tool.

In the old world of automation, integration meant dumping an entire library into your script and hoping you used it correctly. You’d import 50 functions, need 3, and spend hours debugging the ones you accidentally misused.

FlowAI inverts this. I explicitly selected only the three pyATS tools relevant to interface health validation:

1. Connect to device
2. Execute show commands
3. Parse structured output

That’s it. The agent doesn’t have access to unrelated capabilities. It can’t accidentally call the wrong function. It can’t wander into dangerous territory.

This is curated capability – giving the AI exactly what it needs to solve the problem and nothing more.

The result?

• Safer execution (limited blast radius)
• Faster reasoning (smaller tool set means clearer choices)
• Cleaner logs (no noise from irrelevant tools)
• Better governance (explicit control over what the agent can do)

This is what happens when platform design actually considers production realities instead of just demo-day wow factors.

The last configuration step was almost comically simple: pick my LLM.

I chose my provider. I chose my model. Done.

But the implications here are huge.

In traditional automation, your tooling decisions create deep lock-in. Choosing a specific vendor’s API means your code is married to that vendor’s quirks, pricing, and roadmap. Migrating means rewriting everything.

FlowAI abstracts the LLM layer completely. If I want to switch from one model to another – or even one provider to another – I change a dropdown. The agent doesn’t care. The workflows don’t break. The integrations keep humming.

This is infrastructure-grade flexibility in a space that desperately needs it.

And just like that – agent built.

No pull requests. No code reviews. No deployment pipelines.

The agent was live, runnable by me or anyone else on the team, invokable with a single click or API call.

This is the part that still feels surreal.

I pointed the agent at a production network device and clicked Run.

What happened next was automation poetry.

Under 400 seconds, the agent:

1. Established a connection to the network device using pyATS
2. Collected live interface state – not from cached data, but real-time CLI output
3. Dynamically generated health tests based on the actual interfaces it discovered
4. Executed those tests without me writing a single assertion
5. Analyzed the results for errors, utilization spikes, flapping, and anomalies
6. Generated a detailed, human-readable report with findings and recommendations
7. Sent the report to Slack via the deterministic workflow
8. Sent the report via email to the operations team

All of this happened autonomously. No babysitting. No manual intervention. No “let me just tweak this one thing” mid-run.

The agent did its job. Completely. Correctly. Quietly.

To truly appreciate what just happened, let’s rewind and look at how this problem used to be solved.

The dark ages.

You’d SSH into each device individually. Run show interface commands. Copy-paste outputs into Notepad or Excel. Manually eyeball error counters. Try to remember what the baseline should look like. Miss things. Make mistakes. Burn hours.

Characteristics:

• Completely manual
• Error-prone
• Zero scalability
• Knowledge locked in people’s heads
• Undocumented tribal knowledge

This worked when networks had 10 devices. It collapsed under anything resembling modern scale.

The renaissance – or so we thought.

You’d write pyATS job files. Define test classes. Write hundreds of lines of Python to parse CLI outputs, assert expected values, and handle edge cases. Build custom integrations for Slack using requests or slack-sdk. Fight with email libraries. Maintain brittle parsing logic that broke every firmware update.

Characteristics:

• Repeatable and versioned
• Significantly faster than manual
• Required deep Python expertise
• High maintenance burden
• Fragile to platform changes
• Integration code rivaled test code in complexity

This was better. Much better. But it was still expensive – in time, in expertise, in ongoing maintenance. And it was slow to adapt. Every new requirement meant more code, more tests, more integration glue.

Intent-driven. AI-augmented. Deterministically executed.

You describe what you want in natural language. The platform orchestrates the execution. The AI generates the tests dynamically. The workflows handle integrations reliably. The agent runs autonomously.

Characteristics:

• Built in minutes, not days
• No test code to write or maintain
• No integration code to debug
• Accessible to network engineers, not just developers
• Adapts dynamically to infrastructure changes
• Always available, always consistent
• Reusable across teams
• Human-readable outputs
• Audit-ready execution logs

This isn’t just “better NetDevOps.” It’s a fundamentally different paradigm.

Let me be clear about what I experienced:

This wasn’t a toy. This wasn’t a carefully stage-managed demo. This wasn’t “it works on my laptop but good luck in production.”

This was a real network agent, solving a real operational problem, better than anything I could have hand-coded, and I built it in the time it would have taken me to scaffold a Python project.

The implications ripple outward:

Here’s the thing that keeps rattling around in my head:

Automation stopped being about code and started being about intent.

For years, we’ve accepted that automating networks requires programming skills, deep platform knowledge, and endless maintenance. We’ve treated it as a necessary burden – something only the most technical teams could afford to do well.

FlowAI says: what if that’s not true?

What if network automation could be as simple as describing what you want and letting the platform figure out how to deliver it?

What if the expertise required shifted from “how to code this” to “what outcome do I need”?

What if we could deploy production-grade agents faster than we currently deploy configuration changes?

I’m not speculating anymore. I’ve seen it. I’ve built it.

That first blog post I wrote about joining Itential – about orchestrating the future instead of just automating tasks – it wasn’t just marketing speak. It was a bet that there was a better way.

This agent, built in two minutes, validated that bet in the most concrete way possible.

I can’t go back to writing pyATS job files for hours. I can’t go back to hand-rolling Slack integrations. I can’t go back to treating every automation project like a software development lifecycle.

Not because those approaches are wrong – they were necessary stepping stones.

But because now there’s a faster, simpler, more powerful path forward.

And honestly? Once you’ve experienced automation at the speed of thought, everything else feels like you’re coding with one hand tied behind your back.

The future I wrote about isn’t coming.

It’s here.