| Internet-Draft | Agent-to-Agent Ontology Reconciliation | June 2026 |
| Janz, et al. | Expires 12 December 2026 | [Page] |
This document describes a possible direction for inter-system communication in network management, in which two cognitive software agents establish between themselves the basis for exchanging information, without depending on a single rigid data model agreed by their implementers in advance. The agents bring relevant knowledge, can extend it through learning, can reason, and can converse in natural language. The approach is framed as a workflow in which each agent makes explicit the ontology implicit in its data model, the two agents address their differences through conversation, and a translator artefact is produced that is then used during ordinary operation. A central property is that language-model inference is consumed during the agents' conversation rather than on each subsequent message. The document situates the direction relative to adjacent work and illustrates it through three use cases drawn from network management.¶
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.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Inter-system communication in network management is, today, predominantly arranged through shared data models: where systems implement the same model, or compatible profiles of it, the exchange is straightforward, and where they do not, the integration is engineered. Engineering the bridge between two data models is a substantial, recurring cost. Standard models do not anticipate every measurement source, every vendor extension, every operational subtlety; new sources need to be integrated as deployments evolve; occasional transactions need information at an abstraction level different from that of the ongoing conversation.¶
The arrival of large language models, together with the broader move toward agentic software architectures, makes a different option conceivable. A software system that holds relevant knowledge, can extend it, can reason, and can converse in natural language is in principle able to do for itself - in dialogue with a peer that has the same capabilities - much of the bridging work that integrators do today. This document explores that direction. It describes a workflow under which two such systems might construct, between themselves, a translator that runs deterministically thereafter, and gives three illustrations of how the workflow might apply in network management. Pitfalls and considerations for implementation are collected in Section 8.¶
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.¶
The following terms are used:¶
Communication between two systems depends on three things being sufficiently aligned: the ontologies that determine what each can talk about, the semantics that govern what particular utterances mean, and the syntactic conventions that govern how those utterances are expressed. Standard data models are an attempt to settle all three by agreement, in advance of any specific exchange. Where the agreement is complete, no further work is needed at exchange time. Where it is not, the residual gaps need to be closed by other means. Network management offers many reasons why complete prior agreement is not always available: deployments evolve; vendor extensions accumulate; different communities settle on different conventions for the same operational territory.¶
A further consideration is that the appropriate level of abstraction depends on the purpose of an exchange. Two systems may communicate at a high level of abstraction for ordinary purposes and need a more detailed view for an audit or a diagnostic question. The operational practice of presenting information at the abstraction appropriate to a given interaction is known as Variable Abstraction Management [ETSI-ZSM-019], and it implies that no single fixed model is uniformly appropriate even between the same two systems.¶
It is also worth recognising that some differences between ontologies are not bridgeable by any amount of description. Where one party has concepts the other has no basis for, no quantity of explanation will install them. A workflow of the kind discussed here MUST be able to acknowledge such a case and report it, rather than fabricate a correspondence.¶
Two systems are required to communicate for some purpose, but the data models they implement do not, between them, cover the matter unambiguously. The common situations are two: each system implements a recognisable standard model with partial overlap to the other, or the relationship between the two models is more ad-hoc. The customary response - hand-engineered translation logic, often with tool support - is expensive to produce and expensive to maintain across the evolution of the models. The direction explored in this document is whether two systems with the cognitive capabilities described in Section 2 can construct that translation between themselves, calling on human expertise only where they cannot make further progress on their own.¶
The workflow described here treats reconciliation as an iterative conversation between two cognitive agents, each acting on behalf of one of the communicating systems. At each iteration, the agents attempt to interpret material they have been presented with - a data-model instance, an ontology fragment, a description in natural language - against the knowledge each already holds. Where an interpretation is partial, the agents request and supply further information; the exchange can take a variety of forms, including natural-language description, examples and counter-examples, references to standards or to documentation that both agents can consult, structural sketches, and questions put to a human expert. When the two agents have a sufficient working understanding of one another's representation, each proposes the correspondences it will use to translate between the two and validates those proposals against representative cases. Where a translation, once exercised against later material, exposes a difference that the original conversation did not anticipate, the agents can return to the conversation and refine the artefact. In this sense the translator produced by the workflow is maintained rather than delivered.¶
Implementations SHOULD make this iteration explicit, both to enable principled re-engagement and to support audit of the decisions made during the conversation.¶
Differences encountered between two ontologies fall into three textures that admit different treatments. Where both parties recognise a concept but name it differently, the resolution is a dictionary entry between the two names. Where both parties recognise a concept but one represents it more finely than the other, the resolution is for the finer party to convey the distinctions the exchange actually needs; pursuing distinctions beyond what the exchange needs is wasted effort. Where one party has an element with no counterpart on the other side, the treatment is more delicate. Three responses are available, and they are not equally good. The deficient side may refuse to accept the concept, which forces the peer to lose information that may be essential to its purposes. It may escalate to a human, which - if applied to every such case - undermines the value of automating the workflow in the first place. Or it may extend its own ontology, auditably, to host the foreign concept. This last option, which this document refers to as self-extension, is the response a reconciliation workflow SHOULD prefer where the available descriptions support it, with escalation reserved for cases in which no description suffices.¶
Figure 1 summarises the workflow. Each side begins with its data model and makes the ontology that the model carries explicit; the two agents mediate the differences by the conversational mechanism of Section 5.1; and each side then generates the translator that will be used during ordinary operation. A useful property of this arrangement is that the language-model inference - the expensive part - is invoked during the conversation, not during ordinary message exchange. The translator runs deterministically thereafter, with the operational characteristics of conventional interface code. When the model on either side evolves, or when the translator begins to encounter instances it cannot handle cleanly, the workflow can be re-entered and the artefact refreshed; implementations SHOULD provide explicit triggers for this re-entry.¶
+-----------------+ +-----------------+
| Data Model A | | Data Model B |
+--------+--------+ +--------+--------+
| |
| make ontology make |
| explicit ontology |
| explicit |
v v
+-----------------+ +-----------------+
| Ontology A | | Ontology B |
+--------+--------+ +--------+--------+
| |
| <-- conversation --> |
| (description, examples, |
| references, expert input) |
v v
+-----------------------------------------------+
| Agreed correspondences + decision record |
+-----------------------+-----------------------+
|
| generate
v
+-----------------------------------------------+
| Translator A <-> B (deterministic) |
+-----------------------+-----------------------+
|
v
+-----------------------------------------------+
| Ordinary operation (no further |
| language-model inference per message) |
+-----------------------------------------------+
Three situations from network management practice illustrate where the workflow of Section 5 might be applied. None of them is presented as a worked engineering case; each is a sketch of how the workflow could be used.¶
A management system that organises its working knowledge as a graph of entities and relationships needs, from time to time, to integrate a new source of evidence - a measurement instrument, an analytic engine, or a derived signal feed - into that graph. Today, such integrations are typically engineered. The workflow of Section 5 suggests an alternative, in which the new source presents itself in natural language against a loose convention for describing what an evidence source has to offer (what is observed, on which entities, with what triggers, in what units, with what accuracy and how fresh). A cognitive agent acting on behalf of the management system - here called the Gateway - interprets that presentation against the current graph, identifying whether the kind of evidence is one the system already understands. If it is, the new source is registered as a further instance of a known kind, and no further interpretive work is needed. If the kind is new, the Gateway poses clarifying questions appropriate to what has been advertised, receives natural-language answers, and commits, in a single atomic step, both the augmentation of the graph's schema and the registration of the source. An acknowledgement closes the exchange, and the data subscription begins.¶
Two properties of this arrangement are worth noting. First, the consequential work happens once per kind of evidence, not once per source: adding a second source of an already-understood kind is a routine registration, whereas adding the first source of a new kind requires interpretation. Second, every onboarding leaves an auditable trace - the presentation, any clarifying exchange, the schema change committed, and the registration - that can be inspected after the fact and, if a later observation casts doubt on the interpretation, revisited.¶
Figure 2 sketches the message exchange. It is not intended as a protocol specification.¶
New source Gateway
| |
| natural-language self-presentation |
|-------------------------------------->|
| |
| (interpret against current graph) |
| |
| clarifying questions (only when |
|<------------------ the kind |
| answers ---- is new) |
|-------------------------------------->|
| |
| (commit: schema augmentation if |
| needed, registration, binding) |
| |
|<------------ acknowledgement ---------|
| |
| data follows |
|-------------------------------------->|
The second illustration is the more general one. Two systems hold data models for roughly the same operational territory but designed independently, and they need to be made to communicate. The workflow of Section 5 would, in outline, have each agent first make explicit the ontology carried by its model, then engage in conversation to address the differences, and finally generate the translator that runs at its side of the boundary.¶
To make the discussion concrete, the optical-transport domain offers two well-known YANG models in this shape: ONF TAPI [TAPI] on one side and the IETF TEAS family on the other, with [RFC8795] over the network base [RFC8345], extended for optical transport by [I-D.ietf-ccamp-otn-topo-yang] and [I-D.ietf-ccamp-layer1-types]. Both describe nodes, links, termination points, layering, switching, and services, in YANG, but each cuts the same operational reality in its own way. The TAPI and TEAS models are named here purely for illustration; the points that follow are intended to apply to two-data-model reconciliation in general.¶
Several kinds of difference can be expected to arise. Some are matters of terminology - the same concept named differently in the two models, often recognisable as cognates. Some are matters of identity - one model naming elements through flat identifiers, the other through hierarchical ones - which the workflow can accommodate by recording a bijection between identity spaces that the translator subsequently applies. Some are matters of granularity - one model resolving a concept more finely than the other - which the workflow addresses by having the finer side convey the distinctions the exchange actually requires.¶
Of greater interest are differences in how the same reality is decomposed. In the illustrative pair, TAPI represents the transport network as one multi-layer topology, with layer information attached to the termination points; the TEAS family represents the same reality as separate networks per layer, linked by supporting-network references. The workflow would, at this point, have to settle a structural translation that explodes one shape into the other and collapses back again, with the correspondences validated against worked instances before the translator is generated. Such a structural negotiation is the part of the workflow that would benefit most from explicit human attention during mediation.¶
Of greatest interest are differences of scope: elements that one model represents and the other has no native place for. In the illustrative pair, IETF's TunnelTerminationPoint and TAPI's ServiceInterfacePoint are examples of concepts that have no direct counterpart on the other side. Section 5.2 indicated that the workflow's preferred response to such cases is self-extension by the deficient side - extending its own ontology, auditably, to host the foreign concept - with escalation reserved for concepts that no description can install. Whether a particular case admits self-extension is a judgement the agents make in the moment, on the basis of the descriptions available to them; not every concept can be installed in this way, and the workflow is required to recognise when it cannot.¶
Whether reconciliation by this workflow would succeed in any particular two-model case depends on properties of the models, on the knowledge the participating agents can bring to bear, and on the amount and quality of expert attention during mediation. This document does not claim that every such reconciliation can be completed without human intervention. Its claim is that the workflow is a direction worth exploring, that the kinds of difference encountered are bounded and broadly understood, and that the artefact produced - a deterministic translator generated once and then run - has the operational properties an IETF audience would expect of interface code.¶
The third illustration extends the second. Two systems have already established a working translation at one level of abstraction - say, intent-based service provisioning, where the consumer states what it wants and the provider satisfies the intent without exposing the resources used. On occasion, one side puts a question that the established translation cannot answer: an audit, for example, demonstrating that the resources carrying a service lie inside (or outside) a particular geographic region [ETSI-ZSM-019]. The question requires information that the established mediation does not represent.¶
A punctual application of the same workflow can address the situation: the agents extend the established vocabulary just far enough to support the response, produce the response under the extended vocabulary, and either retire the extension at the close of the transaction or retain it if further questions of the same kind are anticipated. In many cases this extension is asymmetric: where the response is intended for consumption by a human operator on the requesting side, the requesting system need not extend its own ontology at all; it receives the response as content, and the human consumes it directly. The responding system extends, produces, and then retires (or retains) the extension on its side alone.¶
Several considerations should inform any implementation that pursues the direction described above.¶
The workflow introduces security considerations beyond those of conventional model-driven exchange. The natural-language descriptions and worked examples exchanged during mediation are inputs to the agents' knowledge, and an adversary in a position to influence those inputs could attempt to mislead the resulting translator. Implementations SHOULD attach provenance and confidence to incoming descriptions and SHOULD support revocation of integrations whose origin is later found untrustworthy. Any decision that augments the system's effective ontology - onboarding a new source, accepting a self-extension during mediation, accepting a punctual extension - MUST be subject to authorisation appropriate to the operational role of the agent and MUST be auditable after the fact. Where a mediation involves presenting information at a level of detail more granular than would ordinarily be exchanged, policy controls MUST be enforced on what may be disclosed, to whom, and under what conditions, and anonymised or aggregated forms SHOULD be supported where finer detail cannot be released. The cognitive agents inherit the general risks of large-language-model-based systems, including prompt injection, hallucination, and miscalibrated confidence; implementations SHOULD apply the usual mitigations and require human review for decisions whose consequences are operationally significant.¶
This document has no IANA actions.¶
The authors thank colleagues for discussions that shaped the ideas in this document, and members of the NMRG and NMOP for ongoing exchanges on the role of agentic AI in network management.¶