Federated Architecture for Global AI Agent Registries

Sharanya Badrinarayanan¹, *Hema Seshadri, Ph.D.¹˒², John Zinky, Ph.D.², Manikandan Meenakshi Sundaram¹, Javier Solis Vindas², Neha Save¹

¹ Northeastern University · ² Akamai Technologies · *Principal Investigator

The value of agent discovery lies in the federated registry model, which allows AI agents to remain on their native platforms while enabling an organization’s registry to discover and interact with them across organizational boundaries. By integrating a federated registry model into existing engineering and business workflows over open protocols, we significantly reduce the need to ‘port’ or migrate agents between platforms, and thereby reduce vendor lock-in.

In Part II, we demonstrated how agents communicate once they have found each other. In Part III, we will explore the discovery layer that makes agentic coordination possible, and how it scales beyond a single registry to a federated network of agent directories.

To answer a question: “I want to go from Harvard to Park Street. What stops, routes, and alerts do I require for this trip?” An application must integrate information from multiple sources. How does that agentic coordination happen? How can an Exchange agent determine which of its agents has the information relevant to its query?

In our MBTA use case, three agents must work together: 

• The StopFinder agent identifies all intermediate stops between Harvard and Park Street 
• The RoutePlanner agent identifies the optimal path and estimated travel time.
• The Alerts agent identifies service disruptions. 

The exchange agent must dynamically find and understand the capabilities of its StopFinder, RoutePlanner, and Alert agents, and coordinate their responses in real time. Agent discovery and registry services are necessary to achieve this coordination.

Can these agents be dynamically found and their capabilities understood? Can an agent coordinate responses in real time? Here is where agent discovery and registry service become apparent. 

Agent Registry & Discovery Service

In this section, we will introduce the service environment required for agent registry and discovery. For agents to communicate flexibly at scale, they need to advertise their services and capabilities. By registering their metadata in an agent registry where other agents and AI users can find them. An agent registry is an environment service that serves as both a directory of AI agents searchable via metadata and a matchmaker that finds target agents based on that metadata. 

The Target agent uses the registry service. The Alerts, RoutePlanner, and StopFinder agents we discussed in Part II of this series each possess specialized domain knowledge. The agents do not self-register on startup. Agent registration is done manually at deploy time by the Kubernetes job, which publishes its metadata to an agent registry service. Each agent’s  AI agent digital passport (Part I) contains metadata describing their skills and capabilities, and, most importantly, their location for reaching them. In our current reference implementation, we store the digital passports for our AI agents in MongoDB.

Figure 1: Agent Registry & Discovery Service

The discovery service provides lookup and matchmaking services to a requesting agent. It reviews the metadata cards of target agents and enables dynamic agent discovery, without hardcoded integrations.

The requester agent uses the discovery service. In our implementation, the exchange agent serves as the requester with coordination domain knowledge (Fig. 1). When it receives a user prompt, it then prompts the registry to discover which agents can fulfill different parts of the request, then orchestrates their responses into a coherent answer.

Inside the digital passport’s public metadata is a Locator. A common practice for locating the agent is to expose a static HTTP(S) URL. For example, the Alerts Agent exposes an HTTP endpoint on port 8001 and is named ‘mbta-alerts’ (Fig. 2). The Locator in its passport is this URL.

Figure 2: Example of a Locator in an AI Agent Digital Passport

AI Digital Passport

AI digital passports are essential to any AI agent registry and discovery service, as their metadata includes the AI digital passport: public metadata cards and private metadata cards (Fig. 1). 

AI digital passports contain:

• Public Metadata: The digital AI agent passport card is registered with the registry and discovery service. It contains public metadata (agent records) about the functions the agent can perform, and hard constraints (security specifications) on how and with whom the agent will communicate with potential peers (Fig. 3). 
• Private Metadata: The digital AI agent deployment standard is registered with the deployment infrastructure. It contains private metadata about the agent’s implementation and resource requirements.

For example, this is the public metadata for the AI digital passport for the RoutePlanner agent (Fig. 3). 

Figure 3: Example of Public Metadata in an AI Agent Digital Passport

When a target agent starts, it publishes an AI digital agent passport to an agent registry (Fig. 1). The requester agent or the orchestrator in our reference implementation searches the registry for matching agents and returns the relevant agents. The registry validates agent metadata to ensure accuracy, monitors agent status, and verifies that the AI digital agent passport contains all required information for the skills and capabilities. 

Now that we have an understanding of agent discovery, registry services, and the storage of agent digital passports, we are ready to learn about the Northeastern registry, a single registry model, a “yellow pages” for AI agents built on Akamai Connected Cloud (Linode) for the MBTA Transit Conversational Intelligence application.

Single Registry Model

A single registry model is an architectural pattern in which an agent’s AI digital passport is stored. Enterprises operate in heterogeneous environments with a diverse mix of technologies for building agents. There are plenty of agent frameworks available, from Salesforce, ServiceNow, Microsoft, Langgraph, AutoGen, OpenAI’s Assistant API, CrewAI, LlamaIndex, and others. In addition, agent frameworks offer their own version of a single-registry model: agent registries or catalogs, each with its own constructs and rules of engagement. with its own set of constructs and rules of engagement. Currently, there are more than 15 popular single-registry models.

As we developed our reference MBTA Transit Conversational Intelligence application, we needed a way for agents to discover one another dynamically. A centralized directory where agents advertise their capabilities and requesters find available services. To do this, we built the Northeastern registry, a single-registry model implemented as a Flask instance with MongoDB to store metadata for every agent in our ecosystem (Fig. 4). A target agent is registered with the Northeastern registry using its AI agent digital passport. Currently, the agents: Alerts, RoutePlanner, StopFinder, and Exchange agents are registered manually with the Northeastern registry through REST API calls.

The Northeastern registry, deployed on Akamai Connected Cloud (Linode), has over thirty registered agents and four live agents across various domains, including transit, food ordering, financial services, career tools, emergency response, and healthcare (Fig. 4). 

Figure 4: Northeastern Registry for Agent Discovery

To answer our previous question: “I want to go from Harvard to Park Street. What are all the stops, routes, and alerts I require for this trip?”, here is what happens behind the scenes. When the exchange agent needs to discover available agents, it first calls the registry’s agent endpoints, which return the registered agents with their metadata, including capabilities, descriptions, and endpoints. The LLM (GPT-4o-mini) helps understand the description, extracts the intent from the user prompt, and matches the capabilities to requirements and selects the most appropriate agents to call.

While the single-registry model works well for our reference application, enterprises want to build business workflows across multiple agent frameworks. Regardless of the tools you use to build your agents, interoperability and cross-registry collaboration are vital. This is where the federated registry model has the potential to come into play, enabling us to build global AI registries. It represents a critical evolution in enterprise AI infrastructure. Just as the early internet evolved from isolated corporate networks into a globally connected system through standardized protocols, agent ecosystems must move from siloed single-registry deployments to federated discovery spanning organizational boundaries. 

Federated Registry Model

This single-registry model works well for a contained ecosystem. But what happens when agents need to collaborate across organizational boundaries? A university researcher building a transit app might need MBTA routing agents from Northeastern, computer vision agents from an enterprise catalog, and government data agents from a municipal registry. Each organization can maintain its own registry with its own schema format or a custom format. 

The federated registry model represents a paradigm shift with the potential to revolutionize the disconnected agentic architectural frameworks. They can enhance operational efficiency and drive innovation by fostering a decentralized, agentic global architecture of autonomous agents that communicate, collaborate, and learn from one another via federated learning.

To advance and test the feasibility of a federated, agentic global architecture, we began by integrating the AGNTCY-ADS and MIT-NANDA registries into the Akamai Connected Cloud (Linode) and, in addition, used the firewall. By prepopulating these registries with agents, we experimented and operated a unified network of registries. The Northeastern switchboard explains how schema translation works here, with an understanding of the different metadata formats. This way, we could discover agents by providing the switchboard with the registry endpoints for the MIT-NANDA and AGNTCY-ADS registries.

Consider this scenario: A user asks to “analyze MBTA ridership patterns and generate a formatted compliance report.” Our MBTA agents can provide the ridership data, but we do not have agents specialized in statistical analysis or document generation. Should we build these capabilities from scratch, or could we leverage existing specialized agents from other organizations?

This is where registry interoperability becomes essential. The MIT-NANDA and AGNTCY-ADS registries may host these required agents, matching the required capabilities to the user prompt. If the exchange agent could discover and invoke agents from these external registries, we could compose solutions from best-in-class components across organizational boundaries rather than reimplementing every capability internally. But each registry evolves independently, with its own schema convention. Here is an example of how metadata for different AI digital agent passports is stored across registries (Fig. 5).

Figure 5: Different Schemas of AI Digital Agent Passport for Different Single Registry Models

Both agent record formats describe similar capabilities, real-time MBTA service alert monitoring, but in different schemas. The differences can be seen in the field names, not in the base format of the agent passport. The exchange agent can understand different schemas with the help of schema translation, understanding metadata information from different registries that come through the switchboard.

Schema translation helps identify the formats used by these agents and ultimately translates them. Without it, you would require custom code to bridge each unique registry metadata schema. But we still need a solution for discovering these agents across multiple registries. And the switchboard helps address this problem.

Switchboard

As all agents have their agent records and metadata, they may not always be registered in the same format. Some agent records may be in simple JSON format, others in the OASF format, and some in Google’s standard metadata format. But what if these formats could be translated from one format to another?

The switchboard code deployed on Akamai Connected Cloud (Linode) uses adapters, specialized connectors that know how to communicate with each registry type (Fig. 6). Each adapter translates the query into the registry’s native format, executes the search using the registry’s protocol, translates responses back to the original format, and returns results to the switchboard. Let us now get into how this works with relevance to the MBTA transit agents and the exchange agent.

Figure 6: Switchboard Implementation & Discovery Service

User prompt: “I need to get from Park Street to Kenmore. Check for any alerts and show me the route.”

Exchange agent to Switchboard: When the exchange agent queries the switchboard  for a specific agent by capability-based search, such as @neu:mbta-alerts, @nanda:mbta-planner, or @agntcy:mbta-routes, the switchboard parses the namespace prefix to determine which registry adapter to invoke (Fig. 6). The switchboard adapters are in play in the current architecture:

• A local switchboard adapter that uses the REST-API to prompt the MIT-NANDA registry,
• A Northeastern adapter that makes HTTP requests to the Northeastern registry, 
• An AGNTCY-ADS adapter that uses gRPC to communicate with the AGNTCY-ADS registry. 

Each adapter executes the lookup using its registry’s native protocol (Fig. 6). REST API calls are made to the Northeastern and MIT-NANDA registry agents, and gRPC requests using protocol buffers to AGNTCY-ADS agents via the AGNTCY-ADS registry, which then translates the response into the MIT-NANDA AI digital agent passport format. The AGNTCY-ADS adapter performs the most complex translation, mapping OASF’s hierarchical skills taxonomy and typed locators into MIT-NANDA and Northeastern’s registries flat capabilities array and endpoint URLs using deterministic field-extraction rules (Fig. 7). 

Figure 7: Example of Cross-Registry Coordination using the Switchboard

So this way the switchboard returns a translated, unified response to the Exchange agent, which can then process all agent metadata consistently, regardless of the originating registry’s schema. Following this, the Exchange agent’s LLM evaluates these available agents, calls the agents in a sequence, and then synthesizes the responses it received from each agent. 

From an Exchange agent’s perspective, the switchboard is invisible, which is exactly the point. When users ask about accessible MBTA routes, they may not know or care about the scene algorithm routing, which involves coordinating three agents registered in different systems, each using a different metadata format. They just get the best answer from the best available agents. This transparency is the hallmark of well-designed infrastructure. 

The internet we know was designed for humans making requests to static servers. You type “google.com,” and the Domain Name System (DNS) translates it to an IP address. DNS does not ask you which domain name server to query, and Google will not require you to specify which websites to search for. The switchboard delivers the same seamless experience for agent discovery. As the ecosystem scales and more registries join the federation registry network, users will continue to ask questions in natural language and get comprehensive answers, oblivious to the complex orchestration happening beneath the surface.

The Case for Dynamic DNS for AI Agents

Despite the considerable advances presented in this blog, several challenges remain unresolved. Currently, in our MBTA Transit Conversation Intelligence implementation, digital AI agent passports store the agent locator as a single static URL. This poses scalability and security issues because the same URL is given to all potential requesting agents. Instead, the locator can be represented as an Agent Name that resolves to a tailored endpoint based on the requester’s context. When a requester agent resolves a target agent’s name, the switchboard should consider the target agent’s location, device type, network conditions, and the real-time health and load of all available endpoints to return a tailored URL. 

An Agent Name Resolution System will need a robust, secure infrastructure at a scale comparable to the existing Internet DNS system. Similar to how Akamai developed Dynamic DNS for webpages in the early 2000s, AI Agent Name resolution needs to extend dynamic DNS to return more than just a server’s IP address. Communication between AI Agents will go beyond simple web-server protocols, for example, using peer-to-peer protocols such as A2A over a Cisco Slip server using a message bus. AI Agent communication can build on the established Internet protocols, but will be more demanding than simple client-server interactions.

In conclusion, the transition from a single model registry to a federated model is a significant step toward decentralized AI. However, the evolution from static URLs to dynamic Agent Name resolution is a step-function change that needs to be addressed for enterprise-scale global AI registries. The next blog post will detail the architecture of a dynamic name-resolution system and how to transform an agent name into a tailored URL.

References:

https://www.akamai.com/products/akamai-inference-cloud-platform

​​https://github.com/agntcy/oasf

https://github.com/projnanda/nanda-index

https://github.com/projnanda/nanda-index/blob/main/switchboard/README.md

https://docs.agntcy.org/dir/overview

https://www.akamai.com/glossary/what-are-dns-servers

https://www.akamai.com/glossary/what-is-dynamic-dns