The Network Chat Interface
Relevant source files
The following files were used as context for generating this wiki page:
The Network Chat Interface is the primary operations console where network engineers interact with the platform using plain English to manage and troubleshoot enterprise infrastructure. It serves as a single pane of glass that translates natural language requests into specific network operations across a multi-vendor environment while ensuring every AI-driven decision is visible, audited, and approved by a human.
Sources: README.md:1-10, CLAUDE.md:1-15
1. Overview
The platform acts as an AI Network Engineer for operations teams, solving the complexity of managing diverse vendors and protocols. It provides a local-first, self-hosted environment where security is the default, and human oversight is mandatory for any state-changing operation.
Supported Vendors and Protocols
The interface facilitates communication with a wide array of infrastructure components:
- Routing & Switching: Cisco (IOS, IOS-XE, NX-OS), Juniper JunOS, Arista EOS.
- Security & Firewalls: Palo Alto PAN-OS, Fortinet FortiOS.
- Application Delivery: F5 BIG-IP.
- DDI (DNS, DHCP, IPAM): BlueCat, Infoblox, Route53.
- Cloud & Virtualization: AWS, Azure, VMware.
Sources: CLAUDE.md:18-32, README.md:27-32
The Specialist Team (Agents)
Instead of interacting with complex software modules, the engineer talks to "specialized team members" known as Agents. A Master Architect acts as the supervisor, routing your question to the right expert:
| Agent Name | Role in the Team |
|---|---|
| Master Architect | The supervisor who listens to your request and routes it to the correct specialist. |
| Consultant | Asks for clarification if your request is too vague or needs more information. |
| Discovery | Scans the network and lists what devices, interfaces, and neighbors exist. |
| Troubleshooting | Diagnoses why a specific flow is failing or why a BGP session is down. |
| DDI Agent | Manages DNS records and DHCP scopes/leases. |
| Security Agent | Audits firewall policies for shadowed or overly-permissive rules. |
| Configuration | Checks for config drift against your approved baseline. |
| Documentation | Generates topology diagrams (Mermaid) and inventory artifacts. |
| Automation | Executes change requests that have already been approved by a human. |
Sources: CLAUDE.md:40-52, backend/app/llm/prompts/init.py:180-330
2. Architecture
The chat interface is powered by seven core components working together. Think of these as the different "servers" or "functions" required to keep the AI Network Engineer running.
Platform Components
- frontend: The operations console you see in your browser. It provides the chat window, topology maps, and approval screens.
- api: The central switchboard that handles your messages, checks your permissions, and manages agent sessions.
- worker: The background engine that performs the heavy lifting, such as running discovery scans, taking config backups, and analyzing packet captures without blocking your chat session.
- postgres: The system of record that stores all device data, change requests, and encrypted credentials.
- neo4j: A living topology map that tracks how every device, interface, subnet, and DNS zone connects to everything else.
- redis: A temporary post office used to pass messages between the API and the background workers.
- ollama: A local AI engine that processes your natural language requests without sending data to the cloud.
Sources: README.md:16-25, deploy/docker/README.md:8-16
Vendor Normalization
The platform uses a "standardized connector" (vendor plugin system) for each manufacturer. Whether you are querying a Cisco Nexus switch or a BlueCat Address Manager, the platform normalizes the raw CLI or API output into a consistent format before the AI analyzes it.
Sources: README.md:26-27, backend/app/plugins/vendors/cisco_nxos/parsers.py:1-25
Deployment Options
- Docker Compose: A single-server setup ideal for labs or small teams. It runs all components on one machine using a simple configuration file.
- Kubernetes/Helm: The production-grade setup. It provides a multi-node, highly available environment with built-in backup systems and strict security hardening.
Sources: deploy/docker/README.md:1-5, deploy/kubernetes/netops/README.md:1-15
3. Operations and Workflow
Change Approval Workflow
Every request that modifies the network follows a strict lifecycle. No AI agent can execute a change unilaterally; it must draft a proposal for human review.
- Draft: An agent (like the DDI or Security Agent) creates a proposed change based on your request.
- Pending Approval: The change appears in the "Changes" tab for a second engineer to review.
- Approved: A human signs off on the change.
- Executing: The Automation Agent takes a pre-change config backup and applies the change.
- Completed/Rolled Back: The system verifies the change. If it fails, it can be rolled back to the previous state.
Sources: backend/app/agents/ddi/agent.py:15-30, backend/app/agents/security/agent.py:18-28, README.md:1-10
System Overview
This diagram shows how you interact with the platform and what external systems it connects to.
The Network Chat Interface sits at the front, routing user commands through the API to the specialized workers and data stores.
Sources: CLAUDE.md:18-32, README.md:16-25
Agent Routing Flow
When you send a message, the "Master Architect" decides which specialist should handle the task.
The routing logic ensures that requests are sent to the correct specialist, with an escalation to the Consultant for unclear intents.
Sources: backend/app/llm/prompts/init.py:180-330, backend/app/agents/consultant/agent.py:65-75
Topology Data Model
The platform maintains a detailed map of your network infrastructure.
The topology engine tracks relationships between physical devices and logical constructs like subnets and DNS records.
Sources: CLAUDE.md:66-72, backend/tests/agents/documentation/test_documentation_agent.py:115-150
4. Technical Summary
The Network Chat Interface is not just a text box; it is the entry point to a highly governed automation system. It relies on a versioned prompt registry to ensure that AI reasoning is consistent and reproducible. Every interaction is logged in reasoning traces, allowing engineers to see exactly why the AI chose a particular path.
Sources: backend/app/llm/prompts/init.py:1-25, README.md:1-10