Why We Build Demos — And What NetClaw Taught Me About Showing, Not Telling
Watching a network engineer’s eyes light up in real time watching an AI agent build a full service provider core from nothing. No slides. No pre-baked configs. Just a blank prompt and six empty routers.
That’s what a good demo does. It compresses months of architecture decisions into 90 seconds of undeniable proof.
The Problem With Explaining AI Network Automation
Try explaining to someone what an AI network engineer does. You’ll get about 30 seconds before their eyes glaze over. “It uses MCP tools to query Nautobot via GraphQL, generates FRR configs from source-of-truth data, pushes them via vtysh, then validates OSPF adjacencies and BGP peering state.”
That sentence is perfectly accurate and completely useless for building conviction.
A demo changes everything. When someone watches an AI agent deploy a 6-router service provider core, populate a source of truth, generate configs from live data, push them to real routers, and then join the network itself as a BGP peer — they get it immediately.
NetClaw, created by John Capobianco, is exactly that kind of system — a CCIE-level AI network engineering coworker built on the OpenClaw framework. I’ve contributed MCP servers to the project and built the self-provisioning demo infrastructure around it to make it accessible to anyone.
→ Try the NetClaw demo yourself at localedgedatacenter.com
What the NetClaw Demo Actually Does
I built the infrastructure to provision a fresh VM on demand with a complete network automation stack:
- ContainerLab topology: 4 P routers, 1 route reflector, 1 PE router — all FRRouting
- Nautobot as the network source of truth
- OpenClaw-powered AI agent with 162 skills across 71 MCP integrations, powered by DeepSeek V4 Flash via Ollama Cloud — delivering fast, reliable, and cost-effective inference for complex tool-calling workflows
- Three.js 3D visualization showing tool calls lighting up integration nodes in real-time
The user pastes a single prompt and watches the agent execute:
- Deploy the topology — routers start completely blank (no interfaces, no IGP, no BGP)
- Start Nautobot and run a design builder job to populate devices, interfaces, IPs, and routing models
- Query everything via GraphQL and generate per-device FRR configurations
- Push configs to all 6 routers via vtysh
- Add additional data not already configured - Create a new Loopback on each Router using the 192.100.100.0/24 subnet and then advertise this address via BGP, do not advertised this new loopback into OSPF. This should be BGP only.
- Validate connectivity — OSPF adjacencies, BGP peering state, end-to-end reachability
- Join the network — the AI agent becomes a real participant, establishing its own OSPF adjacency, learning the topology from the LSDB, and peering via eBGP with the route reflector
The routers start empty on purpose. Users can open the web console, run show running-config, and see nothing. Then they watch the agent build the entire network from source-of-truth data. That contrast is the demo.
The Architecture Behind the Demo
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌─────────────────────────────────────────────────────┐
│ User Browser │
│ ├── Demo Dashboard (localedgedatacenter.com) │
│ └── NetClaw 3D Visual UI (Three.js) │
└──────────────────────┬──────────────────────────────┘
│ Cloudflare Tunnel
┌──────────────────────▼──────────────────────────────┐
│ Demo VM (auto-provisioned, 4hr TTL) │
│ ├── OpenClaw Gateway (port 18789) │
│ │ └── DeepSeek V4 Flash via Ollama Cloud │
│ ├── NetClaw Visual UI (port 3000/3001) │
│ ├── Nautobot (port 8080) │
│ ├── ContainerLab Topology │
│ │ ├── PE1, P1, P2, P3, P4 (FRR) │
│ │ └── RR1 (Route Reflector) │
│ ├── ttyd Console Proxy (port 7680) │
│ └── MCP Servers (protocol-mcp, nautobot-mcp, etc.) │
└─────────────────────────────────────────────────────┘
Each VM is a full clone provisioned in under 3 minutes with:
- Fresh credentials and API tokens
- Latest code pulled from the repo on boot
- Model config injected into the OpenClaw gateway
Why Demos Matter in AI Network Automation
They compress understanding
A 40-page architecture document explains what a system could do. A self-provisioning demo proves what it does do. The cognitive load drops from “imagine this working” to “I just watched it work.”
They build trust through transparency
The NetClaw demo doesn’t hide failures. If OSPF doesn’t converge, you see it. If a config push fails, the agent troubleshoots it live. This is more convincing than a polished video because it proves the system handles real-world messiness.
The demo isn’t just showing what NetClaw can do for networks. It’s showing what the workflow looks like: natural language in, working infrastructure out.
Build Your Own
The pattern is transferable to any complex system:
- Pick one workflow that’s impressive end-to-end, not five that are half-baked
- Automate the setup so the interesting part starts immediately
- Make state visible — dashboards, logs, topology graphs, anything that shows progress
- Let it fail gracefully — recovery is more impressive than perfection
- Time-box it — if your demo can’t land in 15 minutes, scope it down
The best demo is one where the audience forgets they’re watching a demo and starts asking “can it also do X?” That’s when you know you’ve shown enough.
See It Live
Want to watch an AI agent build a real network from scratch? Try the NetClaw demo at localedgedatacenter.com — just $4 for a full 6-router SP core, live AI agent, 3D visualization, and 4 hours to explore.