Network Working Group Y. Cui Internet-Draft Tsinghua University Intended status: Informational Y. Chao Expires: 29 April 2027 C. Du Zhongguancun Laboratory 26 October 2026 Semantic Routing for AI Agent Communication draft-cui-semantic-routing-ai-agent-communication-00 Abstract AI agents often know the intended outcome of a task without knowing which agent, model, tool, workflow, or service should process it. This document describes an application-layer semantic routing framework that selects one Processing Target from task intent, execution context, target capabilities, constraints, and local policy. It defines a common operation-level information model and externally observable selection behavior that protocol bindings can preserve. Semantic matching is implementation-specific. This document does not define task decomposition, multi-agent orchestration, network-layer routing, target discovery, target invocation, or a new agent communication protocol. 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 29 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Cui, et al. Expires 29 April 2027 [Page 1] Internet-Draft AI Semantic Routing October 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals and Scope . . . . . . . . . . . . . . . . . . . . . 3 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Use Cases and Requirements . . . . . . . . . . . . . . . . . 6 3.1. Processing Target Selection . . . . . . . . . . . . . . . 6 3.2. Secure Fallback . . . . . . . . . . . . . . . . . . . . . 6 3.3. Semantic Routing Behavior . . . . . . . . . . . . . . . . 6 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Functional Architecture . . . . . . . . . . . . . . . . . 6 4.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Basic Interaction . . . . . . . . . . . . . . . . . . . . 8 4.4. Trust Boundaries . . . . . . . . . . . . . . . . . . . . 8 4.5. Local Target View . . . . . . . . . . . . . . . . . . . . 8 5. Semantic Routing Information Model . . . . . . . . . . . . . 8 5.1. Semantic Routing Input . . . . . . . . . . . . . . . . . 9 5.2. Target Profile . . . . . . . . . . . . . . . . . . . . . 10 5.3. Routing Decision . . . . . . . . . . . . . . . . . . . . 11 5.4. Routing Error . . . . . . . . . . . . . . . . . . . . . . 12 6. Semantic Routing Procedure . . . . . . . . . . . . . . . . . 13 6.1. Required Processing Order . . . . . . . . . . . . . . . . 13 6.2. Authentication and Input Validation . . . . . . . . . . . 13 6.3. Candidate Construction . . . . . . . . . . . . . . . . . 14 6.4. Constraint Evaluation . . . . . . . . . . . . . . . . . . 14 6.5. Semantic Matching . . . . . . . . . . . . . . . . . . . . 14 6.6. Policy, Preferences, and Selection . . . . . . . . . . . 15 6.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Integration with Existing Protocols . . . . . . . . . . . . . 15 8. Relationship to Other Work . . . . . . . . . . . . . . . . . 16 9. Extensibility and Interoperability . . . . . . . . . . . . . 17 10. Internationalization Considerations . . . . . . . . . . . . . 17 11. Operational Considerations . . . . . . . . . . . . . . . . . 17 11.1. Information Lifecycle and Disclosure . . . . . . . . . . 17 11.2. Non-Determinism and Monitoring . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12.1. Authentication and Authorization . . . . . . . . . . . . 18 12.2. Target Enumeration and Policy Probing . . . . . . . . . 18 Cui, et al. Expires 29 April 2027 [Page 2] Internet-Draft AI Semantic Routing October 2026 12.3. Target Profile Integrity . . . . . . . . . . . . . . . . 18 12.4. Semantic Manipulation . . . . . . . . . . . . . . . . . 19 12.5. Confused Deputy and Tenant Isolation . . . . . . . . . . 19 12.6. Endpoint Safety . . . . . . . . . . . . . . . . . . . . 19 12.7. Decision Integrity and Replay . . . . . . . . . . . . . 19 12.8. Denial of Service . . . . . . . . . . . . . . . . . . . 20 12.9. Fallback and Audit . . . . . . . . . . . . . . . . . . . 20 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 15.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. End-to-End Semantic Routing Example . . . . . . . . 22 A.1. Information Model Example . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction AI agents communicate with agents, models, tools, workflows, and services across different platforms and administrative domains. Static configuration, broadcast queries, and repeated trial invocations can select unsuitable targets, expose task context unnecessarily, or add avoidable communication and processing overhead. Semantic routing addresses this problem at the application layer. A Semantic Routing Function (SRF) evaluates a Task Intent together with Execution Context, Routing Constraints, Target Profiles, and local policy. It produces a Routing Decision identifying a suitable Processing Target. The Requester can then hand the task to that target using an invocation protocol supported by the target. This document defines common information and behavior at the semantic routing boundary. A protocol binding can use this framework without adopting a particular semantic-matching implementation. 1.1. Goals and Scope This document enables a Requester to express a task without naming a predetermined target and enables an SRF to select one authorized target that satisfies all mandatory requirements. It describes logical roles, Routing Input, Target Profiles, Routing Decisions, Routing Errors, operation-level processing, and secure fallback. Cui, et al. Expires 29 April 2027 [Page 3] Internet-Draft AI Semantic Routing October 2026 Publication, discovery, and distribution of Target Profiles are outside scope. Target invocation is also outside scope. Existing description mechanisms, including Agent Cards, can supply target information, and existing agent communication protocols can invoke the selected target. This document defines the information exchanged at the semantic routing boundary, the distinction between mandatory constraints and optional preferences, the order of eligibility and semantic evaluation, one-target decision semantics, and errors. It does not define the SRF's internal algorithm. If a Requester already has sufficient target information, policy, and authorization to select a target locally, it does not need to use an SRF. 1.2. Non-Goals Semantic routing as specified here does not define IP routing, packet forwarding, reachability advertisement, path computation, name resolution, transport-layer load balancing, registry federation, topology discovery, target invocation, task decomposition, workflow planning, multi-agent orchestration, or any particular matching or semantic-information-management implementation. The term "routing" in this document refers only to application-layer selection of a Processing Target for a task. It does not describe how network packets reach that target. 2. Conventions and 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms: * *Requester:* An entity that asks an SRF to select a Processing Target. A Requester can be an AI agent, an application, or an orchestration component. * *Semantic Routing Function (SRF):* An application-layer function that evaluates Routing Input, Target Profiles, and local policy to produce a Routing Decision or Routing Error. * *Routing Input:* The Task Intent, Execution Context, Routing Constraints, and Routing Preferences submitted for one Routing Operation. Cui, et al. Expires 29 April 2027 [Page 4] Internet-Draft AI Semantic Routing October 2026 * *Processing Target:* An agent, model, tool, workflow, or application service capable of processing a task. * *Task Intent:* A description of the outcome to be achieved. A Task Intent describes the work rather than naming a specific Processing Target. * *Execution Context:* Information relevant to a Routing Decision, such as language, domain, content type, data classification, location, or deadline. * *Routing Constraint:* A condition that a Processing Target is required to satisfy. Examples include a required capability, authorization, trust level, data residency, or permitted provider. * *Routing Preference:* A non-mandatory condition used to order otherwise eligible targets. A Routing Preference cannot override a required capability, Routing Constraint, or Eligibility Policy. * *Eligibility Policy:* Local authorization, security, privacy, or administrative policy that determines whether a Candidate Target may be considered for a Requester. Failure to satisfy Eligibility Policy makes a target ineligible. * *Selection Policy:* Local policy used to order or choose among Eligible Targets. Selection Policy cannot make an ineligible target eligible. * *Target Profile:* A machine-readable description of a Processing Target, including its capabilities and policy-relevant attributes. * *Target Information Source:* A system or local configuration that supplies Target Profiles and operational state to an SRF. This document does not define its publication or discovery protocol. * *Candidate Target:* A Processing Target considered by an SRF before all mandatory requirements have been evaluated. * *Eligible Target:* A Candidate Target that satisfies all required capabilities, Routing Constraints, and applicable Eligibility Policy. * *Routing Decision:* The result produced by an SRF, identifying a selected Processing Target and associated decision metadata. * *Routing Error:* The result produced when an SRF cannot complete a Routing Operation or cannot select an Eligible Target. Cui, et al. Expires 29 April 2027 [Page 5] Internet-Draft AI Semantic Routing October 2026 * *Semantic Match:* An implementation-specific assessment of how well a Processing Target is suited to a Task Intent. A Semantic Match is not an authorization, identity, trust, or security assertion. * *Target View:* The set of Processing Targets and policy-permitted target information visible to one SRF for one Requester. A Target View is local and need not be globally complete. * *Routing Operation:* One evaluation of Routing Input that returns one selected Processing Target or a Routing Error. A Routing Operation does not split or execute the task. 3. Use Cases and Requirements 3.1. Processing Target Selection A Requester needs an agent, model, tool, workflow, or service for a task but does not know which available target satisfies its semantic, authorization, input, and data-handling requirements. It sends intent and constraints to an SRF, which returns an Eligible Target. 3.2. Secure Fallback The selected target becomes unavailable. A Requester can request a new Routing Decision, but the new target must continue to satisfy all original required capabilities and Routing Constraints. Fallback does not weaken security or privacy requirements. 3.3. Semantic Routing Behavior For one Routing Operation, the framework distinguishes mandatory requirements from non-mandatory preferences, applies eligibility checks before semantic selection, and returns either one Processing Target or one Routing Error. A Routing Operation does not decompose a task, create subtasks, or assign work to multiple targets. Selection uses the SRF's local Target View and does not require a global routing table or convergence among SRFs. The normative processing behavior is defined in Section 6. 4. Architecture 4.1. Functional Architecture The semantic routing architecture contains four logical roles. Figure 1 shows their relationships. Cui, et al. Expires 29 April 2027 [Page 6] Internet-Draft AI Semantic Routing October 2026 +-----------------------+ Target Profile / State | Target Information |----------------------------+ | Source | | +-----------------------+ v +-------------------+ +-----------------------+ (1) Input | Semantic Routing | | Requester |----------------->| Function (SRF) | | Agent / Application / |<-----------------| | | Orchestrator | (2) Decision | Candidate set | +-----------+-----------+ | Eligibility check | | | Semantic match | | Invocation | Target selection | | using an existing +---------+---------+ | protocol | | | v v +---------------------------------------------------------------+ | Processing Targets | | Agent A Agent B Agent N Model Tool Workflow | +---------------------------------------------------------------+ (1) Routing Input Task Intent + Execution Context + Constraints + Preferences (2) Routing Decision Selected Target + Operation + Endpoint + Validity + Decision Metadata Figure 1: Functional Architecture of Semantic Routing The roles shown in Figure 1 are: * *Requester:* Creates Routing Input, consumes a Routing Decision, and invokes the selected target using an existing protocol. * *Semantic Routing Function:* Validates input, enforces constraints and policy, evaluates semantic suitability, and selects one target. * *Target Information Source:* Supplies Target Profiles and operational state. Its protocol is not defined here. * *Processing Target:* Authorizes and performs the selected operation using a separate invocation protocol. These roles are logical. Multiple roles can be implemented by one system, and one role can be distributed across multiple systems. Cui, et al. Expires 29 April 2027 [Page 7] Internet-Draft AI Semantic Routing October 2026 4.2. Deployment The SRF is the logical component responsible for Routing Decisions; it is not a required algorithm or separate network element. It can be embedded in a Requester, agent host, gateway, or orchestration platform, or deployed as an independent service. Deployment does not change the information-model semantics. The Requester or an application-specific evaluator, rather than the SRF, determines whether a completed task satisfies the original intent. 4.3. Basic Interaction The Requester sends Routing Input to the SRF after relevant Target Profiles are available and before a new task is invoked. After authorization, validation, mandatory-requirement evaluation, and semantic selection, the SRF returns a Routing Decision for one invocation. Invocation uses a separate existing protocol. In an integrated gateway, the decision can remain internal and the gateway can invoke the selected target on the Requester's behalf. 4.4. Trust Boundaries The Requester, SRF, Target Information Source, and Processing Target can be operated by different administrative domains. An SRF MUST NOT assume that a Target Profile is trustworthy merely because it is syntactically valid. The SRF MUST apply local procedures for authenticating profile sources and evaluating capability and security claims. 4.5. Local Target View The Target View is the SRF's logical view of Processing Targets; it does not represent IP links or forwarding paths. Agent discovery and update distribution are outside scope. The SRF uses only the targets and policy attributes available in its local view for the authenticated Requester. The routing boundary can be exposed across administrative domains, but the decision is local. This document does not define a global target catalogue, routing information exchange, or convergence between SRFs. Different SRFs can therefore select different targets from the same Task Intent. 5. Semantic Routing Information Model This section defines the abstract information model. A protocol binding can carry this information, but no standalone binding is defined in this document. Cui, et al. Expires 29 April 2027 [Page 8] Internet-Draft AI Semantic Routing October 2026 5.1. Semantic Routing Input Each Routing Input describes one Routing Operation. It does not contain a task-decomposition plan or a list of agents to be orchestrated. Routing Input contains the following fields: * *routing_id:* A REQUIRED string generated by the Requester to correlate input, decisions, and errors. It MUST be unique within the Requester's active routing operations and MUST NOT contain task content or personal data. It is not an authorization credential, an idempotency key, or a replay-prevention mechanism. * *intent:* A REQUIRED object describing the Task Intent. It contains a REQUIRED description string and MAY contain a required_capabilities array. The description states the desired outcome and SHOULD NOT name a predetermined target. Every entry in required_capabilities is mandatory: an SRF MUST NOT select a target unless that capability is present in, or can be validly derived from, the Target Profile. Capability identifiers SHOULD be absolute URIs when used across administrative domains. A capability that the SRF cannot evaluate is handled as an unsupported Routing Constraint. * *context:* An OPTIONAL object containing Execution Context. This specification defines language, domain, content_types, data_classification, data_location, and deadline. The deadline field, when present, MUST use the Internet date and time format defined by [RFC3339]. * *constraints:* An OPTIONAL array of mandatory Routing Constraints. Each constraint contains a name and a value. The name MUST be an absolute URI as defined by [RFC3986]. If an SRF does not recognize or cannot evaluate a constraint, it MUST return an unsupported_constraint Routing Error. * *preferences:* An OPTIONAL ordered array of Routing Preferences. Earlier elements have higher Requester priority. Each preference contains a URI-valued name and a value. A preference affects ordering only and cannot make an ineligible target eligible. An SRF MAY ignore an unsupported preference; if it does so, the resulting Routing Decision MUST identify that preference in ignored_preferences. Cui, et al. Expires 29 April 2027 [Page 9] Internet-Draft AI Semantic Routing October 2026 Context describes the task but is not a mandatory rule by itself. If a language, location, classification, or other context value must be enforced, the Requester MUST also express that requirement as a Routing Constraint. Security-critical requirements MUST NOT be left for the SRF to infer from free-form intent text. 5.2. Target Profile A Target Profile is the normalized target information used by an SRF; it is not a new discovery mechanism. It can be derived from an existing description such as an Agent Card [A2A], a catalogue, or local configuration. The mapping from those sources is outside scope. A Target Profile used by an SRF contains the following fields: * *target_id:* A REQUIRED stable identifier within the scope of the Target Information Source. * *profile_version:* A REQUIRED opaque value that changes whenever information relevant to routing or policy evaluation changes. * *target_type:* A REQUIRED value identifying the kind of target. This document defines agent, model, tool, workflow, and service. * *description:* An OPTIONAL human-readable description of the target. An SRF MAY use this field for semantic matching but MUST treat it as untrusted input. * *capabilities:* A REQUIRED array of identifiers describing functions supported by the target. Capability identifiers SHOULD be absolute URIs when used across administrative domains. Capability claims are not proof that the target is authorized, trustworthy, or currently able to perform an operation. * *operations:* An OPTIONAL array of callable operations. Each operation has an operation_id, a description, and optional input and output media types. * *languages:* An OPTIONAL array of language tags as defined by [RFC5646]. * *security_attributes:* An OPTIONAL object containing policy- relevant claims, such as an issuer, assurance level, authentication method, or data-handling property. These claims are deployment-specific unless another specification defines their semantics and validation. Cui, et al. Expires 29 April 2027 [Page 10] Internet-Draft AI Semantic Routing October 2026 * *status:* A REQUIRED value indicating operational status. This document defines active, unavailable, and withdrawn. Only an active target is eligible for a new Routing Decision. * *endpoint:* An OPTIONAL URI as defined by [RFC3986], or an endpoint reference used by an authorized Requester to contact the target. An SRF MUST NOT dereference an endpoint solely because it appears in a Target Profile. * *expires_at:* An OPTIONAL timestamp after which the Target Profile is not valid for a new Routing Decision. The timestamp MUST use the format defined by [RFC3339]. A deployment using this field SHOULD define an acceptable clock-skew tolerance. The publication, discovery, update, and withdrawal of Target Profiles are not specified by this document. 5.3. Routing Decision The decision identifies exactly one Processing Target for one Routing Operation. A successful Routing Decision contains the following fields: * *routing_id:* The REQUIRED identifier from the Routing Input. * *decision_id:* A REQUIRED identifier generated by the SRF for audit and correlation. It MUST be unique within the SRF's decision-retention scope and MUST NOT be treated as an authorization credential. * *selected_target:* A REQUIRED object containing the target_id, profile_version, and target_type, and, when applicable, operation_id and endpoint, of the selected Processing Target. * *reason_codes:* An OPTIONAL array of machine-readable identifiers describing factors in the decision. Reason codes SHOULD be absolute URIs when exchanged across administrative domains. They provide diagnostic information and MUST NOT be treated as security assertions. * *ignored_preferences:* An array identifying Routing Preferences that were not understood or not applied. This member is REQUIRED when at least one supplied preference was ignored and is otherwise OPTIONAL. Cui, et al. Expires 29 April 2027 [Page 11] Internet-Draft AI Semantic Routing October 2026 * *expires_at:* A REQUIRED timestamp after which the decision MUST NOT be used to initiate a new target invocation. The timestamp MUST use the format defined by [RFC3339]. A binding or deployment SHOULD define an acceptable clock-skew tolerance. 5.4. Routing Error A Routing Error contains the following fields: * *routing_id:* The Routing Input identifier, when it was present and could be safely parsed. * *error_code:* A REQUIRED machine-readable identifier. This document defines invalid_input, not_authorized, unsupported_constraint, no_eligible_target, and temporarily_unavailable. Extension error codes SHOULD be absolute URIs when exchanged across administrative domains. * *reason:* An OPTIONAL human-readable explanation intended for an authorized operator or Requester. It MUST NOT reveal targets or policy information that the Requester is not authorized to learn. * *retryable:* A REQUIRED Boolean indicating whether repeating the Routing Operation without changing its mandatory requirements might succeed later. * *retry_after:* An OPTIONAL [RFC3339] timestamp before which the Requester SHOULD NOT retry. It MUST be omitted unless retryable is true. The error codes have the following meanings: * *invalid_input:* The Routing Input is malformed or violates an implementation limit. * *not_authorized:* The Requester is not authorized to perform semantic routing or to obtain an applicable Target View. * *unsupported_constraint:* A Routing Constraint or required capability is unknown or cannot be evaluated. * *no_eligible_target:* No target satisfies all required capabilities, Routing Constraints, and Eligibility Policy. * *temporarily_unavailable:* The SRF cannot complete selection because required information or resources are temporarily unavailable. Cui, et al. Expires 29 April 2027 [Page 12] Internet-Draft AI Semantic Routing October 2026 6. Semantic Routing Procedure 6.1. Required Processing Order An SRF MUST behave as if it performs the following steps in order: 1. Establish the Requester's security context and authorized Target View. 2. Validate the Routing Input and identify unsupported mandatory requirements. 3. Construct a Candidate Target set from valid, active, and visible Target Profiles, and apply Eligibility Policy. 4. Evaluate all required_capabilities and Routing Constraints. A target that fails any one of them is removed from further consideration. 5. Evaluate Semantic Match for the remaining Eligible Targets. 6. Apply Routing Preferences and Selection Policy only among Eligible Targets. 7. Return one Routing Decision, or return one Routing Error if no selection can be made. An implementation MAY combine, cache, index, or reorder internal computations for efficiency, but its externally observable result MUST be equivalent to the order above. In particular, a Semantic Match, Routing Preference, or Selection Policy MUST NOT restore a target removed by Eligibility Policy or a mandatory requirement. 6.2. Authentication and Input Validation An SRF MUST establish the Requester's security context before applying requester-specific authorization. A deployment that permits anonymous requests treats an anonymous Requester as a distinct principal with an appropriately restricted Target View. Authorization applies independently to routing information, Target Profile visibility, and target invocation. The SRF MUST reject a known field whose syntax or type is malformed and SHOULD limit message size, nesting, and field counts. Unknown optional members are handled as described in Section 9. Cui, et al. Expires 29 April 2027 [Page 13] Internet-Draft AI Semantic Routing October 2026 If a Routing Constraint or required capability is not recognized or cannot be evaluated, the SRF MUST stop processing and return an unsupported_constraint Routing Error. If a Routing Preference is not recognized, the SRF MAY ignore it; a successful decision then includes it in ignored_preferences. 6.3. Candidate Construction The SRF obtains Target Profiles from one or more Target Information Sources. It MUST exclude profiles that are expired, unavailable, withdrawn, outside the Requester's authorized visibility, or disallowed by Eligibility Policy. It SHOULD verify profile provenance and integrity before using capability or security claims. Candidate Construction means establishing which locally known targets can be considered; it does not mean decomposing the task or creating subtasks. 6.4. Constraint Evaluation The SRF MUST evaluate all required capabilities and Routing Constraints before semantic matching and final selection. A target that fails any required capability or Routing Constraint is not an Eligible Target and MUST NOT be selected. Each mandatory requirement therefore acts as a veto that semantic suitability cannot override. Eligibility Policy applies even when it is not present in the Routing Input. Requester-provided preferences, Selection Policy, and Semantic Match results MUST NOT override Eligibility Policy. 6.5. Semantic Matching The SRF evaluates Task Intent and Execution Context against Target Profiles. Matching and ranking are implementation-specific and can consider capability, description, domain, language, operation, and media-type compatibility. This document does not mandate a metric, threshold, weight, or ranking formula. Text contained in an intent or Target Profile is data, not an instruction to change SRF security policy. An implementation performing automated semantic matching MUST isolate untrusted text from policy control and MUST apply authorization and Routing Constraints independently of that text. Cui, et al. Expires 29 April 2027 [Page 14] Internet-Draft AI Semantic Routing October 2026 6.6. Policy, Preferences, and Selection After semantic matching, the SRF applies Selection Policy and Routing Preferences to the Eligible Targets. The order of preferences indicates Requester priority, but Selection Policy determines the final ordering and can break ties. Selection Policy cannot make an ineligible target eligible. The SRF selects exactly one Eligible Target and returns it as selected_target. It does not return a ranked set for multi-agent execution. The SRF MUST assign a finite expiration time to the Routing Decision. If no Eligible Target exists, the SRF MUST return a no_eligible_target Routing Error. It MUST NOT remove, weaken, or reinterpret a required capability or Routing Constraint in order to produce a result. 6.7. Fallback If the selected target becomes unavailable, the Requester MAY start a new Routing Operation using the original Task Intent, Execution Context, required capabilities, and Routing Constraints. The SRF MUST evaluate the current Target View and return one new target or an error. An implementation performing automatic fallback MUST preserve all original required capabilities and Routing Constraints. It MUST NOT retry a task with side effects unless the target invocation is known to be idempotent or an idempotency mechanism is used. A Routing Decision records a selection, not a reservation of target capacity. Between decision and invocation, the Target Profile, target status, or applicable policy can change. The Requester MUST NOT use an expired decision, and the Processing Target or its gateway MUST perform current authorization at invocation time. A binding can define stronger reservation or freshness mechanisms, but they are outside this framework. 7. Integration with Existing Protocols This document defines a semantic routing information model and processing behavior, not a new standalone routing protocol. A binding to an existing protocol can carry Routing Input to an SRF and return a Routing Decision or error. The binding defines placement, negotiation, serialization, transport, authentication, and error mapping. Cui, et al. Expires 29 April 2027 [Page 15] Internet-Draft AI Semantic Routing October 2026 Existing target-description mechanisms can supply Target Profiles. For example, an Agent Card can provide identity, skills, supported interfaces, security schemes, and interaction modes. The SRF can combine those fields with Eligibility Policy, Selection Policy, and operational information; this document does not change the Agent Card or duplicate agent discovery. After selection, an existing agent communication protocol invokes the selected target. This document does not redefine that protocol's task messages, lifecycle, streaming, cancellation, notification, authentication, or error handling. A binding MUST preserve the Routing Decision and Routing Error semantics defined by this document. It can map them to protocol- specific response fields or status codes, but that mapping MUST NOT turn an unsupported mandatory requirement into a successful decision or disclose information beyond the Requester's authorization. 8. Relationship to Other Work The AI agent protocol framework in [I-D.rosenberg-agentproto-usecases] describes communication relationships among users, agents, and APIs and identifies routing and connection as part of agent-to-agent communication. This document is narrower: it describes the boundary at which one task intent is mapped to one Processing Target, independently of the protocol later used to contact that target. The DAWN requirements in [I-D.king-dawn-requirements] concern discovering and characterizing agents, workloads, and named entities across administrative boundaries. DAWN-like mechanisms can act as Target Information Sources. This document starts after relevant Target Profiles are available and does not define their discovery or distribution. The DMSC architecture in [I-D.li-dmsc-inf-architecture] includes semantic routing as part of a broader infrastructure for dynamic, secure multi-agent collaboration. This document defines a local, application-layer, one-target Routing Operation and does not define network forwarding, collaboration paths, or multi-agent orchestration. The A2A protocol [A2A] defines Agent Cards and agent communication operations. An Agent Card can contribute information to a Target Profile, and A2A can invoke a selected agent. This document neither modifies A2A nor requires it; other description and invocation protocols can be used. Cui, et al. Expires 29 April 2027 [Page 16] Internet-Draft AI Semantic Routing October 2026 9. Extensibility and Interoperability Future specifications can define new context fields, target types, capability identifiers, constraints, preferences, reason codes, and error codes. Cross-domain extensions SHOULD use absolute URI identifiers and MUST document their syntax, semantics, comparison rules, and security considerations. In particular, an extension target type or context-field name SHOULD be represented by an absolute URI rather than by a new unqualified string. Unknown optional context fields and information-model members MUST be ignored unless otherwise specified. A known member with an invalid type or syntax produces an invalid_input Routing Error. Unsupported preferences MAY be ignored and are then reported in ignored_preferences; unsupported constraints and required capabilities MUST NOT be ignored. 10. Internationalization Considerations Task descriptions, target descriptions, and human-readable error reasons can contain natural language. A protocol binding MUST define a Unicode-compatible character encoding and MUST preserve language tags carried in the information model. Language values use the tags defined by [RFC5646]. Implementations MUST NOT assume that free-form text, identifiers, or language tags can be compared using locale- dependent case conversion unless the specification defining that field explicitly permits it. 11. Operational Considerations 11.1. Information Lifecycle and Disclosure Target Profiles are versioned, refreshed, withdrawn, or expired by their source. The SRF MUST NOT use an expired or withdrawn profile. Routing input creates one operation-level decision; task content is sent separately to the selected target. The Requester MUST NOT initiate a new invocation from an expired decision. Logs SHOULD use privacy-preserving correlation identifiers and record relevant policy and profile versions without complete task content. The routing_id and decision_id fields support correlation only. Implementations requiring invocation idempotency, replay protection, or capacity reservation need separate mechanisms provided by a binding or invocation protocol. Cui, et al. Expires 29 April 2027 [Page 17] Internet-Draft AI Semantic Routing October 2026 11.2. Non-Determinism and Monitoring Semantic matching can be non-deterministic; interoperability depends on common input and result semantics, not identical rankings. Deployments SHOULD monitor Target Profile and matching changes and record the information and policy versions used for each decision. 12. Security Considerations The security considerations guidance in [RFC3552] applies. Semantic routing introduces a decision point that can direct tasks and potentially sensitive context to different entities. A compromised or manipulated SRF can therefore cause unauthorized disclosure or execution even when the underlying transport is secure. 12.1. Authentication and Authorization An SRF MUST authenticate Requesters when routing information, target visibility, or local policy depends on identity. It MUST enforce authorization before revealing target identifiers, endpoints, capabilities, or policy attributes. Selection of a target MUST NOT be treated as authorization to invoke that target; the target or its gateway performs its own authorization. 12.2. Target Enumeration and Policy Probing Routing responses and errors can be used to infer which targets exist, which capabilities an organization operates, or which constraints and policies caused exclusion. An SRF MUST limit Target Views and response detail according to the Requester's authorization. It SHOULD return indistinguishable errors when distinguishing not_authorized from no_eligible_target would reveal protected information. Rate limiting and audit can reduce repeated probing. 12.3. Target Profile Integrity Target descriptions and capability claims are untrusted unless their source, integrity, and authority have been verified. An attacker can publish a description designed to match many intents or claim a false trust level. An SRF SHOULD authenticate Target Information Sources and SHOULD validate security-relevant claims using evidence independent of free-form descriptive text. Cui, et al. Expires 29 April 2027 [Page 18] Internet-Draft AI Semantic Routing October 2026 12.4. Semantic Manipulation Task Intent, Execution Context, and Target Profile text can contain adversarial content. Automated semantic matching MUST treat them as data and isolate them from policy control. Untrusted natural- language content MUST NOT control constraint or authorization decisions. An attacker can use semantic squatting, capability stuffing, or misleading descriptions to make a target match a broad set of intents. An SRF SHOULD limit which profile sources may assert a capability, SHOULD prefer verified structured capability identifiers over unverified descriptive similarity, and SHOULD detect unexpectedly broad or rapidly changing claims. 12.5. Confused Deputy and Tenant Isolation An SRF or gateway can act with privileges that the Requester does not possess. It MUST NOT use its own broader authority to reveal or invoke a target on behalf of an unauthorized Requester. Authorization context and delegated authority MUST remain bound to the Routing Operation and, where applicable, to the subsequent invocation. Multi-tenant deployments MUST isolate Target Views, policy, credentials, caches, and audit data between tenants. A cached Routing Decision or semantic result created for one tenant MUST NOT be reused for another tenant unless authorization and all policy- relevant inputs are equivalent. 12.6. Endpoint Safety An attacker can supply a target endpoint that refers to an internal service, loopback interface, link-local address, or another restricted resource. An SRF or Requester MUST NOT dereference or invoke a URI solely because it appears in a Target Profile or Routing Decision. Deployments performing automatic dereferencing or invocation MUST validate the URI scheme and destination against an allowlist or equivalent egress policy. 12.7. Decision Integrity and Replay Routing Decisions can be modified or replayed to substitute an attacker-controlled target. The binding transport MUST provide integrity and peer authentication. A Requester MUST validate the routing_id and expires_at values. Deployments crossing trust boundaries SHOULD use signed or otherwise integrity-protected decisions when transport protection does not extend to the decision Cui, et al. Expires 29 April 2027 [Page 19] Internet-Draft AI Semantic Routing October 2026 consumer. Neither routing_id nor decision_id by itself prevents replay. A binding that permits a Routing Decision to authorize or trigger an action MUST provide an independent freshness or replay-protection mechanism. 12.8. Denial of Service Long intent descriptions, deeply nested input, large candidate sets, and expensive model inference can consume significant resources. An SRF SHOULD enforce message-size, nesting, candidate, execution-time, and rate limits. Authentication and inexpensive syntactic validation SHOULD occur before expensive semantic processing. 12.9. Fallback and Audit An SRF MUST preserve all required capabilities and Routing Constraints during fallback. Failure to find an Eligible Target MUST result in an explicit error rather than weakening a mandatory requirement. Security-relevant events SHOULD be auditable, including authentication failure, unsupported constraints, policy denial, target selection, and fallback. Audit records SHOULD identify the applicable policy and Target Profile versions and MUST be protected against unauthorized access and modification. 13. Privacy Considerations The privacy guidance in [RFC6973] applies. Task Intent and Execution Context can disclose user goals, business activity, content type, location, language, security classification, and other sensitive information. The presence of a context label can itself be sensitive. For example, a data_classification value can reveal that a task concerns protected material even when no task content is sent. Data minimization therefore applies to both context values and their field names or extension identifiers. A Requester SHOULD provide only information required for routing. It SHOULD use references, summaries, or classifications instead of complete task content when the SRF does not need that content. An SRF MUST NOT disclose Routing Input to Candidate Targets merely to determine suitability unless the Requester has authorized that disclosure. Cui, et al. Expires 29 April 2027 [Page 20] Internet-Draft AI Semantic Routing October 2026 An SRF SHOULD minimize retention of Task Intent and Execution Context. Logs SHOULD use opaque correlation identifiers and SHOULD redact or omit natural-language content and personal data. Cross- domain deployments SHOULD document data retention, onward disclosure, and the administrative domains involved in selection. Returning target identifiers, endpoints, or detailed reason codes can reveal organizational capabilities and security policy. An SRF SHOULD limit result detail according to Requester authorization and operational need. 14. IANA Considerations This document defines an abstract framework and does not allocate protocol parameters, media types, or URI schemes. Cross-domain extension values use globally unique identifiers as described in Section 9. This document therefore has no IANA actions. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References Cui, et al. Expires 29 April 2027 [Page 21] Internet-Draft AI Semantic Routing October 2026 [A2A] A2A Protocol Project, "Agent2Agent (A2A) Protocol Specification, Version 1.0.0", 2026, . [I-D.king-dawn-requirements] King, D. and A. Farrel, "Requirements for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet- Draft, draft-king-dawn-requirements-02, 19 October 2026, . [I-D.li-dmsc-inf-architecture] Li, X., Wang, A., Liu, B., and C. Lin, "Dynamic Multi- agent Secured Collaboration Infrastructure Architecture", Work in Progress, Internet-Draft, draft-li-dmsc-inf- architecture-07, 22 May 2026, . [I-D.rosenberg-agentproto-usecases] Rosenberg, J. and C. F. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-agentproto- usecases-00, 4 July 2026, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . Appendix A. End-to-End Semantic Routing Example This non-normative example shows one operation-level Routing Decision. A Requester needs to analyze a confidential Chinese cybersecurity report in PDF format. Target A has a high Semantic Match but does not satisfy the data-residency constraint; Target B satisfies the required capability and all Routing Constraints. Cui, et al. Expires 29 April 2027 [Page 22] Internet-Draft AI Semantic Routing October 2026 Requester SRF Info Source Targets | | | | |--Routing Input>| | | | |--Get Profiles->| | | |<--A and B------| | | | | | | |--Eligibility and constraints | | | Remove Target A | | |--Match preferences and select | |<--Decision B---| | | | | | | |--------------------Invoke B---------------------->| |<-------------------Task Result--------------------| Figure 2: Semantic Routing Example The SRF authenticates the Requester and builds a Candidate Target set from its local Target View. It applies authorization and mandatory requirements before semantic selection, so Target A cannot be selected regardless of its semantic suitability. It returns Target B as the single selected target. The Requester invokes Target B using an existing protocol outside this framework. A.1. Information Model Example The following JSON is a non-normative illustration of Routing Input. It does not define an HTTP endpoint or protocol binding. Cui, et al. Expires 29 April 2027 [Page 23] Internet-Draft AI Semantic Routing October 2026 { "routing_id": "route-7f3a", "intent": { "description": "Analyze a Chinese security report for risks", "required_capabilities": [ "https://cap.example/security-analysis" ] }, "context": { "language": "zh", "domain": "cybersecurity", "content_types": ["application/pdf"], "data_classification": "confidential", "data_location": "CN" }, "constraints": [ { "name": "https://policy.example/data-residency", "value": ["CN"] }, { "name": "https://policy.example/trust-level", "value": "verified" } ], "preferences": [ { "name": "https://pref.example/latency", "value": "lower" } ] } A successful Routing Decision identifies one target: Cui, et al. Expires 29 April 2027 [Page 24] Internet-Draft AI Semantic Routing October 2026 { "routing_id": "route-7f3a", "decision_id": "decision-81b2", "selected_target": { "target_id": "agent-security-analysis-01", "profile_version": "profile-20260828-17", "target_type": "agent", "operation_id": "analyze-report", "endpoint": "https://agents.example/security-analysis" }, "reason_codes": [ "https://reason.example/capability-match", "https://reason.example/policy-permitted" ], "expires_at": "2026-08-28T10:05:00Z" } Identifiers under the example domains are illustrative and do not define interoperable capability, constraint, or preference semantics. If no currently available target satisfies the mandatory requirements, an abstract Routing Error could be represented as follows. This JSON remains illustrative; a binding defines its concrete serialization and protocol status mapping. { "routing_id": "route-7f3a", "error_code": "no_eligible_target", "reason": "No target satisfies all mandatory requirements", "retryable": false } Acknowledgments The authors thank the participants who provided comments on the scope and terminology of application-layer semantic routing for AI agent communication. Authors' Addresses Yong Cui Tsinghua University Beijing 100084 China Email: cuiyong@tsinghua.edu.cn URI: http://www.cuiyong.net/ Cui, et al. Expires 29 April 2027 [Page 25] Internet-Draft AI Semantic Routing October 2026 Yihan Chao Zhongguancun Laboratory Beijing 100094 China Email: chaoyh@zgclab.edu.cn Chenguang Du Zhongguancun Laboratory Beijing 100094 China Email: ducg@zgclab.edu.cn Cui, et al. Expires 29 April 2027 [Page 26]