Internet-Draft Intent Routing Requirements August 2026
Feng Expires 15 February 2027 [Page]
Workgroup:
Network Working Group
Published:
Intended Status:
Informational
Expires:
Author:
C. Feng

Requirements for Intent Routing in Multi-Agent Systems at Internet Scale

Abstract

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 reach and invoke any other agent's capabilities without pre-established bilateral integration, across organizational boundaries, at Internet scale.

This document states the normative requirements for that problem. It prescribes no solution, no specific mechanism, no message format, and no assumption of centralized or distributed architecture. Its purpose is to establish a verifiable yardstick against which any claimed "intent routing" solution can be judged.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 15 February 2027.

1. Terminology

Agent
A participant capable of autonomous reasoning and action, not a passive endpoint.
Requester / Originator
An agent that initiates a coordination request and expresses an intent.
Handler / Provider
An agent that possesses a capability and can fulfill a requester's intent.
Intent
What the requester wants accomplished, abstracted from which specific handler will accomplish it.
Capability
A unit of function that a handler can offer, which can be identified and matched.
Coordination Substrate
The intermediary layer through which requesters and handlers reach each other and establish interaction. This document remains neutral about its form (registry, directory, routing network, gateway, etc.).
Forwarding Node
The element of the coordination substrate responsible for directing a request toward a handler. It may be a deterministic forwarding element or an intermediary that takes on more decision-making. Whether its data-path decisions involve reasoning, and the resulting infrastructure cost, is what Section 3.5.1 and Section 3.5.2 constrain.
Control Plane
The mechanisms responsible for capability registration, advertisement, dissemination, and synchronization (i.e., what capabilities exist and how to reach them).
Data Plane
The mechanisms responsible for delivering an intent request to its target handler.
Administrative Domain / Organizational Boundary
The boundary of a group of participants governed by the same policy and sharing the same trust and governance assumptions.
Reachability
Whether one endpoint can initiate and establish a connection to another. Subject to NAT, firewalls, and network policy, reachability may be one-way or asymmetric.

2. Problem Statement

2.1. The Multi-Agent Coordination Gap

Existing agent frameworks solve orchestration within a single agent, or collaboration among agents in the same framework and the same trust domain. They assume participants already know of each other's existence and interfaces at deployment time.

This assumption fails along three dimensions:

  1. Scale: With N agents, pairwise integration costs O(N^2). Without shared coordination infrastructure, integration cost alone crushes any system.
  2. Heterogeneity: Agents from different frameworks, languages, and runtime environments have no common entry point for reaching and invoking each other.
  3. Organizational boundaries: Across organizations, trust and deployment assumptions no longer hold. No party can compel others to register their capabilities into its private directory.

The Internet solved the same structural problem for host interconnection with shared routing infrastructure. Agent coordination faces a higher layer of that problem: treat capability as a routable object, not as endpoints that must be integrated pairwise.

2.2. Problem Space and Scope

This document covers the span from "a requester expresses an intent" to "locating a handler that can fulfill that intent." Concretely: the expression and decomposition of intent, the identification and aggregation of capability, the directing of requests (routing), and the matching and selection of candidates.

A clarification: in this document, locating a handler is the result of the delivery process, not a separate query-and-return-candidates mechanism. The core action of the coordination substrate is the delivery of the intent request (the data plane); finding the handler is the completion effect of that delivery. Whether the handler's information is returned to the requester, or the intent is delivered directly to the handler, is a policy declared by the handler at registration time (see Section 3.4.3), not an inherent shape of the locating action.

This document does not cover: the interaction protocol after routing (task execution, session establishment, the message formats of result delivery), the schema of any capability description language, or identity, trust, and authorization mechanisms (which are handled elsewhere, but with which the requirements here must coexist).

3. Requirements

The following requirements are normative. Each requirement's rationale explains its motivation but imposes no additional constraint.

3.1. Openness and Heterogeneity

3.1.1. REQ-1: Open Participation

Any agent, regardless of framework, language, or deployment environment, MUST be able to register its capabilities and invoke others without establishing bilateral relationships with each potential partner in advance.

Rationale: Requiring bilateral pre-registration brings back the O(N^2) integration cost verbatim. A shared coordination layer should eliminate pairwise agent integration structurally, just as IP eliminated pairwise host-reachability agreements.

3.1.2. REQ-2: Heterogeneous Handlers

The coordination substrate MUST support heterogeneous handler types (LLM-based, deterministic programs, wrapped legacy services) without requiring the substrate to be redesigned when handler types change.

Rationale: In real deployments, capabilities are provided by many technology stacks. If the coordination layer is sensitive to handler type, it degenerates into one routing mechanism per type.

3.2. Control Plane and Data Plane

3.2.1. REQ-3: Control/Data Plane Separation

Capability registration, advertisement, and dissemination (the control plane) MUST be separated in mechanism from the delivery of intent requests (the data plane).

Rationale: The control plane answers what capabilities exist and how to reach them; the data plane answers where this request is delivered. Coupling them makes every delivery depend on global registration state (violating Section 3.3.1 and Section 3.4.1) and prevents a handler from independently declaring its interaction policy at registration (Section 3.4.3). Internet architecture already separates the control plane (routing protocols) from the data plane (packet forwarding) for this reason: the data plane must be cheap, deterministic, and free of dependence on global state in order to carry per-packet forwarding at scale.

3.3. Scale and State

3.3.1. REQ-4: Bounded State

The coordination mechanism MUST NOT require any single node (or gateway) to maintain state proportional to the total number of agents.

Rationale: If a node's state grows linearly with the total agent population, that node becomes both a scaling ceiling and a single point of failure. A scalable mechanism makes each node's state proportional to what it locally governs or needs, not to the global total.

3.3.2. REQ-5: Capability Aggregation

Capability information MUST be summarizable and aggregable, so that cross-domain (cross-organization, cross-administrative-boundary) capability advertisement is decoupled from the total agent population.

Rationale: Cross-domain advertisement cannot carry every handler's full capability description item by item. Capability must support a form in which multiple capabilities collapse into one advertisable summary; otherwise cross-domain routing degenerates into full replication.

3.4. Delivery and Decision

3.4.1. REQ-6: Local Forwarding Decisions

Every forwarding decision MUST be made locally, based on datagram-visible information plus locally maintained state; no centralized per-request routing decision point is assumed.

Rationale: A centralized per-request routing decision point brings both availability risk (single point of failure) and a scalability ceiling. A scalable system requires decisions to be pushed down to the local level.

3.4.2. REQ-7: Real-Time State Decided by Its Holder

Any matching or selection that depends on real-time state MUST be made by the entity that actually holds that real-time state. For example, load and availability are attributes whose true value only the handler itself knows at the current moment.

Rationale: An intermediary can only infer real-time state through stale, indirect, possibly unsynchronized information. If an intermediary selects on the handler's behalf, it may pick a handler that looks idle in the directory but has just taken a heavy job. The only reliable location for a real-time-state decision is the holder of that state.

3.4.3. REQ-8: Delivery Endpoint Declared by Handler Policy

When registering its capability, a handler MUST be able to declare its desired interaction policy, in particular the delivery endpoint: either the infrastructure delivers the intent directly to the handler, which then decides whether to connect back to the requester; or the infrastructure returns the reachable handler's information to the requester, which then initiates the connection.

Rationale: The root cause of this policy declaration is endpoint reachability (NAT/firewall traversal), not arbitrary handler preference. The policy is the explicit declaration; reachability is the underlying driver. If the handler sits behind a firewall, the requester cannot initiate a connection to it even if the infrastructure returns the handler's information, so only the handler can connect back to the requester. Conversely, if the requester sits behind a firewall, the handler cannot connect to the requester, so only the requester can connect to the handler. Who connects to whom is therefore determined by reachability topology, and only the handler knows its own reachability conditions at registration time, so the delivery endpoint must be declared by the handler. Moreover, for one-shot delivery (no subsequent session after delivery), requiring the infrastructure to return a candidate set is pure waste: the delivery has already reached the handler, and returning reachability information afterward is like a mail carrier who has arrived at the recipient's door running back to tell the sender the door number. When the policy is "return to requester," the infrastructure may return multiple matching handlers, from which the requester chooses; when the policy is "direct delivery," the infrastructure need not return any candidate, because the delivery itself completes the locating.

3.4.4. REQ-9: Session-Agnostic Delivery

The delivery layer of the coordination substrate MUST NOT presume whether a persistent session exists between requester and handler; the delivery mechanism itself MUST remain unchanged regardless of whether a session is established after delivery.

Rationale: The delivery layer's job is to get the intent datagram delivered; whether a session is established afterward is a matter between the endpoints. If the delivery layer presumes a follow-up session must exist, or must not, it forces an endpoint interaction pattern into the infrastructure and breaks its generality. Just as IP remains connectionless and stateless toward upper layers (whether carrying TCP or UDP, IP forwarding is unchanged), the delivery layer should remain session-agnostic, leaving session establishment entirely to the endpoints.

3.5. Semantic and Inference Boundary

3.5.1. REQ-10: Matching Based on Routable Identifiers

Capability matching MUST be performed on routable identifiers; the forwarding nodes of the coordination substrate MUST NOT be required to understand the semantics of the task itself.

Rationale: Semantic understanding depends on task context, which lives at the endpoints (requester and handler), not at forwarding nodes. If the forwarding layer must interpret semantics to forward, every forwarding node bears a semantic-understanding burden, and reasoning is forced into the forwarding path, which destroys determinism, predictability, and performance. Semantic heterogeneity (different domains expressing the same capability differently) is itself a problem to be aligned at the endpoints or at domain boundaries. It should not be dissolved by making every forwarding node understand semantics, because that increases the forwarding layer's burden without actually eliminating the heterogeneity.

3.5.2. REQ-11: Deterministic Forwarding, No Data-Path Inference

Forwarding nodes MUST NOT be required to perform inference (e.g., LLM inference) when making forwarding decisions on the data path; forwarding decisions MUST be deterministic, predictable, and minimal-cost.

Rationale: Inference on the data path pushes up forwarding latency, requires every forwarding node to have inference capability (raising the deployment threshold and operational cost), and makes forwarding behavior unpredictable and hard to debug and audit. The forwarding layer should be positioned like IP forwarding: deterministic lookup and hop-by-hop forwarding, with every step that needs intelligence left to the endpoints.

3.6. Namespace and Isolation

3.6.1. REQ-12: Routable Hierarchical Namespace

Capability MUST be expressible as an aggregable hierarchical namespace supporting prefix matching.

Rationale: Prefix matching plus hierarchical aggregation is the mechanism prerequisite for cross-domain summarized advertisement (Section 3.3.2) and bounded local state (Section 3.3.1) to hold simultaneously. Without an aggregable namespace there is nothing to summarize; without prefix matching there is no way to direct a request correctly without holding the full map.

3.6.2. REQ-13: Isolation and Cross-Domain Authorization

The coordination substrate MUST allow any organization to isolate its capability namespace from others; interoperation across organizational boundaries MUST be explicitly authorized and policy-controlled.

Rationale: Isolation at organizational boundaries is a hard security and governance requirement. If the coordination layer defaults to global visibility (for example, replicating the capability directory across the whole network), an organization cannot participate in collaboration without exposing its internal capabilities, which suppresses cross-organization collaboration. This does not contradict Section 3.1.1 (open participation); it is its precondition. Only when isolation is the default and cross-domain authorization is explicit will an organization participate openly. Isolation should therefore hold naturally at the capability-namespace layer: reachable within a domain, unreachable across domains by default, with cross-domain interoperation enabled by explicit authorization rather than by layering access control on top of a default-open posture. Namespace-level isolation also provides a low-cost private collaboration domain, because the reachability boundary is constituted by the namespace itself and requires no separate isolation-tunnel mechanism.

3.7. Dynamism

3.7.1. REQ-14: Bounded Convergence

The coordination substrate MUST support the addition, update, and withdrawal of capabilities, and MUST exhibit bounded convergence behavior (such changes propagate and stabilize within a predictable bound).

Rationale: Agent capabilities are dynamic. If changes propagate without bound, requesters see inconsistent capability views at different moments, and matching results become indeterminate.

3.8. Reachability

3.8.1. REQ-15: Delivery Reachability

The coordination substrate MUST be able to deliver a request to any registered handler.

Rationale: This is the fundamental reason the coordination layer exists. Locating is worthless if the request cannot ultimately arrive.

3.8.2. REQ-16: Return-Path Reachability

A handler MUST be able to deliver execution results back to the requester endpoint indicated in the request; this return path is not required to traverse the coordination infrastructure's forwarding data plane.

Rationale: Request-response is the minimal closed loop of coordination. Not binding the return path to the coordination data plane lets it reuse existing transport protocols and reduces coupling.

3.9. Location of Intent Decomposition

3.9.1. REQ-17: Intent Decomposed at the Originator

The decomposition from "naturally expressed task intent" to "routable capability identifier" MUST occur at the originating end; the coordination infrastructure MUST NOT be required to perform this decomposition internally.

Rationale: Intent decomposition depends on the requester's full task context (what it actually wants, under what constraints), information only the endpoint possesses. Putting decomposition inside the network hands the step that most needs context to the layer with the least context.

4. Security Considerations

The aggregation and summarization in Section 3.3.1 and Section 3.3.2 introduce the risk of misleadingly aggregated capability. The routable identifiers in Section 3.5.1 and Section 3.6.1 need protection against forgery and poisoning. The cross-domain authorization and namespace isolation in Section 3.6.2 involve policy enforcement and unauthorized access. The originator-side decomposition in Section 3.9.1 touches the privacy boundary of intent. This document states requirements only and prescribes no security mechanism, but these requirements must be compatible with identity, trust, and authorization mechanisms.

5. IANA Considerations

This document has no IANA actions.

6. Informative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", , <https://www.rfc-editor.org/info/rfc8174>.