]>

fengchongllly@gmail.com

IRTF Network Management Research Group AI agents intent networking multi-agent coordination routing architecture network management The rapid proliferation of autonomous AI agents across enterprise and Internet-scale deployments creates a structural challenge that existing agent frameworks cannot address: how to enable any agent to discover and invoke any other agent's capabilities without pre- established bilateral integration, across organizational boundaries, at Internet scale. This document presents the Agentic Intent Network (AIN) as an architecture-level model for open, heterogeneous, dynamically evolving multi-agent coordination. It defines problem drivers, architectural and underlay requirements, architectural components, design invariants, scope boundaries, and a research agenda for the NMRG.

Introduction The deployment of autonomous AI agents is transitioning from isolated experimental systems to large-scale production environments. Individual enterprises deploy tens to hundreds of specialized agents; Internet-scale platforms may eventually host millions. Each agent encapsulates bounded capabilities -- network fault diagnosis, code generation, compliance checking, logistics coordination -- and collaboration among agents is an engineering necessity for accomplishing complex tasks, not an optional feature. The architecture problem is not local orchestration. It is global, open coordination: how can any agent discover and invoke any other agent's capabilities without pre-established bilateral integration, across heterogeneous frameworks and organizational boundaries? At scale, pairwise integration cost grows quadratically, quickly overwhelming any system's operational budget. At organizational boundaries, the trust and deployment assumptions embedded in today's frameworks break down: an agent operated by one enterprise cannot discover or invoke an agent operated by another without custom, manually maintained integration agreements. The name "Agentic Intent Network" reflects three structural commitments of the architecture. "Agentic" denotes that the participating entities are autonomous agents -- systems capable of independent reasoning and action -- rather than passive endpoints or simple services. "Intent" denotes that coordination is expressed as structured, capability-oriented requests, rather than as direct procedure calls or point-to-point messages; an intent captures what the originating agent wants accomplished, abstracted from which specific handler will accomplish it. "Network" denotes that the coordination substrate is organized as a routed network -- with a data plane, a control plane, addressing, and forwarding -- rather than as a registry, a broker, or an orchestration engine. Together, the name captures the core architectural claim: routing-based infrastructure is the appropriate model for open, scalable, heterogeneous agent coordination. AIN proposes a routing-based answer, applying the structural logic of packet networking to inter-agent coordination. A central observation motivating this architecture is that Intent Routers require no AI inference in their forwarding path: their function -- capability prefix lookup and hop-by-hop forwarding -- is structurally isomorphic to IP routing, and can be implemented as a software module on existing routing hardware or as a dedicated appliance. This observation significantly lowers the deployment barrier compared to architectures that embed AI inference engines in the forwarding path. This document is an architecture description in the IRTF style: it specifies what AIN is, why it is needed, and what research questions it opens. Engineering protocol mechanisms, algorithmic details, and implementation enforcement strategies are intentionally out of scope of this document.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Intent:

A structured representation of a task request, expressed as a capability class identifier and associated constraints. An intent specifies what capability is requested and under what conditions, without specifying which agent should execute it.

Intent Datagram:

The self-contained coordination unit carrying an intent, analogous to an IP datagram. An Intent Datagram contains sufficient information for any routing node to make a forwarding decision without consulting external state.

Intent Class:

A hierarchical identifier (e.g., "intent.network.fault.bgp.diagnose") that serves as the routing key for an Intent Datagram. Intent Classes form a prefix- matchable hierarchy enabling aggregation at Agent Domain boundaries, analogous to CIDR aggregation for IP prefixes.

Intent Class OID (IC-OID):

A structured hierarchical identifier for an Intent Class, following a naming scheme analogous to SNMP Object Identifiers. The IC-OID provides a machine-readable encoding of the intent class hierarchy suitable for use in routing tables and capability registrations. This document standardizes the structural properties required for routing -- syntax, hierarchy, and prefix-match behavior -- but does not require any single global allocation authority or imply cross-domain semantic equivalence for identical strings.

Handler Instance Identifier (HID):

A globally unique identifier for a specific Intent Handler instance, used to disambiguate handlers that register the same Intent Class.

Intent Router:

A deterministic forwarding component that routes Intent Datagrams based on Intent Routing Tables. Intent Routers do not perform reasoning or task execution; they implement a deterministic forwarding function. The architecture requires that the forwarding function remain execution-agnostic; the means by which implementations satisfy this property are outside the scope of this document.

Intent Handler:

An application entity that executes atomic intents. An Intent Handler MAY be an LLM-based agent, a deterministic service, or a legacy API wrapper; the routing layer treats all handler types identically.

Intent Registration Protocol (IRP):

A control-plane protocol by which an Intent Handler registers its IC-OID capabilities with its access Intent Router. IRP registration state is then consumed by the routing control plane to maintain capability reachability.

Agent Domain:

A collection of registered entities within a management and policy boundary, analogous to an IP Autonomous System (AS).

Semantic Substrate:

The shared specifications defining capability- description language, IC-OID syntax and hierarchy conventions, and matching rules consumed by AIN control-plane functions.

Intent Routing Table (IRT):

A mapping from IC-OID prefixes to one or more eligible next hops and associated route attributes, maintained by each Intent Router. Specific Handler instances are represented only in the Handler Dispatch Table at their Attachment Router. The IRT is analogous to the IP forwarding table.

Directory Authority (DA):

An optional ecosystem role that may publish IC-OID catalogs, recommended taxonomies, or capability description metadata for offline discovery. A DA is not required for routing correctness, is not in the forwarding path, and does not participate in per-datagram routing decisions.

Foreman Pattern:

An architectural pattern in which a stable, long- lived Intent Handler manages a pool of short-lived Worker Agents internally, keeping Worker Agent lifecycle events invisible to the routing layer.

Problem Statement

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.

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.

Limitations of Existing Frameworks Existing frameworks and protocols (e.g., AutoGen , LangGraph, A2A , MCP ) 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 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 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 (Y = satisfied, P = partially satisfied, N = not satisfied): System R_open R_local R_hetero R_dynamic AutoGen / LangGraph N N P N A2A P N P P MCP P N P N AIN (this document) Y Y Y Y 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.

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.

Requirements

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 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 (). 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 to BGP , 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, ): 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.

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 . 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 (), 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.

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.

AIN Architecture

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.

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 (): 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, ). 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 , 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. Component Responsibility IP Analogy Underlay/Transport Fabric End-to-end reachability under R_u1 and R_u2 Physical + Link Intent Routing Data Plane Stateless forwarding of intent datagrams; reads IRT IP data plane Intent Routing Control Plane IRP processing; IRT computation and distribution IP control plane Management Plane Telemetry, policy, config, and lifecycle governance NMS/OSS Semantic Substrate (NOT a layer) Naming / matching semantics; consumed by control plane Addressing arch./CIDR Application Entities Intent origination and execution; above the stack End hosts IC-OID catalog / directory service (optional) Optional publication of taxonomy metadata, naming guidance, or offline browsing DNS zone files / catalogs

End-to-End Intent Processing Flow Figure 2 illustrates the temporal sequence of a complete intent lifecycle in session mode (the RECOMMENDED default). The routing layer participates only during the discovery and forwarding phase (steps 2-5); all subsequent interaction is direct between endpoints.

| | | | | | [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)| |<--------------------------------------------------->| | | | | | ]]>

Steps explained: The Originator determines the appropriate IC-OID for its intent, either through local knowledge or by consulting a Directory Authority offline. The Originator constructs an Intent Datagram D = <H, P, M> and submits it to the nearest Intent Router (its access IR). The access IR performs a longest-prefix match on the IC-OID in header H against its Intent Routing Table (IRT). The datagram is forwarded hop-by-hop through the IR mesh via multicast diffusion to all Attachment Routers advertising a matching IC-OID prefix. Each receiving AR performs a local Handler Dispatch Table (HDT) lookup and delivers the datagram to registered Handler(s). A Handler that accepts the intent sends a HELLO_REPLY directly to the Originator's callback endpoint (carried in metadata M). From this point forward, the routing layer is not involved. The Originator and Handler complete session establishment (SESSION_CREATE / SESSION_ACK) over a direct transport channel. CDL capability exchange, task execution, and result delivery proceed over the established session using mutually supported application protocols (e.g., gRPC, HTTP, NETCONF). In connectionless mode, the Handler returns a result directly to the callback endpoint without session establishment (steps 7-8 are replaced by a single direct response). The architectural principle is the same: the routing layer's role ends once the datagram reaches a Handler.

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

]]>

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 ().

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 ) 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 ) 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 (). 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.

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

Intent Resolution and Directory Authorities A declarative intent, in the sense of , cannot itself serve as a routing destination: an Intent Router cannot forward on a free- form goal expressed in natural language. AIN therefore distinguishes two naming levels and an explicit resolution step between them. At the semantic level, an intent expresses what an Originator wants accomplished. At the routing level, an IC-OID is a structured, prefix-aggregatable identifier that Intent Routers match against the IRT. The IC-OID, not the intent, is the routing destination. The chain is: intent -> (resolution) -> IC-OID -> hop-by-hop match. This is analogous to name -> (DNS resolution) -> address -> routed in IP, but one semantic level higher: what is named and resolved is a capability class, not a host location. Resolution is performed by the Originator, not by the network. A Directory Authority (DA) is a static publisher of an IC-OID namespace and the definitions of the IC-OIDs within it. A DA does not perform per-request resolution and is not contacted on the forwarding path. Instead, an Originator consults a DA namespace of its own choosing and performs the intent-to-IC-OID mapping locally, at its own end, before emitting an Intent Datagram. Once the IC-OID is chosen, forwarding proceeds through the IRT via IRP-derived state without any further reference to a DA. This preserves R_local (): no centralized per-request resolution oracle is introduced, and no DA is consulted at request time. AIN does not assume a single global naming root. Multiple DAs coexist. An Originator selects which DA namespace to resolve against, and a Handler MAY publish its capabilities under several IC-OIDs drawn from different DA namespaces. A DA's influence derives from adoption -- being widely cited and reused -- rather than from delegation by a central authority. No DA is a prerequisite for routing correctness: DAs reduce cross-domain search and negotiation cost by providing shared, reusable naming, but the forwarding plane depends only on IRT state, not on any DA being reachable. This is a deliberate contrast with the DNS root model, in which a single delegation hierarchy is authoritative for resolution. The governance of IC-OID namespace roots, delegation among DAs, and the alignment of overlapping DA namespaces are ecosystem-level concerns rather than properties of the forwarding mechanism. They are treated as open problems in .

Application Entities

Functional Roles AIN distinguishes two application-level roles above the networking substrate:

Originator:

The orchestrating entity that emits Intent Datagrams into Intent Routing. An Originator holds the full business intent: it decomposes intents into IC-OIDs, determines execution order (serial or parallel dependencies), aggregates sub-results, and holds the originator_callback awaiting final results. An Originator is structurally a limited-capability entity: it emits an Intent Datagram precisely because it does not know in advance which specific Handler will fulfill the intent. An entity that knows its target Handler contacts it directly and does not require Intent Routing. A Handler operating in Mode D or Mode E assumes the Originator role for its sub-intents: it manages sub-intent scheduling, aggregates sub-results, and holds intermediate callback state. From the routing layer's perspective, all entities that inject Intent Datagrams are behaviorally equivalent.

Handler:

Executes atomic intents. A Handler MAY be an LLM-based agent, a deterministic service, or a legacy API wrapper; the routing layer treats all handler types identically. A Handler returns results directly to the Originator's callback endpoint in datagram metadata, bypassing Intent Routing. Each Handler instance is identified by a Handler Instance Identifier (HID). The HID enables the Attachment Router to distinguish between multiple Handlers registered for the same IC-OID prefix without exposing Handler identity beyond that Attachment Router. HID propagation boundaries and the specific role of HID in routing- table construction are engineering details outside the scope of this document.

These roles are above the networking substrate and consume AIN services; they are not part of the forwarding core. A single physical entity MAY simultaneously fulfill multiple roles. Role assignment is decoupled from entity implementation, allowing flexible deployment topologies without requiring changes to the routing fabric.

Behavioral Modes Upon receipt of an Intent Datagram, a Handler MAY exhibit one of five behavioral modes. These modes are not static assignments; the same entity MAY exhibit different modes for different intent classes or at different times. Mode Name Behavior Mode A Direct Execution Executes the intent atomically; returns result via originator callback. Mode B Continued Routing Re-emits the intent toward a more specific IC-OID sub-class for finer-grained handler selection. Mode C Gateway Execution Resolves the intent via private internal orchestration opaque to the routing layer. Mode D Partial Execution and Sub-Origination Partially executes the intent and emits remaining work as sub-Intent Datagrams, assuming the Originator role for those sub-intents. Mode E Pure Sub-Origination Decomposes the intent into sub-Intent Datagrams and emits all sub-intents; aggregates sub-results before returning to the original Originator. Mode B is distinguished from sub-origination (Mode D/E) by its forwarding-refinement function: the entity does not decompose the original intent into sub-tasks, but narrows the routing target to a more specific capability class. From the routing layer's perspective, Mode B produces a single re-emitted Datagram (not a fan-out), and the Originator's callback and correlation remain unchanged. Mode B is architecturally closer to route redirection than to task decomposition. Mode C is architecturally significant because it enables organizations to expose complex internal systems as single-intent handlers without revealing internal structure to the routing layer. Mode E is architecturally significant because it requires the Handler to collect and aggregate partial results before responding; the Handler acts simultaneously as an Originator toward sub-Handlers and as a Handler toward the original Originator.

Foreman Pattern AI Agents typically have dynamic lifecycles: created on demand, destroyed after use. If every AI Agent registered directly with the routing layer, frequent agent creation and destruction would cause continuous IRT churn and routing oscillation, undermining the stability that the control plane depends on. The Foreman Pattern resolves this tension. A stable, long-lived Intent Handler (the "foreman") registers with the routing layer once. The foreman manages a pool of short-lived Worker Agents internally; Worker Agents are created and destroyed on demand within the foreman's scope. Worker Agent lifecycle events are invisible to the routing layer: they do not trigger IRT updates, capability withdrawals, or convergence events. The Foreman Pattern decouples two concerns that would otherwise be coupled: the dynamic lifecycle of AI execution units and the stable registration state required by the routing control plane. AIN specifies the behavior of Intent Handlers (foremen) at the routing interface; it imposes no constraints on the internal management of Worker Agents.

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. 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 () 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 (). 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. 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. Datagram Self-Containment: The datagram MUST carry sufficient routing context in H for forwarding decisions at each hop, without requiring external queries. 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.

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. IP Concept AIN Concept Type IP datagram Intent Datagram Exact IP router Intent Router Exact FIB / RIB IRT (data / control) Exact TTL / hop limit Datagram hop count Exact BGP UPDATE IRP-derived route update Approx. Autonomous System Agent Domain Exact BGP Route Reflector Intra-domain route distributor Approx. IP address IC-OID Approx. DNS zone files / catalogs IC-OID catalog services Approx. Source-address response Callback direct delivery Approx. 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 ().

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.

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.

Relationship to Intent-Based Networking RFC 9315 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.

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.

Relationship to Existing and Related Work

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 .

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 .

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.

Relationship to draft-chuyi-nmrg-agentic-network-inference draft-chuyi-nmrg-agentic-network-inference 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, ): 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 (). 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.

Relationship to ANIMA and GRASP The Autonomic Networking Integrated Model and Approach (ANIMA) and its signaling protocol GRASP 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 (). 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 (). 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 .

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

Relationship to agentproto The IETF agentproto effort 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 (). 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, ) 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.

Open Research Problems

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.

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.

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.

Security Considerations AIN introduces security concerns at two architectural levels. Control-plane threats affect the integrity and availability of capability routing state. Capability-claim spoofing (registering capabilities not possessed) attracts traffic a handler cannot serve, causing service failure and potentially enabling data exfiltration. Routing-state poisoning (injecting adversarial capability reachability updates to corrupt IRTs) can redirect intents to malicious handlers or create black holes. Semantic namespace abuse -- registering IC-OIDs intended to shadow or hijack legitimate capability classes -- is the capability-routing analogue of BGP prefix hijacking. Data-plane threats affect the confidentiality and availability of intent traffic. Privacy leakage of intent contents or originator identity in transit; and denial-of-service against routing or handler interfaces are primary concerns. Callback Endpoint Threats. The callback endpoint carried in datagram metadata M is a significant attack surface in cross-domain scenarios. A malicious entity that can inject Intent Datagrams with a forged callback endpoint can mount reflection and amplification attacks: Handlers would send unsolicited responses to a victim address. Callback endpoints may also be used to enumerate Originator addresses across domains. Mitigations require that callback endpoints be authenticated (e.g., bound to the Originator's verified identity within its Agent Domain) and that Handlers validate callback authenticity before sending responses. The specific authentication mechanism for callback endpoints is an open research problem. Architecture-level mitigation directions include authenticated capability registrations, protected control-plane exchanges, deployment of modern transport security for all inter-node communication, callback endpoint authentication, and explicit governance for identifier namespaces. Detailed threat modeling is identified as a Phase 3 research problem (). Discovery-Trust Separation. A successful routing outcome means only that the routing layer found one or more Handlers registered for a matching IC-OID under applicable domain policy. It does not mean that the Handler is trustworthy, authorized for the Originator's task, or safe to receive the payload. Precise capability verification, credential negotiation, authorization, and payload disclosure decisions are endpoint responsibilities handled during session establishment and application-layer policy evaluation. Domain-Scoped Registration. AIN does not assume uncontrolled global registration. A Handler registers with an access Intent Router in an Agent Domain, and that domain applies admission, authentication, certification, rate-limit, and export policy before registration state influences IRT construction or crosses a domain boundary. This is analogous to the distinction between internal reachability state and BGP prefix export policy: domain policy is part of the control- plane security boundary, not an optional afterthought. Trust Sensitivity. Different intents require different trust treatment. The distinction is not simply read versus write: a read-only Handler processing sensitive medical records, financial data, or confidential operational state may require stronger verification than a Handler that writes low-value public state. Protocol specifications building on this architecture therefore need a use-case and threat-model classification that accounts for data sensitivity, operational authority, monetary risk, safety impact, and blast radius. Transaction Token Integrity. The quality feedback mechanism relies on Transaction Tokens to prevent fabricated feedback. A Transaction Token is a Handler-signed short-lived credential issued at session establishment. Feedback records without a valid Token MUST be silently discarded by receiving Intent Routers. Transaction Tokens prevent fabricated feedback records for interactions that did not occur. They do not, by themselves, prevent coordinated score inflation by Sybil clusters conducting real interactions; that problem is identified as an open research question in . Originator Trust Weighting. Handler edge routers weight incoming feedback by the Originator's reputation. Originators that consistently submit feedback diverging from consensus, or submit feedback without valid Tokens, will have their reputation score reduced by their own edge router. Handler Capability Authenticity. False capability registrations are a routing integrity threat. Mechanisms for IRP authentication are an open research problem identified in .

IANA Considerations This document requests no IANA actions. A future document defining the Intent Datagram wire format or routing-protocol code points may request appropriate IANA registries.

&RFC9315; &RFC2119; &RFC8174; Google DeepMind Anthropic IRTF NMRG IRTF NMRG &RFC2328; &RFC4271; &RFC8990;

Change Log Changes from -00 to -01: Architecture model refined from layered to planes-based organization: explicit data plane, control plane, management plane, and Semantic Substrate. Figure 1 and Table 2 updated. Application entity roles simplified to two (Originator, Handler). The -00 Dispatcher role is subsumed into Originator: a Handler that decomposes and re-emits sub-intents (Mode D/E) assumes the Originator role for those sub-intents. Five behavioral modes (Mode A-E) and the Foreman Pattern added. Intent Router deployment model added: structural isomorphism with IP forwarding/BGP-OSPF operations; three deployment options. Intent Routing elaborated: session establishment mechanism, Quality Feedback Mechanism with Transaction Tokens, CDL Version Handling, best-effort multicast diffusion semantics, Bounded Topology Knowledge principle, and one-hop attachment-point prerequisite. Semantic Substrate: Intent Resolution subsection added, with Directory Authority (DA) model for intent-to-IC-OID mapping; CDL dual-format structural constraint made explicit; NAIM and its derived LLM Context View documented as a network-management-domain realization of the CDL roles. Management Plane: L0-L3 integration levels with degraded-mode behavior when controllers are unavailable. Relationship sections added: draft-chuyi (Section 6.4), ANIMA/GRASP (Section 6.5), DAWN (Section 6.6), and agentproto (Section 6.7). Security Considerations: callback endpoint threat analysis, discovery-trust separation, domain-scoped registration, multi-dimensional trust sensitivity, Transaction Token scoping (Sybil-cluster limitation acknowledged). Open Research Problems: Phase 1 expanded with session establishment, quality feedback, callback endpoint authentication, use-case/trust-model classification, and registration admission control. Phase 2 expanded with Foreman Pattern high availability.

Acknowledgements The author thanks Brian Carpenter for pointing out the relationship between intent-based discovery and ANIMA/GRASP objective discovery, and for the observation that a routing-based approach still requires an explicit naming and resolution model; these comments directly shaped Sections 5.4.1 and 6.5. The author also thanks Eric Rescorla for discussion of threat-model, trust-sensitivity, and registration- admission concerns. Any errors, in particular in the characterization of GRASP and ANIMA, remain the author's own.