Routing Considerations in Agentic Network

In , 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 , 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 , 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 an 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 , 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. On the other hand, as mentioned in , the Media over QUIC Transport (MoQT) provides an alternative for real-time agent communication systems. The MoQT relay infrastructure provides native publish/subscribe messaging capabilities with efficient real-time data streaming and built-in prioritization. Crucially, its integrated caching mechanism ensures robustness by enabling late-joining agents to receive recent context/messages, facilitates recovery from transient disconnections, and allows efficient replay of operation history. Furthermore, it supports hierarchical namespace organization and protocol multiplexing, which significantly enhances scalability and interoperability across diverse agent ecosystems. In both approaches, the communication architecture is simplified by centralizing complex functions within the Agent Communication Server. For AMQP-based systems, agents connect to a message queue server that handles routing and delivery logic. Similarly, in MoQT-based systems, agents establish QUIC connections to the MoQT Relay, which manages routing, discovery, and quality-of-service mechanisms. In these cases, an Agent only needs to have a connection to the Agent Communication Server. We can realize the message distribution 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 , 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 pre-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. For 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 pre-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. Specially, the Agent ID can be structured to include or imply the home AGW ID (e.g., agent123@agw-domain-a.example), then the lookup can be resolved to the target AGW efficiently.

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. The forwarding table can be built more efficiently if the Channel ID itself is structured to include the AGW ID. 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.