Agents Change What Good Automation Architecture Looks Like

Every wave in this industry has changed not just how we operate, but how we build. Scripts taught us to codify tasks. Pipelines taught us to sequence them. Platforms taught us to govern them. Each time, the tooling conversation got the headlines while the architecture conversation – the quieter question of what good design looks like now – did the real work of separating the teams that thrived from the teams that rebuilt everything twice.

Agents are the next wave, and most of the conversation is stuck on the operations side: what happens to the dashboard, the on-call rotation, the ticket queue. Those changes are real. By Gartner’s estimate, roughly 70% of network runtime activity still starts in a GUI, and agents are coming for exactly that work. But the deeper shift, the one I’d want every architect and automation engineer thinking about right now, is this: agents change what good automation architecture looks like. And if you build for the old pattern, you’ll be rewriting sooner than you think.

The Parent Workflow Problem

Most automation today follows the same pattern: the parent workflow. One big workflow that tries to anticipate everything: every vendor variation, every branch, every exception, baked in as conditional logic. And it works. Until the network changes.

A new vendor arrives. An acquisition brings unfamiliar devices. A schema changes on the other side of an API you don’t control. And the parent workflow gets rewritten. And rewritten. And rewritten again. Every branch you add makes the next change harder. Ask anyone who has maintained one of these for three years: at some point, the automation stopped reducing the toil and started being the toil.

Here’s the uncomfortable truth about why. The parent workflow was always doing two jobs at once: deciding what should happen, and doing it.

We fused reasoning and execution into one artifact because we had no other place to put the reasoning. The if/else jungle is judgment, frozen in logic, aging badly.

Separate the Deciding From the Doing

Agents give the reasoning somewhere else to live. And once it has somewhere else to live, the architecture reorganizes itself around a cleaner division of labor. The agent reasons: it reads context, interprets state, decides what should happen and in what order. The workflows execute. They get to become what execution should always have been: small, vendor-specific, single-purpose, boring. Do one thing, do it well, and let something smarter decide when it should be used. The Unix philosophy, finally applied to network operations.

The adaptation moves into the reasoning layer. The workflows stay simple, modular, and boring – which is exactly what you want production execution to be.

When the network changes now, you don’t rewrite a monolith. You add a small workflow for the new vendor, and the agent starts routing to it. The system evolves the way the network evolves: incrementally, at the edges, instead of through periodic rewrites of a core that was never designed for the network you have today.

Guardrails Are a Design Requirement, Not a Setting

The immediate objection – and it’s the right one – is that you’ve just handed routing decisions to a probabilistic system. Engineers don’t trust that. They shouldn’t.

But notice what the composable pattern gives you architecturally: blast radius control. The agent doesn’t get your API surface. It gets a curated set of tools: the specific, governed workflows it’s allowed to call, each with validation on both sides and rollback standing by. Even a hallucinating model can only call an approved tool with an approved shape, and the deterministic automation behind that tool guarantees a safe action. This is what protocols like MCP are actually for: not wrapping your existing APIs in a new interface, which just recreates the old problems, but attaching structured, bounded capabilities to a reasoning system.

Trust doesn’t come from the model getting better. It comes from the architecture making the model’s failures survivable.

Context Is an Engineering Artifact Now

There’s a new discipline forming inside this shift, and it deserves a name: context engineering.

An agent is only as good as what it knows about your network. Not networking in general. The model has read every RFC ever written. Yours. Topology, design intent, naming conventions, runbooks, the tribal knowledge about why that one router is configured the way it is. Today most of that lives in wikis that drifted, diagrams that lie, and the heads of two senior engineers.

Turning it into structured, machine-readable context is real engineering work, and it pays twice. It makes agent reasoning accurate instead of confidently wrong. And it opens the door to design-first automation: define what the outcome should look like in a validated spec, and let the execution path be generated from it, with the model working from a spec you approved, not improvising from a prompt.

The teams treating context as an artifact (versioned, validated, owned) are pulling away from the teams still treating it as documentation.

What This Asks of Engineers

Not machine learning. That’s the question I get most, and the answer keeps being no. The scarce skill in this transition is network expertise, encoded: knowing what good looks like, where the guardrails belong, and how to express both in a form software can act on. Twenty years of judgment, translated into constraints, specs, and small sharp workflows. The engineers who thrive won’t be the ones who learned to fine-tune a model. They’ll be the ones whose judgment became the architecture.

Where Itential Fits

Everything in this post describes a division of labor: agents reasoning, small governed workflows executing, context as a first-class artifact, and control that never leaves the platform. That division of labor is the architecture the Itential Platform is built on. FlowAgents do the reasoning and the routing. Your existing workflows, scripts, and automations stay the execution layer, an asset, not technical debt to be rewritten. And every action, human- or agent-initiated, runs through the same RBAC, approval gates, audit history, and rollback the platform has enforced for over a decade. The agents are new. The discipline underneath them is not.

Go Deeper

Gartner’s Market Guide for Agentic NetOps Software maps this transition at the market level: the category definition, the two forms this software takes, and how to evaluate it. We’re hosting complimentary access.
Get the Market Guide → 

And if you’re rethinking your automation architecture for agents (or arguing with everything I just said), find me on LinkedIn, or catch The Cloud Gambit, where we dig into these shifts with the people building through them.