ainetops R. Schott Internet-Draft Deutsche Telekom Intended status: Standards Track Q. Sun Expires: 6 May 2027 China Telecom D. Voyer Cisco Systems, Inc. 2 November 2026 The problem statement of AI Native Network Operations draft-rqd-ainetops-problem-statement-00 Abstract The introduction of AI agents into network operations is fundamentally reshaping the operation and maintenance (O&M) paradigm, shifting from human-led, passive network management toward intent- driven, self-planning, and intelligent reasoning. While this shift promises significant gains in efficiency and autonomy, it introduces a set of problems that are not yet covered by the existing IETF network management framework. This document identifies and summarizes the deployment and operation problems that arise when AI native network operations (AINETOps) are introduced into operator networks. It systematically enumerates the standardization gaps across Network Management Agent (NMA) lifecycle management, the Human-Agent Interface (HAI), the agent-to-agent task and evidence models, and task risk classification. It does not propose solutions; its purpose is to provide a problem inventory that can anchor future IETF work on solutions and deployment best practices. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Schott, et al. Expires 6 May 2027 [Page 1] Internet-Draft AINETOps Problem Statement November 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definition and Terminology . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2.1. NMA Lifecycle Management . . . . . . . . . . . . . . . . 5 2.1.1. Agent Observability . . . . . . . . . . . . . . . . . 7 2.1.2. Agent Evaluation and Evolution . . . . . . . . . . . 8 2.2. End-to-End Multi-Vendor Agent Execute O&M Operations . . 9 2.2.1. Human-Agent Interface (HAI) . . . . . . . . . . . . . 11 2.2.2. Agent-Agent Interface . . . . . . . . . . . . . . . . 12 2.2.3. Human-Agent and Agent-Agent Interface . . . . . . . . 13 2.2.4. Task Risk Classification . . . . . . . . . . . . . . 14 3. Gap Analysis and Requirements of AINETOps{#sec-ra} . . . . . 15 3.1. NMA Lifecycle Management . . . . . . . . . . . . . . . . 15 3.1.1. Agent Observability . . . . . . . . . . . . . . . . . 15 3.1.2. Agent Evaluation and Evolution . . . . . . . . . . . 16 3.2. End-to-End Multi-Vendor Agent Execute O&M Operations . . 16 3.2.1. Human-Agent Interface (HAI) . . . . . . . . . . . . . 17 3.2.2. Task Model (Agent-Agent Interface) . . . . . . . . . 17 3.2.3. Evidence Model (Agent-Agent Interface) . . . . . . . 18 3.2.4. Task Risk Classification . . . . . . . . . . . . . . 18 3.2.5. Multi-Vendor Interoperability Baseline . . . . . . . 19 4. Use cases of AINETOps{#sec-uc} . . . . . . . . . . . . . . . 19 4.1. Node Configuration Generation . . . . . . . . . . . . . . 19 4.2. Cross-Domain Traffic Steering with Multi-Agent Coordination . . . . . . . . . . . . . . . . . . . . . . 22 5. Relationship to Existing Work{#sec-re} . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Normative References . . . . . . . . . . . . . . . . . . . . . 25 Informative References . . . . . . . . . . . . . . . . . . . . 26 Schott, et al. Expires 6 May 2027 [Page 2] Internet-Draft AINETOps Problem Statement November 2026 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Artificial intelligence (AI) and in particular the "agent" is being introduced into the operation and maintenance of operator networks. This document uses the term AI native network operations (AINETOps) to describe the resulting paradigm: a mode of network O&M in which AI agents are participants in the operations loop, acting on operator intent rather than merely assisting human operators. AI agents offer the potential to transform O&M from "human-led, OSS/ NMS-passive" management to "intent-driven, self-planning, predictable, and intelligently reasoning" operations. Workflows move from "static scripts" to "self-planning", and security moves from "account/person-based" to "task, operation, and authorization- based"control. Operators realize large-scale deployments of such agents in live networks. However, as agentic AI systems are increasingly introduced into ISP network management systems to execute end-to-end O&M operations, traditional network management platforms are proving insufficient for the full operational lifecycle, e.g., * Unable to manage a rapidly growing fleet of heterogeneous Agents from multiple vendors, with divergent versions and capabilities. There lacks mechanisms for state monitoring, discovery and coordination across massive Agents. * Network operators traditionally focus on whether system functions are operational. They now need to assess whether Agent reasoning and actions are correct, secure, and fit for purpose. Agent autonomous decision-making introduces non-deterministic behaviors; it is challenging to quickly troubleshoot root causes spanning Agent, foundation model, tooling and data layers. * Current interfaces are built for deterministic API invocation, not dynamic semantic collaboration between Agents. There are no standardized mechanisms for Agent discovery, capability description, task decomposition, context propagation, result return, and exception handling across multi-vendor implementations. * Multi-vendor Agents cannot reliably interpret shared business intent, which creates ambiguity when executing cross-domain O&M workflows. Schott, et al. Expires 6 May 2027 [Page 3] Internet-Draft AINETOps Problem Statement November 2026 * Business workflows have evolved from static predefined procedures to dynamically adaptive execution. There is a gap in enforcing guardrails to ensure Agent autonomous decisions stay within operational and business boundaries. * Human oversight becomes harder for multi-Agent chained tasks. Context is often lost after a task passes through multiple Agents and workflow stages, making it difficult for operators to retrieve complete information for auditing and validation. Network-management agents may participate in operational tasks that span multiple vendors, management systems, and administrative domains. Each participant needs to understand the task's objective, network scope, constraints, and permitted actions, and to relate returned results to the information and operations that produced them. When these meanings are represented differently across implementations, an operator may be unable to determine whether a task was completed within its intended boundaries, whether its evidence remains applicable, or whether the requested network outcome was achieved. In a multi-vendor environment, the elements that cross organizational boundaries need to be standardized: identity, permissions, interfaces, data formats, and evidence. Each vendor can choose its own internal implementation, as long as it meets the same security and interoperability requirements. Similar requirements arise when a single operator runs a service across multiple network domains or across different countries. This document examines these operational concerns, identifies relevant existing mechanisms, and describes requirements that may need common conventions, profiles, or additional specifications. It does not assume that every concern requires a new protocol or data model. 1.1. Definition and Terminology * AI: Artificial intelligence * AINETOps: AI Native Network Operations, the O&M paradigm in which AI agents are first-class participants in the operations loop. * NMA (Network Management Agent): An agent that performs network management operations such as fault diagnosis, root-cause analysis, configuration, or optimization. See [I-D.zhao-nmop-network-management-agent]. * HAI (Human-Agent Interface): The interface through which an operations (O&M) person interacts with an NMA, including instruction, approval, handoff, and emergency control. Schott, et al. Expires 6 May 2027 [Page 4] Internet-Draft AINETOps Problem Statement November 2026 * A2A (Agent-to-Agent): The interface between two NMAs. * A2C (Agent-to-Controller): The interface between an NMA and a network controller or NMS. * A2N (Agent-to-Network): The interface between an NMA and network devices. * A2U (Agent-to-User/Human): The interface between an NMA and a human operator (closely related to HAI). * LLM: Large Language Model * MCP: Model Context Protocol * NMS: Network Management System * OSS: Operations Support System 2. Problem Statement This section enumerates the deployment and operation problems identified by the AINETOps. The problems are organized along the natural lifecycle of an agent in production: how it is "managed", how it is "observed", how it "evolves", how a "human" interacts with it, and how "agents interact with each other" to complete a task. 2.1. NMA Lifecycle Management A Network Management Agent is a long-lived production component. Like any production software, it has a lifecycle: it is admitted into production, it runs under monitoring, it is changed and rolled back, and it eventually exits production. A unified operational lifecycle can be described as: Production Admission -> Runtime Monitoring -> Change / Rollback -> Production Exit Based on the whole lifecycle of a NMA, it may introduces operational problems for network management Agents running in live production environments, e.g., * Inconsistent Onboarding Standards and Admission Criteria When a network operations agent is introduced into the production environment, there is no unified standard for defining, describing, and validating its capabilities. Different agent vendors and Schott, et al. Expires 6 May 2027 [Page 5] Internet-Draft AINETOps Problem Statement November 2026 development teams use heterogeneous schemas to express what an agent can do -- supported network domains, permissible action scopes, underlying model types, tool dependencies, and operational constraints -- making it impossible for NMS platforms to perform automated capability matching or policy-driven admission decisions. Furthermore, identity attestation, capability verification, and onboarding workflow approval lack standardized mechanisms: operators cannot reliably answer "who is this agent?", "what exactly can it do?", and "under what conditions is it permitted to operate?" before granting production access. * Fragmented Runtime State Visibility and Non-Reusable Execution Records Once an agent enters active operation, the data that characterize its runtime state, such as health status, key performance indicators, task progress, resource consumption, and error conditions, are exposed through vendor-specific formats with no common schema. Operators cannot aggregate state information across agents from different sources into a unified monitoring view. Execution records including task inputs, reasoning traces, action logs, and outcomes, are similarly non-standardized and lack structural semantics that would enable cross-agent search, replay, audit, or reuse. When an anomaly occurs, the absence of uniform anomaly detection thresholds and alerting mechanisms delays operator awareness, extending mean- time-to-detect and increasing blast radius. * Unregulated Change Management and Inadequate Impact Assessment Agents evolve continuously as models are updated, tools are added or removed, prompts are refined, and configuration parameters are adjusted. However, there is no standardized mechanism for versioning these artifacts, describing the semantic differences between versions, or assessing the potential impact of a change before it is deployed to production. Pre-deployment validation against sandbox/ digital twin environments is inconsistent across platforms; some agents support simulation-based verification while others do not, and even when simulation is available, the fidelity of simulated network environments varies widely. Consequently, changes are frequently pushed into production without sufficient safety validation or impact analysis, introducing uncontrolled risk. * Incomplete Decommissioning Procedures and Residual Trust Surfaces When an agent is retired from the production environment, the decommissioning process is often ad hoc and incomplete. Credentials, API tokens, role bindings, and policy grants associated with the agent may not be systematically revoked, leaving residual trust Schott, et al. Expires 6 May 2027 [Page 6] Internet-Draft AINETOps Problem Statement November 2026 surfaces that can be exploited after the agent's intended operational lifetime. Interface bindings, cached data, and derived artifacts (e.g., learned policies, accumulated telemetry baselines) are not consistently cleaned up according to defined retention or purging standards. Moreover, the decommissioning process itself lacks mandatory audit logging, meaning that there is no tamper-evident record of what was revoked, when, and by whom -- undermining both security posturing and regulatory compliance. 2.1.1. Agent Observability Observability has two distinct dimensions for an agent: * End-to-end task perspective: It needs a cross-component view of a single task as it traverses multiple agents and tools. * Agent perspective: the health and performance of an individual agent -- connection status, model/agent/tool call logging, rate- limit statistics, token consumption, and API rate limits. Base on these two perspective, it may introduces operational problems as below: * Lack of End-to-End Task Perspective Observability In multi-agent collaborative scenarios, a single operational task may span multiple agents, tools and backend systems. Without a cross- component, end-to-end task observability view, operators cannot pinpoint which entity -- Agent, Tool, or other supporting systems -- contributes to latency, errors or task failures. Task chains across distributed agents and tools turn into opaque black boxes. This makes root-cause investigation extremely challenging when service anomalies emerge. * Lack of Agent Perspective Observability Individual agent runtime state remains invisible to operation teams. Operators lack direct visibility into agent connection status, model/agent/tool invocation logs, token consumption, rate limiting statistics and risk profiles. Without dedicated agent observability metrics, it is hard to assess individual agent health, execution performance and runtime risks. This hinders real-time detection of agent-side anomalies. * Fragmented Telemetry Across Agent Pipelines Schott, et al. Expires 6 May 2027 [Page 7] Internet-Draft AINETOps Problem Statement November 2026 Current monitoring systems collect metrics in silos. Telemetry data such as agent call counts, task success rate, task execution latency and abnormal task events are not correlated across the whole task pipeline. Fragmented telemetry fails to reconstruct the full lifecycle of cross-agent task execution. Operators cannot establish a complete trace linking task requests, agent delegations, tool invocations and final outcomes, which undermines auditability and incident post-mortem. 2.1.2. Agent Evaluation and Evolution As agentic AI systems for network O&M are continuously evaluated and evolved for carrier production deployment, there is a lack of standardized mechanisms for dynamic Agent capability assessment and standardized interfaces between Agents and simulation systems. This makes it difficult to sustain objective judgement on Agent operational competence and risk status, e.g., * Absence of Standardized Dynamic Evaluation for Agent Capabilities The operational capability and risk posture of a network operations agent are not static -- they evolve as underlying models are updated, tool integrations change, prompts are refined, and operational context shifts. However, there is currently no standardized framework for continuously evaluating agent behavior in production or near-production environments. Evaluation data produced by different agents, platforms, and vendors use heterogeneous schemas with inconsistent semantics: metrics that share the same name (e.g., "success rate," "latency," "safety score") may be computed using different definitions, over different time windows, against different baselines, rendering cross-agent and cross-platform comparison meaningless. Furthermore, safety and stability evaluations lack consistent evidentiary foundations. Different platforms record different subsets of safety-relevant events -- policy violations, rollback triggers, human intervention requests, anomalous output detections, using incompatible formats and granularity levels. Consequently, determining whether a given agent is "stable" or "safe" enough for production deployment becomes a matter of platform-specific interpretation rather than objective, reproducible judgment. Operators cannot form a credible production-readiness assessment that transcends any single vendor's evaluation methodology. * Non-Standardized Interfaces Between Agents and Simulation/Sandbox Environments Schott, et al. Expires 6 May 2027 [Page 8] Internet-Draft AINETOps Problem Statement November 2026 Pre-deployment validation of agent behavior increasingly relies on simulation or sandbox environments that emulate network topology, device state, traffic patterns, and failure scenarios. However, the interfaces through which agents interact with these environments -- and through which environments report results back to evaluation systems -- are entirely ad hoc. Different simulation platforms return execution results, network state transitions, performance indicators, alerts, anomalies, and business impact assessments using divergent field names, semantic definitions, data granularities, and serialization formats. An evaluation system that needs to consume results from multiple simulation platforms must implement per- platform parsing and semantic translation logic, and even then, identical numerical outcomes may carry different meanings depending on which platform produced them. This heterogeneity has two further consequences. First, test results are difficult to reproduce: if scenario inputs, simulation parameters, and result outputs are all defined by each platform independently, then an evaluation obtained from simulation system A cannot be independently verified on simulation system B under equivalent conditions. Second, cross-platform evaluation trust is fundamentally undermined -- operators cannot determine whether divergent evaluations reflect genuine behavioral differences between agents or merely artifacts of incompatible simulation interfaces and reporting conventions. 2.2. End-to-End Multi-Vendor Agent Execute O&M Operations In network operations workflows, multiple agents often sourced from different vendors, operating within different administrative domains, and built on different model architectures, which must cooperate to decompose, delegate, execute, and verify complex operational tasks. This cooperation requires the continuous exchange of task objectives, operational context, constraints, diagnostic questions, supporting evidence, and risk assessments across agent boundaries. Currently, no standardized semantic models exist for any of these exchange artifacts, rendering end-to-end multi-agent collaboration fragile, non-reproducible, and auditably opaque. Experience from an established inter-domain service illustrates which elements must be agreed upon across organizational boundaries. Consider a VPN service connecting two autonomous networks operated by different organizations. For this to work securely, both sides need to agree on at least the following: Schott, et al. Expires 6 May 2027 [Page 9] Internet-Draft AINETOps Problem Statement November 2026 * Identity and trust anchors: how the networks, gateways, and services authenticate each other, for example through certificates and mutual TLS. The identity must be verifiable across organizational boundaries. * Authorization: which peer is allowed to access which networks, services, and ports. Identity alone does not grant permission. Access rights should be narrowly scoped and revocable. * Connection parameters: compatible settings for the tunnel protocol, algorithms, key rotation, address spaces, routing, DNS, and MTU. * Operations and failure handling: how connections are established, renewed, and terminated, and what happens if a key expires, a connection drops, or a peer is compromised. * Logging and incident response: both operators need enough shared information to investigate outages and security incidents, without unnecessarily exposing operational data. Multi-vendor agent collaboration in AINETOps faces the same categories of agreement, but no equivalent standardized definitions exist yet, as detailed in the following sections. The Figure 1 shows the task delegation and evidence message flow between different agents. Schott, et al. Expires 6 May 2027 [Page 10] Internet-Draft AINETOps Problem Statement November 2026 +-----------+ +-----------+ +-----------+ +-----------+ | Fault | | Domain | |Controller | | Other | | Diagnosis | | Agent | | / Tool | ... | Agent | | Agent | | | | | | | +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ | | | | | | | | | (1) Task (goal / context / constraint) |==============>| | | | | | | | (2) Question & Evidence | (phenomenon / analysis) | | |<==============| | | | | | | | | (3) Task (operation / verification) | |==============>| | | | | | | | (4) Result & Evidence | | (execution result / verification) | |<==============| | | | | | | | | (5) Ongoing | | | Collaboration | | |=================>| | | | | Figure 1: Task Delegation and Evidence Return Message Flow 2.2.1. Human-Agent Interface (HAI) The Human-Agent Interface is where an operations person instructs, approves, and critically intervenes in the actions of an agent. A representative scenario is the approval of a high-risk configuration change, in which the agent proposes remediation options and the operator must decide among them. * Loss of Emergency Breakoff and Rollback Control As autonomous agents execute operational tasks, they often proceed through multi-step remediation workflows without built-in phased confirmation gates. Once task execution has commenced, operational context may become stale or inaccessible. When operators detect risks and need to intervene, they lack immediate, reliable channels to issue emergency rollback or isolation commands via the agent interaction surface. This creates safety hazards for high-risk network configuration changes, where timely human override is essential. Schott, et al. Expires 6 May 2027 [Page 11] Internet-Draft AINETOps Problem Statement November 2026 * Insufficient Option Detail and Absence of Attached Evidence Chains When an agent presents remediation alternatives to operators, candidate options typically lack structured risk classification, quantified impact scope, and clear simulation prerequisites. Agent-delivered conclusions do not bundle supporting evidence including execution logs, performance metrics, time windows or network topology snapshots. Without a complete, verifiable evidence trail attached to each proposed option, operators cannot make well-informed real-time judgments, nor readily support post- incident review and regulatory compliance. * Semantic and Format Limitations of Legacy Human-Network Interfaces Traditional human-network interfaces such as CLI, web GUIs, traps, syslog and notifications support basic command delivery and alerting, but are designed for human-to-device interaction rather than bidirectional human-agent dialogue. Existing standards like [RFC5424] define event logging and notification formats, yet they do not specify structured semantics for agent to operator recommendation exchange. The absence of standardized message schemas for remediation options prevents consistent communication of action labels, risk levels, impact scope, affected services, and pre- confirmation simulation requirements between operators and agents. 2.2.2. Agent-Agent Interface When an upstream agent delegates a sub-task to a downstream agent, there is no common schema for expressing what the task is, what it must achieve, and under what constraints it must operate. Three specific problems compound this deficiency: * Task objective semantics are inconsistent: Different agents represent intent, target object, and expected outcome using heterogeneous natural-language templates, structured fields, or ad-hoc JSON schemas with no shared vocabulary. An "intent" expressed by one vendor's fault-diagnosis agent cannot be reliably parsed and acted upon by another vendor's domain-resolution agent without per-integration translation logic. * Task scope boundaries are not uniformly specified: The network scope (which devices, domains, or topology regions are in scope), impact scope (what services or customers may be affected), temporal validity window (when the task is valid for execution), and constraint conditions (rate limits, maintenance windows, coexistence rules) are either omitted entirely or encoded in vendor-specific formats that downstream agents cannot interpret programmatically. Schott, et al. Expires 6 May 2027 [Page 12] Internet-Draft AINETOps Problem Statement November 2026 * Task state transitions are not interoperable: Task lifecycle states -- pending, dispatched, in-progress, completed, failed, rolled back -- along with structured error codes, partial result summaries, and causal failure explanations, lack a common representation. Consequently, when a task passes through a chain of three or more agents, each intermediary must implement custom state mapping, and the original task context is progressively lost or distorted. * Agent identity and trust are not verifiable across organizational boundaries: An agent cannot be reliably attributed to a vendor or operator by its peers, and there is no standardized mechanism (e.g., certificates and mutual TLS) by which one organization's agent authenticates another's. Without verifiable identity, authorization decisions and audit records cannot be anchored to a known party. * Delegated permissions are not constrained across agent chains: When an upstream agent delegates a sub-task, there is no standard permissions format ensuring that the downstream agent receives only the specific data and tool access approved for that task, and that delegated permissions can only be narrowed, never expanded, as the task traverses intermediate agents. 2.2.3. Human-Agent and Agent-Agent Interface As agents collaborate, they continuously exchange observational data, diagnostic logs, performance indicators, command outputs, and analytical conclusions as evidence supporting their decisions. No standard model governs the structure, provenance, or quality of this evidence: * Evidence structure is fragmented: Observations, system logs, KPIs, CLI command outputs, and analytical conclusions are each serialized using different schemas, field naming conventions, and granularity levels across vendors and platforms. A piece of evidence produced by one agent cannot be consumed by another without format-specific parsing and semantic normalization. * Evidence provenance and quality are opaque: Critical metadata -- the source agent or system that produced the evidence, the timestamp of collection, the confidence level or uncertainty bounds, the freshness relative to current network state, and the chain of derivations (raw data -> processed metric -> conclusion) -- are either absent or inconsistently represented. Downstream agents receiving evidence cannot assess its reliability or decide whether it is sufficiently fresh and trustworthy to base further decisions upon. Schott, et al. Expires 6 May 2027 [Page 13] Internet-Draft AINETOps Problem Statement November 2026 * Evidence-to-decision traceability is broken: There is no standardized mechanism to bind a piece of evidence to the task or question it addresses, to the analytical conclusion it supports, or to the subsequent action it justifies. When an operator or auditor attempts to reconstruct why a particular agent made a particular decision, the evidentiary trail is discontinuous across agent boundaries, making root-cause analysis, accountability attribution, and post-incident review fundamentally impaired. 2.2.4. Task Risk Classification Operational tasks in carrier networks carry inherently different risk profiles depending on the nature, scope, and potential blast radius of the actions involved. However, there is no standardized framework for classifying, communicating, and enforcing risk-appropriate controls across multi-agent collaboration chains: * Risk classification is not uniform: Different operators, vendors, and platforms use incompatible risk taxonomies. Some use numeric scales (e.g., R0-R5), others use categorical labels (low / medium / high / critical), and still others embed risk implicitly in role-based access rules. There is no shared vocabulary enabling an upstream agent to communicate "this sub-task carries risk level R4" such that all downstream agents and control-plane components interpret and enforce it consistently. * Permission and approval boundaries are misaligned. For a given risk level, the required human approvals, authorization scopes and executable action sets vary across platforms without a standard mapping. An operation classified as "high-risk" by one domain's policy engine may require four-eyes approval and sandbox pre- validation, while the same operation in another domain may execute autonomously with no human gate. This inconsistency creates exploitable asymmetries where high-risk actions can be routed through lower-control domains to bypass intended safeguards. * Control requirements lack consistent enforcement semantics. Risk- mitigating controls -- mandatory pre-execution verification, automatic rollback triggers, execution boundary confinement (e.g., read-only vs. write-enabled scope), and temporal constraints are not expressed in a machine-interpretable form that travels with the task delegation. Consequently, even when an originating agent specifies strict controls, those controls may be silently dropped or weakened as the task traverses intermediate agents, leaving the final executing agent unaware of the originally intended safety envelope. Schott, et al. Expires 6 May 2027 [Page 14] Internet-Draft AINETOps Problem Statement November 2026 3. Gap Analysis and Requirements of AINETOps 3.1. NMA Lifecycle Management Two concrete gaps make the lifecycle unmanageable today: * Fragmented state and configuration: Across lifecycle stages, agent states and configurations are inconsistent. Information is difficult to reuse, weakening observability, auditability, and continuity. There is no single, standardized capability metadata model for an NMA. * No versioned evolution or retirement: Models, knowledge, and tools lack a unified versioning and validation process. Vendor-specific exit logic creates orphaned access and compliance risks: when an agent is retired, permissions and credentials may not be revoked consistently, leaving residual attack surface. R-1: A unified lifecycle model for Network Management Agents may be defined -- covering standard identities, capability metadata, and trust establishment, together with versioned change, rollback, and offboarding, so that multi-vendor NMAs can be governed consistently across production admission, runtime monitoring, change/rollback, and production exit. 3.1.1. Agent Observability Existing IETF collection frameworks provide infrastructure but not agent-specific semantics. IPFIX [RFC7011] and Syslog [RFC5424] give standardized flow and event collection, but lack agent-specific semantic models. NETCONF notifications [RFC5277] provide a subscription mechanism but do not cover agent internal state and model-inference metrics. Without a cross-component, end-to-end task view, it is impossible to tell which part -- agent, tool, or another system -- is responsible for latency or failure; task chains spanning multiple agents become opaque black boxes. Without an agent-perspective view, individual agent health and performance remain invisible to operations personnel. R-2: A unified observability schema and a set of agent telemetry and metric standards may be defined -- covering connection status, model/agent/tool call logging, token consumption, and API rate limits. So that operations personnel gain end-to-end task observability across heterogeneous agents and tools. Schott, et al. Expires 6 May 2027 [Page 15] Internet-Draft AINETOps Problem Statement November 2026 3.1.2. Agent Evaluation and Evolution Two related gaps concern the "quality" of an agent over time: * Evaluation baseline: Network operation agents lack unified standards for capability definitions, test tasks, datasets, and evaluation metrics. * Evolution and regression: Agent evolution lacks a unified mechanism to compare a new version against a previous one and to identify capability gains or regressions across operational tasks. Without a unified evaluation baseline, it is difficult to determine whether an agent meets production requirements, and it is difficult to objectively compare the capability differences among different agents and versions. The Benchmarking Methodology Working Group (BMWG) is advancing agent benchmarking, but standards for evaluating intelligent agents are still lacking. Without impact validation and regression mechanisms, unverified capability regressions may enter production, increasing operational risk. The IETF has not yet initiated any work on NMA evolution. R-3: How can a unified assessment method -- defining what to evaluate, how to test, how to measure, and how to determine whether an agent meets requirements -- be established, together with agent evolution mechanisms that define triggering conditions, evolution scope, change mechanisms, and verification processes to ensure continuous capability improvement and operational reliability. 3.2. End-to-End Multi-Vendor Agent Execute O&M Operations End-to-end multi-agent collaboration in network operations fails to interoperate not because of any lack of connectivity or transport, but because three shared semantic models are entirely absent at the standards level: there is no Task Model to unambiguously express task goals, scopes, and lifecycle states, so upstream intent degrades into vendor-specific representations that downstream agents cannot reliably parse or align; there is no Evidence Model to normalize the structure, provenance, quality, and traceability of observations, logs, metrics, and analytical conclusions, so evidence cannot be trusted, compared, or bound back to the tasks and decisions it supports; and there is no Task Risk Classification to define consistent risk levels, approval mappings, and enforceable control requirements, so safety envelopes vary across domains and can be silently weakened or bypassed as tasks traverse intermediate agents. Because these three gaps compound multiplicatively rather than independently--distorted task context cannot be corrected without Schott, et al. Expires 6 May 2027 [Page 16] Internet-Draft AINETOps Problem Statement November 2026 trustworthy evidence, and erroneous decisions cannot be contained without enforceable risk controls--each additional hop across agents and administrative domains amplifies the inconsistency, ultimately rendering multi-agent collaboration incapable of being executed reliably, safely, or auditable end to end. 3.2.1. Human-Agent Interface (HAI) Existing Human-Agent interfaces are insufficient for agent interaction: * Insufficient option detail and no evidence chain: CLI, Web GUI, and Trap provide basic command and alert channels but lack structured semantics for agent interaction. Each remediation option is presented with no structured risk classification, impact scope, or simulation requirement. Agents deliver conclusions without showing the supporting data trail (logs, metrics, time windows, topology evidence). * Loss of emergency break-off / rollback control: Syslog and notifications [RFC5424] provide standardized event logging but do not cover bidirectional human-agent dialogue. Agents lack phased confirmation mechanisms after launching tasks; when an operator needs to intervene, context has already been lost. Operators cannot rapidly issue emergency rollback or isolation commands through an agent interaction. R-4: How can a structured Human-Agent Interaction message format be defined -- carrying, for each remediation option, an action label, a risk level, an impact scope, the affected services, and whether simulation is required, together with an evidence chain and auditability mechanism that attaches supporting evidence (logs, metrics, topology snapshots, time windows) to agent analysis, options, and operator decisions. 3.2.2. Task Model (Agent-Agent Interface) To complete an end-to-end operation, a task must often be decomposed and delegated across multiple agents, controllers, and domain tools. A unified "task model" is the schema that expresses such a task -- its identity, intent, time window, scope, suggested operations, and status. Across agents, controllers, and domain tools, the same operation task is often expressed differently in goals, scope, constraints, execution bounds, status, and outputs. This makes consistent delivery, delegation, and task continuation difficult. TM Forum's A2A-T / Task-T work defines task description, interaction flow, and Schott, et al. Expires 6 May 2027 [Page 17] Internet-Draft AINETOps Problem Statement November 2026 status management between agents, and its Task-T / Event-T / Negotiation-T work aligns with shared telecom semantics -- but a standardized task-definition schema for network management agents within the IETF scope does not yet exist. R-5: A standardized task-definition schema is required for Network Management Agents, expressing task identity, intent, time window, scope, constraints, execution bounds, status, and outputs, so that a task can be consistently delivered, delegated, and continued across heterogeneous agents and domain tools. 3.2.3. Evidence Model (Agent-Agent Interface) Closely coupled to the task model is the "evidence model": the structured representation of what an agent observed, did, and concluded, so that a downstream agent or a human can reason over and audit it. Observations, commands, intermediate results, and verification data are reported in inconsistent formats and often lack shared provenance, confidence, and trace context. This weakens cross-agent reasoning, auditability, and human handoff. There is currently no common evidence package that captures provenance, confidence, trace context, and verification results. R-6: How can a unified evidence model be defined, covering the evidence package, provenance, confidence, trace context, and verification results to support cross-agent reasoning and human review is a problem. 3.2.4. Task Risk Classification ISP network tasks carry very different levels of risk. A read-only diagnostic is far less risky than a configuration change on a router. Yet there is no unified standard mapping risk levels to the permissions, approvals, execution scope, rollback, and verification requirements that should apply to each level. Without a unified risk classification, the authorization and intervention semantics described above cannot be anchored: "task- based security" requires a shared notion of how risky a task is. Operators currently encode this knowledge implicitly in tooling and process, which does not scale to multi-vendor agents acting autonomously. Schott, et al. Expires 6 May 2027 [Page 18] Internet-Draft AINETOps Problem Statement November 2026 R-7: How can a unified task-risk classification be defined: for example, R0-R5 risk levels and common assessment rules for network operation tasks, together with the control requirements (permissions, approvals, execution scope, rollback, and verification) that apply to each risk level is a problem. 3.2.5. Multi-Vendor Interoperability Baseline The gaps described above share a common root cause: in a multi-vendor environment, identity, permissions, interfaces, data formats, and evidence all cross organizational boundaries, yet no shared baseline defines them. A practical starting point in standardization is to agree on a small interoperability profile rather than a complete framework. R-8: A minimal multi-vendor interoperability profile for Network Management Agents may be defined -- covering identity proof, permitted tasks, a permissions format with non-expandable delegation, encryption, data-handling rules, logging, revocation, and versioning -- so that agents from different vendors and administrative domains can interoperate under a common security and interoperability baseline. 4. Use cases of AINETOps 4.1. Node Configuration Generation This section describes the use case of multi-agent network configuration generation, in which a high-level service request is translated into validated, per-device configurations through the orchestration of multiple cooperating agents. The use case builds on deployment experience in which configuration generation is decomposed into requirement analysis, planning, generation, validation, and deployment stages, executed by specialized agents that exchange a shared Task Model and Evidence Model. A typical request is expressed as a customer-facing goal, for example, "build an L2VPN service between site X and site Y with 100 Mbps of bandwidth", or "generate an L3VPN for customer A with two sites". The objective is to produce syntactically correct, intent- consistent configurations for every involved device, together with validation evidence, while enforcing operation boundaries (e.g., read-only analysis until explicit approval) and human checkpoints before any configuration reaches the network. The use case relies on two complementary data structures that are shared by all participating agents: Schott, et al. Expires 6 May 2027 [Page 19] Internet-Draft AINETOps Problem Statement November 2026 A Task Model that describes the task itself: its identifier, type, goal (the original request), target process (e.g., the sequence of stages to generate a router configuration), execution mode (e.g., PLAN with READ_ONLY semantics), execution window, current step and current job, process flow, status (RUNNING, END, ERR, EXIT, or WAITING), exit reason, checkpoints that gate human approval, and the list of target devices. The Task Model enables each agent to carry out its part of the task, carries the process information used to control the flow and avoid loops, embeds the security policy that constrains operation boundaries, records human-in-the-loop information for key checkpoints, and carries the error information that supports exception rollback. An Evidence Model, structured as a dictionary keyed by step holding JSON documents, that retains detailed stage outputs for in-depth analysis by upstream or downstream agents while saving the context of model invocations. In current deployments the Evidence Model is populated mainly by the validation stage, where it stores the detailed output of the validation system, service impact metrics, and the test plan and process. Together, the Task Model and the Evidence Model provide a unified, abstracted data model for multi-agent interaction, in the same spirit that YANG provides a unified data model for management interfaces. The configuration generation service is orchestrated as a workflow comprising the following agents and components: A Planning Agent that orchestrates the service process, performs resource authorization and the confirmation flow, initializes the Task Model and Evidence Model, provides the API and human-machine entry points, and delivers the final configuration to the devices via the controller. A Requirement Analysis (sub-)Agent that extracts and classifies requirements (e.g., determining the service type), refines the user requirements and confirms missing parameters, and checks permissions and resource availability to judge feasibility. A Configuration Planning (sub-)Agent that decomposes the task to avoid missing configurations in the generation stage, confirms the environment, derives parameters, selects default parameters from built-in configuration templates and cases, and requests the required network resources (e.g., VLAN, RD, IP addresses) from the resource system. Schott, et al. Expires 6 May 2027 [Page 20] Internet-Draft AINETOps Problem Statement November 2026 Per-vendor Gen-Config Agents that generate the full per-device configuration using skills such as configuration samples, CLI manuals, and plans; syntax checking ensures accuracy. A master agent performs task split and merge for multi-vendor cases and re-plans based on validation results. A Test & Validation Agent that validates the generated configuration, analyzes its service impact, and feeds the results back to the configuration generation agents for iterative processing. A simulation platform may be used for pre-deployment verification. Supporting systems: a Controller that retrieves topology, baseline configuration, and other live-network information and that delivers the final configuration to the devices; a Resource System that allocates resources such as IP addresses, VLANs, and route distinguishers; and an NMS that provides device resource information. The workflow proceeds in five stages. (1) The operator submits the original request; the Planning Agent initializes the Task Model with read-only mode during analysis and planning and enforces resource authorization. (2) Requirement analysis extracts and classifies the requirement (e.g., service type L2VPN), confirms missing parameters, and checks feasibility; the outcome is appended to the process flow. (3) Configuration planning decomposes the task, confirms the environment, derives parameters, and requests resources (VLAN/RD/IP) from the Resource System, while the Controller retrieves topology and baseline configuration. (4) Generation produces the per-device configuration, with the master agent splitting and merging work across per-vendor Gen-Config Agents and syntax checking ensuring accuracy; the Test & Validation Agent then validates the configuration and analyzes its impact, recording Evidence, and on failure the result is fed back for iterative re-generation and re- validation (e.g., req_analysis -> plan -> generate -> validate -> generate -> validate -> configure), with the error information in the Task Model supporting exception rollback. (5) After validation and the human checkpoints, the Controller delivers the final configuration to the devices (e.g., per-PE payloads), and the Task Model transitions to END. One possible interoperability failure occurs when configuration generation, validation, and deployment refer to different revisions of the proposed configuration. A validation result may be correct for the configuration it examined but no longer applicable to the configuration subsequently delivered to a controller. The exchanged information therefore needs to identify the configuration revision, validation inputs, checks performed, and result. Operator approval also needs to be associated with the Schott, et al. Expires 6 May 2027 [Page 21] Internet-Draft AINETOps Problem Statement November 2026 applicable proposal. Configuration generation, validation, controller acceptance, device application, and service verification are separate outcomes; completion of one does not establish completion of the others. 4.2. Cross-Domain Traffic Steering with Multi-Agent Coordination This section describes the use case of resolving cross-domain traffic congestion for an enterprise L3VPN through the coordination of a global Planning Agent with per-domain planning agents, using the same Task Model and Evidence Model. The use case illustrates multi-agent interworking applied to traffic management in a multi-domain setting, and complements the multi-layer planning use cases. Consider an enterprise that connects Site A and Site B via an L3VPN that spans two domains, Domain A and Domain B. The primary path P1 is running at 92% utilization on a 100G link, while the backup path P2 is at 55% and a candidate path P3 is at 30%. The operator needs to migrate 25 Gbps of VPN traffic from P1 to P3, subject to multi-domain constraints: VPN reachability must be preserved, bandwidth must be sufficient on the new path, and end-to-end latency must not exceed 40 ms. No actual network change may occur before the candidate solution is verified end to end. Because no single domain agent holds the full topology, constraints, and policy authority, the planning problem requires cross-domain coordination. The objective is to generate an implementable cross-domain L3VPN planning solution: meet the multi-domain constraints and output paths, policies, and configuration parameters for each domain; verify end-to-end feasibility through unified simulation without changing the actual network; and ensure VPN reachability with sufficient bandwidth and latency at or below 40 ms. Three cooperating agents perform the planning, supported by shared network data and tools that the agents invoke via MCP: A Planning Agent (global network planning agent) that performs global analysis and traffic identification, decomposes the task and coordinates across domains, collects and integrates the domain plans, runs unified simulation and feasibility verification, and generates the end-to-end L3VPN planning solution. Schott, et al. Expires 6 May 2027 [Page 22] Internet-Draft AINETOps Problem Statement November 2026 A Domain A Agent (network planning agent for Domain A) that, given Task-A ("generate Domain A traffic steering plan", scope PE-A -> E3 for VPN-001), computes the optimal intra-domain path (e.g., an SR Policy), generates the traffic-steering policy (routing/QoS), derives example device configuration parameters, and produces constraint check results for Domain A against the target that link utilization after migration does not exceed 70%. A Domain B Agent (network planning agent for Domain B) that, given Task-B ("generate Domain B traffic carrying plan", scope I3 -> PE-B -> CE-B for VPN-001), produces the optimal intra-domain path, the bandwidth/QoS policy, example device configuration parameters, and constraint check results, against the targets of utilization at or below 70% and VPN reachability. The agents share four classes of network data and tools, invoked through MCP: a Network Data Service (topology, link performance, resource constraints, routing); a Policy Planning Tool (path calculation, SR policy generation); a Unified TE Simulation Tool (capacity check, latency evaluation, SLA verification); and a Configuration Check Engine (syntax check, reachability, impact assessment). The interaction proceeds in five steps: (1) the Planning Agent sends Task-A, including the constraints, to the Domain A Agent; (2) Domain A returns the Domain A plan with Evidence A; (3) the Planning Agent sends Task-B, with constraints, to the Domain B Agent; (4) Domain B returns the Domain B plan with Evidence B; and (5) the Planning Agent performs unified simulation over the combined domain plans and the TE model, and generates the end-to-end L3VPN planning solution. The returned Evidence allows the Planning Agent to verify why each domain plan is feasible (constraint checks, latency evaluation) without re- executing the domain agents' internals. The process begins with traffic identification: the Planning Agent observes that P1 (primary, 100G) is at 92% utilization and determines that 25 Gbps must be migrated to the candidate path P3 (30%), and initializes the Task Model with the goal, constraints, and read-only mode. The Planning Agent then decomposes the task and dispatches Task-A (traffic steering plan for Domain A, scope PE-A -> E3) and Task-B (traffic carrying plan for Domain B, scope I3 -> PE-B -> CE-B) with explicit constraints. Each domain agent computes its optimal intra-domain path (e.g., an SR Policy), steering or bandwidth/QoS policy, example device configuration parameters, and constraint checks, returning the plan plus Evidence. The Planning Agent then feeds the domain plans and the TE model into the Unified TE Simulation Tool (capacity check, latency evaluation against the 40 ms bound, SLA verification) and into the Configuration Check Engine Schott, et al. Expires 6 May 2027 [Page 23] Internet-Draft AINETOps Problem Statement November 2026 (syntax, reachability, impact assessment); no actual network change occurs during this phase. The operator reviews the end-to-end plan and its evidence at the Task Model checkpoint. Upon approval, policies and configurations are delivered via the domain controllers, the Task Model transitions to END, and the Evidence is retained for audit and for the trajectory records. One possible interoperability failure occurs when domain agents use different meanings for available bandwidth. One agent may report unused physical capacity, while another reports bandwidth available under reservation or admission policy. The values may use identical units while supporting different feasibility conclusions. Each domain's result therefore needs sufficient context to interpret its constraint checks, including the bandwidth definition, traffic direction, relevant time or model version, and assumptions. The coordinating agent also needs to determine whether the domain plans are compatible at their boundaries. Successful local checks do not by themselves establish end-to-end feasibility. 5. Relationship to Existing Work Existing mechanisms provide important foundations for agent-based network management. A2A defines generic task, status, message, and artifact mechanisms. Existing IETF management protocols and models provide access to network configuration and operational state. [RFC9222] discusses lifecycle considerations for Autonomic Service Agents, while the NMA concept draft describes agent roles and logical interfaces. ICON addresses agent observability, control, and intervention. The question examined here is which network-management information and operational meanings need to be shared across these interfaces, and whether existing mechanisms can represent them consistently. Examples include network and service scope, task constraints, references to the configuration or model used for analysis, and the distinction between a computed result and a verified network outcome. Requirements identified in this document should distinguish reuse of an existing mechanism, a need for a common application profile or mapping, and a candidate gap requiring further specification. Related requirements should be coordinated with the relevant efforts." 6. IANA Considerations This document has no IANA actions. Schott, et al. Expires 6 May 2027 [Page 24] Internet-Draft AINETOps Problem Statement November 2026 7. Security Considerations This document is a problem statement and does not itself introduce new protocols or change the security properties of existing systems. However, the deployment of AI agents in production networks raises security and trust considerations that motivate several of the problems described in draft: task-based authorization, emergency break-off and rollback control, and task risk classification. In particular, the shift from account-based to task-based security, and the need for evidence chains and auditability, are direct responses to the risk of an autonomous agent taking an unauthorized or unexpected action. Multi-vendor deployment sharpens these concerns. An agent operated by another vendor or in another administrative domain remains an external party across a trust boundary. Participants therefore need standardized data classification and handling rules -- whether content is confidential, whether it may be stored or shared, and how long it may be retained -- as well as common security event records that identify the task, the participating agents, the permissions exercised, and the actions performed, subject to defined privacy and retention rules. In addition, changes to protocols, capabilities, or security requirements must not silently break interoperability, which makes versioning and compatibility part of the security surface. Any future solution documents developed from this work must analyze their own security considerations, including agent authentication and authorization, the integrity and confidentiality of the Human-Agent Interface and Agent-Agent interfaces, and the auditability of agent actions. Acknowledgements Much thanks for the valuable comments or feedback from XXX. References Normative References [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . Schott, et al. Expires 6 May 2027 [Page 25] Internet-Draft AINETOps Problem Statement November 2026 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, . Informative References [I-D.zhao-nmop-network-management-agent] XingZhao, Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and J. Zhou, "AI based Network Management Agent(NMA): Concepts and Architecture", Work in Progress, Internet-Draft, draft-zhao-nmop-network-management-agent-05, 5 July 2026, . [RFC9222] Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso, "Guidelines for Autonomic Service Agents", RFC 9222, DOI 10.17487/RFC9222, March 2022, . Authors' Addresses Roland Schott Deutsche Telekom Darmstadt Germany Email: Roland.Schott@telekom.de Qiong Sun China Telecom Beijing China Email: sunqiong@chinatelecom.cn Daniel Voyer Cisco Systems, Inc. Montreal Canada Email: danvoyerwork@gmail.com Schott, et al. Expires 6 May 2027 [Page 26]