Configuration Management

The Configuration Management system acts as the digital archives and safety mechanism for your network, allowing you to back up device settings, detect unauthorized changes (drift), and deploy new configurations with mandatory human approval. It ensures that every change to a router, switch, or firewall is recorded, justified, and reversible.

Sources: CLAUDE.md, README.md, backend/app/plugins/vendors/cisco_nxos/plugin.py:255-258

Overview

The platform provides a self-hosted AI assistant for network operations teams. It solves the problem of manual, error-prone configuration changes by providing a "human-in-the-loop" workflow where an AI drafts changes but a human must approve them before they are pushed to production.

Support and Philosophy

The platform supports a wide range of vendors including Cisco (IOS, IOS-XE, NX-OS), Juniper JunOS, Arista EOS, Palo Alto PAN-OS, Fortinet FortiOS, F5 BIG-IP, and DDI providers like BlueCat and Infoblox. It also integrates with cloud environments like AWS, Azure, and VMware.

The design philosophy is built on four pillars:

• Local-first & Self-hosted: All data and AI processing stay within your infrastructure.
• Human Approval: No AI can change the network without a second human verifying the request.
• Auditability: Every decision made by the AI and every command sent to a device is logged.
• Explainability: The AI provides the rationale for why it suggests a specific configuration.

Sources: CLAUDE.md, README.md

Specialized "Specialist" Agents

The platform routes your requests to specialized "Specialists" who act like members of your engineering team. For configuration tasks, the Configuration Agent handles drift and compliance, while the Automation Agent handles the actual execution of approved changes.

Sources: CLAUDE.md, backend/app/llm/prompts/init.py:192-205

Architecture

The system consists of seven major components working together to manage your network infrastructure:

• Frontend: The web console where you chat with the AI, view the topology map, and approve change requests.
• API: The central brain that handles security, user sessions, and coordinates between the web console and the background engines.
• Worker: The background engine that runs discovery jobs, takes config backups, and captures packets without blocking your session.
• Postgres: The main database (System of Record) that stores your inventory, change history, and text search data.
• Neo4j: A living topology map that tracks how every device, interface, subnet, DNS zone, and application connects to everything else.
• Redis: A high-speed temporary storage used for passing messages between the API and the background workers.
• Ollama: An optional local service that runs the AI models entirely on your own hardware for maximum privacy.

Sources: README.md, deploy/docker/docker-compose.yml:18-190

Vendor Plugin System

The platform uses a standardized connector for each vendor. No matter whether you are talking to a Cisco router or a BlueCat Address Manager, the platform normalizes the output into a consistent format before doing anything with it. This allows the AI to understand "routing tables" or "interfaces" generically across different manufacturers.

Sources: README.md, backend/app/plugins/vendors/cisco_nxos/plugin.py:1-40

Deployment Options

1. Docker Compose: Ideal for lab environments or small teams. It runs the entire platform on a single server using a simplified setup.
2. Kubernetes/Helm: The production-grade option. It supports multi-node deployments, high availability, and advanced security hardening like seccomp profiles for packet analysis.

Sources: README.md, deploy/docker/README.md, deploy/kubernetes/netops/Chart.yaml

Change Approval Workflow

Every configuration change follows a strict lifecycle to prevent accidental outages.

1. Draft: An engineer asks the AI to make a change (e.g., "Add VLAN 10 to core-sw-01"). The AI drafts a Change Request (CR).
2. Pending Approval: The CR appears in the dashboard. A second human must review the proposed commands and the AI's rationale.
3. Approved: Once a human clicks approve, the CR moves to the execution queue.
4. Executing: The Automation Agent takes a pre-change backup of the device. It then pushes the new configuration.
5. Completed or Rolled Back: If the change is successful and verified, it is marked completed. If the change fails or reachability is lost, the system automatically rolls back to the pre-change backup.

Sources: README.md, backend/app/agents/ddi/agent.py:18-35, backend/app/plugins/vendors/cisco_nxos/plugin.py:255-380

Diagrams

System Overview

This diagram shows how users interact with the platform and how the platform connects to your infrastructure and AI providers.

Explanation: The user interacts with the Frontend, which communicates with the API. The API uses Workers to talk to network devices and DDI systems, while storing state in the databases and getting intelligence from the LLM.

Sources: README.md, deploy/docker/docker-compose.yml

Agent Routing

When you send a message, the "Master Architect" decides which specialist should handle it.

Explanation: The Master Architect routes questions to specialists. "Read" tasks like viewing an inventory are immediate, while "Write" tasks like changing a config are sent to the Approval Gate.

Sources: CLAUDE.md, backend/app/llm/prompts/init.py:206-350

Configuration Data Model

This represents what the platform knows about your network connections (the "Living Topology Map").

Explanation: Devices have Interfaces which are part of Subnets. Devices also belong to VLANs. DNS records link names to Devices, and Applications are mapped to the Devices they run on.

Sources: CLAUDE.md, backend/tests/agents/documentation/test_documentation_agent.py:50-130

Technical Implementation Details

Configuration Capabilities (Cisco NX-OS Example)

The platform defines specific capabilities for each vendor to manage configurations safely.

Sources: backend/app/plugins/vendors/cisco_nxos/plugin.py:460-490

Safety Guardrails

The platform includes "Management Path" protection. It will refuse to deploy a change if it detects the commands might shut down the management interface (like mgmt0) or remove the management VRF, which would strand the worker and prevent a rollback.

# Safety check to ensure we don't lock ourselves out
def _management_path_hits(baseline, end_state):
    # Detects if change touches management VRF or mgmt interfaces
    # Rejects if reachability to the platform might be lost

Sources: backend/app/plugins/vendors/cisco_nxos/plugin.py:315-350

Summary

Configuration Management in the AI Network Operations Platform provides a secure, audited, and human-verified way to manage network device settings. By using specialized agents, a standardized plugin system, and a strict approval workflow, it reduces the risk of manual configuration errors while maintaining a complete history of all changes made to the infrastructure.

Sources: README.md, CLAUDE.md