Sources of Inter-Agent Conflicts and Approaches to Conflict Resolution in Network Management
draft-janz-nmrg-inter-agent-conflict-resolution-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Christopher Janz , Fernando Camacho , Lauri Lovén , Per Kangru | ||
| Last updated | 2026-06-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-janz-nmrg-inter-agent-conflict-resolution-00
Network Management Research Group C. Janz
Internet-Draft F. Camacho
Intended status: Informational Huawei
Expires: 12 December 2026 L. Lovén
University of Oulu
P. Kangru
Viavi Solutions
10 June 2026
Sources of Inter-Agent Conflicts and Approaches to Conflict Resolution
in Network Management
draft-janz-nmrg-inter-agent-conflict-resolution-00
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.
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 12 December 2026.
Janz, et al. Expires 12 December 2026 [Page 1]
Internet-Draft Inter-Agent Conflict and Resolution June 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Sources of Inter-Agent Conflict . . . . . . . . . . . . . . . 5
4. Approaches to Conflict Resolution: Coordination Mechanism
Families . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. When Decentralised Markets Can Be Trusted . . . . . . . . 9
5. Selecting and Composing Mechanisms . . . . . . . . . . . . . 9
5.1. Encapsulation as the Load-Bearing Pattern . . . . . . . . 10
5.2. Compose Rather Than Choose . . . . . . . . . . . . . . . 11
5.3. A Worked Example . . . . . . . . . . . . . . . . . . . . 13
6. Application to the Proposed IETF Network Management Agent
Architecture . . . . . . . . . . . . . . . . . . . . . . 14
6.1. The Conflict Surface at A2A . . . . . . . . . . . . . . . 14
6.2. Where Conflict Has to Be Resolved: at Analysis and at the
Decisions . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. NMA / Management-Domain Partitioning Models . . . . . . . 15
7. Recommendations to the IETF NMA Work . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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
Janz, et al. Expires 12 December 2026 [Page 2]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 3]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Agent:
an entity to which an owner has delegated operational goals (its
intents), and which serves them by drawing inferences from what it
can observe and producing outputs that affect the managed state,
adjacent components, or its peers. The term is used inclusively
for the two kinds below. An action-bearing agent runs as an
operational closed loop and so alters network or service state
directly; an information-producing agent confines itself to
observing, analysing, and reporting, and never acts on a managed
entity.
Closed Loop (CL):
an operational observe-analyse-decide-act cycle over managed
entities, in the sense of [ETSI-ZSM-009-1].
Management Domain (MD):
the architectural unit of management authority defined in
[ETSI-ZSM-002]: the entity that holds authoritative network state,
maps requests onto resources, and enforces its own pre-configured
policies and decision logic. An End-to-End Service MD (E2ES MD)
fronts a complete ZSM framework externally and orchestrates
delivery across the underlying domain MDs.
Janz, et al. Expires 12 December 2026 [Page 4]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
Network Management Agent (NMA), Agent-to-Agent (A2A) interface:
the AI-driven entity for Level 4 (L4) autonomous-network
operations, and the interface by which NMAs interact with one
another and with non-AI components, both defined in
[I-D.zhao-nmop-network-management-agent].
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
Janz, et al. Expires 12 December 2026 [Page 5]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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
Janz, et al. Expires 12 December 2026 [Page 6]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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
Janz, et al. Expires 12 December 2026 [Page 7]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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
Janz, et al. Expires 12 December 2026 [Page 8]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 9]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
+================+===========================+======================+
| Conflict type | Well-suited families | Where decided |
+================+===========================+======================+
| Hard | Imperative arbitration; | Intra-MD at |
| contradictions | refusal and re- | earliest check; |
| | negotiation; precedence | inter-MD via A2A |
| | | across MDs |
+----------------+---------------------------+----------------------+
| Soft - | Utility reconciliation; | Intra-MD; inter- |
| objective | negotiation; | MD via A2A; E2E |
| trade-offs | argumentation | for cross-service |
+----------------+---------------------------+----------------------+
| Soft - | Markets; partitioning; | Intra-MD resource |
| resource | priority queues; DCOP | layer; inter-MD |
| contention | | at integrator |
+----------------+---------------------------+----------------------+
| Action and | Pre-execution detection; | Intra-MD on owned |
| ordering | concurrency coordination; | entities; inter- |
| | priority; DCOP | MD via A2A on |
| | | shared entities |
+----------------+---------------------------+----------------------+
| Impact-level | Digital-twin exploration; | Intra-MD NDT; |
| | merged analysis-and- | cross-MD twin at |
| | decision; post-hoc impact | E2E |
| | assessment | |
+----------------+---------------------------+----------------------+
| Intent versus | Normative regulation; | Intra-MD intent/ |
| non-intent | argumentation; lifting | policy layer; |
| | into intent; precedence | supra-MD |
| | | governance |
+----------------+---------------------------+----------------------+
Table 1: Conflict type, the families that suit it, and where the
decision is taken.
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
Janz, et al. Expires 12 December 2026 [Page 10]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 11]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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
Janz, et al. Expires 12 December 2026 [Page 12]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 13]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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
Janz, et al. Expires 12 December 2026 [Page 14]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 15]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 16]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 17]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
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.
Janz, et al. Expires 12 December 2026 [Page 18]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
9. IANA Considerations
This document has no IANA actions.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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.
Janz, et al. Expires 12 December 2026 [Page 19]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
[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.
Janz, et al. Expires 12 December 2026 [Page 20]
Internet-Draft Inter-Agent Conflict and Resolution June 2026
[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>.
Acknowledgments
Much of this thinking developed in tandem with the authors' ETSI ISG
ZSM contributions on agent coordination. We thank colleagues there,
along with the NMRG and NMOP communities, for many useful
conversations on how agentic AI should figure in network operations.
Authors' Addresses
Chris Janz
Huawei
Email: christopher.janz@huawei.com
Fernando Camacho
Huawei
Email: fernando.camacho1@huawei.com
Lauri Lovén
University of Oulu
Email: lauri.loven@oulu.fi
Per Kangru
Viavi Solutions
Email: per.kangru@viavisolutions.com
Janz, et al. Expires 12 December 2026 [Page 21]