Sources of Inter-Agent Conflicts and Approaches to Conflict Resolution in Network Management

Internet-Draft	Inter-Agent Conflict and Resolution	June 2026
Janz, et al.	Expires 12 December 2026	[Page]

Abstract

Network management is increasingly carried out by autonomous, AI-driven agents that observe and act on the network and service state they share. Where their scopes overlap - the same managed entities, resources, or objectives - their independent decisions can prove mutually inconsistent, and such inter-agent conflict is, at bottom, coordination that has not been put in place; the two are best studied together. This document maps the problem for network management: where inter-agent conflict comes from, which families of mechanism resolve it, and how those mechanisms are chosen and combined. It then turns that map on a case of current interest in the IETF - the AI-based Network Management Agent (NMA) architecture - and offers six recommendations for strengthening how that architecture handles inter-agent conflict at its Agent-to-Agent interface.¶

1. Introduction

Software agents have spread across every layer of network management. They sit at the cross-domain service tier, within individual management domains, next to Software-Defined Networking (SDN) controllers, and inside the observe-analyse-decide-act loops that drive managed entities, and they take on assurance, optimisation, configuration, anomaly response, capacity, and lifecycle work. No two are alike: they differ in how much they reason, in how much they are permitted to change, in the objectives they serve, and in the resources they touch. What makes them a system rather than a collection is that their reach overlaps - in what they watch, what they control, and what they would alter - and it is in that overlap that conflict arises and coordination becomes necessary.¶

Conflict and coordination, in this setting, are two descriptions of one thing: a conflict left standing between agents is just a coordination gap that nothing in the architecture closes, so providing the coordination a system needs and heading off the conflicts it would otherwise meet are a single task. That task resolves into three questions - what coordination to install, at which point in the architecture, and how the added machinery should interlock with whatever is already running. Behind all of them lies one larger question: whether agents, growing in number, in capability, and in the scope they are licensed to act on, will go on coordinating at all.¶

This agent-against-agent dimension is, in the authors' view, the part most out of step with where the field is going. Most attention today falls elsewhere - on giving a single agent more capability, and on the one interface where an agent hands work to the authoritative system that carries it out. How agents get along with each other, across the inter-agent interfaces that autonomous-network architectures are only now defining, is comparatively neglected, and the neglect grows more costly as autonomy rises, because added independence multiplies the ways agents can work at cross purposes. This document takes up that neglected dimension for network management: where inter-agent conflict originates (Section 3), the mechanism families that address it (Section 4), and how those are chosen and combined (Section 5). A substantial further aim, developed in the second half, is to bring the framework to bear on the AI-based Network Management Agent (NMA) under development in the IETF (Section 6), ending with six concrete recommendations to that effort (Section 7).¶

The survey is deliberately not exhaustive on any one technique; the goal is a map. Two bodies of work recur as illustrations. ETSI's Industry Specification Group on Zero-touch network and Service Management (ZSM) has produced the most developed treatment of agent conflict and coordination of any standards body, and its Management Domain construct [ETSI-ZSM-002] furnishes the architectural unit the later discussion rests on. Lovén et al. [LOVEN2026] offer the sharpest current treatment of price-based coordination for agentic computing of the kind adjacent to network management. And a recent ETSI study on agents in autonomous networks [ETSI-ZSM-020] speaks directly to the case examined here, placing the network-management agent inside the Management Domain - the very position this document urges on the IETF work. This document does not update or obsolete any existing RFC.¶

None of this is new to telecommunications, and the framing here extends prior work rather than displacing it. Coordinating self-organising functions that contend over shared radio parameters has been standardised since 3GPP Release 10, and a broad research literature classifies the resulting conflicts and the protective, reactive, and proactive remedies for them [SON]; the same concern reappears today as the mitigation of clashes among the xApps and rApps hosted on the O-RAN near-real-time RIC [ORAN-RIC]. Resolving policy conflicts by precedence was studied in distributed-systems management long before [LUPU], and the question has resurfaced for AI-assisted control loops in early 6G work [PARSAEEFARD]. The contribution here is to draw these strands into one frame - separating conflicts visible on inspection from those that emerge only in joint fulfilment, using encapsulation to connect work in markets, control, and learning, and marking the single-epoch / repeated-operation divide as the place the hard problems concentrate.¶

3. Sources of Inter-Agent Conflict

Network management hosts two structurally different kinds of agent, and which kind is in play determines where conflict can occur. An action-bearing agent alters network or service state; because each of its actions might clash with another agent's action, or with standing policy and configuration, its exposure is broad. An information-producing agent only senses, analyses, and reports, touching no managed entity directly, so it enters conflict only at one remove - through the action-bearing agents it informs. The upshot is that exposure to conflict is created by acting, not by reasoning, and the taxonomy that follows is anchored at the action layer. Disagreements over state - two agents holding incompatible pictures of the network - obey the same logic: they signify only insofar as they push agents toward divergent actions, and are otherwise the job of the state-synchronisation layer beneath the action layer. That layer, not the mechanisms catalogued here, is where the inconsistent-state case raised by the NMA draft [I-D.zhao-nmop-network-management-agent] belongs (see Section 6.1).¶

When action-bearing agents act independently, two or more can land on actions that cannot all be true together: inconsistent logically (contradictory demands on one target), structurally (not jointly executable on one entity at one time), consequentially (their downstream effects interfere), or compositionally (an action runs against a policy or configuration set outside the agent layer). The five types below organise these.¶

Hard contradictions:: two demands that cannot both be honoured - no assignment of resources, no plan, and no order of execution will satisfy them together. The stock example from intent-driven networking [ETSI-ZSM-011] pits one intent's cell-throughput ceiling below 5 Mbps against another's floor above 8 Mbps on that same cell. Such conflicts usually show under inspection - intent translation tends to expose them - and are settled by refusing the request, returning it to the intent owner, or applying a priority rule.¶
Soft contradictions:: demands that pull against one another without being flatly irreconcilable, and the kind of conflict most common in operation. ETSI GS ZSM 016 [ETSI-ZSM-016] sets a floor on bandwidth against a ceiling on cost: more capacity usually costs more, yet for any specific pair of thresholds it is generally unknowable in advance whether both can hold. The remedy is one of degree - balancing utilities, negotiating, pricing - rather than refusal. Two sub-cases recur: contention for a bounded resource (link bandwidth, compute, inference slots) and trade-offs between competing objectives (latency against throughput, energy against coverage, cost against reliability).¶
Action and ordering conflicts:: two agents would act on one entity such that the outcome turns on whether one goes first, second, or at the same time - network management's version of database serialisability. ETSI GS ZSM 009-1 [ETSI-ZSM-009-1] handles it as concurrency coordination, and the cure is to sequence or serialise the accesses, with closed-loop priority or policy deciding the order.¶
Impact-level conflicts:: two actions run at once on different entities, yet one's downstream effect cancels or erodes the other's aim - the textbook pairing [ETSI-ZSM-011] being a coverage-improving antenna tilt undone by a power-saving feature. This is the most difficult class, since the clash happens in the running system rather than in any specification. Catching it needs either a prospective tool - virtual actuation on a Network Digital Twin [ETSI-ZSM-018] - or a retrospective one, post-execution impact assessment [ETSI-ZSM-009-1].¶
Intent-versus-non-intent conflicts:: an intent-driven action meets a constraint that was never expressed as an intent at all - a lower-layer policy, a manually applied configuration, a built-in rule [ETSI-ZSM-011] - and, unlike the intent-versus-intent case, there is no counterpart to bargain with; the constraint simply is. The NMA draft [I-D.zhao-nmop-network-management-agent] records essentially this, as a clash between an NMA's dynamically generated policy and a controller's standing one. The way out is to raise the non-intent constraint to intent level - turning the clash into intent-versus-intent - or to apply precedence.¶

A further split runs through every one of the five and, for the choice of mechanism, tends to matter more than which type a conflict is: does it show itself when one inspects specifications, intents, and plans, or only when the system attempts to meet all the operative intents together? As the intent-driven closed-loop work notes [ETSI-ZSM-016], a conflict's reality and its severity frequently surface only while a joint fulfilment is being sought. The soft and impact-level kinds fall disproportionately on this emergent side; an effective intent - one thrown up by several explicit intents working together - can likewise appear only there, betrayed by its own non-fulfilment. The design consequence is sharp: the inspectable kind yields to pre-commitment checkers, whereas the emergent kind demands exploratory search before commitment plus assessment afterwards, so an architecture built only for the first is weakest exactly where it can least afford to be.¶

4. Approaches to Conflict Resolution: Coordination Mechanism Families

The catalogue below is ordered by how much central control each exerts, the most directive first and the lightest peer- and price-based schemes last; these are the options an agent-coordination architecture can draw on. None stands alone in practice, and how they combine is the subject of Section 5.¶

Imperative arbitration:: a coordinator settles the matter outright - by priority, override, resource partitioning, or serialised access. ETSI GS ZSM 009-1 [ETSI-ZSM-009-1] provides exactly such levers in its closed-loop priority attribute, action enable/disable, and concurrency coordination. The approach is dependable and transparent but does not scale to many agents with conflicting preferences, and it fits inspectable conflicts for which a defensible priority or partition is available.¶
Utility reconciliation:: a utility is attached to each intent, and a handler chooses the joint action that maximises some aggregate of them - commonly a weighted sum, as in ETSI GS ZSM 016 [ETSI-ZSM-016]. It fits conflicts of degree; its hard parts are putting utilities on one scale and an aggregation rule that silently bakes in operational choices.¶
Markets and micro-economic mechanisms:: prices do the coordinating - bids go in, a clearing step returns allocations. ETSI GR ZSM 019 [ETSI-ZSM-019] already frames resource allocation among Network-as-a-Service consumers as something to be run economically via service pricing. When decentralised markets can be relied on is the subject of Lovén et al. [LOVEN2026], summarised in Section 4.1. The family fits resource contention among many agents holding private valuations with no single trusted authority; it serves badly where the dispute is over ends, not resources.¶
Negotiation:: agents trade offers and concessions toward an outcome all can accept, requiring no shared currency and tolerating reservation values kept private; formalised by the FIPA Agent Communication Language [FIPA] and the Contract Net Protocol. Both ETSI GR ZSM 011 [ETSI-ZSM-011] and ETSI GR ZSM 019 [ETSI-ZSM-019] already rely on it.¶
Argumentation:: every agent argues for and against the options on the table, and which argument defeats which is modelled explicitly [DUNG]. This is the family to reach for when the reasoning has to stand up - when a decision must be explained and defended, not merely shown optimal - and for norm clashes that have no shared utility scale.¶
Distributed constraint optimization (DCOP):: the conflict is written as weighted constraints over variables owned by different agents, and a least-cost joint assignment is computed [DCOP]. It fits any conflict that can be cast as constraints across a countable agent set; what ETSI GS ZSM 009-1 [ETSI-ZSM-009-1] does at its action-plan-selection step is, in effect, a small DCOP.¶
Normative regulation:: rules - permissions, prohibitions, obligations - forestall conflict by bounding what agents may do, and are already everywhere in ZSM as governance state, trust scores, and capability profiles. Since no rule set foresees every situation, this family nearly always runs alongside others.¶
Social choice and voting:: preferences of symmetric peers are aggregated by a voting rule; in network management this tends to be a building block (consensus among redundant analytics agents, say) rather than the main mechanism.¶
Multi-agent reinforcement learning (MARL):: coordination is learned from experience instead of prescribed by a protocol - adaptable when the shape of the conflict cannot be known in advance, but offering weak guarantees, so under firm service-level agreements it serves better as an adjunct than as the principal layer.¶
Digital-twin-based exploration:: candidate joint actions are rehearsed on a digital twin and only the ones that come through are committed. ETSI GS ZSM 016 [ETSI-ZSM-016] spells this out through the Network Digital Twin of ETSI GS ZSM 018 [ETSI-ZSM-018] and the virtual-actuation loop of ETSI GR ZSM 009-3 [ETSI-ZSM-009-3]. It is the natural answer to impact-level and emergent conflicts, provided it fits the operational latency budget. The twin serves twice over: as a gate that admits or rejects candidates before commitment, and as ground on which the other families rank the survivors - utility reconciliation scoring them against intent utilities read off the twin, or DCOP solved against twin-derived costs. How far a twin can be trusted - whether to use it only to rank and reject candidates, or to rely on it for stronger assurances - depends on the fidelity of the particular implementation, which varies and has to be established case by case.¶

4.1. When Decentralised Markets Can Be Trusted

Whether the market family can be relied on turns on a structural property that is simple to state. Lovén et al. [LOVEN2026] identify the decisive factor as how entangled the dependencies among services are. Where those dependencies stay simple - broadly, tree-shaped, free of cross-cutting ties between stages of a service chain - a decentralised market provably matches what a fully-informed central planner would choose, and nobody profits by misstating what they value. Where they grow entangled, the guarantees collapse: prices may fail to settle, the optimal allocation becomes computationally hard, and no plain two-sided market can be efficient, fair, and self-financing all at once. The takeaway is that it is the shape of the composition, not algorithmic ingenuity, that decides whether a decentralised market holds up - and an awkward shape can frequently be domesticated by hiding the hard part behind a cleaner interface (Section 5.1). Because this work is a preprint still under review, its results warrant reliance only as far as the preprint itself proves them; and they are single-epoch, so the cross-epoch manipulation noted in Section 5 falls outside their reach.¶

5. Selecting and Composing Mechanisms

Which families fit is largely fixed by the conflict type, and the place the decision is taken is fixed by where, relative to a Management Domain (MD), the relevant information sits - inside one domain's own machinery (intra-MD), across domains via the A2A interface or a cross-domain integrator (inter-MD), or at the end-to-end (E2E) service layer. Table 1 sets out both; in practice a deployment will draw on several of its rows, at several loci, at once.¶

Table 1: Conflict type, the families that suit it, and where the decision is taken.
Conflict type	Well-suited families	Where decided
Hard contradictions	Imperative arbitration; refusal and re-negotiation; precedence	Intra-MD at earliest check; inter-MD via A2A across MDs
Soft - objective trade-offs	Utility reconciliation; negotiation; argumentation	Intra-MD; inter-MD via A2A; E2E for cross-service
Soft - resource contention	Markets; partitioning; priority queues; DCOP	Intra-MD resource layer; inter-MD at integrator
Action and ordering	Pre-execution detection; concurrency coordination; priority; DCOP	Intra-MD on owned entities; inter-MD via A2A on shared entities
Impact-level	Digital-twin exploration; merged analysis-and-decision; post-hoc impact assessment	Intra-MD NDT; cross-MD twin at E2E
Intent versus non-intent	Normative regulation; argumentation; lifting into intent; precedence	Intra-MD intent/policy layer; supra-MD governance

5.1. Encapsulation as the Load-Bearing Pattern

A deeper recent finding is that some structural complexity simply resists any clean, fully distributed handling; the response is not to centralise everything, nor to decentralise harder, but to encapsulate - seal the hard sub-problem inside a boundary whose outward face is simple, run it centrally within, and let the world outside coordinate lightly. The move shows up in three literatures. Lovén et al.'s cross-domain integrators [LOVEN2026] take an entangled sub-composition and offer the market just one composite slice in its place - a slice that stays well-behaved outwardly only under stated conditions, something the integrator is built to secure rather than something it gets for free. The nested closed loops of ETSI GR ZSM 009-3 [ETSI-ZSM-009-3] make a set of interdependent loops look, from outside, like one loop. And cooperative MARL's centralised-training/decentralised-execution is the same trick expressed in rewards. The corollary: for some structural complexity there is no middle road - the realistic choice is encapsulation under central control, or breakdown.¶

5.2. Compose Rather Than Choose

In practice no architecture leans on a single family, and that fact deserves to be the stated default. Our suggested default is built from three legs. The first is a normative envelope - permissions, prohibitions, priorities, partitions, in today's agentic vocabulary a guardrail layer - that fences off the admissible actions, so anything unsafe, non-compliant, or beyond an agent's remit never reaches the table as a candidate; coordination, seen this way, is as much prevention as cure. The second is one or more decision mechanisms working inside that fence, chosen by conflict type per Table 1. The third tries candidates out on a digital twin ahead of committing, and stands a diagnostic leg behind that for whatever still slips through - in the near term, a fall back to a last-known-good configuration and a page to an operator. The legs back one another up: a decision mechanism without exploration is fragile against emergent conflict, exploration without a fence is unbounded, and a diagnostic leg pressed into front-line service is an expensive net (Figure 1). ETSI GS ZSM 016 [ETSI-ZSM-016] (partitioning, utility reconciliation, twin exploration), ETSI GR ZSM 019 [ETSI-ZSM-019] (governance overlay, pricing, negotiation), and Lovén et al. [LOVEN2026] (governance, slice market, integrator) each instantiate it; only the middle leg changes.¶

   candidate actions from agents
                |
                v
   +-------------------------------------------------+
   | 1. Normative envelope (guardrail layer):        |
   |    permissions, prohibitions, priorities,       |
   |    partitions - bounds the admissible actions   |
   +-------------------------------------------------+
                |
                v
   +-------------------------------------------------+
   | 2. Decision mechanism(s), chosen by conflict    |
   |    type: utility, market, negotiation, DCOP,    |
   |    argumentation, or imperative arbitration     |
   +-------------------------------------------------+
                |
                v
   +-------------------------------------------------+
   | 3a. Exploratory leg (before commit): digital-   |
   |     twin actuation; vet and rank candidates     |
   +-------------------------------------------------+
                |
                v   committed action
   +-------------------------------------------------+
   | 3b. Diagnostic leg (after commit): impact       |
   |     assessment; rollback + operator escalation  |
   +-------------------------------------------------+

Figure 1: The recommended three-leg default. A normative envelope fences the action space; mechanisms selected per conflict type run within it; an exploratory leg screens candidates before commitment, and a diagnostic leg handles what only appears afterwards.

Two further points round out the picture. First, a mechanism built on the premise that every conflict can be foreseen will fail precisely on the emergent ones that dominate live operation; the exploratory and diagnostic legs, then, are not optional trimmings but the parts that carry the usual case. Second, since the cost of coordinating is largely the cost of shipping information between agents, coordination should sit where that information already is: centralise locally within a domain or trust boundary, and use lighter machinery between boundaries. Hard questions stay open - designing mechanisms for the emergent case, keeping incentives sound once decisions repeat across epochs, conflicts among the composed mechanisms themselves, and re-composition as the agent population shifts. On the cross-epoch front there is progress: [LOVEN-TRILEMMA] shows that when agents persist and learn, single-epoch guarantees stop bounding behaviour and even the marketplace operator turns strategic, with a flat lesson - watching for cheating does not discourage it, and only structural remedies (binding commitment, administrative separation, competition among providers) take the incentive away. Treat single-epoch guarantees as though they extended to non-stop operation, and the problem has been mis-framed from the outset.¶

5.3. A Worked Example

A single end-to-end scenario shows the map at work and leads into the agent-and-domain discussion of Section 6. Take a live ultra-reliable, low-latency slice whose capacity is being raised. Four closed-loop management functions act: one drives the slice modification; a transport-side function recomputes paths and queue weights, converging over seconds to minutes; a radio-side function retunes the slice's resource-block share within a fraction of a second; and admission control goes on admitting sessions, now to the larger quota. Individually all four are correct; the trouble is the spread of their timescales. Anticipating the change, the radio loop has already pared back a neighbouring donor slice's resource-block allotment; the transport loop's revised queue weights have not yet taken effect; and admission is already letting sessions in at the new, higher quota. Across the convergence window the donor slice drops below its latency target and its edge users come up short on throughput. Under the taxonomy of Section 3 the clash is impact-level, and it sits well toward the emergent end: inspected request by request nothing trips an alarm, because what collides is the timing interplay of three loops, not anything in a single specification.¶

The prescription follows from Table 1 and Section 5.2. A normative envelope - latency floors and resource-block ceilings, one set per slice - bounds the proposals any loop can make; a utility step, weighted by each slice's revenue and exposure to penalties, settles on one plan covering both the modification and the admissions; a digital-twin leg trials each candidate and drops the dangerous ones; and a diagnostic leg, falling back to a known-good configuration and paging an operator, mops up what the twin gets wrong. No one family does the whole job. And in NMA terms the place this conflict is settled - within one Management Domain or out across the Agent-to-Agent interface - depends on whether these functions live as co-located services or as separate agents in different domains, which is precisely the partitioning question the next section opens.¶

6. Application to the Proposed IETF Network Management Agent Architecture

The framework above applies directly to a timely case. The IETF Network Management Operations (NMOP) working group is developing [I-D.zhao-nmop-network-management-agent], which defines an AI-based Network Management Agent for Level 4 (L4) autonomous-network operations: internally the four-stage observe-analyse-decide-act loop made AI-explicit (perception, reasoning, planning, and action modules with knowledge and memory), with an Agent-to-Agent (A2A) interface by which NMAs interact with one another and with non-AI components. Alongside the ZSM corpus the NMA overlaps the role of the ZSM closed loop; the vocabularies differ but the concerns are largely the same. The discussion here is constructive: the draft's direction is sound, and the aim is to deepen its treatment of agent coordination to match the autonomy ambitions of L4.¶

The draft's repeated invocation of "SDN controller" is best read, more durably, as standing in for the entity the NMA hands intent or policy to - the thing that holds authoritative network state, maps requests onto resources, and has its own pre-configured policies. In a forward-looking architecture that entity is a ZSM Management Domain (MD) [ETSI-ZSM-002]: a per-technology or per-administrative domain MD where the NMA acts at domain scope, or the E2ES MD where it acts on services spanning domains. The stand-alone SDN controller of the 2010s is either a legacy artifact within such an MD or a transitional shorthand for one. The substitution sharpens the analysis and propagates cleanly to alignment with the ZSM corpus, which already speaks the MD language; "MD" is used below where the draft would say "SDN controller".¶

6.1. The Conflict Surface at A2A

The draft acknowledges two conflict types, both NMA-versus-MD cases under the reading above: configuration-and-policy conflicts (the NMA's intent-derived dynamic policy collides with the MD's pre-configured policy) and inconsistent network-state synchronisation (the NMA's internal model and the MD's authoritative view drift apart). Both are real. But the MD's side is not a passive component to be overridden; it is itself a composition of internal decision logic - closed loops, intent translation, resource management, policy enforcement - each a decision locus with its own conflict-handling responsibilities, so the NMA-versus-MD surface composes against the MD's whole apparatus.¶

More conspicuously, the NMA-versus-NMA case - two action-bearing agents conflicting at A2A - is essentially absent, even though A2A is defined precisely as the locus where multiple NMAs interact. An architecture that defines an inter-agent interface without defining how conflict there is detected and resolved has left the interesting work undone. Under L4 autonomy with multiple NMAs (per-tenant, per-service, per-region, or per-layer), every conflict type of Section 3 becomes available at A2A. L4 autonomy widens this surface rather than narrowing it: more independent decision authority means more candidate collisions and less scope for human intervention to catch what the architecture missed. A2A needs to be the locus where this surface is detected, characterised, and resolved - not merely an interface for state exchange - and it must compose with the conflict-handling the MD already performs per ETSI GS ZSM 009-1 [ETSI-ZSM-009-1], ETSI GR ZSM 011 [ETSI-ZSM-011], and ETSI GS ZSM 016 [ETSI-ZSM-016].¶

6.2. Where Conflict Has to Be Resolved: at Analysis and at the Decisions

Every state-changing action is the output of a decide step somewhere, and in any real architecture that step is plural: an MD composes several internal decision loci, and an NMA contributes one or more inside or outside it. Handling conflict only at those decide loci is too narrow, though. The analyse stage of the loop can head it off earlier: an agent that already knows of other live intents, policies, or proposed plans will analyse differently - it may form a different plan, reassess an expected impact, or set aside a class of action that, considered on its own, looked best. What the analyse stage does not catch falls to three later modes: before any decide locus (pre-execution detection of inspection-detectable cases), jointly inside a decide locus (utility aggregation, market clearing, DCOP, or negotiation, where soft contradictions are usually resolved), and after all of them (post-hoc impact assessment and remediation per ETSI GS ZSM 009-1 [ETSI-ZSM-009-1]); earlier is cheaper. Some conflicts - notably resource contention - are visible only at the locus that sees the resource layer, typically inside the MD, so their surfacing there is by design, not a failure of the NMA-level decision. The architectural question is therefore not where "the" decide step lives but how authority is distributed across NMAs and MDs, what each locus can see, and how conflict feeds back between them.¶

6.3. NMA / Management-Domain Partitioning Models

Five models describe how an NMA can compose with an MD. Real deployments mix them, but the pure models clarify the choices, and Model C is the cleanest, most ZSM-aligned positioning - and the one ETSI's own study on agents in autonomous networks [ETSI-ZSM-020] has already adopted, placing the NMA inside the Management Domain.¶

A - NMA-above-MD:: the NMA is the cognitive layer, handing requests down to an MD whose internal logic remains first-class. Conflicts arise both at A2A above the MD and at the NMA-MD boundary, so coordination needs a feedback path, not just a command path.¶
B - NMA-and-MD as peers:: both independently change the same entities. This is the draft's implicit default. It is usually transitional, an artifact of imperfect separation, and most deployments should refactor toward C or A.¶
C - NMA-inside-MD (recommended default; the ZSM 020 positioning):: the NMA is a management service within an MD, alongside closed loops, intent reasoners, and resource managers. The MD remains the unit of authority; conflict resolution is internal and uses the machinery ETSI GS ZSM 009-1, ETSI GR ZSM 011, and ETSI GS ZSM 016 already specify. This is the positioning ETSI has adopted for the ZSM corpus: ETSI GR ZSM 020 [ETSI-ZSM-020] places the NMA inside the Management Domain. Most of the surface the draft names dissolves; what A2A genuinely needs to support is NMAs in different MDs or at the E2E layer.¶
D - Federated NMAs across MDs:: NMAs at one level coordinate across several MDs - the natural case for cross-domain integrators or per-tenant, per-service, or per-region NMAs. Markets and inter-domain negotiation live here.¶
E - Layered NMAs across strata:: an E2E-layer NMA above per-domain MDs, with vertical A2A, mapping onto ZSM's E2E service MD above per-technology MDs. Conflict flows both up and down. D and E combine freely, with A, B, or C as the per-NMA choice within them.¶

Mechanism families map onto these models predictably. Imperative arbitration and normative regulation are native to the MD, where authoritative policy lives. Markets need peer entities with private valuations and a resource layer to clear against, so Model D is their home and the ETSI GR ZSM 019 [ETSI-ZSM-019] NaaS picture lives there. The intent-reconciliation families can live intra-MD (Model C) or across A2A (Models D and E), so their protocol semantics must support both; digital-twin exploration belongs at the highest scope at which the joint action can be simulated - a domain NDT, or a cross-MD twin at the E2E layer.¶

7. Recommendations to the IETF NMA Work

Six recommendations follow, constructive in intent: the draft's direction is right, and these deepen its agent-coordination dimension to match L4.¶

R1 - Adopt an explicit conflict taxonomy at A2A:: the taxonomy of Section 3 (and ETSI GS ZSM 009-1, GR ZSM 011, GS ZSM 016) applies to both the NMA-versus-NMA and NMA-versus-MD surfaces. The draft SHOULD adopt it rather than re-derive a parallel one, naming hard contradictions, soft contradictions (with resource contention and objective trade-offs), action and ordering conflicts, impact-level conflicts, and intent-versus-non-intent collisions at both surfaces.¶
R2 - Treat A2A as the locus for detection, resolution, and feedback:: the draft SHOULD define A2A hooks for pre-execution conflict detection (exchange of intents, plans, candidate actions in a checkable form), for resolution (exchange of utilities, arguments, priced offers), and for feedback from conflicts surfaced at MD-internal loci. The feedback path MUST NOT be assumed to flow only top-down.¶
R3 - Adopt NMA-inside-MD (Model C) as the default - the ZSM-locked positioning:: Model C is the cleanest positioning, dissolves most of the surface the draft names, and aligns with existing ZSM machinery. Critically, it is also the positioning ETSI has already committed to: ETSI GR ZSM 020 [ETSI-ZSM-020] locks the NMA inside the Management Domain. Adopting Model C as the IETF default is therefore not only the cleanest choice but the one that keeps IETF NMOP and ETSI ZSM structurally aligned at the locus where AI-driven agents meet authoritative network state - a convergence the two bodies would otherwise have to engineer after the fact. The draft SHOULD adopt it as default, catalogue A, B, D, and E as alternatives, and SHOULD resist defaulting implicitly to Model B (peers), the hardest model to coordinate.¶
R4 - Layer conflict handling across MD topology:: four cases need separate treatment - intra-MD coordination among services (including the NMA in Model C), intra-MD peer A2A, inter-MD A2A, and the NMA-MD boundary (Models A and B). Each admits different families; collapsing them onto one undifferentiated A2A definition loses the distinctions.¶
R5 - Pick a small initial mechanism set, with extension hooks:: imperative arbitration, utility reconciliation, negotiation, and normative regulation are a suitable starter set covering most inspection-detectable and joint-decision cases. Markets, argumentation, DCOP, social choice, MARL, and digital-twin exploration can follow as extensions, with A2A providing explicit hooks rather than one fixed coordination model.¶
R6 - Read "SDN controller" as "ZSM Management Domain":: adopt the ETSI GS ZSM 002 [ETSI-ZSM-002] MD vocabulary, name the domain-MD-versus-E2ES-MD distinction where it matters, and frame the NMA's interaction with what it now calls an SDN controller as an NMA-versus-MD interaction. This propagates cleanly to alignment with the ZSM corpus and avoids parallel re-derivation in adjacent bodies.¶

8. Security Considerations

Inter-agent conflict handling introduces considerations beyond conventional model-driven management. Any decision that resolves a conflict by changing network or service state - an arbitration override, a market allocation, a negotiated concession, an action committed after digital-twin exploration - MUST be subject to authorisation appropriate to the agent's operational role and MUST be auditable after the fact. Where resolution depends on inputs exchanged between agents (utilities, preferences, priced offers, arguments, natural-language descriptions), an adversary able to influence those inputs could drive the outcome; implementations SHOULD attach provenance and confidence to such inputs and apply the trust and incentive mechanisms appropriate to the family in use, recognising that market incentive guarantees are per-epoch and do not preclude cross-epoch manipulation.¶

Conflict resolved only after the fact widens the window during which an incorrect or adversarially induced action affects the live network; implementations SHOULD prefer pre-commitment exploration where the latency budget allows. The A2A interface, as a new locus for exchanging intents, plans, and candidate actions, is itself an attack surface: it MUST provide authentication of the communicating agents, integrity and confidentiality of the exchange, and authorisation of the actions an exchange can trigger. Where resolution involves disclosing more granular information than usual, policy controls MUST govern what may be disclosed, to whom, and under what conditions. Finally, AI-driven agents inherit the general risks of large-language-model-based systems - prompt injection, hallucination, miscalibrated confidence - and implementations SHOULD apply the usual mitigations and require human review for resolutions whose consequences are operationally significant.¶

11. Informative References

[I-D.zhao-nmop-network-management-agent]: Zhao, C., "AI based Network Management Agent (NMA): Concepts and Architecture", Work in Progress, Internet-Draft, draft-zhao-nmop-network-management-agent, February 2026, <https://datatracker.ietf.org/doc/html/draft-zhao-nmop-network-management-agent>.
[ETSI-ZSM-002]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Reference Architecture", ETSI GS ZSM 002 V1.1.1, August 2019.
[ETSI-ZSM-009-1]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Closed-Loop Automation; Part 1: Enablers", ETSI GS ZSM 009-1 V1.1.1, June 2021.
[ETSI-ZSM-009-3]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Closed-Loop Automation; Part 3: Advanced Topics", ETSI GR ZSM 009-3 V1.1.1, 2023.
[ETSI-ZSM-011]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Intent-driven Autonomous Networks; Generic Aspects", ETSI GR ZSM 011 V2.1.1, September 2024.
[ETSI-ZSM-016]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Intent-driven Closed Loops", ETSI GS ZSM 016 V1.1.1, October 2024.
[ETSI-ZSM-018]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Network Digital Twin", ETSI GS ZSM 018, 2025.
[ETSI-ZSM-019]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); ZSM Framework for Network-as-a-Service (NaaS)", ETSI GR ZSM 019 V1.1.1, January 2026.
[ETSI-ZSM-020]: ETSI ISG ZSM, "Zero-touch network and Service Management (ZSM); Study on the Utilization of Agents in Autonomous Networks", ETSI GR ZSM 020 V1.1.1, January 2026.
[LOVEN2026]: Lovén, L., Saleh, A., Farahani, R., Murturi, I., Bordallo Lopez, M., Donta, P. K., and S. Dustdar, "Real-Time AI Service Economy: A Framework for Agentic Computing Across the Continuum", arXiv preprint arXiv:2603.05614v1, 2026 (under review, IEEE Trans. Services Computing), 2026, <https://arxiv.org/abs/2603.05614>.
[LOVEN-TRILEMMA]: Lovén, L., Gujar, S., Timperi, K., Mehmood, H., Donta, P. K., Tarkoma, S., and S. Dustdar, "Credibility Trilemma in Polymatroidal Service Markets", arXiv preprint arXiv:2605.26604, 2026, <https://arxiv.org/abs/2605.26604>.
[DUNG]: Dung, P. M., "On the acceptability of arguments and its fundamental role in nonmonotonic reasoning, logic programming and n-person games", Artificial Intelligence, Vol. 77, No. 2, pp. 321-357, 1995.
[DCOP]: Fioretto, F., Pontelli, E., and W. Yeoh, "Distributed Constraint Optimization Problems and Applications: A Survey", Journal of Artificial Intelligence Research, Vol. 61, 2018.
[FIPA]: Foundation for Intelligent Physical Agents (FIPA), "FIPA ACL Message Structure Specification", 2002.
[SON]: Bayazeed, A., Khorzom, K., and M. Aljnidi, "A survey of self-coordination in self-organizing network", Computer Networks, Vol. 196, p. 108222, 2021.
[ORAN-RIC]: O-RAN Alliance, "O-RAN Working Group 3: Near-Real-Time RAN Intelligent Controller Architecture", O-RAN Alliance Technical Report, 2024.
[LUPU]: Lupu, E. C. and M. Sloman, "Conflicts in Policy-Based Distributed Systems Management", IEEE Transactions on Software Engineering, Vol. 25, No. 6, pp. 852-869, 1999.
[PARSAEEFARD]: Parsaeefard, S., "Interaction and Conflict Management in AI-Assisted Operational Control Loops in 6G", arXiv preprint arXiv:2110.12025, 2021, <https://arxiv.org/abs/2110.12025>.

Sources of Inter-Agent Conflicts and Approaches to Conflict Resolution in Network Management

Abstract

Status of This Memo

Copyright Notice

Table of Contents