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.
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.
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.
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.
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.
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.
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.
Requirements locked – spec approved in writing. No platform access, no environment authentication, no discovery until this gate is recorded.
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.
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.
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
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
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
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
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
Nornir-based network automation through IAG – Python-native multi-vendor device automation against the approved solution design, with structured task inventories and parallel execution.
Multi-vendor network automation, structured Python workflows
Every 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.
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.
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.
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.
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 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.
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