Semantic Routing for AI Agent Communication

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

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

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.1. Functional Architecture

The semantic routing architecture contains four logical roles. Figure 1 shows their relationships.¶

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

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

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

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

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

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

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

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

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

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

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

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

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, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[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, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/rfc/rfc5646>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

15.2. Informative References

[A2A]

A2A Protocol Project, "Agent2Agent (A2A) Protocol Specification, Version 1.0.0", 2026, <https://a2a-protocol.org/v1.0.0/specification/>.

[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, <https://datatracker.ietf.org/doc/html/draft-king-dawn-requirements-02>.

[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, <https://datatracker.ietf.org/doc/html/draft-li-dmsc-inf-architecture-07>.

[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, <https://datatracker.ietf.org/doc/html/draft-rosenberg-agentproto-usecases-00>.

[RFC3552]

Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/rfc/rfc3552>.

[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, <https://www.rfc-editor.org/rfc/rfc6973>.

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

{
  "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:¶

{
  "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
}