Huawei

christopher.janz@huawei.com

Huawei

hesam.rahimi@huawei.com

Huawei

henry.yu1@huawei.com

Network Management Research Group NaaS intent agent negotiation closed loop autonomous networks This document describes a possible direction for the management of Network-as-a-Service (NaaS), in which the relationship between a service consumer and a provider is treated not as a static contract but as a continuous, automated negotiation conducted on both sides by cognitive software agents. A NaaS whose required bandwidth, latency and availability move continuously cannot be settled once at order time; it is a standing dialogue - intent, quote, agreement and in-life change - that today stops at the customer-operator boundary and is bridged by humans. The document frames that boundary as the unautomated gap, sketches an end-to-end agentic negotiation architecture that closes it, and describes the intent instance as a managed object whose life cycle includes scarcity-driven pricing and closed-loop renegotiation. It maps the architecture onto already-published specifications from several bodies, showing that the direction rests on a standards basis rather than on new protocol invention. Two NaaS settings illustrate its utility.

Introduction Network-as-a-Service (NaaS) describes an arrangement in which a consumer obtains network services on demand, expressed by what the consumer needs rather than by how the provider realises it. For a class of demanding applications the bandwidth, latency and availability a service must deliver do not hold still: they track the workload above the network, which itself moves with external events. A service whose required characteristics change continuously cannot be captured by a contract signed once at order time. The relationship is inherently in-life rather than one-shot - a standing, ongoing dialogue between the consumer and the operator about what is needed now, what it costs now, and what should change next. Inside an operator, much of the machinery to conduct that dialogue already exists. Closed-loop automation assures live services against their objectives; intent-driven management lets objectives be stated declaratively; and economic frameworks for NaaS describe how a provider should ration scarce resources by price. Inside a consumer, applications know the quality they need and the price they are willing to pay. What still depends on a human is the seam between the two: the customer-operator boundary, across which intent, quote, agreement and in-life change have to pass. Standards exist on both sides of that seam, but they stop at the edge and do not meet across it. A consumer that is rich in intent meets an operator that is rich in capability in a portal: a person fills in a form, an order works its way through tickets, and the result is measured in days. There is no live negotiation - no counter-offer, no scarcity-aware quote, no automatic in-life change - and the signed contract is opaque to the consumer's own software. The broader move toward agentic software architectures, in which autonomous components hold knowledge, reason, converse and act through well-defined tools, makes a different option conceivable. If each side of the boundary is represented by an agent, the dialogue that a human conducts today can be conducted between the agents directly, in seconds rather than weeks, and continuously rather than once. This document explores that direction. It frames NaaS as a standing negotiation (), states the boundary problem (), sketches an end-to-end agentic negotiation architecture that closes it (), and describes the life cycle of the negotiated object (). It then maps every interface and event of the architecture onto an already-published specification, drawn from several standards bodies and from emerging ecosystem work, to show that the direction is a composition of existing standards rather than a call for new protocol (). Two NaaS settings illustrate the utility of the approach (), and the document closes by situating the work relative to current NMRG activity and naming the research questions it raises (). None of the architecture described here is presented as a worked engineering specification; it is a direction the authors believe is worth the research group's attention.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used:

Network-as-a-Service (NaaS):

a network service obtained on demand and expressed by required outcomes - typically bandwidth, latency and availability - rather than by the resources used to realise it, as framed for the management context by .

Cognitive Agent:

an autonomous software entity built around a language model and one or more controlled stores of knowledge, able to reason about what it is presented with, to converse in natural language, and to act on the world only through a bounded set of typed tools .

Negotiation Plane:

an additive layer in which the consumer's and the operator's agents exchange intents, quotes, agreements and counter-offers. It sits above whatever orchestration each party already runs and takes no hard runtime dependency on it.

Intent:

a declarative expression of operational objectives that an entity wishes a network to meet, without specifying how, as defined by .

Intent Instance:

the live, managed object created when an intent is accepted: a standing agreement with state, governed across its life from negotiation through assurance, renegotiation and termination, rather than a static document.

Intent Wallet:

a signed, auditable authorization object, carried with each intent, that states the spending and policy envelope within which a consumer's agent may commit - the network's equivalent of an agent-payment authorization.

Scarcity-Based Pricing:

the rationing of network resources through price rather than by exposing allocation to the consumer, with scarcer resources priced higher than plentiful ones .

Closed Loop:

a control arrangement in which observed or forecast behaviour of a live service is continuously compared against its objectives and drives corrective action without human intervention .

Variable Abstraction:

the operational practice of presenting information at the level of detail appropriate to a particular interaction .

NaaS as a Standing Negotiation The management framework for NaaS set out in distils the setting into three recurring characteristics, all of which bear on why the relationship cannot be static. First, service composition is complex: a service may be connectivity-only or may include non-connectivity components at arbitrary topological complexity, each component individually customised for bandwidth, latency and availability. Second, composition is dynamic: services, their components and their characteristics are created, modified and deleted continuously, not once at order time, so the relationship is inherently in-life. Third, demand is fragmented: it arrives in parallel from many sources, aggregated through stages under different ownership, so that retail and wholesale demand may flow through one or more NaaS operators before reaching the framework that satisfies it. Taken together these characteristics describe demand that is continuous, heterogeneous and economically driven. The same framework observes that a NaaS consumer has no intrinsic means of regulating its own resource use and that resources should therefore be rationed rationally, generally through price, with scarcer resources priced higher than plentiful ones. A NaaS relationship therefore has the shape of a market: demand is endogenous to the applications above the network, and willingness to pay - not visibility into allocation - is what bounds consumption. Treating such a relationship as a fixed contract is a category error; it is more faithfully modelled as a continuous negotiation between the two sides. What makes that negotiation tractable to automate is that the consumer and the operator each already hold one half of it. The consumer is intent-rich: it knows the quality-of-service, latency, bandwidth and cost ceiling it wants. The operator is capability-rich: it offers graded services over resources whose scarcity and price move in real time. The missing element is not knowledge on either side but a means of conducting the exchange between them automatically and continuously.

Problem Statement: Intent Does Not Cross the Boundary Closed-loop automation already lives inside the operator, and intent already lives inside the consumer; standards exist on both sides. The gap is the customer-operator boundary itself. Today that boundary is crossed by a human: a person reads the consumer's need, translates it into an order, and waits while the order traverses business and operations support systems. The crossing is slow, measured in days to weeks; it is one-directional, with no counter-offer and no scarcity-aware quote; it is one-shot, with no automatic in-life change as conditions evolve; and its product - the signed contract - is opaque to the consumer's own agents, which cannot reason about an obligation they cannot read. The direction explored in this document is whether the two sides, each represented by a cognitive agent, can conduct that crossing between themselves: declaring intent, returning a scarcity-aware quote, exchanging counter-offers, signing a machine-readable agreement, and renegotiating it in flight when conditions change - calling on a human only where the agents cannot proceed. The remainder of the document describes an architecture for doing so and the standards on which it rests.

An End-to-End Agentic Negotiation Architecture

Three Domains and a Negotiation Plane The architecture organises the negotiation across three interoperating domains, joined by a negotiation plane that is additive: it sits above whatever orchestration the operator already runs and wraps it through typed tool interfaces, taking no hard runtime dependency. The Enterprise domain is the intent owner. It acts as the intent wallet for network services: it detects application demand, expresses it as intent, and authorises spend within a signed policy envelope. The Business Support System (BSS) domain is the business broker. It verifies authorization, prices the catalog against live scarcity, signs agreements and drives renegotiation, translating operational reality into commercial offers and counter-offers. The Operations Support System (OSS) domain is the intent handler and executor - the existing closed-loop platform, now wrapped in an agentic layer - which plans and provisions the service across its segments and then assures the live agreement. sketches the arrangement.

The negotiation plane across three domains. | (verify, price,|==>| (plan, provision| | wallet) | A2A | sign, reneg.) | | assure) | +----------------+ | +----------------+ +-------+--------+ | | | negotiation plane | wraps | (additive, no hard runtime v existing | dependency) orchestration ]]>

Cooperating Agents with Single Responsibilities Within the three domains the negotiation is carried by a small set of cooperating agents, each with a single, auditable responsibility, and every state change flows through a typed tool rather than through free text. The arrangement described by the authors uses seven. On the Enterprise side, a requirement agent translates application telemetry into a service intent, and a policy agent holds the intent wallet, attaches it to every intent, debits on acceptance, and decides on counter-offers within signed guardrails. On the BSS side, a policy agent verifies the wallet end-to-end - signature, expiry, revocation, holder and policy fit - before any token is spent, and a negotiation agent returns scarcity-aware quotes, signs agreements, emits orders and runs the renegotiation strategy. On the OSS side, a negotiation agent validates the order and hands off across a deliberately thin BSS-OSS interface, a planning agent provisions the service across access, transport and optical segments, and an assurance agent runs a per-agreement state machine over telemetry and forecast, emitting predicted-breach and recovery events. The decomposition is illustrative rather than prescriptive; what matters is that responsibilities are separated, that each state-changing action is attributable to a single agent, and that the two sides are peers conducting a dialogue rather than a client driving a server.

Four Well-Defined Seams The plane is bound together by four kinds of interface, and a single principle governs all of them: the language model supplies judgement, but every state-changing action flows through a typed call, never through the prompt. Agent-to-agent exchange across organisational domains - intents, quotes, agreements, counter-offers, and the wallet credential - travels over an agent-to-agent protocol . Agent-to-tool exchange within a single trust domain - price, sign, debit, provision, migrate, revoke - travels over a typed tool protocol ; this is the state-mutation boundary. Events fan out over a publish/subscribe fabric, so that downstream agents derive their own state by subscribing rather than polling. A live event feed drives operator and consumer dashboards from the same stream that drives audit and replay. Because every mutation is a typed, published event, the negotiation is auditable and replayable by construction.

The Intent Wallet and a Bounded Model Authorization in the architecture is a signed object, and judgement is bounded by deterministic rules. The intent wallet is realised as a verifiable credential : a signed, auditable statement that a given agent may commit up to some amount, for workloads of some class, with some service-level floor, within some time window. It rides with every intent as a message part, so that trust travels with the request; the operator verifies it before any quoting effort is spent, and debits are gated against a cumulative ledger so that they survive re-issue. The credential is the cryptographic container for the consumer's business logic - for example, raising the ceiling for a revenue-critical workload class while another class is held down. The language model contributes judgement in the grey area: narrating a quote, choosing among acceptable items, accepting or rejecting a counter-offer with awareness of workload class. Deterministic checks enforce a safety floor around it - wallet verification, the debit gate, a capacity-locked filter, a service-level-honour check, a strategy chooser. Even if the model errs it cannot move outside the envelope: a bad wallet is refused, an unaffordable offer rejected, a service-level-breaking step-down blocked. Where no model is available, the rules drive every decision and the system still runs. This containment is a property the authors consider essential to deploying cognitive agents in an operational role, and it is revisited in .

Intent-Instance Life-Cycle Management

The Intent Instance as a Live Object When an intent is accepted it becomes an intent instance: not a document but a managed object with state, governed across its life. The object is negotiated, fulfilled and then continuously assured, with a closed loop choreographing the transitions. Most in-life changes modify the live service in place - the service identifier and the consumer's flow label persist while bandwidth, latency or protection adjust under traffic - and a replacement service, with a new label and a make-before-break migration, is reserved for the case where in-place modification cannot meet the new objective. names the states.

The intent instance as a managed object with state. Negotiated --> Agreed --> Provisioned --> Assured | (predicted breach / recovery) | v Restored <----- Renegotiated <-------------- (at-risk / cooling) | v Terminated ]]>

End-to-End Negotiation Flow A single intent traverses the plane as a sequence of typed, auditable transitions, each measured in seconds rather than days. The requirement agent emits an intent and the enterprise policy agent attaches the wallet. The BSS policy agent verifies the credential end-to-end before any token is spent. The BSS negotiation agent queries scarcity and capacity from the OSS and returns a scarcity-aware quote. The enterprise policy agent picks within budget, guarded by service-level and ceiling rules, and the wallet is debited against the cumulative ledger. The BSS negotiation agent signs an agreement and the tag returns to the consumer; an order is issued, the OSS provisions the service, inventory is recorded, and the service is live. The same sequence, run in reverse from an assurance signal, is what drives renegotiation.

Scarcity-Driven Pricing Consumers neither see nor control allocation; resource use is rationed economically, through price . Telemetry becomes a forecast, the forecast maps to a scarcity band, and the band sets the surge baked into the quote - per parameter and per path. A path that is lightly used carries the baseline price; as utilisation rises a modest, then a steep, surge is applied; and a grade whose resource is effectively exhausted is withdrawn until it clears. Because a service is a tuple of bandwidth, latency and availability grades, scarcity bites unevenly across the three axes: a region of the network can have ample raw bandwidth yet be tight specifically on its lowest-latency routes, so the latency grade surges while the bandwidth grade does not. A consumer whose flow can tolerate a longer path avoids the surge by taking one, which in turn relieves contention on the scarce routes for everyone. The accepted and refused price points become an empirical record of the consumer's price sensitivity - itself one of the categories of economic information the NaaS framework expects a provider to synthesise .

Closed-Loop Renegotiation The element the authors consider the operator-grade differentiator is renegotiation of a live, signed agreement in both directions. The assurance agent flags an at-risk agreement from telemetry and forecast. The negotiation agent chooses a strategy by workload class - step up for a service-level-sensitive class, step down for a cost-sensitive one - and computes a counter-offer. The consumer's policy agent clears the wallet and a service-level-honour check, after which the model accepts or rejects; no human is involved. The change is then applied: the live service is modified in place where it can be, or migrated make-before-break where it cannot, with traffic flowing throughout. When the scarcity clears, a post-recovery offer walks the grades back to the cost-optimal point. A single-flight gate prevents flutter-driven duplicate offers, and each reissued agreement carries a linked identifier so that the audit trail joins it to its original. This is what turns a static service-level agreement into a two-directional negotiation: the same external event that makes the consumer want more network also tends to make that network scarcer and dearer, so each side's position moves at once, and it moves through price.

Standards Foundations and Mapping The claim that runs through this document is that the architecture is a composition of existing standards into a cross-boundary procedure that each of them, individually, stops at the edge of; no new protocol is invented. This section makes the claim concrete, because it shows that the gap of can be closed by arranging published work rather than by chartering new work. The management framework is anchored by the Zero-touch network and Service Management (ZSM) body of work. The ZSM reference architecture supplies the management domains and the end-to-end service management domain that define the boundaries the agents negotiate across. Intent-driven closed loops supply intent negotiation as a structured procedure - proposal, feasibility, counter-offer, acceptance - and the in-life assurance arc realised as renegotiation here. The NaaS framework supplies identity, variable abstraction and the economic-information model on which scarcity-aware pricing rests; its three pillars - identity management, variable abstraction and economic information - map directly onto, respectively, the wallet holder identity and per-flow label, the intent that hides resources, and the telemetry-to-forecast-to-band pricing loop. The network digital twin provides a prospective-actuation substrate against which a candidate in-life change may be validated before commitment. The intent body itself reuses established information models . The commercial seam - quote, agreement, order and inventory - reuses a published catalog of open APIs , and the closed-loop choreography reuses a published management API . The provisioning seam reuses transport and slicing models from the IETF and the Broadband Forum . Authorization reuses verifiable credentials , and the consumer-facing API profile reuses an open network API . The agent and tool wires reuse emerging ecosystem protocols . summarises the mapping; the point of the table is not its individual rows but the absence of any row that requires a new specification. Each interface maps to a published specification.

Concern	Specification	Role in the architecture
Intent body	TMF921 + 3GPP TS 28.312	emitted by the requirement agent; carried on A2A
Intent negotiation	ETSI ZSM 011 / 016	proposal, feasibility, counter-offer, acceptance
Quote / counter-offer	TMF648	scarcity-aware pricing output; renegotiation body
Agreement (signed)	TMF651	signed by BSS; tracked by OSS assurance
Order activation	TMF622	BSS to OSS negotiation
Service inventory	TMF638	OSS planning output records
Closed-loop choreography	TMF753A	breach to counter to change to recovery
NaaS economic model	ETSI GR ZSM 019	scarcity bands; per-consumer pricing
Management framework	ETSI ZSM 002 / 011 / 016	domains, intent, closed loops
Prospective actuation	NMRG network digital twin	validate candidate change before commit
Slicing / transport	IETF ACTN / L3SM; BBF TR-451	provisioning shapes across segments
Authorization	W3C VC; CAMARA QoD	intent wallet; consumer-facing API
Agent / tool wire	TMF A2A; LF A2A; MCP	all inter-agent and agent-tool calls

Two observations about the table are worth drawing out for a research audience. First, the entries span several organisations - ETSI, TM Forum, 3GPP, the IETF, the Broadband Forum, the W3C, CAMARA and the Linux Foundation - which is itself the difficulty: each settles its own side of the boundary and none owns the crossing. Second, the newest entries - intent wallets expressed as verifiable credentials, and agent-to-agent and agent-to-tool protocols - are ecosystem concepts still stabilising at the time of writing. The architecture treats them as load-bearing, which means the direction's maturity is bounded by theirs; this is named as a research consideration in rather than hidden.

Illustrative Use Cases Two NaaS settings illustrate where the architecture of is useful. Neither is presented as a worked engineering case; each is a sketch of how the negotiation would be used, offered to show utility rather than to specify an implementation.

Service Switching Across IP and Optical Networks An operator runs two coexisting networks - a best-effort IP network and a deterministic fine-grain optical transport network. A consumer's demand can be served by either, and the agents negotiate which one carries it, switching the live service between them as scarcity, price and service-level risk evolve. A workload burst triggers an intent for premium transport; the operator quotes both tiers with live scarcity surge applied. Under congestion the deterministic tier surges beyond the consumer's wallet. Rather than fail, the agents reach an autonomous compromise: the workload runs on best-effort IP first, and upgrades to the deterministic optical service once the forecast says the surge has cleared. The switch is made make-before-break, with an overlap window, and the agreement and audit trail follow the service across the network-type boundary. The utility on display is that a demand which could not be satisfied at the requested grade and price is nonetheless satisfied - degraded gracefully and then restored - without a human in the loop.

Dynamic Performance-on-Demand for Financial Trading A financial-services firm, Enterprise X, runs trading flows that cross equity, currency and commodity exchanges, system to system. Operator Y runs an end-to-end deterministic optical mesh with a point of presence near every exchange and carves deterministic services - each a tuple of bandwidth, latency and availability grades - bound to individual flows. Because trading conditions change continuously, so do the service levels each flow needs; the relationship between X and Y is a standing negotiation between agents. Five flow classes carry the setting - market-data, order-execution (the money path), inter-site risk replication, block synchronisation and bulk transfer - each with a distinct service-level shape. Scarcity arises in two different places: the firm's own private access spur, which only its traffic contends for and which it resolves by re-prioritising its own flows; and everything inside the operator's shared mesh, where scarcity reflects the aggregate demand of all the operator's customers and the firm can respond only through price. Latency, on a mesh, is an economic choice among paths: the shortest route is the scarcest, so pricing latency steers tolerant flows onto longer paths, spreading load and lowering prices for all. Three short episodes show the negotiation at work. A volatile equity open surges market-data and turns order-execution latency-critical; because the bottleneck is the firm's own private spur, the firm resolves it itself - paying up for the money path under a wallet ceiling it has raised for the day, and dropping a running bulk backup to its lowest grades to free headroom. An energy and metals shock drives a computation across two sites over the operator's shared core, producing one event and two opposite negotiations: the service-level-critical risk-replication flow holds the scarce shortest route and pays, while the latency-tolerant block-synchronisation flow accepts a longer path at a cheaper grade in a quieter window. An unrelated tenant then congests a core path carrying the firm's remote order-execution, and the operator's forecast predicts a breach; the contract is renegotiated in flight - rerouted onto a diverse path and stepped up to hold the latency ceiling, then stepped back down once congestion clears - modified in place while traffic flows. Across the three, the utility is the same: a relationship that behaves like a market nested inside the financial markets that drive it, in which demand is endogenous, scarcity is rationed by price, different flows negotiate differently, and the agreement renegotiates itself.

Relationship to NMRG Work and Open Research Questions The direction described here sits squarely within the research group's stated priorities of self-managing networks, intent-based networking, and the coupling of artificial intelligence with network management. It builds directly on the group's concepts of intent , on autonomic and closed-loop foundations , and on the network digital twin as a substrate for validating changes before commitment . It is also a concrete instance of several of the challenges catalogued in the group's work on coupling AI with network management - among them the need to bound model behaviour, to keep decisions auditable, and to retain a deterministic fallback. What the present document adds is a specific setting - the customer-operator NaaS boundary - in which intent-based networking, closed-loop assurance and agentic AI are not three separate topics but three aspects of a single negotiation. The direction raises research questions the authors believe are worth the group's attention:

• How should a consumer's willingness to pay be expressed, signed and bounded so that an agent may commit on its behalf without a human in the loop, and how should such an authorization compose when demand is aggregated through several NaaS operators in series?
• What guarantees can be made about a negotiation in which a language model supplies judgement, and what is the right division of labour between model and deterministic rule so that the system is safe when the model errs and still runs when no model is present?
• How should scarcity-based pricing be designed so that it is incentive-compatible - steering tolerant demand off scarce resources - without exposing allocation, and how is the resulting price-sensitivity record governed as data?
• How can the auditability and replayability that follow from an event-sourced negotiation be turned into operator-grade assurance that a contested in-life change was correct?
• How stable is a composition that depends on still-emerging ecosystem protocols for its agent and authorization wires, and what is the migration path as those protocols mature?

Considerations for Implementation Several considerations should inform any implementation. The negotiation plane SHOULD remain additive, wrapping existing orchestration through typed tools rather than taking a hard runtime dependency that would couple the production path to model-driven decisions; correspondingly, every state-changing action SHOULD flow through a typed tool call rather than through model output, so that what an agent can do is bounded by construction. An authorization that commits spend MUST be verifiable end-to-end before any quoting effort is expended on it, and debits MUST be gated against a ledger that survives re-issue, so that a replayed or reissued agreement cannot double-spend. In-life change SHOULD prefer in-place modification - with replacement and make-before-break migration reserved for cases where in-place change cannot meet the new objective, and the consumer's operational identity persisting across it - and renegotiation SHOULD be protected against oscillation, for example by a single-flight gate and a cooling-down period, with each reissued agreement carrying a linked identifier to its original. Finally, the system SHOULD retain a deterministic fallback that drives every decision when no model is available, so that availability of the negotiation does not depend on availability of a model.

Security Considerations The architecture introduces security considerations beyond those of conventional model-driven ordering. Authorization is the central one. Because a consumer's willingness to pay is expressed as a signed wallet that an agent may spend without a human in the loop, the wallet MUST be verified end-to-end - signature against the issuer identity, expiry, revocation, holder match and policy fit - before any quoting effort is spent, and every debit MUST be gated against a cumulative ledger so that a replayed, reissued or forked agreement cannot exceed the signed envelope. Compromise of a wallet issuing key, or of the ledger, is a high-value target and SHOULD be treated accordingly. The agents are built around language models and inherit the general risks of such systems, including prompt injection, hallucination and miscalibrated confidence. The architecture's principal mitigation is containment: the model supplies judgement, but every state-changing action flows through a typed tool guarded by deterministic checks, so that a model error cannot move the system outside its envelope. Implementations MUST NOT allow model output to effect a state change directly, SHOULD require human review for decisions whose consequences are operationally significant, and SHOULD retain the deterministic fallback described in . Because the negotiation is event-sourced, every state transition is an auditable, replayable record; this is a security asset, but the event fabric and audit store thereby become sensitive and MUST be protected against tampering and unauthorised disclosure. Finally, the demand-presentation and price-sensitivity data synthesised during negotiation is commercially sensitive and is attributable to a consumer through its operational identity labels; policy controls MUST govern what may be disclosed, to whom and under what conditions, and per-consumer identity SHOULD use generic operational labels rather than exposing the consumer directly.

IANA Considerations This document has no IANA actions.

Normative References Informative References Work in Progress Work in Progress ETSI ISG ZSM ETSI GS ZSM 002 ETSI ISG ZSM ETSI GS ZSM 011 ETSI ISG ZSM ETSI GS ZSM 016 ETSI ISG ZSM ETSI GR ZSM 019 V1.1.1 3GPP 3GPP TS 28.312 TM Forum TM Forum TMF921 TM Forum TM Forum TMF648 TM Forum TM Forum TMF651 TM Forum TM Forum TMF622 TM Forum TM Forum TMF638 TM Forum TM Forum TMF753A TM Forum TM Forum, work in progress Linux Foundation Anthropic W3C W3C Recommendation CAMARA Project (Linux Foundation) Broadband Forum Broadband Forum TR-451

Acknowledgments The authors thank colleagues for discussions that shaped the ideas in this document, and members of the NMRG and the NMOP working group for ongoing exchanges on the role of agentic AI in network and service management.