Network Automation with Python, Ansible and AI Agents

The toolset

• Python libraries: Netmiko for SSH CLI sessions, NAPALM for a vendor-neutral getter and configuration API, ncclient for NETCONF, and pyATS with its parsers for testing and state comparison.
• Ansible: agentless automation with vendor network collections (for example cisco.ios, cisco.nxos and cisco.iosxr), connection plugins such as network_cli and netconf, and check and diff modes.
• AI agents: language models that read inventory and state through tools, draft plans and playbooks for review and explain results.

Inventory and discovery

Automation is only as good as its inventory. Maintain a source of truth for devices, roles, sites and management addresses, and generate automation inventory from it rather than maintaining separate lists. Discovery jobs then compare what the source of truth expects with what the network reports, such as software versions, neighbours and interface states, and flag the differences for review.

Configuration management

Declarative modules describe the desired state and let the module work out the commands. Ansible network resource modules support states such as merged, replaced and overridden, which differ in how much existing configuration they touch. Choosing the narrowest state that achieves the goal limits unintended removals.

- name: Add voice VLAN
  hosts: site_access_switches
  gather_facts: false
  tasks:
    - name: Ensure VLAN 30 exists
      cisco.ios.ios_vlans:
        config:
          - vlan_id: 30
            name: VOICE
        state: merged

Running the playbook with --check --diff shows the intended changes without applying them, which gives reviewers something concrete to approve.

Change validation

1. Capture a pre-change snapshot of the features the change touches, for example interfaces, VLANs and routing.
2. Apply the approved change.
3. Capture a post-change snapshot with the same collection.
4. Compare the snapshots and assert the expected differences, and only those, are present.

pyATS supports this pattern directly: it can learn device features into structured objects and produce a diff between two snapshots. Assertions should be specific, such as VLAN 30 active on the listed ports, rather than a general sense that nothing looks broken.

Rollback concepts

Rollback has to be designed before the change, not improvised after it. Platforms offer different mechanisms:

• Commit-confirmed models, as on Cisco IOS XR and Junos, apply a change and revert it automatically unless it is confirmed within a set time.
• Cisco IOS XE supports configuration archives and configure replace to return to a saved configuration, and a revert timer that requires confirmation.
• Where no native mechanism exists, keep a verified backup and a tested reverse procedure for each step.

Where AI agents fit

• Translate a request into a scoped plan and list the pre-checks it needs.
• Draft or adapt playbooks for an engineer to review, not to run unreviewed.
• Read discovery and diff output and explain it in plain language.
• Never hold device credentials or decide on their own to apply a change.

Operational safeguards

• Change windows and approved targets enforced by the automation, not only by policy.
• Canary first: apply to one device, verify, then continue in small batches.
• Stop conditions: halt the run on the first failed verification instead of continuing.
• Concurrency and rate limits to protect controllers and devices.
• No automatic retry of a change after a lost connection until the device's real state is known.