Core Platform Components
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The AI Network Operations Platform is a self-hosted AI assistant designed specifically for network engineering teams to manage, discover, and troubleshoot complex infrastructure. It provides a natural language interface that allows engineers to interact with their network in plain English, performing tasks such as topology mapping, routing analysis, and configuration management across various vendors.
Sources: README.md:3-8, CLAUDE.md:3-13
The platform's primary goal is to solve operational challenges for network teams by acting as an "AI Network Engineer." It prioritizes security and human control: the system is self-hosted (keeping data local), provides visible reasoning for all AI decisions, and requires explicit human approval before any change is executed on the network.
Sources: README.md:3-8, CLAUDE.md:34-43
Overview
For a network operations team, the platform provides a unified way to interact with multi-vendor infrastructure using plain English. It eliminates the need to manually crawl through various CLI outputs or vendor-specific dashboards for discovery and troubleshooting.
Sources: CLAUDE.md:7-13, README.md:3-8
Supported Vendors and Protocols
The platform uses a standardized connector system to support a wide array of infrastructure vendors:
- Networking/Routing: Cisco (IOS, IOS-XE, NX-OS), Juniper JunOS, Arista EOS.
- Security: Palo Alto PAN-OS, Fortinet FortiOS.
- DDI (DNS/DHCP/IPAM): BlueCat, Infoblox, AWS Route53.
- Cloud & Virtualization: AWS, Azure, VMware.
- App Services: F5 BIG-IP.
Sources: CLAUDE.md:17-31, README.md:21-27
Specialized Team Members (Agents)
Instead of thinking of the platform as a single program, it is best viewed as a team of specialized members called "Agents." A Master Architect listens to your request and routes it to the correct specialist:
- Discovery Agent: Enumerates inventory, LLDP/CDP neighbors, and scans subnets.
- Troubleshooting Agent: Diagnoses why a route is missing, a BGP peer is down, or a flow is being blocked.
- DDI Agent: Handles DNS record lookups and DHCP scope utilization.
- Security Agent: Audits firewall policies for shadowed or overly permissive rules.
- Documentation Agent: Generates network diagrams (Mermaid), runbooks, and inventory CSVs.
- Automation Agent: The only team member allowed to actually run approved changes.
Sources: CLAUDE.md:45-56, backend/app/llm/prompts/init.py:183-255, backend/app/agents/ddi/agent.py:46-59
System Overview Diagram
This diagram shows how users interact with the platform and what external systems the platform connects to.
The platform acts as the central hub between the engineer and the diverse vendor environment.
Sources: CLAUDE.md:17-31, README.md:21-27
Architecture
The platform is composed of seven core components that work together to process requests and manage the network.
Core Components
- frontend: The operations console where you chat with the AI, view topology maps, and approve changes.
- api: The central brain that handles security, manages user sessions, and coordinates the AI agents.
- worker: The background engine that runs discovery jobs, takes config backups, and captures packets without blocking your session.
- postgres: The system of record that stores device inventory, user accounts, and change history.
- neo4j: A living topology map that tracks how every device, interface, subnet, and application connects to everything else.
- redis: A fast message bus that passes tasks from the API to the background workers.
- ollama: An optional component that provides a local-first AI brain, ensuring your network data never leaves your premises.
Sources: README.md:11-19, deploy/docker/README.md:10-18, deploy/docker/docker-compose.yml:21-177
Standardized Vendor Connectors
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 specialists to reason about "Interfaces" or "BGP Peers" without needing to understand the specific CLI syntax of every vendor.
Sources: README.md:21-27, CLAUDE.md:61-68
Agent Routing Diagram
The following diagram illustrates how the Master Architect routes a request to a specialist.
The Master Architect ensures the right specialist handles the right task.
Sources: backend/app/llm/prompts/init.py:183-255, backend/app/agents/ddi/agent.py:12-25
Deployment Options
The platform can be deployed in two primary ways depending on the environment.
| Option | Use Case | Description |
|---|---|---|
| Docker Compose | Lab / Small Teams | A single-server setup that is quick to start but has no high-availability. |
| Kubernetes (Helm) | Production | A multi-node setup that is hardened by default and designed for large environments. |
Sources: deploy/docker/README.md:3-8, deploy/kubernetes/netops/README.md:3-16
Deployment Comparison Diagram
Docker is best for getting started quickly, while Kubernetes is for production scale.
Sources: deploy/docker/README.md:3-8, deploy/kubernetes/netops/README.md:110-120
Change Approval Workflow
Every change follows a strict lifecycle to ensure reliability and safety. Before any change is applied, the platform always takes a pre-change config backup.
Workflow Stages
- Draft: The AI specialist (e.g., DDI Agent) creates a proposed change.
- Pending Approval: The change is visible in the console, waiting for a second human engineer to review it.
- Approved: A human has verified the change and clicked "Approve."
- Executing: The Automation Agent applies the change to the device.
- Completed/Rolled Back: The change is finalized or, if it fails, reverted using the pre-change backup.
Sources: CLAUDE.md:41-43, README.md:3-8, backend/app/agents/ddi/agent.py:12-25
Change Lifecycle Diagram
No change hits your production network without a human looking at it first.
Sources: README.md:3-8, CLAUDE.md:41-43
Network Topology Data Model
The Neo4j "living topology map" organizes network data as a series of connected relationships. This allows the AI to understand how a failure in one area impacts others.
Key Relationships
- Device: The physical or virtual node (Cisco, Juniper, etc.).
- Interface: Connects a Device to a Subnet or another Interface.
- Subnet: Groups IP addresses; linked to VLANs.
- DNS Zone/Record: Maps names to Subnets or specific Devices.
- Application: Depends on DNS Records and Devices.
Sources: CLAUDE.md:73-81, backend/app/agents/ddi/agent.py:46-59
Topology Map Concept
This is how the platform "sees" your network connectivity.
Sources: CLAUDE.md:73-81, backend/app/agents/ddi/agent.py:46-59
Conclusion
The AI Network Operations Platform provides a robust, component-based architecture for modern network engineering. By combining specialized AI agents with a strict human-in-the-loop approval workflow and a comprehensive topology data model, it enables teams to automate complex tasks safely and efficiently across diverse vendor environments.
Sources: README.md:3-8, CLAUDE.md:34-43