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

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

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

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

This document covers the span from "a requester expresses an intent" to "locating a handler that can fulfill that intent." Concretely: the expression and decomposition of intent, the identification and aggregation of capability, the directing of requests (routing), and the matching and selection of candidates. A clarification: in this document, locating a handler is the result of the delivery process, not a separate query-and-return-candidates mechanism. The core action of the coordination substrate is the delivery of the intent request (the data plane); finding the handler is the completion effect of that delivery. Whether the handler's information is returned to the requester, or the intent is delivered directly to the handler, is a policy declared by the handler at registration time (see ), not an inherent shape of the locating action. This document does not cover: the interaction protocol after routing (task execution, session establishment, the message formats of result delivery), the schema of any capability description language, or identity, trust, and authorization mechanisms (which are handled elsewhere, but with which the requirements here must coexist).

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

Any agent, regardless of framework, language, or deployment environment, MUST be able to register its capabilities and invoke others without establishing bilateral relationships with each potential partner in advance. Rationale: Requiring bilateral pre-registration brings back the O(N^2) integration cost verbatim. A shared coordination layer should eliminate pairwise agent integration structurally, just as IP eliminated pairwise host-reachability agreements.

The coordination substrate MUST support heterogeneous handler types (LLM-based, deterministic programs, wrapped legacy services) without requiring the substrate to be redesigned when handler types change. Rationale: In real deployments, capabilities are provided by many technology stacks. If the coordination layer is sensitive to handler type, it degenerates into one routing mechanism per type.

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

The coordination mechanism MUST NOT require any single node (or gateway) to maintain state proportional to the total number of agents. Rationale: If a node's state grows linearly with the total agent population, that node becomes both a scaling ceiling and a single point of failure. A scalable mechanism makes each node's state proportional to what it locally governs or needs, not to the global total.

Capability information MUST be summarizable and aggregable, so that cross-domain (cross-organization, cross-administrative-boundary) capability advertisement is decoupled from the total agent population. Rationale: Cross-domain advertisement cannot carry every handler's full capability description item by item. Capability must support a form in which multiple capabilities collapse into one advertisable summary; otherwise cross-domain routing degenerates into full replication.

Every forwarding decision MUST be made locally, based on datagram-visible information plus locally maintained state; no centralized per-request routing decision point is assumed. Rationale: A centralized per-request routing decision point brings both availability risk (single point of failure) and a scalability ceiling. A scalable system requires decisions to be pushed down to the local level.

Any matching or selection that depends on real-time state MUST be made by the entity that actually holds that real-time state. For example, load and availability are attributes whose true value only the handler itself knows at the current moment. Rationale: An intermediary can only infer real-time state through stale, indirect, possibly unsynchronized information. If an intermediary selects on the handler's behalf, it may pick a handler that looks idle in the directory but has just taken a heavy job. The only reliable location for a real-time-state decision is the holder of that state.

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

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

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

Forwarding nodes MUST NOT be required to perform inference (e.g., LLM inference) when making forwarding decisions on the data path; forwarding decisions MUST be deterministic, predictable, and minimal-cost. Rationale: Inference on the data path pushes up forwarding latency, requires every forwarding node to have inference capability (raising the deployment threshold and operational cost), and makes forwarding behavior unpredictable and hard to debug and audit. The forwarding layer should be positioned like IP forwarding: deterministic lookup and hop-by-hop forwarding, with every step that needs intelligence left to the endpoints.

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

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

The coordination substrate MUST support the addition, update, and withdrawal of capabilities, and MUST exhibit bounded convergence behavior (such changes propagate and stabilize within a predictable bound). Rationale: Agent capabilities are dynamic. If changes propagate without bound, requesters see inconsistent capability views at different moments, and matching results become indeterminate.

The coordination substrate MUST be able to deliver a request to any registered handler. Rationale: This is the fundamental reason the coordination layer exists. Locating is worthless if the request cannot ultimately arrive.

A handler MUST be able to deliver execution results back to the requester endpoint indicated in the request; this return path is not required to traverse the coordination infrastructure's forwarding data plane. Rationale: Request-response is the minimal closed loop of coordination. Not binding the return path to the coordination data plane lets it reuse existing transport protocols and reduces coupling.

The decomposition from "naturally expressed task intent" to "routable capability identifier" MUST occur at the originating end; the coordination infrastructure MUST NOT be required to perform this decomposition internally. Rationale: Intent decomposition depends on the requester's full task context (what it actually wants, under what constraints), information only the endpoint possesses. Putting decomposition inside the network hands the step that most needs context to the layer with the least context.