| Internet-Draft | Agentic Routing Considerations | March 2026 |
| Du | Expires 3 September 2026 | [Page] |
As the development of the AI technology, an AI Agent would be able to do some tasks as an assistant to human beings. During the task process, the Agent may need to connect to other Agents with different skills relative to the task. The Agent to Agent communication is a new kind of traffic for Internet, and some new requirements for networking are proposed. This document describes some routing considerations in the agentic network, especially for the cross-domain scenarios, in which the agentic network works as an overlay network above the IP network.¶
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 RFC 2119 [RFC2119].¶
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 3 September 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.¶
In [I-D.rosenberg-ai-protocols], some use cases and requirements for AI Agent protocols are introduced. Meanwhile, a framework is described for the agent communications, and it includes the communications between AI agent and User, AI agent and API, AI agent and AI agent. In this document, we mainly focus on the Agent to Agent communication scenarios.¶
In the agentic network, it is assumed that many Agents exist, and they need to cooperate to complete tasks. The AI Agents in the same task group need to form a virtual network to communicate with each other, and after the task completing, the communication group may be released.¶
The main purpose of this document is to describe some routing considerations in the agentic network. Other issues, such as the discovery and authentication of the target Agents, are out of scope.¶
The Agent commutation nowadays mainly happens in the intra-domain scenarios, in which many problems would be simpler. As introduced in the [I-D.zyyhl-agent-networks-framework], the scenarios about the single trusted domain are analyzed firstly, and cross-domains are suggested to be considered in future. In that trusted domain, a Registration Server is responsible for establishing the trust relationship, and a Communication Server is responsible for communications between the Agents. For these intra-domain cases, most of the agents should be well known to the administrator, or to the Registration Server.¶
When the scenarios are extended into the Internet level, where cross-domains become unavoidable, things become more complicated. As mentioned in the [I-D.rosenberg-ai-protocols] , an Agent should not trust another Agent only because it is one of the results provided by a search engine on the Internet, and a high level of trust is required for one AI agent to talk to another one in the inter-domain cases. Meanwhile, in the cross-domain scenarios, if different domains could follow the same standardized realization, the communication would be much easier.¶
There are many different tasks and different scenarios for Agent communications. In this section, we introduce three kinds of connection modes as follows.¶
Direct-connected mode: AI agents directly send and receive messages without the need for intermediate nodes for processing.¶
Indirect Communication by using one Agent Communication Server: It often appears in a single domain scenario. Communication between AI agents requires processing/relaying by a Agent Communication Server, and the AI agent must be aware of and interact with the Agent Communication Server.¶
Indirect Communication by using the AGW network: It often happens in cross-domain scenarios. An AI agent firstly connects a Communication Server or called an Agent Gateway (AGW), and then communicates with other Agents by using the AGW network. The Agents in the task group may attach to different Agent Gateways, so that more hops are involved.¶
The second case can also work for cross-domain scenarios, if we assume that a super Agent Communication Server exist. However, the distributed solution mentioned as the third one will have benefits such as the path length and the scalability.¶
If the Agent communication only happens between two Agents, the peer-to-peer mode would be the most straightforward approach. We can also call it a direct-connected mode.¶
If more Agents are involved in the communication for the task, this direct-connected mode can also work. However, the leader of the task group needs to be responsible for all the transmitting of the messages.¶
Normally, the leader is the Agent that receives the task, and finds partners to complete the task. Thus, in this case, the leader initiates the task group, and is responsible for the interaction of the Agents, while other Agents only need to have a connection to the leader.¶
As mentioned in [I-D.mpsb-agntcy-messaging], the Advanced Message Queuing Protocol (AMQP) is often used for enterprise messaging systems. With the message system, asynchronous processing is enabled, and reliable message delivery for distributed transactions can be guaranteed. Additionally, it supports flexible routing and easy integration of new components, enhancing overall architecture resilience and adaptability.¶
Therefore, if many Agents exist in the enterprise, they can communicate by using a message queue system, which can simplify the communication of Agents because many functions about communication can be done outside of the Agent.¶
In this case, an Agent only needs to have a connection to the Agent Communication Server. We can realize the message queue system in this Agent Communication Server.¶
For cross-domain scenarios, multiple Agent Communication Servers could exist. As it is for inter-domain, we can also consider that Agent Communication Server works as the Agent Gateways.¶
It is assumed that each domain has an Agent Gateway, and the Agent Gateways have already been connected by some means. Thus, the A2A connection is composed of three parts, i.e., from the source Agent to the AGW A1 that it attaches to, from AGW A1 to another AGW A2, and from AGW A2 to the target Agent.¶
The structure is described in [I-D.mpsb-agntcy-slim], in which the Agent Gateway is considered as a Message Node or a Routing Node.¶
After connecting the Agent Gateways, we establish an overlay network above the IP network for cross-domain scenarios of the Agent communication. Based on this overlay network, Agents can dynamically establish virtual groups on demand.¶
The AGWs should be able to support flexible forwarding mechanisms. Four requirements are listed as follows.¶
Forwarding based on Agent ID: AI agents should have a structured ID that can be discovered and addressed.¶
Forwarding based on AGW ID: The forwarding table of AGW IDs should be per-configured in the AGW.¶
Forwarding based on Channel ID: The channel ID is related to the virtual group. It supports multicast in the task group.¶
Forwarding based on Skill: It happens in the discovery stage. When many agents can provide the same skill, they can advertise the same skill ID into the AGW network.¶
In the last case, the registration/discovery system can also give the suggestion about which Agent should be connected. However, anycast on the AGW network can also be a potential solution for some scenarios. It is similar to the relationship between the GSLB (Global Server Load Balance) technology based on DNS and the anycast technology based on BGP.¶
The number of Agents in the agentic network could be very large. However, the Agent IDs normally can not be aggregated as IP addresses do. Thus, we do not need the AGW to have a complete forwarding table for all the Agent ID in advance.¶
If a target Agent ID is received, and an AGW does not know how to route the traffic. It can query the registration/discovery system for that ID.¶
Meanwhile, for the intra-domain traffic, the AGW could support the forwarding of the traffic more easily. The AGW should be aware of the Agents that attach to it, and maintain an attached Agent table.¶
As talked before, the interconnection of the Agent Gateway is the per-condition of the AGW network. Some information exchanges should be supported among the AGWs.¶
If an AGW can not recognize a specific Agent ID, it should perform a discovery procedure, and obtain the target AGW ID that the Agent attaches to. Next, the AGW forwards the message to the target AGW, and the target AGW should be aware of the location of the Agent.¶
As the communication happens among a task group, and the AGW network would support many virtual networks, each for a task group, AGW should support forwarding based on the channel ID.¶
AGWs that are involved in the traffic of a task group should maintain a forwarding table of the channel ID corresponding to the task group.¶
Meanwhile, the AGW should be aware of the local-connected Agents that have subscribed the channel.¶
In the agentic network, many Agents own the same skill, and they can advertise the same target address into the agentic network. The selection method may related to the network distance, the predicted service experience, etc.¶
TBD.¶
TBD.¶