Stateful Infrastructure Orchestration

Infrastructure State That’s Always Current, Always Governed

Define resource models for any device or service across any domain, vendor, or infrastructure type. Generate them from plain language with AI. Every state change runs as a governed workflow so state is always current, always attributed, and always queryable.

Request a Demo Watch a Demo

The State Problem

Live Infrastructure State, Updated on Every Execution

Most infrastructure state management is either point-in-time, capturing what things looked like when you last ran a scan, or domain-specific, covering only the systems a single tool was built to manage. Itential’s stateful orchestration layer is operational and continuous. State updates automatically every time a governed workflow executes, across network devices, cloud instances, virtual services, and IT systems simultaneously. Every change attributed to the workflow that made it. Every instance queryable in real time.

How to Productize Network Services with Stateful Orchestration

Resource Models

Generate Resource Models From Plain Language

Resource models define the schema, typed properties, relationships, and lifecycle stages for any infrastructure resource type: network devices, cloud instances, virtual network functions, SD-WAN controllers, and any custom service type. Define them manually in JSON schema, or describe what you need in plain language and an Itential Builder Skill generates the model via the platform’s REST APIs, committed to Git in one step. Any domain. Any vendor. No proprietary modeling language required.

Explore Builder Skils

Builder-Skill-Generated Resource Models

Describe the resource type and an Itential Builder Skill generates the model via platform REST APIs: typed properties, lifecycle stages, CRUD scaffolding, committed to Git automatically.

Readable, Versionable, Extensible JSON

Standard JSON schema, readable and extensible by any engineer without specialized tooling, version-controlled in Git alongside the workflows that operate on them.

Any Resource Type, Any Domain

Network devices, cloud instances, virtual network functions, SD-WAN controllers, security services. Any infrastructure resource modeled across any domain in one state layer.

Governed State Changes

Every Infrastructure Change Validated & Attributed

State changes aren’t database writes. They’re governed workflow executions. Every Create, Update, and Delete triggers a workflow with pre/post validation, approval gates, blast-radius controls, and an immutable audit trail before state is updated. A Day 0 Create applies configuration across every required domain via Itential Gateway, validates the outcome, and creates the resource instance in one governed execution path. The state record reflects what actually executed, not what was intended.

Watch the Demo

Create: Day 0 Provisioning as a Governed Workflow

Provisioning creates a tracked instance: configuration applied across every required domain, CMDB updated, ITSM ticket closed, all initial property values captured and attributed.

Update: Day 2 Operations With Validation

Every property update triggers a governed workflow: change validated, applied across affected systems, instance record updated with the exact workflow that changed it.

Delete: Governed Decommission With Dependency Validation

Dependencies validated before any removal, configuration removed across all domains, downstream records updated, instance archived with complete change history through retirement.

Agent Context

The Context Layer for Accurate Agent Reasoning

Before a FlowAgent reasons through any infrastructure action, it queries the stateful orchestration layer for current resource state: typed properties, change history, service dependencies, compliance posture, and lifecycle stage, all returned as structured context in one query. The agent acts on facts, not assumptions from stale documentation. After execution, state updates automatically in the same workflow path so every subsequent agent query reflects what’s actually running.

AI Reasoning for Network Automation: How It Works

Agents Query Structured State Before Acting

FlowAgents pull resource state from the platform’s internal tool library, returning typed properties, change history, compliance posture, and lifecycle stage as structured context the agent can act on. No log parsing. No shell scraping. No stale documentation.

External AI Systems Get the Same Structured Access

Any connected LLM or AIOps platform queries infrastructure state through the MCP Server: schema-validated, RBAC-enforced, audited. Write access only through governed CRUD workflows.

State Updates Automatically After Every Execution

When a workflow updates infrastructure, the instance record updates in the same execution path. No separate sync step, no reconciliation job.

AI-Driven Lifecycle

AI-Driven Lifecycle Operations at Scale

Resource models define what a resource is. Lifecycle workflows define what happens to it. Itential Builder Skills generate both. Describe a Day 2 operation: a software upgrade, a compliance remediation, a configuration standardization. The Builder Skill generates the workflow that operates on the resource model, commits to Git, and CI/CD deploys it automatically. A FlowAgent then queries current state across thousands of instances simultaneously, identifies scope, and calls the workflow as a governed tool. No manual inventory work. No discovery scans. The full lifecycle, at scale.

AI-Driven Lifecycle Management

Workflows That Operate on Resource Models

Resource models define what a resource is. Lifecycle workflows define what happens to it across Day 2 operations: software upgrades, compliance remediation, configuration standardization. Builder Skills generate both, governed identically.

Agents Identify Scope Automatically

FlowAgents query the state layer to identify exactly which instances need a lifecycle operation. No manual inventory work. No discovery scans. The scope of the operation falls out of the state query.

Workflows Run as Callable Agent Tools at Scale

Lifecycle workflows live in the FlowAgent’s allowlisted tool library with structured inputs, defined outputs, and governed execution. Agents call them in parallel across thousands of instances, no direct infrastructure access required.

Drift Detection

Intended vs. Actual State, Visible & Remediable

For every tracked instance, the stateful orchestration layer compares intended state defined in the resource model against actual state recorded by LCM. Drift is flagged at the property level: specific configuration values, version strings, interface states. Remediation runs through governed Actions with validation, approval gates, and audit history, the same execution model as any other state change.

How to Productize Network Services with Stateful Orchestration

Property-Level Drift Detection

Every tracked instance is compared against its resource model schema. Drift surfaces at the property level: specific config values, version strings, interface states. Engineers know exactly what changed and when.

Drift Remediation Through Governed Actions

Drift response runs through governed Actions: Create, Update, or Delete workflows with validation, approval gates, and audit history. Whether a remediation is auto-triggered or routed for human review is configured at the workflow level, not improvised.

Audit History at Every Property Change:

Every Action against an instance is recorded: which property changed, by which workflow, at what time, with what approver. LCM maintains a complete history that auditors and engineers can query.

Use Cases

Stateful Orchestration in Action

What stateful orchestration looks like at customers managing real infrastructure. Define resource models. Generate them from plain-language specs. Provision through ITSM. Run agent-driven lifecycle operations at scale. Audit every state change. Every example below runs through Lifecycle Manager’s governed Action engine with property-level attribution and an immutable change history.

Explore Demo Library

Agent-Driven Operations

Server Patching Across Thousands of Instances, Governed

A FlowAgent queries LCM for software version across every tracked server, identifies patch candidates, and calls the patch Action as a governed tool. The Action runs in parallel through Itential Gateway with pre/post checks. Every patched instance updates its state automatically. The agent never touches infrastructure directly.

Watch the Demo

Audit Evidence

Always-Ready Audit Evidence for Every Lifecycle Change

Every state change is attributed to the Action that made it, with the workflow, timestamp, approver, and before/after property values captured in the instance record. When auditors ask who provisioned what, when, and what changed, LCM has the answer. No manual reconstruction from logs.

Watch the Demo

Service Lifecycle

Turn ITSM Tickets Into Governed Service Instances

A ServiceNow request triggers a governed Create Action. LCM provisions every component across network and cloud domains, captures the instance’s full property set, updates the CMDB, and closes the ticket. At end of life, a governed Delete validates every dependency and archives the complete service history.

Watch the Demo

Spec-Driven Development

Generate a Resource Model From a Plain-Language Spec

An engineer describes the resource they want to model: a hybrid cloud service with X properties, lifecycle stages from Day 0 through decommission, and the Actions that operate on each. An Itential Builder Skill calls the platform’s REST APIs to generate the JSON Schema model and the Create, Update, and Delete Action scaffolding. The model commits to Git, CI/CD deploys it, and LCM is tracking instances within minutes. From spec to production-ready resource, no engineer building schema and Action workflows from scratch.

NEED SOMETHING HERE

Get Started

Dive Deeper into Stateful Orchestration with Itential

Demos

AI-Driven Lifecycle Management for Infrastructure Provisioning

Watch now

Webinars

End-to-End Infrastructure Lifecycle — How Itential LCM Turns Tickets into On-Demand Services

Watch now

Guides & Whitepapers

AI Agents for Infrastructure: A Practical Taxonomy of Agent Types, Paradigms, & When to Use Each

Frequently Asked Questions

–+

Terraform manages the state of cloud resources it provisions, but that state is a file, not a governed execution layer. When something changes outside Terraform, state drifts with no attribution and no record of what changed it or when. Day 2 operations require additional tooling or manual intervention, with no approval gates, no human-in-the-loop controls, and no audit trail. Cisco NSO provides YANG-based model-driven configuration management for network devices but requires deep YANG expertise to extend and has limited integration with IT systems outside the network domain. Itential’s stateful orchestration layer covers what both leave unaddressed: every state change is a governed workflow execution, with pre/post validation, approval gates, and an immutable audit trail. Resource models use standard JSON schema, not YANG, so any engineer can define and extend them. Terraform and Cisco NSO can both be called as governed steps inside Itential workflows.

–+

FlowAgents query Lifecycle Manager directly through the platform’s internal tool library before reasoning through any action. The agent receives structured context in one query: current typed property values, recent change history, software version, compliance posture, service dependencies, and lifecycle stage. This structured context is what makes agent reasoning accurate. Agents act on facts from a live state layer, not assumptions from documentation or log parsing. After an agent-initiated workflow executes, the affected instance records update automatically in the same execution path. Every subsequent agent query reflects the actual current state. External LLMs and AIOps platforms access the same state through the Itential MCP Server, schema-validated and RBAC-enforced before anything executes.

–+

A resource model defines the schema for a class of infrastructure resource: typed properties, relationships between resources, lifecycle stages, and the CRUD Actions available at each stage. Think of it as the template. What properties does a network device have, what lifecycle stages does it move through, what governed workflows run at each transition? A resource instance is a specific real-world occurrence of that model: a particular router, a deployed VPN service, a cloud instance. Every instance carries its own state record with current typed property values, an immutable change history, and a reference to every workflow that changed it. Models can be defined in JSON schema manually or generated from plain language using Itential Builder Skills. Both produce the same governed artifact.

–+

For every tracked instance, Lifecycle Manager compares intended state defined in the resource model against actual state recorded by LCM. Drift surfaces at the property level: which specific config values, version strings, or interface states deviate from intended. Remediation runs through governed Actions: Create, Update, or Delete workflows with validation, approval gates, and audit history. Whether remediation auto-triggers or routes for human-in-the-loop review is configured at the workflow level, not improvised. One important caveat: changes made outside LCM (out-of-band on the device or through other tools) aren’t automatically reflected in LCM state. Workflow Actions are the canonical path for state updates, and external change detection requires explicit integration.

–+

Yes. Resource models are defined in standard JSON schema, not a proprietary or vendor-specific modeling language. Any infrastructure resource with a programmatic interface can be modeled: custom network controllers, proprietary cloud services, homegrown platforms, third-party systems. Define the typed properties you want to track, the lifecycle stages the resource moves through, and the CRUD Actions that govern state changes. The platform generates the REST API endpoints and MCP tool exposure for that model automatically. Or describe the resource type in plain language and an Itential Builder Skill generates the model definition and CRUD workflow scaffolding, committed to Git and deployed in one step.

–+

Yes. Every state change executed through Lifecycle Manager is captured as a structured record: which Action ran, which workflow it called, the inputs received, the approver if approval gates fired, the timestamp, and the before-and-after property values on the affected instance. The complete change history for any resource is queryable, exportable, and immutable. When an auditor asks who provisioned a service, when, what changed across its lifecycle, and what evidence supports compliance, LCM has the structured answer. No manual reconstruction from logs, no piecing together CMDB snapshots.

Get Started

Ready to See Itential in Action?

See how stateful orchestration fits your infrastructure.

Talk to an Expert