From the Campus Operations edition of October 15, 2026
Internet2 puts HAWAT multi-agent AIOps troubleshooting live against its production network, read-only by default, with plans to open-source it for campuses
Internet2 (U.S. research and education network consortium) · Research and education network operations; campus IT operations · United States (with a SURF, Netherlands, proof of concept)
- Publisher
- Internet2
- Original publication
- Internet2 blog, 14 October 2026
- Source retrieved
- 2026-10-16
What happened
Internet2's Network Services team says HAWAT (Heuristic Analysis With Adaptive Troubleshooting), a multi-agent AI troubleshooting system, is now live against the Internet2 production network and available for testing by its engineers. Purpose-built agents each use a Model Context Protocol (MCP) server exposing one operational system: the distributed looking glass, configuration database, time-series telemetry and Network Service Interface circuit provisioning. Tools are read-only by default, a human stays in the loop and the engineer makes the final call. The stated goal is to cut mean time to investigate and repair, but no measurements are given. In August Internet2 released a public MCP server for its Periscope looking glass. A proof of concept with SURF, shown at TNC26 in June, let SURF's agent call Internet2's agent across the organizational boundary; the exchange took about five minutes. Next steps include production use, automated ticket intake and triage, broader model evaluation, and authentication and observability work. Internet2 intends to open-source the platform as a containerized package member institutions can run on their own infrastructure.
Why it matters
Shows agentic AI entering core IT operations for the higher-education network community with conservative controls (read-only tools, human decision). It offers campus network and NOC teams a possible shared platform and a reference pattern for exposing operational systems to agents via MCP. Relevance is to IT operations; it says nothing about broader administrative work.
Evidence and measured results
Self-reported status and design by the team building it. No metrics on accuracy, time saved or incidents. The five-minute agent-to-agent exchange is a single demonstration timing.
Limitations and uncertainty
Self-report that also promotes upcoming TechEX26 sessions. Early deployment for internal testing; no measured outcomes. National backbone context differs from campus networks.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-15; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Campus and regional network teams spend much troubleshooting time gathering context across many tools, with limited staff.
- Stakeholders
- Network engineering manager
- NOC lead
- CIO or CTO
- Information security office
- Regional R&E network partners
- Discovery questions
- Which operational systems expose APIs today?
- How long does context-gathering take for typical incidents?
- Would the team run an open-source platform on its own infrastructure?
- What controls are required before an agent can read or change network state?
- Value hypothesis
- Interpretation: read-only agent assistance may shorten diagnosis for routine incidents if data access and logging are in place.
- Potential engagement
- A bounded pilot connecting two read-only operational systems to an agent framework and replaying past incidents to measure diagnosis time.
- Unsupported claims
- Measured reduction in mean time to repair
- Readiness for autonomous network changes
- Staffing reductions in network operations
Pre-sales engineering
Role takeaway
- Fit
- Fits teams with API-accessible telemetry, configuration and looking-glass data and appetite for open-source tooling.
- Architecture and integration
- Per-system MCP servers, specialized agents, model-agnostic orchestration, optional agent-to-agent calls with peer networks; containerized deployment.
- Prerequisites
- API access to telemetry and configuration systems
- Agent identity and authentication
- Logging of all tool calls
- Constraints
- Authentication and observability not yet complete per the source
- Backbone-scale design may not match campus networks
- Cross-organization agent calls need inter-institution agreements
- Security
- Keep tools read-only by default, authenticate agents, rate-limit public endpoints and log every call for audit.
- Proof of value
- Replay of historical incidents comparing agent-assisted and manual diagnosis time
- Accuracy review of agent findings by senior engineers
- Security review of MCP endpoints before exposure
Delivery
Role takeaway
- Work
- Stage adoption of an MCP-based AIOps assistant from read-only testing to engineer-approved live use.
- Dependencies
- Network engineering team
- Security office
- Owners of telemetry and configuration systems
- Ownership
- Network engineering owns the platform and MCP servers; engineers retain decision authority on incidents.
- Skills and adoption
- Engineers need training on agent use and verification; platform staff need MCP and model-evaluation skills.
- Governance checkpoints
- Security review before any write capability
- Model evaluation per task
- Post-incident review of agent contributions
- Acceptance criteria
- Proposed: measured time to diagnosis on replayed incidents compared with baseline
- Proposed: zero unapproved state changes
- Proposed: complete tool-call logs retained
- Risks
- Over-trust in agent conclusions
- New attack surface from exposed MCP servers
- Maintenance burden of an open-source stack
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
One MCP server per operational system, with specialized agents above them and model choice kept open, is a pattern campuses can reuse for ITSM, monitoring and configuration data. Cross-organization agent-to-agent calls expose named skills without exposing the full stack. Production use still needs authentication and observability, which the team lists as pending work.
Governance
Who approves, reviews and stays accountable for outcomes?
Human-in-the-loop with engineer final decision and read-only defaults are the stated controls. Open-sourcing shifts operational responsibility to each adopting institution. Model evaluation by task is planned rather than adopting models by habit.
Security and privacy
What data, permissions and controls need testing?
Read-only tools limit change risk. A public MCP server and cross-boundary agent calls create new interfaces that need authentication, rate limiting and logging; the post lists authentication and observability as work still to do.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Framed as augmenting engineers by removing repetitive context-gathering, with engineers involved in design. No workforce effect or accessibility testing is reported.
Procurement
What should contracts, pricing and exit terms secure?
An open-source, containerized community platform could substitute for some commercial AIOps tooling, but institutions would carry support costs.
Operating model
Which teams own the service once it runs?
Moves NOC work toward reviewing assembled context and deciding fixes. Cross-network agent collaboration could change how multi-domain incidents are handled between institutions.
Publication history
- 2026-10-15Campus Operations · Issue 385 resources
Stable resource ID: internet2-hawat-aiops-multi-agent-network-troubleshooting-20261014