Need for Dynamic Resolution of AI Agent Names

John Zinky, Ph.D.², *Hema Seshadri, Ph.D.¹˒², Sharanya Badrinarayanan¹

¹ Northeastern University · ² Akamai Technologies · *Principal Investigator

Our earlier exploration in this series introduced the MBTA Transit Conversational Intelligence multi-agent system. Consider the implications if this system achieves massive adoption due to its utility. In this scenario, millions of MBTA commuters deploy a personal Exchange Agent on their mobile devices to interact with domain agents such as Alerts, StopFinder, and Planner. This shifts the user experience from traditional web page interactions to a model where the user owns a society of agents capable of privately integrating personal data while filtering out intrusive advertisements. However, this scale introduces significant security and performance challenges for the MBTA domain agents. Managing these concerns requires that the communication path between the requester and target agents be dynamically tailored to the environmental context, including geographical location, device specifications, network state, security protocols, payment capabilities, and the real-time load on both the infrastructure and the target agents.

Establishing communication between agents is a multi-step process. First, the requesting agent discovers a target agent that meets its functional requirements. Then the requesting agent resolves the target agent’s name into a tailored endpoint for a communication channel to the target agent. Finally, the requesting agent uses the tailored endpoint to interact with the target agent.

As described in Part III of the series, the user’s Exchange Agent will discover the MBTA domain agents (Alerts, StopFinder, Planner) using the switchboard federated registry model. In Part I, we understood how the agent discovery result is an agent’s digital AI passport, which is a trusted collection of metadata about what services the agent can perform and constraints on how to communicate with it.

The agent’s digital AI passport could present a communication endpoint to the Target Agent as a static URL, which would be the same for all users requesting communications with the target. Unfortunately, a static URL does not offer the flexibility to tailor the URL endpoint to each requesting agent. Inter-agent communication is expected to have enhanced security and scalability requirements beyond traditional client-server communication seen in web and API interactions. 

Instead of a static URL for the target agent’s location, an Agent Name can be presented in the AI agent’s digital passport. Each requesting agent resolves the target agent’s name when it wants to communicate.  This dynamic resolution returns a tailored URL for this specific agent and the current state of the environment between the requester and the target agents. 

Dynamic resolution is concerned with how to set up a secure and scalable communication path between agents so they can interact. Resolution manages system issues, such as performance and security.  Performance concerns address system efficiency through functions such as load balancing, round-trip minimization, throughput maximization, and the horizontal scaling of agent instances. Simultaneously, security concerns encompass critical safeguards including authentication, authorization, privacy, access control, compliance logging, and the maintenance of data integrity.

The requesting agent then establishes a connection at the tailored endpoint, performing all the required handshakes. After the connection is established, the requesting and target agents can interact securely and at scale. Having well-defined commitment times facilitates the smooth creation of a communication path, allowing incremental establishment of trust while limiting the consumption of valuable resources by malicious agents, such as denial of service attacks (DoS). Note: AI Agents may consume significant quantities of resources to answer a user prompt request, such as querying a large language model using a GPU. The communication channel should make considerable effort to protect agents from undesirable interactions.

Lessons learned from deploying DNS on the internet show that even moderately used web servers need to deploy substantial communication infrastructure to handle their performance and security concerns beyond the functionality of the web server itself. For performance concerns, the infrastructure may include resolving DNS names to endpoints closer to the client, load balancing across servers, caching content, and using private communication links. For security concerns, the infrastructure may offer DDoS protection, web application firewalls, TLS certificate management, and malicious bot detection. 

Creating this tailored communication infrastructure is beyond the expertise of typical web page service providers, so the job is delegated to third-party “DNS hosting services” that specialize in operating communication infrastructure. As we will see in a later section, similar and additional functionality will be needed in the communication path between AI agents. Dynamic resolution is the process that allows future “agent hosting services” to deploy and tailor the communication channels between AI agents.

Dynamic Agent Name Resolver System Architecture

The architectural goal of dynamic resolution is to define the steps needed to deploy communication between agents over a physical environment. Like the  Domain Name System (DNS), dynamic resolution mediates interactions between the requester agent, the target agent, and the communication environment between them (Fig. 1). This results in scalable communication channels that are secure, efficient, and robust.

Figure 1: Using the Dynamic Name Resolution System

We model the Dynamic Resolution architecture after the Internet DNS, which has global deployment and decades of operational and security experience. The existing DNS system might be used to bootstrap an agent naming system, but we suspect that it will need substantial refinements as agentic applications scale and evolve (Fig. 1). The architecture description will use DNS terminology where possible and will introduce agent extensions where necessary.

The process starts when a target agent creates its agent name relative to its namespace. The target’s name can be registered in a public directory where the requester agent can discover it, as described in Part III of the blog series. If the target agent requires high security or expects substantial usage, it may delegate the creation of a tailored endpoint to a comms infrastructure provider. In the DNS system, the authoritative name server is the front-end interface to the system that deploys the comms and target agent and is responsible for creating tailored endpoints. When the requester agent wants to get a communication endpoint to interact with the target agent, it sends a query to its recursive resolver. The resolver and the authoritative name server work together to deploy a comms infrastructure that is tailored to the environmental context between the three main components: Requester, Target, and Comms. Note that the gathering of environmental context and restrictions may involve many rounds of negotiations. 

Agent Path Names

Agent Names must be understandable by humans, but rigorous enough to be resolved uniquely by machines.  We propose that an agent name use the familiar path name structure found in file directories or DNS names. The name starts at a root and then follows a path of child nodes until a leaf name is reached. The whole path would be the name pointing to the agent at a leaf. The root node is an anchor for a namespace, and the path is a unique string relative to the root. Hence, a path name is a tuple of a unique namespace and a relative string.

Figure 2: An Agent Name is a Path through a Name Space

The IETF standard for Uniform Resource Names (URN) [RFC 8141] partitions a name string into the following parts (Fig. 3):

1. Namespace Identifier is a unique string for a namespace. 
2. Path name string to the agent name relative to the namespace
3. Name separator is syntactic sugar that indicates that the string should be interpreted as a name.

URN name strings have the form:

Figure 3: Uniform Resource Names (URN) String Form

Namespace Identifier (NID), to be an official URN, must be universally registered in the Internet Assigned Numbers Authority (IANA).   We propose instead that the NID string be the DNS name for the root name server that is managing the namespace.  Using a DNS name would reuse the existing DNS name registry, certificate infrastructure, and DNS scaling. The URL to the namespace server could be derived from the DNS Name by a fixed procedure that converts the DNS name to a URL, adding https as the protocol and an OpenAPI spec for the different query functions.

The syntax of an agent name string needs to be standardized, given that there are lots of options (Fig. 4 and 5). But the basic structure follows the URN formulation of three parts: unique namespace, relative name, and syntactic sugar to separate them.

Figure 4: Standardization of the Syntax of an Agent Name

Other URI styles for an agent name have a more verbose form (Fig. 4). But while these are familiar and standard, they may have too much syntax for non-programmers:

Figure 5: Different URI Styles for Agent Names

Notice that the agent name is independent of the environmental context in which it is resolved. The path name should not muddle naming with communication issues, such as protocol, version, security, and other environment context metadata, as done in other proposed naming schemes, such as ANS Naming, DNS-AID. These environmental context issues are addressed at resolution time, not naming time. 

Establishing the Environment for Communications

Acquiring detailed knowledge of the environment is essential for balancing various system priorities. The environment is managed by three primary entities: the requester agent, the target agent, and the underlying communications infrastructure. Each component, typically under separate logical ownership, oversees specific resource sets. Interactions among these parties function as incremental commitments to a collective environmental understanding. While these agreements can be retracted, doing so necessitates the renegotiation of all subsequent arrangements.

The culmination of this negotiation occurs when all parties reach a consensus on the environmental context, establishing the mutual trust and metadata validation required for communication. This is not an instantaneous event; rather, each interaction progressively builds trust and shared intelligence. Furthermore, these established interactions can be leveraged across multiple resolution queries from various requester and target agents. To better understand this dynamic, we will examine specific interactions to identify the types of knowledge exchanged and the timing of these transfers.

Target Agent Registration

When the target agent is created, it needs to do at least two things: figure out how it should be deployed and advertise its existence (Fig. 6).

Figure 6: Registration of Public and Deployment Metadata

Deployment involves the technical details of hosting an agent on its owner’s infrastructure. For basic agents, this might only involve recording the agent’s name with a namespace server. This server functions as an external authority, authenticating the agent name and managing interactions with external trust systems. Because agents utilize the owner’s resources during every access, managing these resources through the owner’s infrastructure is essential.

Agents with moderate to high usage require robust infrastructure to address performance and security. Such deployments necessitate strategic planning and the configuration of services like security monitoring, horizontal replication, and load balancing. During this process, the target agent provides private metadata to a deployment infrastructure controller. The namespace server then tasks the authoritative name server with generating tailored endpoints. The agent becomes operational following this multi-stage setup.

Registration consists of compiling the target agent’s public metadata into a digital AI passport and submitting it to an Agent Discovery and Registry Service (Fig. 6). This public metadata details the agent’s capabilities and any usage restrictions, which define the expected behavior for communication channels and requesting agents. These constraints might include specific protocol requirements, such as A2A, or geographical limitations. The registry serves as an external authority that ensures the agent’s passport remains accurate, authentic, and tamper-proof.

Requester Agent Resolution Request

After the requester discovers a potential target agent, it extracts from the target’s digital passport the Agent Name and restrictions on the requester’s environmental context.  The requester examines its own resources to determine if it can meet the restrictions. If it can, the requester will make a resolver query with both the target agent name and its own environment context. 

Figure 7: Requester Resolves an Agent Name

The resolution process begins with the resolver query being directed to the requester’s recursive resolver (Fig. 7). The requester agent utilizes this recursive resolver as a proxy to gain access to the overall resolver system. To ensure secure communication and reliable operation, the requester must first establish trust with the recursive resolver. Once trust is established, the recursive resolver essentially acts as a representative for the requester agent to interact with the downstream resolver system. Consequently, a secure connection is a mandatory requirement for all communication between the requester and the recursive resolver.

Requester Environmental Context is a structure of key-value pairs that could include information about the client’s geographical location, bounds on payment, network CIDR, desired protocol, and version of its software. Here is an example of the kinds of environmental context that the requester may supply. After extensive experimentation, standards are needed to define the actual key/value pairs.

Recursive Resolver finds Authoritative Name Server

The recursive resolver extracts the namespace ID [dataworksai.com] and path name string [alerts.mbta-transit-cl] from the agent name (see Fig. 7). We proposed that the namespace ID be a DNS name, so standard web-service access can be used to access the top-level namespace server. 

Figure 8: Recursive Resolver Finds the Authoritative Name Server

The recursive resolver calls the namespace server with a query that includes the path name string and the requester context. The namespace server may be the authoritative nameserver, or it may refer to another nameserver. The referral process may take several iterations, hence the name recursive resolver (Fig. 8). 

The top-level namespace server is the representative for the target agent, but may know nothing about how the agent is deployed. The top-level namespace server does know about the structure and organization of the path name string and can refer down the path name until the authoritative name server is at the leaf of the name. The authoritative nameserver knows how the target agent is deployed and may be owned by the communications infrastructure and not the target agent.

Authoritative Name Server returns Tailored End-Point

The authoritative name server is the runtime access to the target agent’s deployment infrastructure. It is the holder of all the environmental metadata that is necessary to make a tailored communication path between the requester and target agents (Fig. 9). 

Figure 9: Authoritative Name Server Returns Tailored Endpoint

The deployment infrastructure gathers real-time information about the current state of the target agent and communication resources. These resources are known because they were set up when the target agent was created and recorded its deployment metadata with the infrastructure. The requester’s metadata is known because it was sent as part of the context in the resolver query.

The Tailored End-Point may physically already exist, or new components may need to be deployed based on the overall environmental context. In either case, a tailed endpoint is returned to the recursive resolver. Depending on the desired format, the recursive resolver may convert the response into a URL that the requester agent can use to make a connection to the target

Tailored Communications Channel

The deployment infrastructure is responsible for creating and maintaining communication channels between the requesting agents and the target agent. For high-demand target agents, the channels may involve a complex topology between the tailored end-points given to a specific requester and the target (Fig. 10). Each tailored endpoint can trace a path through the deployment to get the desired level of service the requester requires. Along the path, the agent-to-agent communication will encounter different services. 

For example,  an A2A proxy can act as a firewall to protect the target agent from malicious prompts and protect the requester from inappropriate responses. Other components may collect compliance traces, act as slim gateways, or horizontally scale the target agent. As we gain experience with usage patterns of Agent-to-Agent communication, we expect a rich collection of communication services that will help make internet of Agents secure and scalable. 

Figure 10: Tailored Communication Channels between Agents

Pulling it all together

We have described an agent name resolver based on the DNS name resolver architecture. The architecture shows that the requester agent, target agent, and the comms infrastructure must cooperate to exchange information about the environmental context (Fig. 11). 

Figure 11: Full Dynamic Agent Name Resolver System

The basic Dynamic Resolution steps are:

1. Target agent is created and deployed
2. Target agent records its deployment metadata with a hosting service
3. Target agent advertises its existence by registering with a discovery service
4. Requestor agent discovers a target agent that meets its functional requirements
5. Requestor agent resolves a target agent name, given the requestor’s environmental context, using its recursive resolver
6. Name space server refers the recursive resolver to an authoritative name server that is responsible for the target agent
7. Authoritative name server finds or makes a communication channel between the requester and target agents.
8. Recursive resolver returns a tailored URL to the communication channel
9. Requestor agent uses the communication channel to interact with the target agent.

The setup of the communication channel occurred independently of the agents. During resolution, the comm channel and tailored endpoint were established in a single pass. Although the basic channel and target agent had been configured previously, the metadata was finalized during this one-pass process. As inter-agent communication becomes more complex, we anticipate that this one-pass resolver model will become insufficient, necessitating a transition toward a multi-pass “adaptive resolver” framework. The adaptive resolver architecture is described in the paper: NANDA Adaptive Resolver: Architecture for Dynamic Resolution of AI Agent Names. This blog has also refined some of the ideas behind Dynamic Resolution described in that paper.

Conclusion

Dynamic resolution for agent names allows for the creation of tailored communication channels between the requesting and target agents. This is a significant benefit that cannot be achieved with endpoints using static URLs. The tailored communication channels allow agent-to-agent communication to be secure and scalable. Prototyping the dynamic resolution service will be a focus of future research and will be described in future blogs. Part VIII will describe the design of the Dynamic AI-Agent Naming System (DANS) as a single server with REST APIs.  Part IX will describe the prototype of DANS and the integration into the MBTA society of AI-Agents.

References

Blogs in the series Deploying the Internet of AI Agents:

1. Part 1: Stop Building Bots, Start Building AI Agent Networks 
2. Part 2: Implementing MBTA Transit Conversational Intelligence with Emerging AI Protocols
3. Part 3: Federated Architecture for Global AI Agent Registries

Akamai Tutorials on DNS, scaling, and securing web services:

4. What is a DDoS Attacks 
5. What is an Application Load Balancer
6. What is Content Caching
7. What is Web Application Firewall (WAF)
8. What is AI Agent Firewall
9. What is bot detection
10. What are DNS Servers
11. What is a Recursive Resolver

Other AI Agent Naming Research:

12. RFC 8141 Universal Resource Names (URN)
13. DNS-AID
14. ANS Naming
15. AGNTCY
16. NANDA Adaptive Resolver: Architecture for Dynamic Resolution of AI Agent Names