]> Tsinghua University

Beijing 100084 China cuiyong@tsinghua.edu.cn http://www.cuiyong.net/

Zhongguancun Laboratory

Beijing 100094 China chaoyh@zgclab.edu.cn

Zhongguancun Laboratory

Beijing 100094 China ducg@zgclab.edu.cn

Applications and Real-Time Area Network Working Group AI Agent Semantic Routing Agent Communication Application-Layer Routing 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.

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.

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

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.

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

Use Cases and Requirements

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.

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.

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 .

Architecture

Functional Architecture The semantic routing architecture contains four logical roles. shows their relationships.

Functional Architecture of Semantic Routing | 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 ]]>

The roles shown in 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.

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.

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.

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.

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.

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.

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

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.

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

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.
• 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 . A binding or deployment SHOULD define an acceptable clock-skew tolerance.

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

Semantic Routing Procedure

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.

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

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.

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.

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.

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.

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.

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

Relationship to Other Work The AI agent protocol framework in 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 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 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 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.

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.

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

Operational Considerations

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.

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.

Security Considerations The security considerations guidance in 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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Privacy Considerations The privacy guidance in 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. 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.

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 . This document therefore has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. A2A Protocol Project Five9 Cisco AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents With Names (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. China Telecom China Telecom Huawei Technologies New H3C Technologies This document presents an architectural framework for dynamic multi- agent collaboration from an infrastructure perspective. It outlines the network requirements introduced by large-scale agents collaboration, and proposes a systematic approach to enabling Dynamic Multi-agent Secured Collaboration (DMSC) through infrastructure capabilities. The architecture focuses on how network control and forwarding functions can actively participate in agent collaboration.

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.

Semantic Routing Example | | | | |--Get Profiles->| | | |<--A and B------| | | | | | | |--Eligibility and constraints | | | Remove Target A | | |--Match preferences and select | |<--Decision B---| | | | | | | |--------------------Invoke B---------------------->| |<-------------------Task Result--------------------| ]]>

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.

Information Model Example The following JSON is a non-normative illustration of Routing Input. It does not define an HTTP endpoint or protocol binding. A successful Routing Decision identifies one target: 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.

Acknowledgments The authors thank the participants who provided comments on the scope and terminology of application-layer semantic routing for AI agent communication.