Spec-Driven Development for Agentic Operations with Itential
The operating model applied – to the use cases your team actually runs, at the scale and complexity your environment actually demands.
Guides 1 and 2 established what SDD is and what it looks like applied to real network and infrastructure automation. This guide covers how Itential operationalizes it – the three agents that execute the five stages, the governed API skills that connect the model to your infrastructure, the artifact chain that functions as the audit record, and the progression from AI-assisted delivery to autonomous operations.
TL;DR
What's In This Guide
Three agents, five stages: The Spec Agent, Solution Architecture Agent, and Builder Agent – what each is authorized to do, what artifact it produces, what it cannot do, and how artifact-based handoffs govern the transition between stages.
Five agents, any LLM: The Itential Skills package ships with five agents that work with any LLM. Three are the SDD delivery agents that execute the five stages – Spec Agent, Solution Architecture Agent, Builder Agent. Two are Itential Platform agents for agentic operations and governed conversion of existing agent work. All five invoke governed API skills against your actual infrastructure.
The trust progression: Three stages from AI-assisted to governed autonomy – what each looks like operationally, what earns the right to advance, and where most production teams should operate today.
Who this guide is for
Network & Infrastructure Engineers
Understand how the agents execute SDD, what each is authorized to do, how the governed skills connect to your actual infrastructure, and where to start based on where your team is today.
Automation Managers & Leads
Understand how Itential enforces phase boundaries, what governs agent execution, and how the artifact chain makes every delivery auditable – for human teams and agentic operations alike.
VPs, Directors & CTOs
Understand the governed autonomy progression, what the trust advancement requires, and what organizational prerequisites produce the foundation to move from AI-assisted to autonomous operations.
In This Guide
01 The Problem with Unconstrained Agent Execution 05 The Governed Autonomy Progression 02 Three Agents, Five Stages: How Itential Executes SDD 06 The Spec Library – 22 Ready-to-Use Starting Points 03 Governed Skills – Every Integration Surface as an API 07 Getting Started – Entry Points by Maturity 04 The Artifact Chain as the Audit RecordThe Problem
The Problem with Unconstrained Agent Execution
An AI agent that operates on network and infrastructure without a governing operating model is not autonomous operations. It is unaccountable automation. The agent makes decisions at machine speed against requirements that were never formally agreed, in an environment it may not have fully validated, producing outputs with no authoritative record of what it changed or why.
This is not a hypothetical risk. It is the predictable outcome of deploying AI agents without the structural foundations that make human-executed automation trustworthy – approved requirements, reviewed designs, enforced phase boundaries, and a reconciled record after delivery. AI acceleration without those foundations does not eliminate the structural failures of informal practice. It reproduces them at machine speed and at larger scale.
The organizations advancing toward agentic operations safely are not doing so by constraining what their agents can do. They are doing so by ensuring agent execution occurs inside a governing operating model – one that defines the boundaries of agent authority, enforces phase transitions, and produces an auditable record of every action. SDD is that operating model. Itential is the platform that makes it executable.
The critical distinction: SDD practiced without platform enforcement degrades under AI acceleration. Agents produce well-formatted artifacts faster, but nothing enforces the gates. Nothing connects the spec to execution. Nothing makes the as-built record authoritative. The operating model exists on paper and is absent in practice. Platform enforcement is what converts SDD from a methodology into a governed system – and what makes agentic operations trustworthy at production scale.
The Execution Model
Three Agents, Five Stages: How Itential Executes SDD
Itential operationalizes the five SDD stages through three named agents. Each agent owns specific stages, is authorized to access specific platform capabilities, produces required artifacts, and cannot advance past a gate without explicit approval. The agent is the execution mechanism. The SDD operating model is the boundary that defines what it is authorized to do.
Stage 01
Requirements
Spec Agent
customer-spec.md
The Spec Agent runs requirements as a structured conversation – no platform access, no environment queries, no design work. It surfaces discovery questions about the use case, integration dependencies, operational constraints, blast radius, and acceptance criteria. It produces a written spec that captures what the automation must do, what success looks like, and what is explicitly out of scope.
Authorized to do
Conduct structured discovery conversation
Clarify scope, constraints, and success criteria
Produce and refine the customer spec document
Surface integration dependencies for feasibility
Not authorized to do
Access the platform or any environment
Make feasibility assumptions before Gate 1
Begin any design or implementation work
Advance to feasibility without Gate 1 approval
Requirements locked – spec approved in writing. No platform access, no environment authentication, no discovery until this gate is recorded.
Stage 02
Feasibility
Solution Architecture Agent
feasibility.md
Feasibility is the first point of platform access. The Solution Architecture Agent authenticates to the target environment via a scoped service account, inventories available API skills and integrations, validates platform capabilities against the approved spec, and identifies existing automation assets available for reuse. Findings that conflict with approved requirements surface as tradeoffs requiring a formal decision – not silent scope changes absorbed into design.
Authorized to do
Authenticate via scoped service account
Inventory available API skills & integrations
Identify reuse candidates in existing automation estate
Surface platform constraints against the approved spec
Not authorized to do
Redefine approved requirements based on findings
Absorb requirement conflicts silently into design
Begin any design or implementation work
Advance to design without an approved feasibility report
Stage 03
Design
Solution Architecture Agent
solution-design.md
The Solution Architecture Agent takes the approved feasibility findings and produces the solution design – the execution contract the build phase answers to. The design maps approved requirements to discovered capabilities: which components will be built, which assets will be reused, the dependency order for build, acceptance criteria per component, and the testing approach. Once approved at Gate 2, this document is the locked authority. Build does not interpret it – it executes it.
Authorized to do
Map requirements to feasibility findings
Specify component inventory & dependency order
Define reuse decisions and acceptance criteria
Produce the solution design document for review
Not authorized to do
Begin building any platform asset
Make design decisions not grounded in approved feasibility
Advance to build without Gate 2 approval
Execution contract locked – solution design approved. Build cannot begin until this gate is recorded. The approved design is the authority build answers to, not the agent's interpretation of it.
Stage 04
Build
Builder Agent
platform assets
The Builder Agent executes the approved design in dependency order – command templates, configuration primitives, and parsing logic before composite orchestration; child workflows before parent workflows. Assets are imported atomically. Where build encounters conditions not addressed in the approved design, those are surfaced as documented deviations – not resolved through ad-hoc judgment that bypasses the approved design.
Authorized to do
Build assets in approved dependency order
Import assets atomically to the platform
Verify each asset against approved acceptance criteria
Surface deviations for documentation
Not authorized to do
Reinterpret the approved solution design
Make scope decisions not authorized by the design
Skip acceptance criteria verification
Absorb deviations without recording them
Stage 05
As-Built
Builder Agent
as-built.md
After delivery is verified, the Builder Agent compares the implemented automation against the approved solution design and produces the as-built record. Deviations are documented – what changed, why it changed, what conditions required adaptation. The solution design is updated with an as-built section. Original artifacts are preserved. The reconciled record becomes the authoritative baseline for all future work on this use case – what the next engineer, the next agent, and the next audit start from.
Authorized to do
Compare delivered state against approved design
Document deviations and their causes
Amend spec & design additively, preserving originals
Produce the reconciled as-built record
Not authorized to do
Overwrite or replace original approved artifacts
Skip as-built production when no deviations occurred
Treat as-built as optional when delivery is clean
Govererned API Skills
Five Agents, Every Integration Surface as a Governed API Skill
The agents above execute the SDD lifecycle. What they execute against is the platform’s governed skill library – every system your automation touches, exposed as an API skill the platform orchestrates against the approved spec. Not open API access engineers manage themselves. Skills with defined inputs, defined outputs, and defined access boundaries that execute within the governance envelope the operating model establishes.
The Itential Skills package ships with five agents and works with any LLM. Three of those agents are the SDD delivery agents – they map directly to the five stages and own the lifecycle from requirements through as-built. The other two are Itential Platform agents that extend beyond the SDD lifecycle for agentic operations and governed conversion of exploratory work. The platform skills below are what all five agents invoke against your actual infrastructure.
SDD Delivery Agents – 3 Agents, 5 Stages
Three agents execute the five SDD stages. Each owns specific stages, produces a required artifact, and cannot advance past a gate without explicit approval. These are the agents that operationalize the operating model.
spec-agent
Spec Agent
Structured discovery conversation. Produces the approved customer spec. No platform access until Gate 1.
Stage 01 – Requirements
solution-arch-agent
Solution Architecture Agent
Platform discovery, integration validation, feasibility report and solution design production.
Stages 02 & 03 – Feasibility & Design
builder-agent
Builder Agent
Executes the approved design in dependency order. Imports assets atomically. Produces the as-built record.
Stages 04 & 05 – Build & As-Built
Itential Platform Agents – Agentic Operations on the Platform
Two additional agents extend the skills package beyond the SDD lifecycle. These operate directly on the Itential Platform – one for creating and running AI-powered agents within the platform, one for converting existing agent work into governed SDD deliveries.
flowagent
FlowAgent
Creates and runs AI-powered FlowAgents on the Itential Platform – LLM providers, tool definitions, and mission scopes. Agents execute within the governance boundaries the approved spec defines.
Agentic workflows & AI-driven operations on platform
flowagent-to-spec
FlowAgent to Spec
Takes an existing FlowAgent and produces a deterministic workflow spec – converting exploratory agent work into a governed SDD delivery path with proper documentation and artifact chain.
Bridge from agentic exploration to governed delivery
Utility Skills – Retrofit & Discovery
project-to-spec
Project to Spec
Reads an existing Itential platform project and reverse-engineers a spec and solution design from it – onboarding existing automation into SDD governance without starting from scratch.
Retrofit path for existing automation
explore
Explore
Authenticates to your Itential Platform environment and lets you browse what's available – adapters, integrations, existing automation assets – before committing to a formal SDD engagement.
Discovery before a formal engagement begins
Network & Device Skills – Governed Access to Network Infrastructure
itential-devices
Device Management
Governed access to network devices – configuration retrieval, backups, diffs, device groups. Every call traceable to the approved spec.
Network provisioning, change management, compliance
itential-golden-config
Golden Config
Golden config management against the approved compliance definition – drift detection, compliance grading, and remediation execution.
Configuration compliance, drift remediation
itential-mop
Method of Procedure
Command templates with validation rules – structured execution of network change procedures with pre/post validation gates.
Change management, software upgrades
itential-lcm
Lifecycle Manager
Resource models, instances, and lifecycle action execution – governed management of network service lifecycles from activation through decommission.
Service lifecycle, device onboarding & retirement
Infrastructure & Cloud Skills – Governed Access to Infrastructure APIs
iag-python
Python via IAG
Python scripts executed through the Itential Automation Gateway – governed, ephemeral runtimes with no dependency conflicts, running where your infrastructure lives.
Cloud APIs, drift detection, custom integrations
iag-ansible
Ansible via IAG
Ansible playbook execution through IAG – server configuration, hardening, patching, and infrastructure provisioning against the approved solution design.
Server compliance, OS patching, infrastructure config
iag-opentofu
OpenTofu via IAG
OpenTofu/Terraform plan and apply through IAG – cloud resource provisioning against the approved IaC specification, with pre/post validation and drift baseline capture.
Cloud provisioning, IaC delivery, VPC & resource lifecycle
iag-nornir
Nornir via IAG
<p style="font-size:18px;color:#ffffff;line-height:1.65;margEvery skill executes within the governance envelope. The Itential Automation Gateway distributes execution to wherever your infrastructure actually lives – network devices, on-prem servers, cloud APIs across AWS, Azure, and GCP – without losing the governance properties the SDD operating model requires. The skill is the governed interface. The gateway is what gets it there.
The Audit Record
The Artifact Chain as the Audit Record
Every SDD engagement executed through Itential produces a complete, linked sequence of artifacts – from the initial approved spec through the reconciled as-built record. This is the audit record. Every decision from intent to production state is traceable to the artifact that authorized it.
Approved Spec
customer-spec.md
Feasibility Report
feasibility.md
Solution Design
solution-design.md
Delivered Assets
automation + configs
As-Built Record
as-built.md
This chain answers the questions that informal practice cannot. What was the original requirement? What did feasibility find? What did the design approve? What was actually built? Where did it deviate and why? Every question an auditor, a compliance team, a future engineer, or a subsequent agent might ask is answered by the artifact chain – not by inspecting workflow code or relying on whoever built it to remember.
For agentic operations, the artifact chain is what makes machine-speed execution auditable. An agent that deploys automation in twenty minutes leaves the same artifact trail as a human engineer working over two weeks. The speed changes. The accountability does not.
What the Chain Enables on Day 2
Every Day 2 engagement – extension, debug session, modification, handoff – starts from the reconciled as-built record rather than from archaeology. The next engineer knows exactly what was built, what deviated from the design, and why. The next agent can be scoped against the same artifact chain. The compliance team has the evidence package they need without a post-delivery documentation sprint. The automation estate compounds rather than accumulates debt.
For compliance teams: The artifact chain from approved spec through as-built record is the evidence package for every automated change. Auditors can trace any delivered automation to its approved requirements and see exactly where implementation diverged from the design and why. This is not post-hoc documentation – it is a required output of the delivery process, produced by the platform as the engagement closes.
Goverened Autonomy
The Governed Autonomy Progression
Itential is the agentic operations platform for network and infrastructure automation. Agentic operations in Itential follow a trust progression – not a capability ladder, but a governance model. Each stage increases the scope of agent authority based on demonstrated reliability of agent execution. Human oversight shifts from execution-level to gate-level to policy-level. The SDD operating model remains constant throughout. What changes is who performs each stage and at what level humans maintain decision authority.
01
AI-Assisted SDD
Human-in-loop throughoutAgents draft artifacts – the spec, feasibility report, solution design, and as-built record. Human engineers review, refine, and approve each one. Build may still be human-executed. Agents accelerate artifact production; humans retain decision authority at every stage and gate. This is the appropriate starting point for teams introducing AI into an established SDD practice.
02
AI-Driven SDD
Human-at-gatesAgents execute all five stages. Human engineers govern both approval gates – Gate 1 locking requirements, Gate 2 locking the execution contract. Execution is agent-driven; governance is human-maintained. The human role shifts from builder and reviewer to approver. This is where most production deployments will operate as agent reliability is established through the AI-Assisted stage.
03
Governed Autonomy
Human-at-policy levelFor well-understood, low-blast-radius operations within a mature spec library, agents operate within pre-approved policy boundaries. A class of operations is approved, not individual requests. Agents execute and produce as-built records. Human oversight applies at the policy level – not per engagement. This stage requires a mature as-built record library to define the boundaries agents operate within.
The progression from Stage 1 to Stage 3 is earned, not assumed. Stage 3 autonomy for VLAN provisioning on a mature, reconciled automation estate is reasonable. Stage 3 autonomy for a new integration class with no prior as-built record is not. The artifact chain is what makes the advancement decision defensible – each engagement’s as-built record is evidence of agent execution quality that can be assessed before trust is extended further.
Most production infrastructure teams will operate at Stage 2. That is the correct posture for most production automation – and it produces significant value. Stage 3 is not a target for all use cases. It is appropriate for specific, well-bounded operations where the as-built record library is sufficient to define the policy boundaries agents operate within. The goal is not maximum autonomy. The goal is the right level of autonomy for each use case, with the governance to back it up.
The Spec Library
22 Ready-to-Use Starting Points
The Itential Builder Skills ship with 22 technology-agnostic High-Level Design specs – one for each of the most common network and infrastructure automation use cases. Each spec is a starting point, not a template to follow verbatim. Hand it to the Spec Agent, tell it what’s different about your environment, and it refines it for your specific infrastructure before kicking off a delivery.
Networking
Port Turn-Up
Networking
VLAN Provisioning
Networking
Circuit Provisioning
Networking
BGP Peer Provisioning
Networking
VPN Tunnel Provisioning
Networking
WAN Bandwidth Modification
Operations
Software Upgrade
Operations
Config Backup & Compliance
Operations
Network Health Check
Operations
Device Onboarding
Operations
Device Decommissioning
Operations
Change Management
Operations
Incident Auto-Remediation
Security
Firewall Rule Lifecycle
Security
Cloud Security Groups
Security
SSL Certificate Lifecycle
Infrastructure
DNS Record Management
Infrastructure
IPAM Lifecycle
Infrastructure
Load Balancer VIP
Infrastructure
Config Drift Remediation
Infrastructure
Network Compliance Audit
Infrastructure
AWS Webserver Deploy
The specs are available in the Itential Builder Skills GitHub repo. Clone the repo, pick the spec closest to your use case, and use the Spec Agent to refine it for your environment before kicking off a delivery. The repo also includes example environments and helpers – JSON scaffolds for workflows, templates, and projects – that accelerate the Build stage.
Getting Started
Entry Points by Automation Maturity
The right starting point depends on where your team is today. Three practical paths based on your current automation state.
If you have existing automation but no SDD
Start with project-to-spec
Before building anything new, establish a baseline. The project-to-spec skill reads existing platform projects and reverse-engineers a spec and solution design from what's already deployed. This produces the as-built record your existing automation never had – and makes it the starting point for all future Day 2 work on those use cases. Build the governance layer on top of what you already have, then extend it forward with SDD.
/itential-builder:project-to-spec
If you have SDD practice but no agents
Start at Stage 1 – AI-Assisted
Use the Spec Agent to draft requirements, the Solution Architecture Agent to produce feasibility reports and solution designs, and the Builder Agent to construct assets – but review and approve every artifact before advancing. Run three to five engagements at Stage 1 before evaluating whether agent artifact quality supports moving to Stage 2. The as-built records from those engagements are the evidence base for that decision.
/itential-builder:spec-agent
If you are starting from scratch
Start with the full model from day one
Teams starting without an existing automation estate have the advantage of building the spec library from engagement one. Every engagement produces a reconciled as-built record that compounds. The spec library becomes the agent's operating boundary library. The as-built collection becomes the training ground for advancing through the trust stages. Starting with the full SDD model is not harder – it is faster to a trusted, scalable automation estate than retrofitting governance later.
/itential-builder:spec-agent → solution-arch-agent → builder-agent
See It Running
Watch the Builder Skills execute a full SDD delivery – spec file to deployed automation – or talk to our team about applying the model in your environment.
Guide 01
What Is Spec-Driven Development?
Read Guide 1 →
Guide 02
SDD for Network & Infrastructure Automation
Read Guide 2 →
Guide 03
Spec-Driven Development for Agentic Operations with Itential
You Are Here