Build Agents vs. Operate Agents: How to Adopt AI in Infrastructure Operations

The Difference that Matters

Introduction

Everyone agrees AI agents are coming to infrastructure operations. Almost no one agrees on where to start. Leadership wants an agent strategy this quarter. Your security team wants to know what an AI is allowed to touch. And the loudest voices in the market are pushing you toward the scariest possible starting point: an autonomous agent making changes in production.

Most teams stall right there, because the question they’ve been handed sounds like a risk decision. Should we let AI act on our network? Framed that way, the safe answer is no, and the whole program waits.

This guide reframes the question. “AI agents” is one term hiding two fundamentally different technologies with fundamentally different risk profiles.

Because here’s what the conflation hides: you can adopt build agents today, get the velocity gains of AI-generated automation, and never let an agent touch production. Every outcome stays deterministic. The question stops being whether to adopt AI and becomes what order to adopt it in.

Adopting AI stops being a risk decision. It becomes a sequencing decision.

The LLM ‘Smiling Curve’

The Wrong Question Is Blocking the Right Work

A decade of automation effort produced real progress and a hard ceiling. Intent-based frameworks struggled as vendors kept differentiating underneath the abstractions. Sources of truth became multi-year data projects that blocked the automation they were meant to enable. And infrastructure as code, the most successful pattern of the era, carried a hidden cost: teams encoded their design documents and methods of procedure directly into their pipelines, welding portable designs to unportable implementation details. Every error path, every edge case, every offline device got hand-coded into execution logic. The technical debt compounded until most organizations could only afford to automate a fraction of their infrastructure.

Agentic AI is the first technology that changes that math, but only if it’s placed where it performs. Large language models are strong at two extremes: general knowledge (what a port turnup is, how a software upgrade should go, networking theory and fundamentals) and the hyper-specific (RFCs, detailed design documents). They’re weakest in the messy middle of OS-specific, multi-vendor questions, because vendor specifics live behind paywalls in TAC tickets and code bases the models never trained on.

That performance curve is the foundation of this framework. The two agent types succeed for the same reason: each one keeps the LLM at the edges of the curve where it’s strong, and keeps deterministic execution in the middle where the LLM is weak. Build agents use general and specific knowledge to generate automation from well-written specs. Operate agents use context you supply (MCP tools, skills, knowledge bases) to reason through live problems. Neither asks the model to freestyle in the messy middle.

Put the LLM where it performs. Put determinism everywhere else.

Two Agents, Two Jobs

Build Agents vs. Operate Agents

Build agents change how automation gets made. Operate agents change how it runs. Everything else in this guide follows from that distinction.

Build Agents // AI That Writes Your Automation

What they are. Build agents are the coding agents your software peers already use: Claude Code, Codex, Cursor. The early expectation was a fleet of specialized agents, one for building, one for testing, one for releasing. What actually emerged is universal code-generation agents that take on personas through skills: load a requirements-collector skill and the same agent gathers requirements; load a solution-designer skill and it produces a design; load a builder skill and it generates the code. The discipline that makes this reliable is Spec-Driven Development.

The output can be exclusively deterministic assets.

How they work. An automation developer, and it is human-led at every step, writes a spec: the problem definition, a high-level flow, phases, key design decisions, what’s in and out of scope, risks, assumptions, and requirements. For a task like port turnup, that spec is already more rigorous than the requirements most teams collect before writing a Python script today. The build agent translates the spec into a plan: how each requirement will be satisfied, the design decisions it’s making, where a script fits versus a workflow, how it will be tested, and a full component inventory down to the Jinja templates. The developer reviews and approves at each stage, then the agent generates the code.

The property that matters. Everything a build agent produces is deterministic. The generated workflow, script, or automation runs exactly the way your hand-written automation runs today: same execution, same change process, same governance. The AI’s judgment is applied at design time, under human review, and never at runtime. If your organization is not ready for an agent to make config changes in production, you can still adopt build agents fully. No agent ever touches your network.

What it changes. The effort shifts from instrumenting code to designing systems. For a decade, design documents sat on the shelf while the real logic lived in pipelines. Build agents reverse that: the design document becomes the source, and the implementation is generated from it. Teams get their architecture practice back, and the technical debt of hand-maintained pipelines stops compounding. Software teams that made this shift saw developer velocity climb once they stopped judging AI by vibe-coded function calls and started feeding it real specs.

Where trust still has to be earned. None of this works if the spec is bad or the review is a rubber stamp. A vague spec produces a plausible-looking automation that fails the same way vibe-coded output does, just with better paperwork. And “human review” that’s really a five-second click-through doesn’t catch anything an LLM couldn’t. The deterministic guarantee only holds if the humans in the loop are actually reviewing, not just signing.

Once you believe the implementation is free, you put your best people on design. That’s where they belonged all along.

Operate Agents // AI That Acts in Your Environment

What they are. Operate agents are ReAct agents (reason, act, repeat) that do work in your infrastructure: a NOC connectivity troubleshooting agent, a software upgrade agent, a port turnup agent. They run in a loop, reasoning about a goal, calling a tool, evaluating the result, until they reach an outcome. Practitioners managing infrastructure start to think of themselves as managing teams of agents.

Trust is layered, not modeled.

The anatomy. Three layers make an operate agent trustworthy, and none of them is the LLM. Model Context Protocol (MCP) provides the what: governed access to context from your systems, the way NETCONF once replaced screen-scraping the CLI. Skills provide the how: reusable instructions for performing a task well. Knowledge bases provide the boundaries: your network use policy, your AI policy, your maintenance window policy, loaded into the agent’s context so it operates inside your rules. An agent built this way joins the 2 a.m. bridge with more context than the human who got paged: it has already pinged, already traced, already read the policy, while your own 2 a.m. context window is running on four hours of sleep.

Governed by design, not by exception.

The property that matters. Operate agents produce reasoned outcomes, not predetermined ones. That’s the point: you stop pre-coding every error path and let the agent work through the cases nobody scripted. It’s also the risk, which is why operate agents demand what build agents don’t: runtime governance. Scoped tools, constrained knowledge, human approval where the blast radius warrants it, and a full audit of every reasoning step and action.

How they fit what you run today. Adopting operate agents doesn’t mean abandoning how you consume automation. Agents can sit behind the same APIs, forms, events, and ticket queues you use now: an agent can watch the ServiceNow queue, run diagnostics, update the ticket, and send the email, engaging with the systems and people around it the way your automations already do.

The Framework at a Glance

An Operating Pattern

The Determinism Sandwich

The two agent types aren’t competing adoption paths. They meet in an operating pattern worth naming: the determinism sandwich.

Every pipeline starts as a beautiful straight line: pre-check, gather data, generate config, push, post-check, notify.

Then production happens, and the worst thing about determinism shows up: it keeps being deterministic. Every error condition, every offline device, every malformed record has to be hand-coded, and the straight line becomes a thicket of exception logic that caps how many pipelines a team can afford to maintain.

The sandwich splits the work by what each side is good at. The common path stays deterministic: it’s known, it’s high-volume, and it should run the same way every time at fixed cost. The long tail of exceptions goes to reasoning: instead of pre-coding a thousand failure branches, an agent works through the rare cases as they occur. And the whole thing runs under deterministic control: governed triggers on top, governed execution on the bottom, reasoning contained in the middle. Agents underneath determinism, so the flexibility is real but bounded.

One way to hold the economics in your head: CPUs for what you know, GPUs for what you don’t. If a task runs 10,000 times a day down a known path, paying an LLM to re-reason it is waste. If a pipeline fails at 2 a.m. over an edge case nobody coded, spending tokens on reasoning is cheaper than the outage. The balance is per use case and per environment, and it will shift as both your automation and your trust mature.

Deterministic where the work is known. Agentic where it isn’t. Governed everywhere.

Automation Adoption All Over

Sequencing: From First Spec to Autonomous Operations

Agentic adoption is rhyming with automation adoption a decade ago. Teams debated whether scripts belonged in production at all; every change got a human review and a diff set. Then pipelines earned trust and went headless. The same acceptance curve is starting again with agents, except this time the industry has a map, because AI is, at its core, an automation technology. Pattern-match accordingly, and sequence deliberately.

Stage 1: Adopt build agents. Ship deterministic outcomes.

Start where the risk conversation is shortest. Write your first spec for a well-understood task (port turnup is the classic), run it through a build agent with SDD discipline, and deploy the generated automation through your existing change process. Your operating model doesn’t change. Your governance doesn’t change. Your velocity does. This stage also rebuilds a muscle most teams lost: writing design documents that are actually load-bearing.

Stage 2: Introduce operate agents on read-only work.

Give your first operate agent the job you’d give a new hire: investigate, don’t change. Ticket triage and enrichment, connectivity diagnostics, compliance checks, documentation. Constrain it with your policies in its knowledge base and a scoped set of tools. Keep a human in the loop on anything that would touch state. This is where the organization learns to read an agent’s reasoning and calibrate trust against evidence.

Stage 3: Govern agents into the change path.

As trust builds, let operate agents propose and execute bounded changes through governed execution: pre-checks, approvals where blast radius warrants, post-validation, rollback, full audit. Move from human-in-the-loop to human-on-the-loop for the categories that have earned it. Build the determinism sandwich: deterministic spine, reasoning for exceptions.

Stage 4: Expand autonomy per use case, not globally.

Human-out-of-the-loop is a destination for specific, well-bounded use cases, not a switch you flip for the environment. Some categories of work will run autonomously within a year; others should keep an approval gate indefinitely. The maturity model is per use case, and that’s a feature.

Signals You’re Ready to Advance

• Build to operate (read-only): Your build-agent pipeline has shipped several automations through your normal change process with no rollback surprises, and your team trusts the generated code enough to stop line-by-line diffing it.
• Read-only to governed change: Your first operate agent’s reasoning has been reviewed enough times that false positives are rare, and the team can articulate why it made a call, not just that it made one.
• Governed change to autonomous: The use case has run under human approval long enough that approvals are consistently rubber-stamping correct decisions, not catching real errors. If approvals are still catching mistakes, the use case isn’t ready to lose them.

At every stage: engage your AI governance team.

Governance didn’t arrive with AI. You already worried about guardrails, secrets, and access when the automation was Python and Ansible; agents just raise the stakes. Most organizations now have an AI governance team, and most practitioners assume it exists to say no. In practice it has a dual mandate: accelerate agentic adoption and keep it safe. Teams that engage early report more support than they expected. Bring your governance team your sequencing plan, and you’ll likely find they’ve been waiting for someone to show up with one.

Ask These Questions

Four Questions That Place Any Use Case

• How often does it run? High-frequency work compounds token cost. If it runs constantly down a known path, it belongs in deterministic execution, whether hand-built or generated by a build agent.
• Is the path known? If you can write the procedure down, write the spec and generate it. If the work is diagnostic, ambiguous, or novel, that’s reasoning territory: an operate agent.
• What’s the blast radius? Read-only and reversible work is where operate agents earn trust. High-consequence changes keep humans in the loop and deterministic execution on the final step.
• What happens when it fails? If failure means a page at 2 a.m., ask which side prevents it: more pre-coded error handling, or an agent that reasons through the long tail? The sandwich usually answers: deterministic spine, reasoning at the edges.

How to Lead the Agentic Era

Final Takeaways

The organizations that lead the agentic era won’t be the ones that bolted an agent onto existing tooling, and they won’t be the ones that waited for the risk to feel smaller. They’ll be the ones that recognized “AI agents” as two technologies, adopted them in the right order, and ran both through the governance that already protects production.

• Separate the build conversation from the operate conversation in your strategy, your security review, and your budget.
• Start build-side now: pick one well-understood use case, write the spec, generate the automation, ship it deterministically.
• Treat design documents as the durable asset. Implementations are becoming free; architecture is not.
• Give your first operate agent read-only work, real policies in its knowledge base, and scoped tools.
• Budget tokens by multiplier: one-off on the build side, per-run on the operate side. Convert proven reasoning into deterministic automation.
• Engage your AI governance team with a sequencing plan, and push your vendors for quality MCP servers.

The Agentic Operations Platform

Where Itential Fits

The framework in this guide doesn’t require Itential. But it does require a place where both agent types resolve to governed execution, and that’s what the Itential Platform is built to be.

On the build side, Itential Builder Skills bring Spec-Driven Development to infrastructure teams: open source skills for Claude Code that take a plain-language spec through requirements, design, and build, producing governed, deterministic automation.

On the operate side, FlowAgents are ReAct agents with the anatomy this guide describes: tools scoped and locked at build time, knowledge grounded in live infrastructure state, and every reasoning step and action captured in an auditable session. FlowAgents never touch infrastructure directly; they act through governed execution paths, whether that’s a platform workflow, an automation or script running through Itential Gateway, or a direct API call.

And the sandwich is native: deterministic, agentic, and hybrid execution run through one governed engine, so a workflow can call an agent for the one step that needs judgment, an agent can hand off to deterministic execution for the steps that must be exact, and proven reasoning can be captured as deterministic automation so you stop paying to re-think solved problems. Same RBAC, same approvals, same audit, whichever mode executes. For the platform-selection side of this decision, see the evaluation guide: From Orchestration to Agentic Operations.

AI adds reasoning. Itential adds the guardrails.