An Agentic AI Framework for Hallucination Mitigation in Network Intent Translation

1.1. Scope and Limitations

The scope is natural-language intent interpretation, policy generation, and pre-deployment validation and recovery. Checks are limited to the original intent, the selected schema and relational rules, and authoritative context explicitly supplied to the workflow. Few-shot examples illustrate representations; they do not establish facts or requirements for the current request.¶

Autonomous control of operational networks, device-level policy enforcement, runtime intent assurance, and verification of network conditions not supplied to the workflow are outside this document's scope. The document does not specify independent agent runtimes, agent discovery or inter-agent communication protocols, or network digital twin integration. These capabilities are not prerequisites for the translation workflow.¶

Error-free translation, quantified hallucination reduction, superiority over non-agentic approaches, and generalization across domains or models are not established by the preliminary implementation description. These are unvalidated claims, distinct from the architectural scope exclusions above; relevant evaluation considerations are given in Section 9.1.¶

1.2. Relationship to Other Work

The framework addresses the intent-translation function discussed in [RFC9315] and [I-D.irtf-nmrg-ibn-usecases]. It focuses on errors within the translation workflow, while downstream orchestration and operational assurance remain separate functions. The broader application of agentic AI to the IBN lifecycle and network management is discussed in [I-D.cxxx-nmrg-ai4ibn] and [I-D.hong-nmrg-agenticai-ps]. This document uses a bounded workflow definition of agentic behavior rather than prescribing a general autonomous-agent architecture.¶

Model specialization and adapter composition are discussed in [I-D.cgfabk-nmrg-ibn-generative-ai]. The present framework instead focuses on validation evidence and recovery of candidate policy artifacts, regardless of whether the underlying model is specialized. Human review and audit of LLM-assisted network-management decisions are addressed in [I-D.cui-nmrg-llm-nm]; degraded translation results can be handed to such review processes. The separation of outcome and process metrics in [I-D.cui-nmrg-llm-benchmark] informs the proposed evaluation considerations, without implying that this framework has demonstrated end-to-end network configuration correctness. These Internet-Drafts are work in progress and do not provide a universal normative definition of agentic AI.¶

3.1. Intent Translator

The Intent Translator is a modular subsystem responsible for converting natural language intent into a structured, machine-readable policy document suitable for enforcement in intent-based management systems. It forms the core of the intent translation framework, providing parallel extraction, schema-constrained generation, multi-dimensional validation, and trace-based adaptive retry. The final output is expressed in a structured format such as YAML and adheres to the policy modeling defined in [TS-28.312].¶

Architecturally, the Intent Translator operates as a partially parallel pipeline composed of four functional components, a deterministic merge step (the Intent Composer), and a feedback router (the trace driven recovery agent). The two Extractors execute in parallel on the same input; their outputs are merged by the Intent Composer and consumed by the Policy Generator. The Policy Validator then evaluates the candidate policy along three complementary dimensions, and the trace driven recovery agent uses the resulting failure-mode trace to dispatch targeted regeneration when needed. The pipeline supports schema-grounded extraction, schema-as-grammar generation, failure-mode-specific validation, and adaptive retry. It is designed to support transparent, extensible, and standards-aligned translation of human goals into actionable configurations.¶

                  +----------+
                  | IBN User |
                  +----------+
                       |
                       | natural language intent
                       v
 +--------------------------------------------------------------+
 |                                            Intent Translator |
 |                                                              |
 |   +---------------------+      +---------------------+       |
 |   |  Scenario Extractor |      |   Slot Extractor    |       |
 |   +---------------------+      +---------------------+       |
 |              |                            |                  |
 |              |    (parallel inference)    |                  |
 |              +-------------+--------------+                  |
 |                            |                                 |
 |                            v                                 |
 |                 +---------------------+                      |
 |                 |   Intent Composer   |                      |
 |                 +---------------------+                      |
 |                            |                                 |
 |                            v                                 |
 |                 +---------------------+  +----------------+  |
 |                 |  Policy Generator   |<-|      Policy    |  |
 |                 +---------------------+  | Knowledeg Base |  |
 |                            |             +----------------+  |
 |                            v                                 |
 |                 +---------------------+                      |
 |                 |  Policy Validator   |                      |
 |                 +---------------------+                      |
 |                            |                                 |
 |             pass           |       fail (with trace)         |
 |               +------------+------------+                    |
 |               |                         v                    |
 |               |               +-------------------+          |
 |               |               |  Trace driven     |          |
 |               |               |  recovery agent   |          |
 |               |               +-------------------+          |
 |               |                         |                    |
 |               |                         v                    |
 |               |                  targeted retry              |
 +---------------|----------------------------------------------+
                 v
          Validated YAML
          policy document

The main components of the Intent Translator (Scenario Extractor, Slot Extractor, Intent Composer, Policy Generator, Policy Validator, and trace driven recovery agent) are illustrated in Figure 1.¶

• Scenario Extractor: A component that classifies the input intent into a structural coordinate. In the 3GPP-based instantiation described here, the role is selected from Communication Service Customer (CSC), Communication Service Provider (CSP), and Network Operator (NOP), as defined in [TS-28.530]. The scenario is selected from four IntentExpectation subclasses in [TS-28.312]: RadioNetwork, RadioService, EdgeServiceSupport, and 5GCNetwork. These selected roles and scenarios form twelve cells that constrain downstream policy choices for this instantiation. Schema-as-grammar constraints restrict the output to this configured set; it is not a universal classification of network-management intent.¶

• Slot Extractor: A component that, in parallel with the Scenario Extractor and given the same natural language input, extracts named entities (such as area codes, user groups, or service identifiers) and structured slot values required to populate the policy document. Typical slots include target name, target value, target unit, and target condition. The Slot Extractor is also realized under schema-as-grammar constraints, so that entity types and slot enumerations (such as units and comparison conditions) are restricted to valid values at decoding time.¶

• Intent Composer: A component that merges the outputs of the two Extractors into a single structured intermediate representation (the Intermediate JSON) that the Policy Generator consumes. The Intent Composer performs a deterministic, schema-shaped aggregation - it does not itself perform language understanding.¶

• Policy Generator: A component that synthesizes a candidate policy document. It consumes the merged Intermediate JSON produced by the two Extractors and emits a candidate policy document, typically in YAML, that targets the schema defined in [TS-28.312]. The Policy Generator operates under schema-as-grammar constraints derived from the target OpenAPI specification, limiting token continuations to those admitted by the compiled grammar. Post-generation validation remains necessary because not all semantic or cross-slot constraints are expressible in the generation grammar. Optionally, the Policy Generator may be specialized to the target domain through supervised adaptation, for example by parameter-efficient fine-tuning over a corpus of intent-policy pairs.¶

• Policy Validator: A component that evaluates the candidate policy along three complementary dimensions and emits a failure-mode trace. The three sub-components are described in Section 3.4. Unlike a single pass/fail check, the failure-mode trace identifies which structural or semantic invariant was violated, enabling the trace driven recovery agent to take a targeted corrective action.¶

• Trace driven recovery agent: A component that consumes the failure-mode trace from the Policy Validator and dispatches targeted regeneration. The router supports failure-mode-specific corrective actions, such as regenerating the policy under additional structural constraints when a cross-slot violation is detected, or re-extracting slot values when a value-range violation is detected. The router enforces a bounded retry budget and emits a degraded intent if the budget is exhausted without successful validation.¶

• Policy Knowledge Base: A repository component that supplies domain knowledge consumed by the other components. It maintains the schema of the target standard (used by the Policy Generator for schema-as-grammar compilation), examples of valid policy documents (used for few-shot retrieval), and the relational invariants between schema fields (used by the Policy Validator for cross-slot consistency checking). The Policy Knowledge Base may be extended over time as new schema versions and new examples become available.¶

Together, these components support a transparent transformation of user-defined goals into system-aligned candidate policies that can be validated before downstream use. The architecture is modular and extensible, allowing domain-specific enhancements (such as substitution of the underlying language model, the constrained decoder, or the validator implementation) without modification to the end-to-end pipeline.¶

3.2. Parallel Extractor Decomposition

The two Extractors share the same natural language input but address cognitively distinct sub-tasks. The Scenario Extractor performs abstraction-level reasoning and taxonomy classification, determining how the intent maps to a coordinate in the role-scenario space. The Slot Extractor performs token-level pattern matching and schema-aware slot filling, identifying entity spans and structured values in the surface text. Decomposing these sub-tasks permits each inference to use a narrower task and schema-as-grammar specification. Any resulting reduction in translation errors requires evaluation.¶

                  Natural Language Intent
                            |
              +-------------+-------------+
              |                           |
              v                           v
    +--------------------+     +--------------------+
    | Scenario Extractor |     |   Slot Extractor   |
    +--------------------+     +--------------------+
              |                           |
              v                           v
       {role, scenario}        {entities, slot values}
              |                           |
              +-------------+-------------+
                            |
                            v
                  +-------------------+
                  |  Intent Composer  |
                  +-------------------+
                            |
                            v
                     Policy Generator

The internal flow of the parallel extraction step is illustrated in Figure 2.¶

• Scenario Extractor: In this 3GPP-based instantiation, the logical function selects one of the three management roles (CSC, CSP, NOP) and one of four selected IntentExpectation subclasses (RadioNetwork, RadioService, EdgeServiceSupport, 5GCNetwork). The selected roles and scenarios define twelve permitted (role, scenario) combinations. Decoding is constrained to emit one of these combinations, recorded as a small JSON object.¶

• Slot Extractor: A logical function that, in parallel with the Scenario Extractor and from the same natural language input, identifies the named entities (such as area codes, user groups, or service identifiers) and the structured slot values (target name, target value, target unit, target condition) that the policy will carry. Slot values are constrained at decoding time to belong to valid enumerations (for example, a closed set of comparison conditions and a closed set of units), so that downstream schema validation cannot fail on out-of-vocabulary slots.¶

• Intent Composer: A deterministic step that merges the two Extractor outputs into a single Intermediate JSON document of the form {role, scenario, entities, slot values}. The Intent Composer does not invoke a language model. The two Extractors operate on the same input independently, so any cross-output inconsistency that may arise is left to the Policy Validator to detect downstream.¶

The two Extractors may share the underlying language model instance, differing only in their prompt and in the schema-as-grammar specification applied at decoding time. This sharing can keep the number of distinct model artifacts low and reduce the operational complexity of maintaining heterogeneous model families. The two inferences are independent, so they may be executed either sequentially on a single accelerator or concurrently when batched inference is supported by the runtime.¶

Parallel decomposition can be preferable to sequential decomposition (in which the output of the Scenario Extractor is injected as context to the Slot Extractor) for two reasons. First, parallel execution can reduce cascading errors from the Scenario Extractor into the Slot Extractor. Second, the two outputs may be cross-checked downstream, providing an additional consistency signal to the Policy Validator and the trace driven recovery agent.¶

Role separation is logical. The Extractors and Policy Generator provide language-model functions; the Semantic Judge may also use a language model. Intent Composer and the schema and relational validators provide deterministic processing or checking. These functions may share model instances and need not be deployed as independent agents. The agentic property described here is their bounded feedback-driven coordination.¶

3.3. Policy Generator

The Policy Generator synthesizes a candidate policy document from the merged Intermediate JSON. The principal design constraint is that candidate output should remain within the structural language admitted by the target OpenAPI-derived schema grammar. This constraint is enforced through schema-as-grammar [Outlines][XGrammar][GCD], in which the schema is compiled into a schema-derived grammar consumed by the language model decoder. The general efficacy and known limitations of schema-as-grammar across heterogeneous schemas have been characterized in recent benchmarks [JSONSchemaBench]; not all schema features are expressible as efficient grammars, which is one reason post-generation validation remains part of the framework.¶

        +---------------------+
        |   Intent Composer   |
        +----------+----------+
                   |
                   | Intermediate representation
                   v
    +-----------------------------+
    |            Policy Generator |
    |                             |
    |   +--------------------+    |   +----------------+
    |   |  Grammar Compiler  |<---|---| Policy         |
    |   +--------------------+    |   | Knowledge Base |
    |              |              |   +--------=-------+
    |              v              |
    |   +---------------------+   |
    |   | Constrained Decoder |   |
    |   +---------------------+   |
    +--------------+--------------+
                   |
                   | Candidate policy representation
                   v
            Policy Validator

The internal workflow of the Policy Generator is illustrated in Figure 3.¶

• Grammar Compiler: A component that compiles the target schema, such as the OpenAPI-derived schema of [TS-28.312], into a grammar supported by the constrained decoder. It reads the schema from the Policy Knowledge Base. Reference resolution and normalization of constructs such as discriminator, allOf, and oneOf may be necessary, but transformations must preserve the relevant source constraints; replacing allOf by oneOf is not a general equivalence. Constraints not enforced by the compiled grammar remain subject to post-generation validation, and the implementation should identify the supported constraint subset.¶

• Constrained Decoder: A component that runs the language model with the compiled grammar applied at every decoding step. At each step, the grammar restricts the set of token continuations to those that keep the partial output extendable to a schema-admissible completion. The Constrained Decoder consumes the Intermediate JSON produced by the Intent Composer and emits the candidate policy document.¶

Schema-as-grammar enforcement reduces syntactic invalidity (F-syn) by constraining the output language, but it does not, by itself, establish semantic coherence across slots. For example, a candidate document may satisfy every individual field constraint while combining an object type and a target name that are incompatible under the IntentExpectation type hierarchy of [TS-28.312]. Such cross-slot violations are detected downstream by the Policy Validator.¶

The Policy Generator may optionally be specialized through supervised adaptation, including Low-Rank Adaptation (LoRA) [LoRA]. The model, adaptation method, and any claimed reduction in translation errors are deployment and evaluation choices, not prerequisites or demonstrated guarantees of this architecture.¶

3.4. Policy Validator

The Policy Validator evaluates schema conformance, cross-slot consistency, and faithfulness to the original intent as complementary dimensions. Its observations support diagnosis and recovery, but do not prove statistical independence of the checks, a unique upstream cause, or the absence of hallucination.¶

             +---------------------+
             |  Policy Generator   |
             +----------+----------+
                        |
                        | candidate policy
                        v
   +-----------------------------------------+
   |                        Policy Validator |
   |                                         |
   |    +-------------------------------+    |
   |    |       Schema Validator        |<--- schema/profile
   |    |        (schema shape)         |    |
   |    +---------------+---------------+    |
   |                    |                    |
   |                    v                    |
   |    +-------------------------------+    |
   |    |       Semantic Solver         |<--- invariants
   |    |        (cross-slot)           |    |
   |    +---------------+---------------+    |
   |                    |                    |
   |                    v                    |
   |    +-------------------------------+    |
   |    |       Semantic Judge          |<--- intent/context
   |    |     (intent faithfulness)     |    |
   |    +---------------+---------------+    |
   |                    |                    |
   +--------------------+--------------------+
                        |
                        v
             { pass | failure trace }
                        |
              +---------+---------+
              |                   |
        pass  |                   | fail + trace
              |                   v
              |           +----------------+
              |           | Trace driven   |
              |           | recovery agent |
              v           +----------------+
        Validated policy

The internal architecture of the Policy Validator is shown in Figure 4. The checks execute in order and produce structured observations. Each check reports pass, fail, or not assessed, with a reason when assessment is uncertain, blocked by an earlier failure, or cannot be completed. A check that was not assessed is not treated as a pass. The declared acceptance policy determines the final disposition and any retry.¶

• Schema Validator (syntax check): This sub-component checks the candidate instance against the selected target schema. A YAML candidate is first parsed and, where needed, normalized to the data representation expected by the validator. The relevant schemas and external references are resolved from the OpenAPI specification, with any dialect adaptation required by the chosen JSON Schema validator, such as a Draft 2020-12 implementation [JSON-Schema-2020-12]. It detects F-syn and schema-expressible F-val. Schema compilation or resolution failures are reported as configuration or assessment failures, rather than attributed automatically to hallucination. Grammar enforcement does not remove the need for these checks.¶

• Semantic Solver (cross-slot check): This sub-component checks configured relational and domain constraints not fully captured or enforced by the selected schema and generation grammar. For the described 3GPP instantiation, these include the permitted relationship between object type and target name. A Satisfiability Modulo Theories (SMT) solver such as Z3 [Z3] may implement these checks and report F-xs. A solver result applies only to the encoded constraints and does not establish correctness of facts outside the supplied context.¶

• Semantic Judge (meaning check): This sub-component evaluates the semantic faithfulness between the original natural language intent and the candidate policy document. It detects semantic mis-grounding (F-sem), such as the selection of a schema branch that is structurally valid but does not match the user's stated goal, and the portion of value-range errors (F-val) that depend on natural language context. The Semantic Judge may be realized as a language model judge with calibrated few-shot examples, optionally supplemented by deterministic lexical overlap checks for robustness. An LLM-based assessment can be incorrect or uncertain and is not ground truth. Lexical overlap may supply diagnostic evidence, but is not sufficient by itself to establish faithfulness.¶

The labels F-syn, F-xs, F-sem, and F-val correspond to the four failure-mode categories defined in Section 2. The mapping associates each failure-mode category with its primary detecting sub-component: the Schema Validator emits F-syn and the schema-expressible portion of F-val; the Semantic Solver emits F-xs; and the Semantic Judge emits F-sem and the natural-language-context-dependent portion of F-val. F-val therefore has two detection paths, reflecting the practical observation that some value-range or unit errors are caught at the schema level while others require natural language context. The failure-mode trace produced by the Policy Validator is consumed by the trace driven recovery agent described in Section 3.5.¶

A deployment declares which checks are required or advisory and how their outcomes are combined. For example, acceptance may require the Schema Validator and Semantic Solver to pass and a semantic assessment to meet the stated criteria. A deterministic alternative to the Semantic Judge must cover those semantic criteria; lexical overlap alone is not an acceptance gate. Failed or unassessed required checks remain explicit and prevent a clean validation-success result. Advisory warnings and any acceptance with warnings are recorded separately from clean acceptance.¶

A logical validation trace should identify the intent and candidate, the candidate version, the schema/profile and relational-rule versions, each check and its outcome, applicable failure-mode labels, the affected fields, and references to available evidence. Recovery records should identify the selected retry target, attempt count, remaining budget, and final disposition. Evidence may include input spans or constraint identifiers; unavailable evidence is not fabricated. These are functional reporting requirements, not a new wire encoding or inter-agent protocol. Their coverage in a particular prototype must be verified separately.¶

3.5. trace driven recovery agent

When the Policy Validator emits a failure trace, the recovery-control function uses the observations and the configured policy to select a permitted corrective action. A trace can contain multiple failure labels, and the detecting component does not uniquely determine the originating cause. The controller may follow fixed routing rules; independently autonomous planning or a model-driven routing implementation is not required by this architecture.¶

            +---------------------+
            |  Policy Validator   |
            +---------------------+
                       |
                       | failure-mode trace
                       v
              +-----------------+
              | Trace driven    |
              | recovery agent  |
              +-----------------+
                       |
    +------------+-----+-----+------------+
    |            |           |            |
  F-syn        F-xs        F-val        F-sem*
 (syntax)  (cross-slot)   (value)     (meaning)
    |            |           |            |
    v            v           v            v
+---------+ +---------+ +---------+ +-----------+
| Policy  | | Policy  | |  Slot   | | Scenario  |
|Generator| |Generator| |Extractor| | Extractor |
+---------+ +---------+ +---------+ +-----------+

* F-sem retries Policy Generator when the coordinate is correct.

(retry budget enforced; on exhaustion, a degraded intent is emitted)

One possible routing policy for the trace driven recovery agent is summarized in Figure 5 and described below. The mapping is a deployment policy and can be adjusted based on implementation experience and local validation data.¶

• F-syn (syntactic invalidity): Route to the Policy Generator for regeneration. This case may occur when the generation constraints are incomplete, miscompiled, or not fully aligned with the validator used after generation.¶

• F-xs (cross-slot inconsistency): Route to the Policy Generator with additional configured constraints or corrective guidance, such as binding the object type to a trusted (role, scenario) coordinate. A prompt directive provides guidance; a hard constraint requires enforcement by the generation grammar or a validation tool.¶

• F-val (value-range error): Route to the Slot Extractor for re-extraction of the affected slot values.¶

• F-sem (semantic mis-grounding): Route to the Scenario Extractor if the failure trace indicates an incorrect (role, scenario) coordinate; otherwise route to the Policy Generator with an additional semantic hint. In some deployments, F-sem alone may not justify retry because the Semantic Judge has inherent calibration limits.¶

The trace driven recovery agent enforces a bounded retry budget. When the budget is exhausted without successful validation, the router emits a degraded intent that records the residual failure mode and the most recent candidate policy. Degraded intents are suitable for routing to a human operator or to a downstream validation pipeline before deployment.¶

The routing policy itself is subject to validation. A deployment should verify that a selected retry target is likely to reduce the observed failure mode and should update the routing table if local data indicates a different dominant cause. For example, an F-xs trace may be routed to the Policy Generator with an additional hard constraint when the role-and-scenario coordinate is trusted, but another deployment might route the same failure to re-extraction if the coordinate is uncertain.¶

Recovery preserves the original intent. When a Scenario or Slot Extractor result changes, the Intent Composer merges the updated outputs, the Policy Generator regenerates the candidate, and the applicable checks run again. Candidate versions and evidence remain correlated so that stale results are not reused as proof of a revised candidate's validity. The controller does not silently relax user requirements to obtain a pass. Ambiguous inputs and unresolved failures are returned with an explicit review-needed disposition. A deployment specifies its retry-count limit and any additional time or token limits; exhaustion terminates the workflow with the residual status recorded.¶

3.6. Standardized Data Models and Interfaces

Policy artifacts are data instances serialized in formats supported by the target model, such as YAML [YAML], JSON, or XML. YANG [RFC6020][RFC7950] defines a data model rather than a serialization. NETCONF [RFC6241], RESTCONF [RFC8040], or REST [REST] may carry an artifact only through an appropriate model-specific encoding and interface binding; changing serialization alone does not provide a semantic mapping between models. For the 3GPP instantiation, validation uses the relevant schemas from the OpenAPI specification of [TS-28.312]. A deployment or evaluation identifies the exact schema version and artifact references, the selected role/scenario taxonomy, and the relational-rule set. This document does not define a new intent language or a new transport protocol.¶

As described in the modular architecture of the framework, user-defined natural language intent is processed through a partially parallel pipeline that includes the Scenario Extractor, the Slot Extractor, the Policy Generator, the Policy Validator, and the trace driven recovery agent. The schema and the cross-slot relational invariants are sourced from the Policy Knowledge Base, enabling schema-as-grammar enforcement and failure-mode-specific detection. This design is intended to help translate operational goals - even when imprecisely expressed - into policy representations that can be checked for schema conformance, cross-slot coherence, and semantic faithfulness to the user's intent.¶

Therefore, this document defines a practical and extensible architecture for intent translation in management systems. Through this architecture, high-level user goals can be mapped to structured policy outputs that are suitable for validation and downstream automation. The framework enables intent-based management to support scalable, knowledge-grounded automation in complex service domains such as networks, vertical-specific networks, and intelligent edge infrastructures.¶

9.1. Evaluation Considerations

Future evaluations should compare a single translation call, schema-constrained generation, validation with generic retry, and the described failure-directed recovery, using comparable models, inputs, and call or token budgets. If model-directed routing is implemented, its effect should be isolated by comparison with fixed routing under otherwise matched conditions. Separating outcome and process measures follows the evaluation perspective in [I-D.cui-nmrg-llm-benchmark].¶

Report residual semantic errors or hallucinations among accepted policies, erroneous acceptance, detection and recovery outcomes by failure mode, clean-acceptance coverage, warning/review/rejection rates, and latency and token or call cost. Error rates must be reported with acceptance coverage so that rejecting every input is not mistaken for successful mitigation. The Semantic Judge's own output is not the evaluation oracle; use independent reference constraints, validated policies, or expert assessments. Translation-quality measures do not by themselves establish operational intent fulfillment.¶