| Internet-Draft | IAIP | February 2026 |
| Sun & Zhang | Expires 9 August 2026 | [Page] |
This document specifies the Intent-based Agent Interconnection Protocol (IAIP) operating at the Agent Gateways (AG), which defines the interaction mechanisms between AI Agents (at the Agent Domain) and the AG (at the Interconnection Services Domain). This specification focuses on dynamic interconnection among agents based on semantic intent, rather than static network addressing alone. This protocols defines the mechanisms for agent registration via capability advertisement, Gateway Validation, Intent Resolution and Matching, Routing Decisions and Forwarding, enabling the discovery, selection and dispatching of intent queries based on agent capabilities and task requirements at AG.¶
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 5 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
The emergence of agentic networks marks a fundamental shift from static, address-based networking to semantic, intent-driven interactions. Autonomous agents powered by advanced artificial intelligence models are capable of reasoning, planning, and executing tasks on behalf of users or other agents. Interactions are increasingly expressed in terms of high-level objectives or natural language intents, rather than predefined service endpoints or static interfaces.¶
Traditional networking and service discovery mechanisms assume that communication targets are identified by fixed addresses, names, or service identifiers. These assumptions no longer hold in agentic environments, where the appropriate execution entity for a request may depend on semantic interpretation, contextual constraints, and dynamic system conditions. As a result, routing decisions based solely on static addressing or preconfigured bindings are insufficient to support flexible and scalable agent collaboration.¶
Intent-based interconnection addresses this gap by enabling the Agent Gateway to resolve and forward requests according to their semantic intent, rather than their destination address. By decoupling request dispatch from rigid topology and static identifiers, intent-based interconnection allows autonomous agents to be dynamically discovered, selected, and invoked based on their advertised capabilities.¶
This document introduces the Intent-based Agent Interconnection Protocol (IAIP) to provide a standardized mechanism for capability-based registration and validation, intent-aware discovery and routing at AG. IAIP is designed to operate as an application-layer protocol for interconnection service domain, complementing existing transport and networking infrastructure without requiring changes to underlying transport protocols.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.¶
A declarative expression of a desired outcome. In the intent-driven routing protocol, intent is represented at three conceptual layers:¶
Existing network interconnection and gateway mechanisms are predominantly organized around static identifiers, such as network addresses, domain names, or service labels. At the application and service-dispatch layer, these mechanisms assume that the functionality associated with a agent behind a gateway is stable, explicitly addressable and functionally static. While effective for traditional client-server and microservice architectures, this assumption becomes increasingly inadequate for the dynamic interconnection required by agentic networks.¶
First, traditional interconnection protocols provide limited support for expressing semantic intent. High-level requests such as "analyze this dataset" or "resolve a billing issue" do not naturally correspond to a single predefined endpoint. Encoding semantic meaning into static addresses or service names requires manual configuration and tight coupling between task requesters and service providers, which undermines flexibility and scalability.¶
Second, static interconnection lacks adaptability to dynamic lifecycle of AI Agents. In the Agent Domain, agents may be instantiated, fine-tuned, or deprecated rapidly based on computational load or task requirements. Static bindings or name-based resolution mechanisms are generally unable to reflect real-time changes in agent's availability or intent-processing capacity, leading to service selection or routing dispatch failures.¶
Third, existing protocols offer limited support for intent-aware resolution. When a request arrives at the gateway without a specific destination address, traditional gateway have no mechanism to parse the intent and match it against a local registry of vector-based capabilities. This behavior is misaligned with agentic workflows, where ambiguous or underspecified intents are common and may require clarification, delegation, or escalation to more generalist agents.¶
These limitations motivate the need for an intent-driven interconnection protocol specifically at the Agent Gateway that can manage registration and routing based on semantic intent and dynamically advertised capabilities, rather than relying solely on fixed addresses or static identifiers. This protocol addresses these challenges by transforming the gateway from a static packet forwarder into a semantic ingress/egress point, enabling establishing agent interconnection while maintaining compatibility with the Interconnection Service Domain.¶
The following example illustrates a typical use case of the Intent-based Agent Interconnection Protocol operating at the Agent Gateway.¶
A Customer Service Dispatcher Agent, acting as the Leader Agent, transmits a user inquiry to the AG for intent resolution and service response. Specialized Partner Agents (Billing, Technical Support, Sales) have previously registered their specific semantic domains with the AG. For explicit queries like "My credit card was charged twice," the AG identifies a high-confidence semantic match and routes the request to the Billing Agent. Upon completion, the AG relays the result back to the Leader Agent. Conversely, when handling ambiguous inputs (e.g., "I'm having a bad experience") where semantic similarity scores fail to meet the required confidence threshold, the AG encapsulates the intent and forwards the intent to a Generalist Fallback Agent. This mechanism ensures the request is constructively resolved via clarifying questions or human escalation, thereby preventing service failure.¶
Figure 1 illustrates the interaction diagram between AI agent and Agent Gateway.¶
[Agent Domain] [Interconnection Service Domain] +-----------+ IAIP +---------------+ | AI Agent | <-------------> | Agent Gateway | <---> [Core Router] +-----------+ +---------------+
To support the interaction with AI Agents, the AG MUST implement the following specific Functional Components within the Interconnection Service Domain.¶
The protocol functions in two primary phases.¶
Figure 2 illustrates the updated two-stage processing pipeline between AI Agents and AG.¶
+--------------+ +------------------------+ +--------------+
| Leader Agent | | Agent Gateway | | Partner Agent|
|(Intent Init.)| |(Network Infrastructure)| |(Intent Exec.)|
+------+-------+ +------------+-----------+ +------+-------+
| | |
| Phase 1: Identity Reg & Capability Advt. |
| | |
|--(1) Identity Reg -->| |
| [ACP-IF-01] | |
| |<--(2) Identity Reg --|
| | [ACP-IF-01] |
| | |
| |<--(3) Publish Cap ---|
| | [ACP-IF-06] |
| | |
| |-->(4) Sync & Trust --|
| | [ADF / DTMgF] |
| | |
| Phase 2: Intent-based Routing |
| | |
|--(5) Submit Intent ->| |
| [Signed Vector] | |
| | |
| |-->(6) Resolve Intent-|
| | Match ADF DB |
| | DTMgF Filter |
| | |
| |<--(7) Cand. List ----|
| | [Ranked + Sig] |
|<--(8) Verify & Select| |
| | |
|=========(9) Routing and Execution =========>|
| [E2E via ACP-IF-08/09] |
|=============================================|
Phase 1: Agent Registration & Capability Advertisement¶
This stage is the prerequisite for any agent participation. It involves Identity Registration (mandatory for all) and Capability Publication (mandatory for service providers). The steps are as follows:¶
Phase 2: Intent-based Routing and Forwarding¶
This stage is triggered when a registered Leader Agent submits a semantic intent request. The Agent Gateway resolves and routes the intent to eligible Partner Agents. The steps are as follows:¶
This section specifies the binary structure of IAIP messages. The protocol uses a Type-Length-Value (TLV) design to ensure extensibility.¶
+--------------------------------------------------------------------+ | IAIP Message (TLV-based) | +--------------------------------------------------------------------+ | | | +-------------------+------+-----------------------------------+ | | | Type | Len | Value | | | +-------------------+------+-----------------------------------+ | | | Common Header TLVs | | | +-------------------+------+-----------------------------------+ | | | VERSION | 1 | Protocol version | | | | MSG_TYPE | 1 | INTENT_REQ / CAP_ADV / ERROR | | | | MSG_ID | var | Unique message identifier | | | | SENDER_ID | var | Source agent / router ID | | | | RECEIVER_ID | var | Target agent / router ID | | | | TIMESTAMP | 8 | Unix time / logical time | | | | TTL / EXPIRY | 4 | Validity / hop limit | | | | CORRELATION_ID | var | Request-response correlation | | | | INTEGRITY_TAG | var | MAC / signature | | | +-------------------+------+-----------------------------------+ | | | | +-------------------+------+-----------------------------------+ | | | Payload TLVs (depend on MSG_TYPE) | | | +-------------------+------+-----------------------------------+ | | | | -- CAPABILITY ADVERTISEMENT (CAP_ADV) -------------------------- | | | AGENT_ID | var | Advertising agent identifier | | | | ENDPOINT | var | Network / logical endpoint | | | | FUNC_DESC | var | Functional descriptors | | | | INTENT_DOMAINS | var | Supported intent types | | | | IO_SCHEMA | var | Input/output constraints | | | | PERF_METRICS | var | Latency, success rate, etc. | | | | RESOURCE_LIMITS | var | Token / compute budget | | | | | -- CAPABILITY REFRESH (CAP_REFRESH) ---------------------------- | | | AGENT_ID | var | Agent identifier | | | | TTL_UPDATE | 4 | Extended lifetime | | | | METRIC_DELTA | var | Updated performance metrics | | | | | -- CAPABILITY DEREGISTER (CAP_DEREGISTER) ---------------------- | | | AGENT_ID | var | Agent identifier | | | | REASON_CODE | 2 | Deregistration reason | | | | EFFECTIVE_TIME | 8 | Time of effect | | | | | -- INTENT REQUEST (INTENT_REQ) --------------------------------- | | | OBJECTIVE | var | Task objective | | | | CONSTRAINTS | var | Preferences / limits | | | | CONTEXT | var | Context metadata | | | | PRIORITY | 1 | Request priority | | | | BUDGET | var | Cost / token budget | | | | PRIVACY_FLAG | 1 | Intent privacy level | | | | OBFUSCATED_INTENT | var | Encrypted / masked intent | | | | | -- ROUTE DECISION / INTENT RESPONSE ---------------------------- | | | TARGET_AGENT_LIST | var | Selected target agent(s) | | | | MATCH_CONFIDENCE | var | Similarity / rank score | | | | FORWARDING_INFO | var | Next-hop / endpoint | | | | FALLBACK_INDIC. | 1 | Fallback used? | | | | | -- ROUTING FEEDBACK -------------------------------------------- | | | OUTCOME | 1 | Success / failure | | | | OBSERVED_LATENCY | var | Execution latency | | | | OBSERVED_COST | var | Resource usage | | | | ERROR_INFO | var | Error details | | | | | -- ERROR MESSAGE ----------------------------------------------- | | | ERROR_CODE | 2 | Error identifier | | | | DIAGNOSTIC | var | Human-readable info | | | | RETRY_AFTER | 4 | Backoff hint | | | | | -- SECURITY EXTENSION (SECURITY_EXT) --------------------------- | | | AUTHN_INFO | var | Certificate / token ref | | | | AUTHZ_SCOPE | var | Authorization scope | | | | NONCE | var | Anti-replay | | | | SIGNATURE / MAC | var | Integrity protection | | | | ENCRYPTION_CTX | var | Intent confidentiality ctx | | | | +--------------------------------------------------------------------+
The table above summarizes the field requirements. Key fields include:¶
This section specifies the normative processing behavior of the Agent Gateway (AG), organized by the functional components defined in Section 5. The Agent Access Component (AAC) handles ingress connectivity and security; the Local Capability Registry (LCR) manages state; and the Intent Forwarding Routing Table (IFR) executes decision logic.¶
The examples in this section are provided for illustration only and are non-normative.¶
A Partner Agent registers its translation service with cost constraints.¶
[Common Header] MSG_TYPE =
CAP_ADV SENDER_ID = "agent-trans-01", TTL/EXPIRY = 3600 [Payload],
FUNC_DESC = "service:translation; lang:en-to-zh", RESOURCE_LIMITS =
"max_tokens=2048", SECURITY_EXT = "(signature bytes...)"¶
Step 1: Leader Agent sends Intent Request¶
[Common Header] MSG_TYPE =
INTENT_REQ SENDER_ID = "leader-agent-007", MSG_ID = "req-1024"
[Payload], OBJECTIVE = "(vector: [0.12, 0.95, ...])", BUDGET =
"100"¶
Step 2: Gateway returns Candidate List
(Response)
The AG finds two matching agents. The first
one is a direct match, so Fallback Indicator is 0.¶
[Common Header] MSG_TYPE =
RESPONSE RECEIVER_ID = "leader-agent-007", CORRELATION_ID =
"req-1024" [Payload], TARGET_AGENT_LIST = [1] "agent-trans-01"
(Conf: 0.92, Endpoint: "10.0.1.5:8080"), [2] "agent-trans-03" (Conf:
0.85, Endpoint: "10.0.1.8:8080"), FALLBACK_INDIC. = 0x00 (No
Fallback)¶
After execution, the Leader Agent reports performance metrics back to the AG to update the LCR's dynamic scores.¶
[Common Header] MSG_TYPE =
ROUTING_FEEDBACK SENDER_ID = "leader-agent-007" [Payload], OUTCOME =
1 (Success), OBSERVED_LATENCY = 250 (ms), OBSERVED_COST = 50
(tokens)¶
The AAC serves as the termination point for the interconnection session. It MUST intercept all incoming IAIP messages before they reach the LCR or IFR.¶
Upon receiving any message, the AAC MUST perform the following validations:¶
SENDER_ID against the credentials provided in the
AUTHN_INFO TLV or the underlying transport session (e.g.,
mTLS).¶
INTEGRITY_TAG or SIGNATURE. If verification
fails, the AAC MUST drop the message and return an ERROR
with code AUTH_FAILED.¶
The AAC acts as the first line of defense. It MUST validate the
syntax of Common Header fields (e.g., VERSION,
MSG_TYPE). Malformed packets MUST be rejected immediately
to protect the internal IFR engine.¶
The LCR maintains the dynamic database of attached Agents. It processes capability management messages validated by the AAC.¶
When the AAC forwards a CAP_ADV message, the LCR
MUST:¶
Upon receiving a CAP_REFRESH, the LCR MUST look up the
existing profile and extend its validity by TTL_UPDATE.¶
The LCR MUST periodically purge entries that have exceeded their expiry time without refresh (STALE state) to ensure the IFR does not route to dead agents.¶
The Intent Forwarding Routing Table (IFR) functions as the dynamic
routing engine of the Agent Gateway. After an INTENT_REQ
successfully passes AAC validation, the IFR MUST evaluate the request
and produce a ranked TARGET_AGENT_LIST containing one or more
eligible Partner Agents.¶
The IFR MUST interpret the OBJECTIVE TLV as an intent
descriptor and query the Local Capability Registry (LCR) to obtain
the current set of active Capability Profiles.¶
The IFR MUST apply mandatory constraints to reduce the candidate
set prior to semantic evaluation. When a request includes constraint
fields such as BUDGET, the IFR MUST compare these
constraints against the corresponding attributes in the Capability
Profiles (e.g., RESOURCE_LIMITS) and exclude agents that do
not satisfy the required conditions.¶
Additional policy-based constraints MAY be applied according to local administrative policy.¶
For the remaining candidates, the IFR MUST perform semantic matching between the request intent and the advertised capabilities. The specific matching method is implementation-dependent; however, the IFR MUST compute a relative confidence score that reflects the degree of intent-capability alignment.¶
The IFR MAY incorporate additional operational signals, such as historical performance metrics (e.g., latency or success rate), when deriving the final ranking.¶
The IFR MUST preserve the relative ordering of candidates when
constructing the TARGET_AGENT_LIST.¶
The IFR SHOULD select the highest-ranked candidates for inclusion in the response, subject to local policy.¶
If no candidate satisfies the acceptance criteria (e.g., minimum
confidence threshold), the IFR SHOULD invoke the Fallback Mechanism.
When fallback is applied, the Agent Gateway MUST set
FALLBACK_INDIC to 0x01.¶
For multi-hop scenarios, the AG enforces loop prevention using the
TTL field in the Common Header. If TTL <= 1, the
request is dropped. Duplicate MSG_ID, are suppressed to
prevent broadcast storms.¶
Errors detected by any component (AAC auth failure, LCR parsing
error, IFR no-route) MUST result in an ERROR message returned
to the sender, containing the appropriate ERROR_CODE.¶
Figure 3 illustrates the protocol processing pipeline within the Agent Gateway (AG). The protocol operation relies on the coordination between three normative functional components: the Agent Access Component (AAC), the Local Capability Registry (LCR), and the Intent Forwarding Routing Table (IFR).¶
The process begins when a Partner Agent transmits a capability advertisement (CAP_ADV) [Section 8.1.1].¶
Ingress Validation: The AAC [Section 8.2] intercepts the message to perform session authentication and integrity verification.¶
Registry Update: Upon successful validation, the AAC forwards the payload to the LCR [Section 8.3]. The LCR parses the functional descriptors and updates its internal database, mapping the agent's semantic profile to its network endpoint.¶
The routing process is triggered when a Leader Agent submits an intent request (INTENT_REQ) [Section 8.1.2].¶
Ingress Validation: The AAC validates the request format and the sender's authorization scope.¶
Routing Decision: Validated requests are passed to the IFR [Section 8.4], which executes the core decision logic:¶
Egress Processing: The partner agent list is passed to the Forwarding module [Section 8.5]. This module enforces Time-To-Live (TTL) checks and duplicate suppression to prevent routing loops before dispatching the forwarded request to the Partner Agent.¶
+--------------+ +--------------+
| Leader Agent | | Partner Agent|
| (Source/App) | | (Target/Phy) |
+-------+------+ +-------+------+
| (2) Intent Req | (1) CAP_ADV
| [Sec 8.1.2] | [Sec 8.1.1]
v v
+------------------------------------------------------------------+
| Agent Gateway (Interconnection Domain) |
|------------------------------------------------------------------|
| |
| +--------------+ (CAP_ADV) +--------------------+ |
| | Agent Access |------------------------->| Local Capability | |
| | Comp (AAC) | | Registry (LCR) | |
| | [Sec 8.2] | | [Sec 8.3] | |
| +------+-------+ +---------+----------+ |
| | ^ |
| | (INTENT_REQ) | Candidate |
| v | Retrieval |
| +---------------------------------------------------+----------+ |
| | Intent Forwarding Routing Table (IFR) [Sec 8.4] | |
| |--------------------------------------------------------------| |
| | 1. Candidate Retrieval (Query LCR) [Sec 8.4.1] --------------+ |
| | 2. Constraint Filtering [Sec 8.4.2] | |
| | 3. Semantic Eval & Ranking [Sec 8.4.3] | |
| | 4. Selection & Fallback [Sec 8.4.4] | |
| +------+-------------------------------------------------------+ |
| | Selected Target List |
| v |
| +----------------------+ |
| | Forwarding & Loop | |
| | Prevention [Sec 8.5] | |
| +------+---------------+ |
| | |
+--------+---------------------------------------------------------+
| (3) Forwarded Request
v
+-------------+
| Partner Agt |
| (Execution) |
+-------------+
This document specifies the functional components, protocol procedures, and message formats of the Intent-based Agent Interconnection Protocol (IAIP). It defines the mechanisms for capability-aware registration, semantic intent resolution, and dynamic routing. By abstracting the complexity of agent discovery and intent matching, IAIP ensures scalable and adaptive collaboration across heterogeneous agent systems.¶
This document focuses on the Intent-based Agent Interconnection Protocol at the Agent Gateway for inter-agent collaboration in the Internet of Agents (IoA). Security of the IoA ecosystem is not detailed in this document. Security considerations relevant to cross-domain intent routing, capability advertisement integrity, trust federation among multiple agent service providers, and end-to-end confidentiality of agent interactions are suggested to be deeply discussed through other proposals.¶
This document makes no request for IANA action.¶