NA006 - AI hype with Peter Sprygada

Posted on October 10, 2025 • 6 min read • 1,156 words
Share via

Network automation veteran Peter Sprygada joins to discuss AI hype, MCP protocol, and practical applications in network automation

NA006 - AI hype with Peter Sprygada
Photo by Steinzi

Network Auto Magic Podcast Episode Summary  

AI hype with Peter Sprygada

Episode Overview  

In this episode, Steinn and Urs sit down with network automation legend Peter Sprygada (Chief Architect at Itential) to cut through the AI hype and discuss what’s real, what’s noise, and where AI actually makes sense in network automation. Peter brings his decades of experience from ATM/Frame Relay days through Ansible’s early years to today’s AI-driven automation landscape.

Episode Guest  

  • Peter Sprygada: Chief Architect at Itential, former lead engineer at Ansible (employee #7), and the person responsible for Ansible’s networking capabilities. A traditional network engineer who’s been automating networks since before we called it “network automation.”

Listen to the show on YouTube:  

Listen to the show anywhere:  

Listen now!

Show notes resources:  

What we cover:  

The AI Hype Landscape  

Separating Hype from Reality  

  • Everything is “AI”: You can attach AI to anything these days - even feeding your dog
  • The Problem: People say “I want AI” without defining what they actually want to accomplish
  • Core Issue: Same problem that plagues automation - inability to concisely define the task
  • Key Insight: The technology isn’t bad; the problem is knowing what to do with it

Current State of AI in Networking  

  • Production Use Cases: Mostly limited to operations side (monitoring, troubleshooting, compliance)
  • Configuration Management: Peter is NOT using AI to configure devices (and doesn’t recommend it for 12-24 months minimum)
  • Cultural Barriers: Network engineering culture is inherently suspicious of tooling (for good reasons)
  • Real Applications: Config compliance, drift detection, observability, alarm remediation

MCP (Model Context Protocol) - The Game Changer  

What MCP Solves  

  • Standardized Language: Created a protocol for LLMs to communicate with applications, filesystems, and network devices
  • Game Changing Moment: Late 2024 announcement changed Peter’s perspective on AI in networking
  • Key Difference from REST APIs:
    • REST requires copious code and works with software-defined IDs
    • MCP abstracts complexity and uses natural language
    • Humans relate to English words, not identifiers

How MCP Works  

  • Three Exposures: Tools, resources, and prompts (focus on tools for networking)
  • Guardrails: Can constrain what LLMs can do on infrastructure
  • Tool-Based Approach: Expose specific operations rather than raw API endpoints
  • Abstraction Layer: Ties together disparate API endpoints into functional tools

MCP Implementation Philosophy  

  • Wrong Approach: Converting REST APIs 1:1 into MCP servers (missing the point)
  • Right Approach: Create specific, actionable tools with guardrails
  • Example: Instead of 864 API endpoints, expose 2-4 tools that call 10-15 APIs on the backend
  • Service Catalog Mentality: Think of MCP tools as a service catalog, not raw endpoints

Architecture and Best Practices  

Two-Layer Architecture  

  • Deterministic Layer: Static, defined workflows (Itential, Ansible, Terraform)
  • Reasoning Layer: LLM that rationalizes what needs to be done
  • Security Model: Deterministic layer is the gateway to infrastructure
  • Guardrails: Put checks and balances in the deterministic operations

Practical Implementation Patterns  

  • Elicitation: MCP can ask questions back to users before executing
  • Multi-Check System: Check hundreds of data points before performing tasks
  • Security Layers: Implement guards at both MCP and orchestration levels
  • Human-in-the-Loop: Maintain human oversight for critical operations

Use Cases and Applications  

Operational Use Cases (Today)  

  • Config Backups: Simple operations automated through agents
  • Troubleshooting: Feed OSPF LSDB or BGP data to LLMs for analysis
  • Network Optimization: LLMs can analyze routing databases to suggest improvements
  • Maintenance Windows: Automated link draining with safety checks
  • Compliance Checking: Automated configuration drift detection

Design and Planning (Emerging)  

  • Network Design: Using AI to design better, more efficient networks
  • Architecture Optimization: Analyzing entire network topologies
  • Documentation: Understanding legacy BGP communities and attributes
  • Best Practices: AI-assisted design decisions

Challenges and Concerns  

Non-Determinism Problem  

  • Key Issue: Abandoning determinism by using LLM products
  • Traditional Tools: Ansible, Terraform are predictable (input X = output X+1)
  • LLM Behavior: Non-deterministic, can vary between sessions
  • Solution: Keep deterministic operations at the execution layer

Real-World Scenarios  

  • Session Isolation: Different LLM sessions might make conflicting decisions
  • Context Awareness: LLMs need access to schedules, existing configs, etc.
  • Vendor Implementations: Risk of vendors creating 1000+ MCP endpoints (repeating past mistakes)
  • Industry Patterns: History of leaky abstractions (Yang, Ansible modules, etc.)

The Skills Gap Problem  

  • Future Concern: What happens when experienced engineers retire?
  • Knowledge Loss: New generation may not know how to troubleshoot without AI
  • Agent Limitations: Agents can’t solve unexplainable network outages
  • Balance Needed: Can’t let automation get completely out of control

Industry Perspectives  

Vendor Ecosystem Challenges  

  • Multiple Protocols: MCP isn’t the only AI communication protocol
  • Vendor Implementations: Risk of poorly thought-out MCP implementations
  • Historical Patterns: Industry keeps making same mistakes (NetConf, Yang, REST, now MCP?)
  • Incremental Progress: Better to make small improvements than wait for perfection

Lessons from Ansible Era  

  • Module Quality: Vendors auto-generated modules from specs (added no value)
  • One-to-One Mapping: Creating Ansible modules that mirrored REST endpoints exactly
  • Same Mistakes: Industry is repeating this pattern with MCP
  • Right Approach: Think about use cases first, then create abstractions

Looking Forward  

12-24 Month Outlook  

  • Operations Focus: AI will continue to be used for network operations, not configuration
  • Gradual Adoption: Slow integration with proper guardrails
  • Cultural Shift: Need to overcome network engineering’s justified skepticism
  • Tool Evolution: MCP and similar protocols will mature

Opportunities  

  • Design Tools: Huge untapped potential in network design and planning
  • Troubleshooting: Advanced analysis of routing databases and network state
  • Automation Accessibility: Lower barriers to entry for network automation
  • Operational Efficiency: Removing mundane tasks from human operators

Words of Caution  

  • Define Your Goals: Know what you want to accomplish before choosing technology
  • Maintain Skills: Don’t lose fundamental networking knowledge
  • Test Thoroughly: Especially important with non-deterministic systems
  • Start Small: Begin with low-risk operations, build confidence gradually
  • Keep Humans Involved: Maintain oversight, especially for critical systems

Key Takeaways  

  1. AI is Not Magic: It’s a tool that requires clear problem definition
  2. MCP is Different: First protocol that made Peter believe in AI for networking
  3. Determinism Matters: Keep predictable operations at the execution layer
  4. Operations First: AI works better for monitoring/troubleshooting than configuration
  5. Think Use Cases: Design MCP tools around workflows, not raw APIs
  6. Guard Rails Required: Multiple layers of security and validation needed
  7. Skills Still Matter: Fundamental networking knowledge remains critical
  8. Incremental Progress: Small improvements are better than waiting for perfection

Final Thoughts  

Peter’s perspective as someone who initially dismissed AI hype but was converted by MCP provides a balanced view of where the technology actually adds value. The key message: AI in networking isn’t about replacing network engineers, it’s about handling mundane operations and providing better insights for complex troubleshooting. Success requires clear thinking about use cases, proper guardrails, and maintaining the deterministic foundations that networks depend on.

The episode serves as both a reality check on AI hype and a practical guide for network engineers looking to understand where and how AI can actually help in their day-to-day operations.