Agentic Intent Network (AIN): A Routing-Based Architecture for AI Agent Coordination at Scale

3.1. The Multi-Agent Coordination Gap

Current AI ecosystems are rich in model capabilities and local agent frameworks, but poor in open coordination primitives. Systems can orchestrate agents that are already inside the same framework or trust domain, yet lack a common architecture for Internet-scale, cross-domain interaction among independently operated agents.¶

Consider a concrete scenario: an enterprise deploys a customer- service agent (Framework A) that needs to invoke a compliance- checking agent (Framework B, operated by a different business unit) and a logistics-status agent (a third-party API wrapper). Today, each of these connections requires a separate, manually negotiated integration: agreed-upon API schemas, bilateral trust configuration, and per-link lifecycle management. None of the three agents can discover the others dynamically; each new agent added to the ecosystem requires O(existing agents) new integration agreements. This is not an implementation deficiency -- it is a structural absence of shared coordination infrastructure.¶

This creates a coordination gap: autonomous agents can reason and act locally, but cannot reliably discover, select, and invoke remote capabilities in a neutral, scalable, framework-independent way.¶

3.2. The O(N^2) Bilateral Integration Problem

Without shared routing infrastructure, N agents require up to N(N-1)/2 bilateral integrations to interoperate. Each integration entails interface mapping, trust negotiation, lifecycle management, and operational monitoring.¶

Engineering mitigations -- common API conventions, shared SDKs, service registries -- reduce implementation friction but do not change the underlying structure: each pair of agents that must interoperate still requires explicit, maintained coordination state. As agent populations grow and cross organizational boundaries, the per-pair cost cannot be engineered away; it must be eliminated architecturally.¶

The Internet solved an identical structural problem for host interconnection. Before shared routing infrastructure, connecting N hosts required bilateral reachability agreements. IP eliminated this by introducing a shared forwarding substrate: any host can reach any other host without pre-arrangement, because routing state is maintained by the network rather than by endpoint pairs. AIN applies the same logic to agent coordination: per-agent integration overhead is reduced from O(N) to O(1) by introducing shared capability routing infrastructure.¶

3.3. Limitations of Existing Frameworks

Existing frameworks and protocols (e.g., AutoGen [WU2023], LangGraph, A2A [A2A2025], MCP [MCP2024]) provide useful local mechanisms but do not, by themselves, satisfy the full set of open architectural needs.¶

AutoGen and LangGraph are intra-framework orchestration systems. They excel at coordinating agents that are co-deployed within the same runtime and trust boundary, but provide no mechanism for an agent in one framework to dynamically discover or invoke an agent in another. Interoperability across framework boundaries requires custom bridging code, reproducing the bilateral integration problem at the framework level.¶

MCP [MCP2024] addresses the connection between LLM-based agents and external tools or data sources. Its scope is LLM-to-resource integration, not agent-to-agent routing. MCP does not define how an agent discovers which other agents exist, selects among candidates, or routes a request across multiple coordination hops.¶

A2A [A2A2025] defines an interaction protocol for pairs of agents. It is analogous to HTTP: it standardizes the exchange format for a single interaction, but it does not address discovery, capability routing, or multi-hop forwarding. Two agents using A2A must still know each other's endpoints in advance.¶

The following table summarizes how these systems satisfy the four architectural requirements defined in Section 4.2 (Y = satisfied, P = partially satisfied, N = not satisfied):¶

Note: The ratings in Table 1 are assessed at the data-plane forwarding layer. AIN's Y rating for R_local reflects that each forwarding decision is made using only the local IRT and the datagram header, with no per-request central oracle.¶

AIN is not a replacement for these frameworks; it is the missing coordination layer above and between them. MCP belongs within AIN's execution runtime layer; A2A's agent card mechanism is a candidate representation for AIN capability descriptions.¶

3.4. Why This Is a Network Management Research Problem

First, the AIN control plane introduces new convergence challenges that have no direct precedent in IP routing. Capability registration state carries semantic identifiers (IC-OIDs) rather than topological addresses. Convergence correctness -- the guarantee that every Intent Router's IRT eventually reflects the true handler population without loops or black holes -- must be established over a semantic identifier space whose structure differs fundamentally from IP prefixes. Defining convergence conditions, bounding convergence time, and proving loop-freedom under dynamic handler populations are open research problems of the kind NMRG is positioned to address.¶

Second, the AIN coordination substrate is itself a networked system that requires operational management. As agent populations scale, operators need telemetry on capability routing behavior, anomaly detection for malformed or malicious IRP registrations, policy controls on which agents may register which capabilities, and mechanisms for graceful handler failure and capability withdrawal. These are directly analogous to the network management functions that NMRG has studied for IP infrastructure, now applied to a new class of coordination plane.¶

Third, practical AIN deployment is coupled with the underlying network and system environment in ways that require joint analysis. IRP propagation generates control-plane traffic whose volume and burstiness depend on agent population dynamics. Intent Datagram forwarding latency is bounded by both AIN routing behavior and underlay transport characteristics. These coupling effects are deployment-engineering questions that sit squarely within the scope of NMRG work on AI deployment.¶

4.1. Design Principles

The requirements in this section are not assembled as a feature wishlist. They are derived from three architectural principles that have proven effective in building open, scalable networked systems, applied here to the agent coordination domain.¶

Principle 1: End-to-End Argument. Saltzer, Reed, and Clark [SRC1984] established that functions requiring application-specific knowledge should be implemented at the endpoints, not in the network substrate. Applied to AIN: task execution, semantic reasoning, and result interpretation belong at Handlers and Originators. The routing fabric must remain thin, deterministic, and execution- agnostic. This principle drives R_local and the design invariants of Networking-Execution Separation and Payload Opacity (Section 5.6).¶

Principle 2: Narrow Waist Design. The Internet's scalability rests on a minimal common interface -- the IP datagram -- that decouples heterogeneous link technologies below from heterogeneous applications above. AIN adopts the same strategy: the Intent Datagram and IC-OID form a narrow waist enabling any agent framework to participate without requiring coordination fabric redesign. This principle drives R_open and R_hetero.¶

Principle 3: Decentralized Scalability. Centralized coordination introduces bottlenecks, single points of failure, and policy coupling that limit scale. Distributed routing protocols, from OSPF [RFC2328] to BGP [RFC4271], demonstrate that local forwarding decisions based on distributed state can achieve global reachability without central oracles. AIN applies this to capability routing. This principle drives R_local and the bounded-convergence constraint in R_dynamic.¶

Principle 4: Bounded Topology Knowledge. No AIN entity is required to maintain routing-topology knowledge beyond its local attachment point. Originators require only the target IC-OID and the address of their access Intent Router. Handlers require only the address of their access Intent Router for IRP injection. Topology-dependent coordination beyond that attachment point is the exclusive responsibility of the routing layer. This principle is complementary to Handler Location Opacity (Invariant 5, Section 5.6): bounded topology knowledge defines what each entity MUST know (local attachment only), while Handler Location Opacity defines what an Originator MUST NOT need to know (specific Handler identity/address).¶

A fifth consideration -- Policy/Mechanism Separation -- informs the overall design: routing mechanisms are specified to be generic and stable; capability-matching semantics and selection policies are explicitly layered above the forwarding core, allowing them to evolve independently without requiring changes to the routing fabric.¶

4.2. Architectural Requirements

R_open (Open Participation):

Any agent, regardless of framework, language, or deployment environment, MUST be able to register capabilities and invoke others without bilateral pre-registration.¶

Derivation: Follows from the Narrow Waist principle. Requiring bilateral pre-registration reproduces the O(N^2) integration cost documented in Section 3.2. A shared registration and routing substrate eliminates this cost structurally, as IP eliminated the need for pairwise host reachability agreements.¶

R_local (Local Decision-Making):

Each forwarding decision MUST be made locally using datagram-visible and locally maintained state; no centralized per-request routing oracle is assumed.¶

Derivation: Follows from the End-to-End Argument and Decentralized Scalability. A centralized routing oracle would become a bottleneck, a single point of failure, and a policy chokepoint -- reproducing architecturally the same problems that distributed routing protocols were designed to eliminate.¶

R_hetero (Heterogeneous Capability Matching):

The architecture MUST support heterogeneous handler types (LLM-based, deterministic, legacy-wrapped) without requiring routing-fabric redesign.¶

Derivation: Follows from the Narrow Waist principle and Policy/Mechanism Separation. The routing fabric must remain agnostic to execution substrate. Capability-matching semantics reside in the Semantic Substrate (Section 5.4), not in forwarding components, allowing handler technology to evolve without architectural disruption.¶

R_dynamic (Dynamic Capability Discovery):

The architecture MUST support dynamic capability additions, updates, and withdrawals with bounded convergence behavior.¶

Derivation: Follows from Decentralized Scalability and the operational reality of large-scale deployments. Agent populations are not static: handlers are deployed, updated, and retired continuously. The routing fabric must accommodate this dynamism while providing convergence guarantees sufficient for operational stability -- a direct analogue of liveness and loop-freedom requirements in IP routing protocols.¶

4.3. Underlay Requirements

R_u1 (Handler Reachability):

Any Intent Router MUST be able to deliver an Intent Datagram to any registered Intent Handler.¶

R_u2 (Callback Reachability):

Any Intent Handler MUST be able to deliver execution results to the Originator endpoint indicated by datagram metadata, using existing transport protocols, without routing through the Intent Routing data plane.¶

This document intentionally does not mandate specific implementation patterns for satisfying R_u1 and R_u2. Overlay networks, service meshes, message queues, and conventional IP transport are all candidate mechanisms. The deliberate non-prescription reflects an IETF layering principle: the AIN routing layer should not be coupled to a specific transport mechanism.¶

5.1. Architecture Overview

AIN is organized into three architectural parts:¶

(A) AIN Networking: underlay/transport fabric satisfying R_u1 and R_u2; Intent Routing with an explicit data plane and control plane; and the Semantic Substrate consumed by the control plane.¶

(B) Application Entities above the stack: Originator and Handler roles, which use AIN Networking but are not components of it; and optional IC-OID catalog/directory services, which may publish naming conventions or taxonomy metadata but are not architectural prerequisites.¶

(C) Execution Runtime and Compute Infrastructure: LLM and tool SDKs, adapters for legacy services, and compute resources (GPU/TPU, scheduling, placement) used by application entities.¶

     +-----------+     +------------------+     +-----------+
     |Originator |     | Originator       |     |  Handler  |
     |(emits     |     | (decomposes &    |     | (executes |
     | intents)  |     |  emits sub-      |     |  intents) |
     +-----+-----+     |  intents)        |     +-----+-----+
           |           +--------+---------+           | (a)
           |    Intent           |   (b)              | IRP
           |    Datagrams        |   sub-intents      | (announce)
           +---------------------+--------------------+
                               |
     ====================================================
     |            AIN Networking Substrate              |
     |                                                  |
     |  +--------------------------------------------+  |
     |  |    Intent Routing Control Plane            |  |
     |  |  (IRP processing, IRT computation,        |  |
     |  |   route-state distribution)                |  |
     |  +------------------+-------------------------+  |
     |           (c)       | IRT updates               |
     |  +------------------v-------------------------+  |
     |  |          Management Plane                  |  |
     |  | (telemetry, policy, config, lifecycle)    |  |
     |  +------------------+-------------------------+  |
     |           (e)       | observe / govern          |
     |  +------------------v-------------------------+  |
     |  |    Intent Routing Data Plane               |  |
     |  |  [IR]---[IR]---[IR]---[IR]                 |  |
     |  |  stateless, deterministic, reads IRT       |  |
     |  +--------------------------------------------+  |
     |                     ^                            |
     |           (d)       | naming / matching          |
     |  +------------------+--------------------------+  |
     |  |            Semantic Substrate               |  |
     |  |  (IC-OID namespace, capability-matching    |  |
     |  |   semantics, aggregation consistency)      |  |
     |  +--------------------------------------------+  |
     ====================================================
                          |
     +--------------------------------------------------+
     |          Underlay / Transport Fabric             |
     |  (provides R_u1: handler reachability and        |
     |   R_u2: callback reachability)                   |
     +--------------------------------------------------+

       IR  = Intent Router
       IRP = Intent Registration Protocol
       IRT = Intent Routing Table

Note on Figure 1: The vertical layout is a separation-of-concerns diagram, not a data-flow sequence. IRT state is written exclusively by the Control Plane and read exclusively by the Data Plane; the Management Plane observes both but does not sit in the IRT update path and does not participate in forwarding decisions.¶

The figure is read in two dimensions: vertical organization represents separation of concerns, and the lettered interactions (a)--(e) represent the principal information flows through the architecture.¶

Application Entities sit above the AIN Networking Substrate and consume its services; they are not part of the forwarding core. This boundary enforces the Networking-Execution Separation invariant (Section 5.6): an Intent Router forwards datagrams but never executes the tasks they carry.¶

Within the Networking Substrate, the Semantic Substrate occupies the base position because it provides the naming and matching semantics that the control plane depends on; it is not a forwarding layer. The Underlay/Transport Fabric is architecturally external: AIN states what reachability properties it requires (R_u1, R_u2) but does not prescribe how they are satisfied.¶

Control flow (interactions (a) and (c)). When a Handler registers or updates its capabilities, it uses IRP to register IC-OIDs and reachability information with its access Intent Router (a). The Intent Routing Control Plane processes IRP registration state, applies matching semantics from the Semantic Substrate, and computes or updates entries in the Intent Routing Table (IRT) at each Intent Router (c). This is the AIN analogue of a routing protocol: IRP- derived state propagation drives distributed route-state convergence, so that every Intent Router eventually holds an IRT reflecting the current handler population.¶

Data flow (interactions (b) and forwarding in the data plane). An Originator emits an Intent Datagram carrying an IC-OID. An Originator may decompose a compound task into sub-intents and emit multiple datagrams (b). The routing layer performs multicast diffusion toward Attachment Routers that have matching Handlers. Each Intent Router performs a local IRT lookup on the IC-OID, selects the next hop or next-hop set required by the diffusion tree, and forwards the datagram -- without consulting any central oracle and without inspecting the payload (Payload Opacity, Section 5.6). Forwarding continues hop-by-hop until the datagram reaches Attachment Routers that can deliver it to matching local Handlers.¶

Naming and matching (interaction (d)). The Semantic Substrate provides IC-OID namespace structure, prefix hierarchy conventions, and matching rules that the control plane consumes when processing IRP registrations and computing IRT entries. The Semantic Substrate is not contacted per-datagram; its definitions are incorporated into control-plane logic at configuration time.¶

Management flow (interaction (e)). The management plane observes both routing planes and applies operator policy: telemetry collection, anomaly detection for IRP behavior, capability-registration policy controls, and lifecycle governance for handler onboarding/withdrawal. Management functions are orthogonal to forwarding correctness.¶

Result delivery (not shown in Figure 1). Successful execution results are returned by the Handler directly to the Originator using the callback endpoint carried in datagram metadata, bypassing the Intent Routing data plane entirely. This source-address direct delivery model preserves stateless forwarding at Intent Routers and is analogous to an application response bypassing the discovery mechanism after the destination endpoint is known. The underlying network continues to route the response using its normal forwarding mechanisms.¶

AIN's primary role is capability discovery and intent routing. Once an Originator has established a direct session with a Handler via the session establishment mechanism described in Section 5.3, all subsequent application-layer interaction occurs directly over mutually supported existing protocols (e.g., gRPC, NETCONF, REST, HTTP) without routing-layer participation. AIN does not define or replace the payload-level communication protocols used between Originator and Handler. This design avoids reinventing existing transport and application protocols and allows AIN to be deployed incrementally on top of the existing TCP/IP infrastructure.¶

Originator         IR(access)     IR...IR     AR        Handler
    |                  |            |          |            |
    | [1] Resolve intent to IC-OID (local / DA lookup)     |
    |                  |            |          |            |
    | [2] Submit       |            |          |            |
    |  Intent Datagram |            |          |            |
    |----------------->|            |          |            |
    |                  | [3] IRT    |          |            |
    |                  |  prefix    |          |            |
    |                  |  lookup    |          |            |
    |                  |            |          |            |
    |                  | [4] Hop-by-hop forwarding         |
    |                  |----------->|--------->|            |
    |                  |   (multicast diffusion to         |
    |                  |    all matching ARs)              |
    |                  |            |          |            |
    |                  |            |          | [5] HDT    |
    |                  |            |          |  lookup &  |
    |                  |            |          |  deliver   |
    |                  |            |          |----------->|
    |                  |            |          |            |
    | ................. routing layer exits .................|
    |                  |            |          |            |
    | [6] HELLO_REPLY (direct, to callback endpoint)       |
    |<----------------------------------------------------|
    |                  |            |          |            |
    | [7] SESSION_CREATE / SESSION_ACK (direct)            |
    |---------------------------------------------------->|
    |<----------------------------------------------------|
    |                  |            |          |            |
    | [8] CDL exchange, execution, result delivery (direct)|
    |<--------------------------------------------------->|
    |                  |            |          |            |

5.2. Intent Datagram

The Intent Datagram is the fundamental coordination unit, analogous to the IP datagram. It is a self-contained triple:¶

D = <H, P, M>

where H is a routing header carrying the datagram type, intent class (IC-OID), hop count, forwarding trace, and constraint set; P is the task payload, which is opaque to routing nodes; and M is metadata carrying the correlation identifier, the originator's callback endpoint for result delivery, and optional fields for application- layer interaction control (see below). REQUEST datagrams are used for capability routing. ERROR datagrams are used for routing-stage failure feedback and are delivered directly to the originator's callback endpoint without capability lookup.¶

The routing header H contains all information required by an Intent Router to make a forwarding decision. The payload P carries the application-level task specification and is never inspected by the routing layer. The metadata M carries the callback endpoint that Handlers use for direct result delivery, satisfying R_u2 without burdening the routing layer.¶

Metadata M MAY additionally carry the following optional fields:¶

• connection_mode: Indicates whether the Originator initiates the connection to the Handler (originator_initiated) or the Handler initiates the connection to the Originator (handler_initiated). When handler_initiated, M MUST also carry an originator_listen_endpoint. This field does not affect routing layer behavior (routing completes before any connection is established).¶

• originator_listen_endpoint: The network address at which the Originator listens for incoming connections from Handlers. Only meaningful when connection_mode is handler_initiated.¶

• accept_check_endpoint: An OPTIONAL lightweight query endpoint exposed by the Originator, applicable only when connection_mode is handler_initiated. In handler-initiated mode, the Originator may receive connection requests from multiple Handlers concurrently. After Intent Routing has terminated at the Handler's Attachment Router (AR), and before endpoint delivery to a local Handler in this mode, the AR MUST query this endpoint, when present, to ask whether the Originator still accepts candidates. The AR performs this query in its endpoint-delivery role, not in its routing-forwarding role. If the query returns "reject", the AR drops the Datagram silently and does not notify the local Handler. If the query fails or the field is absent, the AR defaults to "accept" (fail-open). Each query is independent; the AR maintains no per-request state. The result does not alter the IRT lookup, next-hop selection, multicast diffusion, or any routing state. The querying AR and the Originator may reside in different Agent Domains; their communication uses the ordinary underlay and does not traverse the Intent Routing layer.¶

The hop count field in H serves the same purpose as the IP TTL: it bounds the number of forwarding hops, prevents forwarding loops, and triggers an error notification to the Originator when exhausted. The routing header MAY carry optional diagnostic metadata to support operational observability. The specific structure and content of such metadata are implementation-defined and constitute open research questions (Section 7.1).¶

5.3. Intent Routing

Intent Routing is organized into two distinct internal planes, directly mirroring the internal structure of IP's network layer.¶

Attachment-point prerequisite. Before emitting traffic into AIN, an Originator and a Handler MUST know the address of their directly attached access Intent Router. They are not required to know any topology beyond that one-hop attachment point.¶

Data Plane. The data plane performs stateless, deterministic, per-datagram multicast diffusion. For each arriving Intent Datagram, the data plane performs an IRT prefix lookup on the IC-OID in H, applies locally maintained selection policy to the resulting next-hop set, and forwards the datagram toward Attachment Routers with matching Handlers. If no compliant next hop exists, or if the hop count is exhausted, the data plane generates an error notification delivered directly to the Originator's callback endpoint. The data plane reads the IRT but never writes to it, and maintains no per-flow state.¶

Control Plane. The control plane builds and maintains the IRT by running three protocols. First, the Intent Registration Protocol (IRP), through which Intent Handlers register IC-OID capabilities and reachability information with their access Intent Routers. The specific fields, lifecycle management, and propagation controls of IRP messages are outside the scope of this document. Second, an intra-domain routing protocol (OSPF-inspired [RFC2328]) that propagates capability information within an Agent Domain, ensuring that every Intent Router in the domain eventually holds a consistent view of the handler population. Third, an inter-domain routing protocol (BGP-inspired [RFC4271]) that exchanges aggregated IC-OID prefixes across Agent Domain boundaries, with policy filtering at border routers. The IRT is the shared interface between the two planes, analogous to the IP RIB (written by the control plane) / FIB (read by the data plane) relationship. Admission and certification decisions for IRP registrations, and inter-domain acceptance or re-advertisement of IC-OID prefixes, are domain policy functions in this control plane. A domain MAY refuse import or suppress export of selected prefixes at its boundary. AIN defines no syntactic distinction between public and private IC-OIDs; a prefix is domain-local if it is simply not advertised beyond that domain.¶

The routing layer performs best-effort multicast diffusion. Each Intent Router performs longest-prefix matching to select the most- specific IRT entry, then replicates the Datagram toward all eligible next-hop branches associated with that entry, so that the Datagram reaches Attachment Routers with matching Handlers. Each AR independently evaluates local candidates. The diffusion is best- effort in two senses: the routing layer does not guarantee that all registered Handlers are reached (transient IRT inconsistency, hop-count exhaustion, or policy filtering may prevent delivery to some ARs), and it does not guarantee a minimum or maximum number of responding Handlers. The routing layer does not return a candidate list to the Originator. Candidate count and cut-off logic are entirely application-layer concerns.¶

This design choice is motivated by the stateless forwarding invariant: enforcing a specific candidate count would require per-request coordination state at forwarding nodes. The specific mechanisms by which Originators terminate acceptance (timeout, quality threshold, or endpoint-based filtering) are engineering details outside the scope of this document.¶

Attachment Router (AR) Dual Role. An AR may serve two distinct functions depending on the source of the arriving Datagram:¶

• When a Datagram arrives from a directly affiliated Intent Router (i.e., it has already been diffused through the routing layer): the AR acts as the diffusion endpoint, delivering the Datagram to local matching Handlers only. It does NOT re-inject the Datagram into the routing layer.¶

• When a Datagram arrives from an external source (e.g., an Originator connecting directly to this AR as its access point): the AR acts as both an access entry point (injecting the Datagram into the routing layer's diffusion process via its affiliated IR) AND a diffusion endpoint (delivering to local Handlers).¶

This source-based distinction is determined by interface classification (internal interface toward affiliated IR vs. external interface toward Originators or other domains) and is implemented in a fully stateless manner. The "already diffused, do not re-inject" rule prevents reinjection loops at the AR boundary. Loop-freedom within the Intent Router mesh remains a property of the routing and diffusion mechanisms.¶

The control plane's use of OSPF-like and BGP-like mechanisms is structural, not a claim of literal protocol reuse. The propagation semantics, aggregation logic, and convergence goals are isomorphic; the identifier space (semantic IC-OID prefixes rather than topological addresses) requires new protocol design and new convergence theory (Section 7.1).¶

Session Establishment. Session establishment via HELLO/HELLO_REPLY is the RECOMMENDED default interaction mode for all multi-turn agent interactions. It uses Intent Routing to diffuse the initial discovery Datagram to matching Attachment Routers. Handlers that receive the Datagram may negotiate capability and session parameters directly with the Originator, allowing the Originator to bind subsequent turns to a selected Handler endpoint -- bypassing the Intent Routing data plane for the duration of the session. The routing layer does not return a candidate list; candidate response and selection are application-layer behavior. This design keeps Intent Routers stateless while enabling context-preserving multi- turn interactions at the application layer.¶

Direct delivery -- sending a task payload directly in an Intent Datagram without prior session establishment -- is an OPTIONAL optimization applicable only when ALL of the following conditions are simultaneously met: (a) the task is atomic and stateless, requiring no multi-turn interaction; (b) the payload is not sensitive and may transit the routing infrastructure; (c) no CDL negotiation is required; and (d) fire-and-forget semantics are acceptable. Analogy: direct delivery is to session flow as UDP is to TCP -- both coexist with distinct applicability boundaries. When any condition is not met, session flow MUST be used.¶

Dynamic Properties and Resource State. AIN distinguishes stable routing reachability from dynamic operational state. The IRT is built from relatively stable capability-class reachability, not from high-frequency properties such as instantaneous load, current availability, price, or detailed runtime status. Such dynamic properties MAY be represented by reference in CDL, MAY be checked by an Attachment Router immediately before local delivery, or MAY be negotiated directly during session establishment. They SHOULD NOT be propagated as inter-domain capability-routing state unless a future protocol specification defines explicit freshness, caching, and abuse-control semantics. This preserves the routing layer's bounded-convergence property while still allowing applications and management systems to obtain current state when needed.¶

Quality Feedback Mechanism. The architecture supports a distributed quality feedback mechanism through which Handler quality state used for candidate ranking reflects observed execution quality over time. Quality state SHOULD NOT be carried in inter-domain capability reachability advertisements. The mechanism must satisfy two architectural properties: (a) feedback must be attributable to verified interactions to prevent fabrication, and (b) no single Originator's feedback should disproportionately influence Handler scores. The design of the feedback record format, anti-gaming controls, aggregation algorithm, and propagation path are outside the scope of this document.¶

CDL Version Handling. The architecture requires that CDL updates during an active direct session be resolved without routing-layer re-involvement in the common case. The specific negotiation and fallback strategy for CDL version mismatches is outside the scope of this document.¶

5.4. Semantic Substrate

The Semantic Substrate defines the shared specifications and algorithms that enable the control plane to process capability registration state in a consistent, aggregatable way. It is not a protocol layer; it is to AIN what IP addressing architecture and CIDR prefix rules are to IP routing -- shared naming and matching semantics that the control plane presupposes.¶

The Semantic Substrate comprises three components. First, the Capability Description Language (CDL): a structured representation of handler capabilities, employing a dual format that is both machine-readable (for deterministic payload validation) and LLM- interpretable (for LLM-based Originators generating intent payloads). Second, IC-OID taxonomy governance: the intent class namespace, its hierarchical structure, and prefix aggregation rules. Third, semantic matching rules: the scoring functions consumed by the control plane when evaluating registered capabilities for a given intent class.¶

All CDL instances MUST preserve the dual-format structure defined above: one machine-readable representation and one LLM-interpretable representation. Capability domains vary in content conventions within that shared structure, not in the structural requirement itself. For example, a configuration-class Handler MAY emphasize JSON Schema in the machine-readable part; an analytics-class Handler MAY emphasize few-shot examples in the LLM-interpretable part; and a complex-decision Handler MAY emphasize natural-language Markdown in the LLM-interpretable part. There is no requirement for semantic uniformity across capability classes. The dual-format structural requirement is universal; the content conventions within that structure are domain-specific. This contrasts with languages such as YANG, which require strict schema alignment across all participants before communication can occur. The routing layer is agnostic to CDL content. CDL content is opaque to Intent Routers during forwarding.¶

The routing layer performs coarse-grained classification matching on IC-OID prefixes; fine-grained capability verification is deferred to the application layer during session establishment. This two- stage approach mirrors Internet architecture: IP routing handles reachability; application-layer negotiation handles service compatibility.¶

As a concrete illustration in the network management domain, the NAIM framework [NAIM] defines a canonical, YANG-aware NAIM Document as the machine-readable semantic authority and derives a token- efficient LLM Context View for AI consumption. Together, these representations provide a concrete realization of CDL's machine- readable and LLM-interpretable roles. A network-management Intent Handler that registers an IC-OID such as "intent.network.config.interface" could publish a NAIM Document and make its derived LLM Context View available during capability exchange. Upon receiving a routed intent, the Handler translates the intent payload into protocol operations via NAIM Operation IR [NAIM-OP], which provides a protocol-neutral intermediate representation bridging AI agents and NETCONF/RESTCONF execution. This example illustrates the end-to-end path from AIN intent routing through CDL-described capabilities to concrete network operations, without implying that NAIM is the only CDL candidate; other domains will develop their own content conventions within the same dual- format structure.¶

5.5. Application Entities

5.6. Design Invariants

AIN relies on five architectural invariants. Any system that violates an invariant breaks the scalability or correctness properties of the architecture. These invariants constrain data-plane forwarding behavior after IRT state is installed. They do not require universal control-plane admission. IRP admission policy, certification checks, and inter-domain prefix filtering are governance inputs to control-plane state construction; underlay isolation mechanisms (for example, VPN deployment choices) remain an external scope boundary.¶

1. Networking-Execution Separation: The forwarding plane and the execution plane serve architecturally distinct functions and MUST be separated. Forwarding components MUST NOT perform task execution. Application entities (Originators and Handlers) MUST NOT make forwarding decisions. The means of enforcing this separation at the implementation level -- including verification and deployment isolation strategies -- are left to future specification work.¶

   Note: the optional accept_check_endpoint mechanism (Section 5.2) does NOT violate this invariant. Intent Routing has terminated at the AR before the query occurs. The AR then acts in its endpoint-delivery role and queries the Originator for a binary accept/reject signal. Each query is independent and stateless from the AR's perspective. The result gates endpoint admission after routing completion; it is not an input to any IRT lookup, next-hop selection, multicast diffusion, or other Intent Routing forwarding decision. The query therefore does not violate R_local (Section 4.2).¶

2. Hop-by-Hop Locality: Each forwarding decision MUST be made locally using only the datagram header and the local IRT. No per-flow state is maintained at any Intent Router.¶

3. Payload Opacity: Intent Routers MUST treat the payload P as opaque and MUST NOT depend on payload semantics for forwarding correctness. All routing-relevant information is in H.¶

4. Datagram Self-Containment: The datagram MUST carry sufficient routing context in H for forwarding decisions at each hop, without requiring external queries.¶

5. Handler Location Opacity: Originators MUST NOT be required to know the identity, address, or current availability of any specific Handler prior to emitting an Intent Datagram. Handler discovery is the exclusive responsibility of the routing layer. This invariant is the direct application of the End-to-End Argument to the Originator-routing-layer boundary: Handler location is routing state, and routing state belongs in the network, not at the application endpoints.¶

5.7. Structural Correspondence with IP Networking

AIN intentionally mirrors key Internet architectural primitives. This correspondence is structural, not a claim of literal protocol reuse. "Exact" denotes that operational semantics transfer without modification; "Approx." denotes that the forwarding structure is shared but the semantic domain differs, requiring new theory.¶

Note: "Exact" denotes that operational mechanics transfer without modification. "Approx." denotes that the propagation or forwarding structure is shared but the semantic identifier space introduces new questions (e.g., convergence properties) not present in the topological IP domain. IRP-derived route updates share the propagation mechanism of BGP UPDATEs (receive, validate, install, re-advertise) but operate over a semantic prefix space whose aggregation and convergence properties require independent analysis.¶

The practical consequence of the structural correspondences is that the extensive literature on distributed routing protocol design, convergence analysis, and fault tolerance is directly applicable to AIN's forwarding mechanics. The architectural claim is that the forwarding mechanism (longest-prefix match, hop-by-hop decision, decrement-and-forward) is identical and directly transferable, while the aggregation policy and convergence theory require new research specific to the semantic identifier space. IC-OID prefixes are semantic rather than topological; their aggregation does not reflect physical locality. This document specifies forwarding invariants that hold regardless of identifier semantics; convergence conditions for the semantic prefix space are identified as an open research problem (Section 7.1).¶

5.8. Intent Router Deployment Model

A key claim of this architecture is that Intent Routing infrastructure does not require a new category of specialized hardware. This section substantiates that claim.¶

The Intent Router's data-plane function -- IRT prefix lookup and hop-by-hop datagram forwarding -- is structurally equivalent to IP FIB longest-prefix match. Both operations accept a variable-length key, locate the longest matching prefix in a routing table, and return the matching next-hop set. Existing TCAM hardware that accelerates IP FIB lookup is structurally analogous to the IRT lookup function. Adapting it to IC-OID prefix matching requires a suitable binary encoding of the IC-OID hierarchy; the forwarding ASIC itself does not require redesign. The forwarding operation itself -- decrement hop count, append trace, lookup, select, transmit -- is not more complex than IP forwarding with options processing.¶

The Intent Router's control-plane function -- IRP propagation and IRT maintenance -- maps directly onto operations that network equipment vendors have implemented in BGP and OSPF for decades. Intra-domain IRP propagation is structurally equivalent to OSPF LSA flooding: receive an IRP update, validate it, install an IRT entry, and re-advertise to neighbors. Inter-domain IRP propagation is structurally equivalent to BGP prefix advertisement: aggregate internal IC-OID prefixes at domain borders, apply policy, advertise to peers. The key difference -- semantic IC-OID prefixes rather than topological addresses -- affects the matching function but not the propagation mechanism.¶

Intent Routers can therefore be deployed in three ways, in order of implementation effort: (a) as a software module on existing routing hardware, sharing physical interfaces and the management plane, analogous to adding MPLS or Segment Routing support to an existing router; (b) as a software process on commodity x86 infrastructure, suitable for enterprise deployment and cloud-based Intent Router-as- a-Service; or (c) as a dedicated appliance using routing ASICs from existing designs.¶

This observation has a direct architectural implication. Approaches that embed AI inference in the forwarding path introduce non- deterministic forwarding latency, require LLM serving infrastructure at every routing node, and create cascading failure risk when model serving is overloaded. AIN's Networking-Execution Separation invariant prevents this coupling. Intent Routers can be operated by the same network equipment vendor and operator community that builds and operates today's IP routing fabric, without requiring that community to operate AI inference infrastructure.¶

5.9. Management Plane

AIN includes an explicit management plane responsible for operational governance of the routing substrate. Its core functions are:¶

• Telemetry: observe IRP churn, convergence behavior, forwarding anomalies, and quality-feedback distribution.¶

• Policy control: constrain which entities may register which IC-OID prefixes, and enforce domain policy at management time.¶

• Configuration and lifecycle: automate handler onboarding, credential/profile updates, and graceful capability withdrawal.¶

• Fault operations: support anomaly detection and incident response without changing forwarding/data-plane behavior.¶

The management plane does not participate in forwarding decisions. If management controllers are unavailable, Intent Routing data-plane forwarding and control-plane convergence remain functionally correct with the last known valid state; management capabilities degrade to reduced observability and delayed policy/config updates.¶

To support incremental deployment, management-plane integration can be described in four practical levels:¶

• L0: manually configured attachment and static policy.¶

• L1: centralized inventory and capability registration workflows.¶

• L2: streaming telemetry plus automated anomaly detection.¶

• L3: closed-loop policy orchestration with guarded rollback.¶

5.10. Relationship to Intent-Based Networking

RFC 9315 [RFC9315] defines IBN intents as declarative goals for network behavior management. AIN intents are routable requests for AI-agent capability invocation. The two are complementary: IBN concerns network operation goals; AIN concerns inter-agent coordination routing. An AIN-based management system could itself use IBN to express network configuration goals that emerge from agent coordination.¶

5.11. Scope Boundaries

AIN is designed for open, dynamic, cross-domain agent coordination at scale. It is not the appropriate solution for:¶

• Hard real-time tasks, where coordination latency introduced by capability routing is architecturally unacceptable.¶

• Fully static and deterministic workflows, where all handler assignments are known and fixed at design time, making dynamic capability discovery unnecessary.¶

• Closed single-framework deployments, where all participating agents share the same runtime and trust boundary and no cross- domain coordination is required.¶

Explicitly defining these boundaries is consistent with the End-to- End Argument: functions that do not benefit from routing-based indirection should not be routed. Recognizing these non-goals increases architectural clarity and helps implementers identify when AIN provides structural value.¶

6.1. Relationship to draft-irtf-nmrg-ai-challenges

AIN adds a coordination-layer perspective to AI/network-management challenges, including semantic-route convergence, capability authenticity, and explainable multi-agent routing behavior. The capability routing convergence problem -- ensuring IRT consistency under dynamic handler populations -- is a new class of routing research problem. Capability authenticity -- preventing false capability registrations from attracting traffic they cannot serve -- is a new class of routing security problem directly relevant to the challenges surveyed in [NMRG-AI-CHALLENGES].¶

6.2. Relationship to draft-irtf-nmrg-ai-deploy

AIN has deployment implications for capability registration traffic patterns, convergence dynamics, and coupling between agent- coordination control behavior and network/system deployment choices. IRP propagation generates control-plane traffic whose volume and burstiness depend on agent population dynamics; this interacts with the network capacity and management concerns addressed by [NMRG-AI-DEPLOY].¶

6.3. AIN as a Third Research Dimension

AIN frames a third research dimension alongside:¶

• AI for network management, and¶

• network/system support for AI services.¶

The third dimension is open, routed network infrastructure for AI- agent coordination itself -- infrastructure that must be managed, monitored, and evolved like any other critical networked system. This dimension is orthogonal to the other two and is not addressed by existing NMRG work items.¶

6.4. Relationship to draft-chuyi-nmrg-agentic-network-inference

draft-chuyi-nmrg-agentic-network-inference [CHUYI2026] proposes an agentic network architecture for supporting agent interconnection and multi-level inference, focusing on cloud-edge-device hierarchies and AI-enhanced gateway functions within operator-controlled environments.¶

AIN and draft-chuyi are complementary and address different coordination planes.¶

Coordination scope. draft-chuyi focuses on vertical inference hierarchies -- device-edge-cloud pipelines -- within a single operator's infrastructure. AIN addresses horizontal, cross-domain coordination among independently operated agents across organizational and Internet-scale boundaries.¶

Routing substrate philosophy. draft-chuyi proposes AI-enhanced gateways that perform intent-aware forwarding with AI assistance in the data path. In practical terms, draft-chuyi embeds AI inference into the gateway forwarding path, whereas AIN adds deterministic capability routing while preserving Networking- Execution Separation. AIN maintains strict Networking-Execution Separation (Invariant 1, Section 5.6): Intent Routers are deterministic and LLM-free; AI execution is confined to application entities above the networking substrate. This separation is what enables Intent Routers to be implemented and operated by the same infrastructure community that builds IP routing equipment (Section 5.8).¶

Deployment path. Both approaches deploy on existing network infrastructure. draft-chuyi requires adding AI inference capability to gateway forwarding paths. AIN requires adding a capability routing software module and IRP support -- operations in the established repertoire of network equipment vendors.¶

The two approaches may be deployed in a complementary manner: AIN providing the horizontal open-coordination substrate across organizational boundaries, and approaches such as draft-chuyi providing optimized vertical inference pipelines within operator- controlled environments.¶

6.5. Relationship to ANIMA and GRASP

The Autonomic Networking Integrated Model and Approach (ANIMA) and its signaling protocol GRASP [RFC8990] established, well before the current interest in AI agents, that the target of discovery can be an entity capable of handling a stated objective rather than a named server. AIN shares that premise: an Originator discovers a Handler by the capability class it can serve, not by a pre-known address. In this respect AIN is closer in spirit to GRASP objective discovery than to name-based resolution such as DNS.¶

AIN attempts to extend that premise along three axes.¶

Routability across administrative domains. GRASP objective discovery operates within an autonomic domain, using flooding scoped to the Autonomic Control Plane (ACP). AIN makes the intent identifier (IC-OID) hop-by-hop routable through prefix aggregation in the IRT, so that discovery and forwarding can cross organizational boundaries at Internet scale rather than remaining within a single trust domain.¶

A federated, evolvable naming layer. ANIMA technical objectives are defined in standards-track documents as a curated set. AIN does not assume a single authority or a fixed catalogue of intent classes: multiple Directory Authorities coexist, an Originator selects which namespace to resolve against, and a Handler MAY publish under several IC-OIDs (Section 5.4.1). Naming is federated and allowed to evolve through adoption rather than pre-registered in one place.¶

Target domain. GRASP is bound to the ANIMA substrate, including the ACP and the associated bootstrapping and security infrastructure. AIN targets general AI-agent coordination and does not presuppose that substrate, stating instead its reachability expectations as underlay requirements (Section 4.3).¶

These are extensions in intent, not claims of completeness. The correspondence between GRASP's discovery, synchronization, and negotiation mechanisms and the AIN control plane merits closer study, and ANIMA's operational experience with autonomic discovery is directly relevant to the open problems in Section 7.¶

6.6. Relationship to DAWN

DAWN describes the discovery problem space for agents, workloads, and named entities, including discovery across administrative boundaries and discovery by skills, capabilities, attributes, and other properties [DAWN-PS]. The DAWN requirements are explicitly solution-neutral: they distinguish discovery from registration, selection, capability exchange, task orchestration, and agent-to- agent communication, and they allow discovery information to be returned directly or by reference to another resource [DAWN-REQS]. This boundary is important for AIN because AIN intentionally keeps fine-grained capability exchange and final selection out of the routing layer.¶

Within that design space, AIN separates two patterns that are often conflated. When an Originator already knows the target agent or service identity, endpoint or agent-name discovery mechanisms are sufficient. AIN addresses the earlier case in which the Originator has a capability-oriented intent but does not know which Handler, or even which class of Handler, can satisfy it. In that case, the routing layer performs intent-class reachability over IC-OID prefixes rather than resolving a known server or agent name.¶

This distinction does not require AIN to replace endpoint identity, bearer transport, or session-establishment mechanisms. Such mechanisms remain useful when the target identity is already known or after AIN routing has delivered an initial Intent Datagram to one or more matching Handlers. They may also be used as underlay or session mechanisms satisfying R_u1 and R_u2. Conversely, AIN's Intent Routing layer does not define a replacement for those bearer or session protocols.¶

Architecturally, the distinction is whether discovery is centered on a known identity, a published attribute set, or a routable capability class. AIN standardizes the last model as a routing architecture: IRP registers Handler capability reachability within an Agent Domain, inter-domain policy controls which IC-OID prefixes are exported, and the data plane remains deterministic and payload-opaque. This does not preclude deployments from using DAWN-related mechanisms or other agent discovery protocols at the session, identity, or underlay layers.¶

The DAWN use-cases draft identifies capability-oriented discovery, resource-oriented discovery, administrative-scope extensions, and operational discovery as distinct use-case categories [DAWN-USECASES]. AIN most directly targets capability-oriented discovery and administrative-scope extension: IC-OID reachability lets an Originator route toward a class of capability without knowing a specific Handler identity, and Agent Domain policy determines which prefixes are visible outside a domain. Resource-oriented discovery is supported only as a layered behavior: stable resource classes can be represented as capability classes or constraints, while rapidly changing resource state is obtained by reference, by Attachment- Router-local checks, or during endpoint negotiation. Operational discovery is supported through the management plane and related network-management profiles, but diagnosis, remediation, and execution remain outside the routing layer.¶

AIN also preserves the DAWN distinction between security of discovery information and trust in the discovered entity. A successful AIN routing outcome establishes only that one or more Handlers are registered for a matching IC-OID under applicable domain policy. It is not an assertion that the Handler is authorized, competent, safe to receive a payload, or suitable for the Originator's task. Those decisions are made through endpoint capability verification, authorization, and policy evaluation after the initial routing event.¶

6.7. Relationship to agentproto

The IETF agentproto effort [AGENTPROTO] proposes protocol building blocks for agent-to-agent and agent-to-tool communication, with deliverables including a session protocol for multimodal data exchange and a framework document identifying transport, identity, and authorization building blocks.¶

AIN and agentproto address overlapping but distinct aspects of agent communication.¶

Session architecture overlap. AIN already defines a session establishment framework for agent-to-agent interaction: routing- mediated discovery followed by HELLO/HELLO_REPLY, SESSION_CREATE / SESSION_ACK, CDL capability exchange, and application-layer execution over the established session (Section 5.1.1). This framework specifies the architectural flow, the interaction modes (session flow vs. connectionless direct delivery), and the invariant that Intent Routers remain stateless throughout. agentproto proposes a standards-track session protocol covering session lifecycle, multimodal transport binding, and context management. The two are complementary in scope: AIN's session framework defines the discovery-to-session transition and the architectural constraints the session must satisfy, while agentproto's session protocol could provide the wire-level mechanism implementing that session -- particularly for multimodal and long-lived interactions that benefit from QUIC, WebTransport, or MoQ transport substrates.¶

Underlay candidate. AIN's underlay requirements (R_u1 and R_u2, Section 4.3) are deliberately transport-agnostic. An agentproto session protocol is a natural candidate mechanism for satisfying handler reachability and callback reachability between AIN application entities.¶

Identity and authorization. The agentproto effort is expected to coordinate with WIMSE and OAuth on agent identity and fine-grained, behavior-driven authorization. AIN's control-plane security -- IRP registration authentication, capability-claim verification, and inter-domain prefix trust -- requires identity and authorization primitives but does not define them. The mechanisms emerging from agentproto's coordination with WIMSE and OAuth could provide the authentication substrate that AIN's IRP and capability registration depend on.¶

Discovery. Discovery of AI agents is outside the proposed scope of agentproto, which identifies coordination with discovery work in the Internet and Operations areas. AIN provides its own routing-based discovery mechanism: IC-OID prefix matching in the IRT delivers Intent Datagrams to Handlers that have registered matching capabilities, without the Originator knowing their identity. This capability-class routing is complementary to, and architecturally distinct from, endpoint or attribute-based discovery mechanisms, including mechanisms considered by DAWN.¶

7.1. Phase 1: Foundations

• Capability Description Language (CDL): formal specification with decidability guarantees; dual-format design covering both machine-readable schema and LLM-interpretable description; versioning and backward compatibility.¶

• Intra-domain capability-routing protocol: design and analysis of an OSPF-inspired IRP propagation protocol; convergence conditions and loop-freedom proof over the IC-OID prefix space, where identifiers are semantic rather than topological.¶

• Management-plane baseline: telemetry schema, policy distribution, and onboarding/withdrawal workflows for L0-L3 management levels, including failure-mode analysis when management controllers are unavailable.¶

• Minimal interoperable Intent Datagram schema: wire format, type encoding, IC-OID serialization, and constraint set encoding sufficient for basic interoperability.¶

• DAWN-aligned capability reference profile: a minimal profile that specifies how AIN exposes capability-card or descriptor references, communication parameters, trust indicators, and static/dynamic property markers without requiring the routing fabric to carry full discoverable objects or perform selection.¶

• Baseline identity and trust for capability claims: cryptographic attestation of capability registrations without requiring disclosure of implementation details.¶

• Use-case and trust-model classification: a structured taxonomy of agent interactions by trust sensitivity, including capability authority, data sensitivity, operational blast radius, and verification requirements. Read-only and write-capable interactions are not sufficient categories: a read-only Handler processing sensitive medical or financial data may require stronger trust than a write-capable Handler operating on low-value public state.¶

• Registration admission control: mechanisms by which Agent Domains authenticate Handlers, rate-limit or reject abusive registrations, and prevent large-scale spam registration of false capabilities before such registrations can affect IRT construction or inter-domain export policy.¶

• Formal convergence and loop-freedom over IC-OID prefix space: analogues of the liveness and safety properties established for IP routing protocols, applied to a semantic identifier space.¶

• Session establishment mechanism: a protocol for Originators to discover candidate Handlers through Intent Routing, negotiate capability and session parameters directly with candidates, and bind subsequent turns to a selected Handler -- while keeping Intent Routers stateless throughout.¶

• Quality feedback mechanism: formal specification of Transaction Token format, feedback record encoding, Originator-weighted aggregation algorithm, and convergence properties of distributed reputation propagation via reverse-path forwarding. Transaction Tokens prevent fabricated feedback records for interactions that did not occur, and reputation weighting can partially reduce the influence of low-reputation Originators. An open sub-problem is resistance to coordinated real-interaction score inflation by Sybil clusters, where token validation is insufficient and initial reputation equality can permit temporary manipulation. Sybil- resistant reputation bootstrapping remains an open research question.¶

• Underlay transport characterization: formal analysis of the reliability, latency, and security properties of candidate R_u2 satisfaction mechanisms under adversarial conditions.¶

• Callback endpoint authentication: mechanisms to bind callback endpoints to verified Originator identities, preventing reflection, amplification, and address-enumeration attacks in cross-domain scenarios.¶

7.2. Phase 2: Scaling

• Inter-domain capability-routing policy and IC-OID prefix aggregation: BGP-inspired protocol specification with aggregation consistency guarantees and policy filtering semantics.¶

• Multi-metric optimization under heterogeneous constraints: simultaneous optimization across latency, monetary cost, reliability, and reputation; stability conditions for feedback- driven route scoring.¶

• Stability analysis for feedback-driven route scoring: conditions under which iterative score updates based on observed handler performance converge rather than oscillate.¶

• Cross-domain latency and resource budget allocation: formal model of latency budget distribution across the routing and execution tiers of a multi-hop agent coordination chain.¶

• Foreman Pattern high availability: session state consistency guarantees across foreman instances under failure; interaction between foreman pool management and routing stability.¶

7.3. Phase 3: Ecosystem

• Ecosystem convergence of IC-OID taxonomies and catalogs: how industry groups, operators, standards bodies, and commercial alliances publish and compete on naming conventions without making any single authority a prerequisite for routing correctness; and how policy-scoped advertisement controls visibility across domains.¶

• Security and adversarial robustness at ecosystem scale: capability-claim fraud, routing-state poisoning, intent privacy threats, and namespace abuse at Internet scale.¶

• Economic settlement and incentive alignment across domains: multi-hop settlement protocols for routing fees; mechanism design for truthful capability registration; reputation system design resistant to gaming.¶

• Regulatory fragmentation and data-residency enforcement: interaction between data-residency routing constraints and inter-domain routing policy at global scale.¶

10.1. Normative References

[RFC9315]

Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/info/rfc9315>.

[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>.

10.2. Informative References

[A2A2025]

Google DeepMind, "Agent2Agent (A2A) Protocol", 2025, <https://github.com/google-deepmind/agent2agent>.

[CHUYI2026]

Guo, C., "Agentic Network Architecture and Protocol for Supporting Agent Interconnection Communication and Multi-level Inference", Work in Progress, Internet-Draft, draft-chuyi-nmrg-agentic-network-inference-00, 2026, <https://datatracker.ietf.org/doc/html/draft-chuyi-nmrg-agentic-network-inference-00>.

[MCP2024]

Anthropic, "Model Context Protocol", 2024, <https://modelcontextprotocol.io/>.

[NMRG-AI-CHALLENGES]

IRTF NMRG, "Challenges for Network Automation with AI/ML Techniques", Work in Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges, 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ai-challenges>.

[NMRG-AI-DEPLOY]

IRTF NMRG, "Network and System Considerations for Deploying AI Services", Work in Progress, Internet-Draft, draft-irtf-nmrg-ai-deploy, 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ai-deploy>.

[DAWN-PS]

Akhavain, A., Moussa, H., and D. King, "Problem Statement for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-akhavain-moussa-dawn-problem-statement-05, July 2026, <https://datatracker.ietf.org/doc/html/draft-akhavain-moussa-dawn-problem-statement-05>.

[DAWN-REQS]

King, D. and A. Farrel, "Requirements for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-king-dawn-requirements-01, April 2026, <https://datatracker.ietf.org/doc/html/draft-king-dawn-requirements-01>.

[DAWN-USECASES]

King, D., Yao, K., and K. Adler, "Use Cases for the Discovery of Agents, Workloads, and Named Entities", Work in Progress, Internet-Draft, draft-kay-dawn-use-cases-00, June 2026, <https://datatracker.ietf.org/doc/html/draft-kay-dawn-use-cases-00>.

[NAIM]

Feng, C., "NAIM: A Canonical Semantic Representation for AI-Assisted YANG Modeling and Validation", Work in Progress, Internet-Draft, draft-feng-netmod-naim-01, July 2026, <https://datatracker.ietf.org/doc/html/draft-feng-netmod-naim-01>.

[NAIM-OP]

Feng, C., "Operation Intent Intermediate Representation for AI-Assisted Network Management", Work in Progress, Internet-Draft, draft-feng-netconf-naim-op-00, July 2026, <https://datatracker.ietf.org/doc/html/draft-feng-netconf-naim-op-00>.

[AGENTPROTO]

Krishnan, S., "Agent Communication Protocols", June 2026, <https://datatracker.ietf.org/doc/bofreq-krishnan-agent-communication-protocols/>.

[RFC2328]

Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC8990]

Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.

[SRC1984]

Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", DOI 10.1145/357401.357402, November 1984, <https://doi.org/10.1145/357401.357402>.

[WU2023]

Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., Jiang, L., Zhang, X., White, R., Burger, D., Lara, V., Foyer, A., and C. Wang, "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", DOI 10.48550/arXiv.2308.08155, 2023, <https://doi.org/10.48550/arXiv.2308.08155>.