Itential logo
Automation Engineering

Build, Manage, & Execute Automation Across Every Domain

Generate Python scripts, Ansible playbooks, and OpenTofu plans from plain language using Spec-Driven Development, committed to Git and ready to execute immediately. Or bring what you already have. Either way, every automation becomes a governed, callable service.

The Automation Engineering Tax

From Scattered Scripts to Governed Automation Services

Every network team has a library of automation assets: Python scripts, Ansible playbooks, OpenTofu plans. The problem isn’t the automation. It’s the tax around it. No standard execution environment, no governed access, no audit trail, just Flask wrappers and shared environments nobody owns. Itential brings the standardization that’s missing. Onboard the scripts your team already wrote through Git sync. Generate new automations from plain language with Spec-Driven Development. Every automation, old or new, becomes a callable, governed service – invokable by workflows, agents, and CI/CD pipelines, with RBAC, secrets injection, and rollback enforced on every execution.

Git Sync & Decorators

Bring Your Own Automations

Every Python script, Ansible playbook, OpenTofu plan, Nornir module, Netmiko script, and Scrapli interaction your team has already built can be onboarded without modification. Connect to your Git repository (GitHub, GitLab, or Bitbucket) and the execution layer syncs automatically. Apply a JSON schema decorator to any automation to auto-generate a REST API endpoint. A personal script becomes a callable, governed service.

Decorators: JSON Schema to REST API in Minutes

Define input parameters using a JSON schema decorator. The platform auto-generates a documented REST API endpoint callable by workflows, agents, and CI/CD pipelines.

Real-Time Git Sync: Always Current

The execution layer connects directly to your Git repository. Every execution runs the latest committed version. No manual deploys. No version drift.

iagctl: CLI-First Management

Manage execution services, publish automations, and define decorators from the command line. Fits into existing CI/CD and GitOps workflows without friction.

Spec-Driven Development

Generate Production Automations From Plain Language

Itential Builder Skills are AI agent skills available on the Anthropic Marketplace that let any team generate automation artifacts from plain language. Describe what you need: a Python script to collect show command output, an Ansible playbook to push a software upgrade, an OpenTofu plan to provision a VPC. The Builder Skill generates the artifact, commits it to your Git repository, and the execution layer syncs it automatically. Immediately executable, governed, and callable by workflows, agents, and pipelines from the first run

icon of a cog and lines of text or code
Itential Builder Skills on the Anthropic Marketplace

AI agent skills that generate real Python scripts, Ansible playbooks, and OpenTofu plans through the platform’s REST APIs. Available today, installable in minutes.

Git-Native, Immediately Executable

Every Builder Skill commits its output to your Git repository. The execution layer syncs automatically, running the latest committed version without a manual deploy step.

Same Governance From Run One

Builder-Skill-generated automations are governed identically to hand-built ones: RBAC, secrets injection, audit trails, callable by workflows and agents from the first execution.

Multi-Executor Support

Every Executor in One Governed Layer

Network infrastructure automation isn’t one tool. It’s many. Python for custom logic. Ansible for multi-vendor configuration management. OpenTofu for cloud infrastructure. Nornir for concurrent device operations. Netmiko and Scrapli for CLI device interaction via SSH. The platform manages all of them from one place: one RBAC model, one audit trail, one Git sync, one secrets management layer, regardless of which executor runs.

Python, Ansible, & OpenTofu Plans

Full support for Python scripts, Ansible modules, playbooks, roles, and collections, plus OpenTofu  plans, all managed and executed from one governance layer.

Nornir, Netmiko, Scrapli for CLI Device Operations

Concurrent device operations via Nornir, command execution via Netmiko, modern platform interaction via Scrapli, all through the same governed execution environment as Python and Ansible.

One RBAC Model, Every Executor

Access controls, secrets injection, audit logging, and approval gates apply consistently across every execution type. Same governance model, every time.

Since we deployed Itential, the speed at which we are developing automations and innovation has increased massively.
Shirish Basant Rai
Network Platforms & Systems Architect, Colt
Ephemeral Runtimes

Consistent Execution, Zero Dependency Management

The execution environment problem is one of the biggest hidden taxes in network automation engineering: shared virtual environments, dependency conflicts between Ansible collections, Python version mismatches that break playbooks in production but not in development. The Itential Gateway eliminates this entirely by creating a dedicated ephemeral runtime environment for every execution. Dynamically built, always consistent with the committed automation version, destroyed after execution completes. Concurrent executions never conflict.

Ephemeral Environments Per Execution

Every execution gets its own dynamically created runtime with the correct Python version and dependencies, built instantly and destroyed after completion. No shared state between executions.

Concurrent Execution Without Conflict

Run the same playbook against 500 devices simultaneously, each execution fully isolated. Failures in one execution don’t affect any other.

No Server Management, No Environment Maintenance

The execution layer manages runtime creation automatically. No shared venvs to maintain, no server patching cycles disrupting automation, no dependency upgrade coordination across teams.

Secrets & Credentials

Credentials Injected at Runtime, Never Exposed

Device credentials, API keys, vault tokens. The things every automation needs and the things that never belong in a script. The Itential Gateway integrates with HashiCorp Vault, CyberArk, AWS Secrets Manager, and its own secrets store, retrieving the right credentials at runtime and injecting them into each ephemeral execution environment. Engineers reference secrets by name in decorators. The Itential Gateway handles the rest. Secrets never appear in automation files, in execution logs, or in Job Viewer output.

Native Integration With Vault, CyberArk, AWS Secrets Manager

Itential Gateway integrates directly with HashiCorp Vault, CyberArk, AWS Secrets Manager, and its own native secrets store. Use the secrets management system your security team already approves.

Runtime Injection, Per-Execution Scope

Secrets are retrieved at execution start, injected into the ephemeral runtime as environment variables or Ansible vault variables, and discarded when the runtime is destroyed. Each execution sees only the credentials it needs.

Never Stored in Files or Logs

Secrets never live in scripts, playbooks, decorators, or Git. Never appear in execution logs. Never show up in Job Viewer output. Auditors get attribution. Engineers don’t get blast radius.

Callable as Services

Every Automation Available to Agents, Workflows & Pipelines

An automation isn’t valuable until other things can call it. Every automation onboarded through Git sync or generated by a Builder Skill is automatically registered as a callable service across the platform. FlowAgents add it to their tool library. Workflows invoke it as a governed step. CI/CD pipelines hit it as a REST endpoint. Engineers can still run it from the iagctl CLI. One automation, every consumer.

FlowAgent Tool Library Registration

Every automation is registered in the FlowAgent tool library with structured inputs and outputs. Agents include them in their allowlisted skill set, call them with reasoned inputs, and observe the structured result. Agents reason. Automations execute.

REST API Endpoint Per Automation

Every decorated automation auto-generates a documented REST API endpoint. Callable from CI/CD pipelines, ITSM platforms, monitoring tools, or any system that speaks HTTP, with schema validation, RBAC, and audit logging applied automatically.

FlowMCP Gateway for External AI

External LLMs and AI systems access automations as callable skills through FlowMCP Gateway. Schema-validated, RBAC-enforced, and audited before anything executes. Bring your own AI. Govern every action.

Use Cases

From Script to Governed Service

Every example below runs through the same governed execution layer: ephemeral runtime, injected secrets, RBAC enforced, audit trail attached. Whether the automation came from your existing Git repo, a Builder Skill, or both, every execution looks the same to operators, agents, and auditors. Same engine. Same governance. Every run.

Bring Your Own Automation

Onboard Years of Automation Work Without Rewriting It

Connect your existing Ansible, Python, OpenTofu, Nornir, Netmiko, and Scrapli repos. The Gateway syncs the entire library, applies JSON schema decorators, and turns every script and playbook into a callable governed service. Engineers keep working in their IDE. The team gets governance, RBAC, and audit on every execution overnight.

Watch the Demo
Spec-Driven Development

Generate a Production Automation From a Plain-Language Spec

An engineer describes the automation they need to an AI assistant powered by an Itential Builder Skill. The Skill generates the Ansible playbook or Python script, commits to Git, and the Gateway syncs and runs it within minutes. From spec to a real, governed automation, no engineer building anything from scratch.

Watch the Demo
Ephemeral Runtimes

10,000 Concurrent Executions, Zero Dependency Conflicts

A PSIRT-driven remediation runs the same Python script against 10,000 devices simultaneously. Each execution gets its own ephemeral runtime with the right dependencies. Credentials inject per execution from Vault. Failures in one execution don’t affect any other. No shared venvs, no version drift, no late-night dependency triage.

Watch the Demo
Callable as Services

Every Automation Reachable from Agents, Workflows, AI & Pipelines

A FlowAgent calls a Python script from its tool library. A workflow invokes the same script as a governed step. A CI/CD pipeline hits it as a REST endpoint. An external LLM accesses it through FlowMCP Gateway. One automation. Every consumer. Every execution governed identically.

Watch the Demo

Dive Deeper into Automation Engineering with Itential

Frequently Asked Questions

+

The DIY approach to turning Python scripts and Ansible playbooks into callable services means building and maintaining the execution layer yourself: Flask apps to expose scripts as APIs, Jinja2 templates for input rendering, virtual environment management per automation, custom RBAC bolted on top, audit logging built from scratch, and a Jenkins job or cron script acting as a pseudo-execution layer. Every one of those components is custom code your team owns, maintains, and debugs when something breaks in production. The platform replaces that entire stack – JSON schema decorators auto-generate REST APIs for any script, playbook, or plan. Ephemeral runtimes eliminate venv management. RBAC, secrets injection, and audit logging apply automatically to every execution. SDD generates new automations from plain language without writing a line of code. The automation engineering tax disappears entirely.

+

Ansible Automation Platform is an excellent managed execution environment for Ansible – it handles Ansible playbook execution, inventory management, scheduling, and basic RBAC well within the Ansible ecosystem. Where it falls short: it’s Ansible-specific. Python scripts, OpenTofu plans, Nornir modules, Netmiko scripts, and Scrapli interactions require separate execution infrastructure outside AAP. There’s no SDD capability to generate Ansible playbooks from plain language and commit them to Git automatically. And there’s no native path for FlowAgents to invoke Ansible playbooks as governed tools through an MCP interface. Itential’s execution layer runs Ansible alongside every other automation type under one governance model – and existing Ansible playbooks from AAP can be called as governed steps inside Itential workflows without modification.

+

Nautobot and NetBox are network source of truth and IPAM platforms – they track what your network looks like, store inventory, and model network data. Network to Code builds and maintains these platforms and provides professional services around them. None of them are automation execution platforms. They don’t execute Python scripts or Ansible playbooks, they don’t govern who can run what automation against which devices, they don’t create ephemeral runtime environments, and they don’t expose automations as governed REST API endpoints callable by agents and pipelines. Itential complements Nautobot and NetBox directly – the execution layer queries Nautobot or NetBox for device inventory and configuration intent via REST API, then executes governed automations against the devices those platforms track.

+

Every automation engineering capability is exposed as a documented REST API endpoint. The Itential MCP Server exposes those APIs as callable skills for any connected LLM. Describe the automation you need – its purpose, the devices it targets, the inputs it requires, the expected output – and the LLM calls the platform’s REST APIs to generate the automation artifact: a real Python script, Ansible playbook, or OpenTofu plan. The artifact commits to your Git repository automatically. The execution layer syncs it immediately – it’s executable, governed, and callable from the first run. The output is identical to a hand-built automation in every technical respect – same file format, same Git workflow, same execution behavior, same governance.

+

Secrets – device credentials, API keys, vault tokens – are never stored in automation files or passed as plain text inputs. The execution layer integrates with secrets management systems – HashiCorp Vault, CyberArk, AWS Secrets Manager, and platform-native secrets storage – and injects the correct credentials at runtime for every execution. Engineers define which secret a decorator input maps to at configuration time. At execution time, the platform retrieves the secret, injects it into the runtime environment, and the automation accesses it as an environment variable or Ansible vault variable. Secrets are never exposed in execution logs, never visible in Job Viewer outputs, and never accessible to the automation beyond the scope of the execution that required them.

+

Every decorated automation is automatically registered as a callable tool in the FlowAgent tool library – structured input schema, defined output schema, governed execution. When a FlowAgent reasons through a goal that requires running an automation – collecting show command output from a device group, pushing a configuration change, running a validation script – it calls the automation tool with structured inputs from its allowlisted skill set. The execution layer creates an ephemeral runtime, runs the automation with injected secrets, captures the output, and returns it as structured data to the agent’s reasoning loop. The agent uses the output to continue reasoning – deciding the next step, evaluating the result, or triggering a follow-on workflow. The agent never touches infrastructure directly. The execution layer controls what actually runs.

Get Started

End the Script Sprawl

Personal Python scripts. One-off Ansible playbooks. Jenkins jobs nobody owns. See how Itential standardizes the chaos and makes every automation a callable, governed service.

Talk to an Expert