{"resourceId":"internet2-hawat-aiops-multi-agent-network-troubleshooting-20261014","versions":[{"version":"external-66a887feb9739036e3ccba1b18fc970e54319dbd891b113fa77918ab6a55c572","resource":{"id":"internet2-hawat-aiops-multi-agent-network-troubleshooting-20261014","title":"Internet2 puts HAWAT multi-agent AIOps troubleshooting live against its production network, read-only by default, with plans to open-source it for campuses","organization":"Internet2 (U.S. research and education network consortium)","sector":"Research and education network operations; campus IT operations","geography":"United States (with a SURF, Netherlands, proof of concept)","publishedAt":"Internet2 blog, 14 October 2026","publicationDate":"2026-10-14","eventDate":null,"sourceName":"Internet2","sourceLabel":"Member consortium self-report by its lead network software architect","sourceUrl":"https://internet2.edu/building-ai-into-network-operations-at-internet2/","evidenceClass":"public-sector-association","outcomeClass":"emerging","topics":["developers-agents","infrastructure","operating-model","data-security"],"finding":"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.","sledRelevance":"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":"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.","architectureImplications":"Interpretation: 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.","governanceImplications":"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.","securityPrivacyImplications":"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.","caveats":"Self-report that also promotes upcoming TechEX26 sessions. Early deployment for internal testing; no measured outcomes. National backbone context differs from campus networks.","streamIds":["campus-operations"],"roles":{"sales":"For sales, this signals that the R&E community is building shared, open AIOps rather than only buying it. Campus network teams may adopt or extend HAWAT, which shapes demand toward integration, MCP connectors and support services rather than licences. Engage on readiness to expose operational data safely. The source cannot support claims of reduced repair time or staffing savings; it reports none.","engineering":"For pre-sales engineering, the pattern is MCP servers wrapping each operational system with read-only tools, specialized agents and human approval. Fit is strongest where telemetry, configuration and ticket data are already accessible via APIs. Prerequisites include identity for agents, logging of every tool call and test cases from past incidents. Validate claims by replaying historical incidents and measuring time to diagnosis against engineers' records.","delivery":"For delivery, run a staged adoption: connect read-only tools first, test on past incidents, then use live with engineer approval. Define who owns each MCP server, how models are chosen and what is logged. Add authentication and observability before any wider access. Track time to investigate and repair before and after, compare agent findings with engineers' records, and keep a rollback plan."},"roleDetails":{"sales":{"customerProblem":"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"],"discoveryQuestions":["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?"],"valueHypothesis":"Interpretation: read-only agent assistance may shorten diagnosis for routine incidents if data access and logging are in place.","potentialEngagement":"A bounded pilot connecting two read-only operational systems to an agent framework and replaying past incidents to measure diagnosis time.","unsupportedClaims":["Measured reduction in mean time to repair","Readiness for autonomous network changes","Staffing reductions in network operations"]},"engineering":{"fit":"Fits teams with API-accessible telemetry, configuration and looking-glass data and appetite for open-source tooling.","architectureIntegration":"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.","proofOfValue":["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":{"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.","skillsAdoption":"Engineers need training on agent use and verification; platform staff need MCP and model-evaluation skills.","governanceCheckpoints":["Security review before any write capability","Model evaluation per task","Post-incident review of agent contributions"],"acceptanceCriteria":["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"]}},"retrievedAt":"2026-10-15T21:57:23-05:00","enrichedAt":"2026-10-15T22:09:02-05:00","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Framed as augmenting engineers by removing repetitive context-gathering, with engineers involved in design. No workforce effect or accessibility testing is reported.","procurementImplications":"An open-source, containerized community platform could substitute for some commercial AIOps tooling, but institutions would carry support costs.","operatingModelImplications":"Moves NOC work toward reviewing assembled context and deciding fixes. Cross-network agent collaboration could change how multi-domain incidents are handled between institutions.","sourceVerification":{"openedUrl":"https://internet2.edu/building-ai-into-network-operations-at-internet2/","referenceExcerpt":"Tools are read-only by default, which keeps the early deployment safe while we build trust.","promptVersion":"sled-research-v4.0","model":null,"basis":"agent-reported inspection"}}}]}