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.
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.
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.
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.
The execution layer connects directly to your Git repository. Every execution runs the latest committed version. No manual deploys. No version drift.
Manage execution services, publish automations, and define decorators from the command line. Fits into existing CI/CD and GitOps workflows without friction.
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
AI agent skills that generate real Python scripts, Ansible playbooks, and OpenTofu plans through the platform’s REST APIs. Available today, installable in minutes.
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.
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.
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.
Full support for Python scripts, Ansible modules, playbooks, roles, and collections, plus OpenTofu plans, all managed and executed from one governance layer.
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.
Access controls, secrets injection, audit logging, and approval gates apply consistently across every execution type. Same governance model, every time.
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.
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.
Run the same playbook against 500 devices simultaneously, each execution fully isolated. Failures in one execution don’t affect any other.
The execution layer manages runtime creation automatically. No shared venvs to maintain, no server patching cycles disrupting automation, no dependency upgrade coordination across teams.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.