Diagram: Agent Routing Flow
Relevant source files
The following files were used as context for generating this wiki page:
- CLAUDE.md
- README.md
- backend/app/llm/prompts/__init__.py
- backend/app/agents/documentation/agent.py
- backend/app/agents/ddi/agent.py
- backend/app/agents/security/agent.py
- backend/app/agents/consultant/agent.py
- backend/tests/agents/eval/test_routing_eval.py
- deploy/docker/README.md
- deploy/kubernetes/netops/README.md
Overview
The AI Network Operations Platform acts as an automated "AI Network Engineer" that helps operations teams manage complex multi-vendor environments. It solves the problem of manual infrastructure management by allowing engineers to interact with their network using plain English to perform discovery, troubleshooting, and configuration changes.
The platform is built on a "local-first" philosophy, meaning it can run entirely within your private network without sending data to external AI providers. Every significant action follow a strict safety protocol: the AI explains its reasoning, logs its steps for auditing, and requires a human engineer to approve any change before it is executed on a live device.
The Specialist Team (Agents)
In this platform, "agents" are like specialized team members. When you ask a question, the system determines which specialist is best equipped to handle it:
- Discovery Agent: Enumerates and lists what exists in the inventory.
- Troubleshooting Agent: Diagnoses why something is broken (e.g., routing or BGP faults).
- DDI Agent: Manages DNS, DHCP, and IP addressing.
- Security Agent: Audits firewall policies and security posture.
- Configuration Agent: Narrates configuration drift and compliance.
- Documentation Agent: Generates diagrams, runbooks, and inventories.
- Packet Analysis Agent: Queries and summarizes existing packet captures.
- Automation Agent: Executes changes that have already been approved by a human.
- Consultant Agent: Asks clarifying questions if your request is too vague.
Sources: CLAUDE.md:1-20, README.md:1-15, backend/app/llm/prompts/__init__.py:230-290
Architecture
The platform consists of seven core components that work together like a well-coordinated operations center.
| Component | Network Operations Role |
|---|---|
| Frontend | The web console where engineers chat with the AI and view topology maps. |
| API | The central brain that handles security, user sessions, and coordinates agents. |
| Worker | The background engine that runs long discovery jobs and takes configuration backups. |
| Postgres | The primary database that stores the inventory, logs, and audit trails. |
| Neo4j | A living topology map that tracks how every device, interface, and subnet connects. |
| Redis | The high-speed messaging system that coordinates the worker's jobs. |
| Ollama | The local AI engine that allows the platform to think without using the internet. |
Sources: README.md:21-30, deploy/docker/README.md:5-15
Vendor Connectivity
The platform uses a standardized "connector" or plugin for each vendor. Whether you are talking to a Cisco router, a Juniper switch, or a BlueCat DNS manager, the platform normalizes the output into a consistent format. This means the AI doesn't need to know the specific syntax of every vendor's CLI; it only deals with the standardized network data.
Supported vendors include Cisco (IOS, NX-OS), Juniper, Arista, Palo Alto, Fortinet, F5, BlueCat, and Infoblox, as well as cloud providers like AWS and Azure.
Sources: CLAUDE.md:22-38, README.md:32-35
Deployment Options
- Docker Compose: Ideal for labs or small teams. It runs everything on a single server.
- Kubernetes/Helm: Designed for production environments. It supports high availability across multiple nodes and includes automated backups via tools like pgBackRest.
Sources: README.md:40-50, deploy/docker/README.md:1-5, deploy/kubernetes/netops/README.md:1-20
Diagram: System Overview
This diagram shows how engineers interact with the platform and what external systems the platform manages.
The System Overview illustrates the path from the user interface to the final managed device, highlighting the internal "Living Topology Map" (Neo4j).
Sources: CLAUDE.md:22-38, README.md:21-35, deploy/docker/README.md:5-15
Diagram: Agent Routing Flow
When you send a message, the Master Architect (the supervisor) acts like a dispatcher, determining which specialist should receive the ticket.
The Agent Routing Flow shows how requests are directed to specialists. Read-only tasks provide immediate answers, while any request to modify the network is diverted to an approval gate.
Sources: backend/app/llm/prompts/__init__.py:130-290, backend/app/agents/ddi/agent.py:10-35, backend/app/agents/security/agent.py:10-40, backend/tests/agents/eval/test_routing_eval.py:160-250
Diagram: Change Approval Flow
Every change follows a non-destructive lifecycle to ensure network stability.
The Change Approval Flow emphasizes the human-in-the-loop requirement, where a second engineer must approve a draft before the Automation Agent executes the task.
Sources: backend/app/agents/ddi/agent.py:45-55, backend/app/agents/security/agent.py:75-85, deploy/docker/README.md:120-130, deploy/kubernetes/netops/README.md:100-110
Diagram: Topology Data Model
This represents "what the platform knows about your network," stored in the Neo4j graph database.
The Topology Data Model illustrates the relationships between physical devices, logical addressing (IP/VLAN), and application-level dependencies.
Sources: CLAUDE.md:75-85, backend/tests/agents/documentation/test_documentation_agent.py:100-140
Summary
The platform's routing flow ensures that network requests are handled by the appropriate specialist agent while maintaining a strict security boundary. By centralizing all operations through a Master Architect and enforcing a human-approval gate for all state-changing actions, the platform provides a safe and audited environment for network automation.
Sources: CLAUDE.md:40-50, backend/app/llm/prompts/__init__.py:230-290