The Vendor Plugin System

Relevant source files

The following files were used as context for generating this wiki page:

• CLAUDE.md
• README.md
• backend/pyproject.toml
• deploy/docker/README.md
• deploy/kubernetes/netops/README.md
• backend/app/plugins/vendors/cisco_nxos/parsers.py
• backend/app/agents/documentation/agent.py

The Vendor Plugin System acts as a standardized connector for every hardware manufacturer and cloud provider the platform manages. It translates vendor-specific command outputs—like a Cisco "show ip route"—into a consistent, universal format that the AI can understand and use regardless of which device it is talking to.

Sources: README.md, backend/app/plugins/vendors/cisco_nxos/parsers.py:1-15

1. Overview

The AI Network Operations Platform is designed as a self-hosted AI assistant for network operations teams. Its primary purpose is to help engineers discover infrastructure, troubleshoot routing and security issues, and manage changes across a multi-vendor environment using plain English.

The platform supports a wide array of vendors and protocols, including:

• Routing & Switching: Cisco (IOS, IOS-XE, NX-OS), Juniper JunOS, Arista EOS.
• Security: Palo Alto PAN-OS, Fortinet FortiOS.
• Application Delivery: F5 BIG-IP.
• DDI (DNS, DHCP, IPAM): BlueCat, Infoblox.
• Cloud & Virtualization: AWS, Azure, VMware.

The design philosophy prioritizes a "local-first" and secure approach. Every change requested by the AI requires a human to approve it before execution, and every decision made by the AI is fully explained and logged for auditing. Interaction with the platform is handled by specialized "agents"—think of these as virtual team members with specific expertise, such as the Troubleshooting Agent for fixing outages or the DDI Agent for managing IP addresses.

Sources: CLAUDE.md, README.md, backend/app/agents/documentation/agent.py:12-25

2. Architecture

The platform is composed of seven core components that work together to provide the AI assistant experience:

• frontend: The web console where you chat with the AI, view your topology, and approve changes.
• api: The central brain that handles requests, checks permissions, and manages AI sessions.
• worker: The background engine that runs long discovery jobs, takes config backups, and captures packets without blocking your session.
• postgres: The system of record that stores all your device inventory, user accounts, and audit logs.
• neo4j: A living topology map that tracks how every device, interface, and subnet connects to everything else.
• redis: A fast message broker that coordinates tasks between the API and the background workers.
• ollama: An optional tool for running AI models locally on your own hardware for maximum privacy.

Sources: README.md, deploy/docker/README.md

Deployment Options

Engineers can deploy the platform in two ways based on their needs:

1. Docker Compose: Ideal for a lab or a small team. It runs everything on a single server and is quick to set up for testing.
2. Kubernetes/Helm: The production-grade option. This supports multi-node clusters and high availability to ensure the assistant is always online.

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

The Standardized Connector (Vendor Plugins)

The platform uses a capability-based plugin system to interact with hardware. This means the platform doesn't need to know the specific commands for every device; instead, it asks for a "capability" (like "get routing table"), and the specific vendor plugin handles the SSH or API call. For example, the NX-OS plugin uses specific parsers to turn "show ip route vrf all" into a standard list of routes.

Sources: README.md, backend/app/plugins/vendors/cisco_nxos/parsers.py:27-40

Change Approval Workflow

Safety is a core requirement. Every modification to the network follows a strict lifecycle:

1. Draft: The AI proposes a change (e.g., adding a DNS record).
2. Pending Approval: An engineer reviews the proposal in the "Changes" dashboard.
3. Approved: Once a human clicks approve, the platform prepares for execution.
4. Executing: A pre-change config backup is taken automatically before the change is applied.
5. Completed/Rolled Back: If the change succeeds, it is marked complete; if it fails, the platform can use the backup to restore the previous state.

Sources: README.md, deploy/kubernetes/netops/README.md

3. Diagrams

System Overview

This diagram shows how users and administrators interact with the platform and what external systems it connects to.

Agent Routing

When you ask a question, the "Master Architect" decides which specialist should handle it.

Topology Data Model (The Living Map)

This shows what the platform knows about your network and how items are linked in the graph database.

Deployment Options

Comparison between the lab-friendly Docker setup and the production Kubernetes setup.

4. Technical Summary

The following table summarizes the key capabilities provided by the plugin system.

Capability	Purpose	Data Type
Discovery API	Automatically identifies device hardware, OS, and serial numbers.	DeviceFacts
Interfaces	Collects status, IP addresses, speeds, and error counters.	NormalizedInterface
Routes	Builds a map of the routing table, including VRFs and next hops.	NormalizedRoute
Neighbors	Discovers L2 topology using LLDP and CDP.	NormalizedNeighbor
Firewall Policy	Audits security rules for shadowed or overly permissive entries.	NormalizedFirewallRule
HA Status	Checks the health of vPC or High Availability clusters.	NormalizedHaStatus

Sources: backend/app/plugins/vendors/cisco_nxos/parsers.py:50-80, backend/tests/plugins/test_panos_conformance.py:450-465

5. Implementation Example

The following is an example of a parser used in the Cisco NX-OS plugin to convert raw text into a structured list of IP routes.

def parse_routes(raw_output: str, *, device_id: UUID, collected_at: datetime) -> list[NormalizedRoute]:
    # Use a pre-defined template to pull data from the raw command output
    rows = _parse_with_template("show ip route", raw_output)
    results = []
    for row in rows:
        # Extract network and next hop information
        network = row.get("network", "").strip()
        # Create a standardized route object that the AI understands
        results.append(
            NormalizedRoute(
                device_id=device_id,
                destination=ip_network(f"{network}"),
                protocol=_route_protocol(row.get("protocol", "")),
                next_hop=row.get("nexthop_ip", ""),
                vrf=row.get("vrf", "")
            )
        )
    return results

Sources: backend/app/plugins/vendors/cisco_nxos/parsers.py:220-250

Conclusion

The Vendor Plugin System is the foundation of the platform's multi-vendor support. By normalizing data from various sources into a single "language," it allows the AI agents to perform complex troubleshooting and documentation tasks without being limited by the specific command syntax of individual manufacturers. This abstraction ensures that as new vendors are added, the platform's core intelligence remains effective across the entire infrastructure.