Network Address for Every GroupChat

[nembal]

The Problem: Inter-Group Communication is a Wiring Problem

AutoGen excels at creating sophisticated conversations between agents within a GroupChat. However, communication between two separate GroupChat instances—especially across different processes or machines—reverts to a manual "wiring" problem. The same issue exists when an AutoGen agent needs to interact with an external, non-AutoGen agent (e.g., a standalone MCP server).

Developers are forced to hardcode client logic and endpoints into custom tools. This tightly couples agent systems, making them brittle and hindering the creation of truly dynamic, large-scale multi-agent topologies.

A DNS-Based Solution: Agent Interface Discovery (AID)

What's missing is a simple, robust discovery primitive at the network layer.

I've finalized a specification called Agent Interface Discovery (AID) that provides this. It uses a standard DNS TXT record to map a domain name directly to an agent's interface URI.

An entire AutoGen GroupChat, fronted by a simple API endpoint, could have a permanent address:

_agent.research-division.mycorp.com. IN TXT "v=aid1;p=openapi;uri=https://api.research.mycorp.com/v1"

How This Fits Directly into AutoGen's Architecture

This isn't an alternative to AutoGen's mechanics; it's a network-layer enhancement.

1. Exposing a GroupChat as a Discoverable Service:
A GroupChatManager can be exposed via a lightweight API (e.g., FastAPI). The UserProxyAgent acts as the entry point, receiving tasks and injecting them into the group. With AID, this entire coordinated system is no longer a silent black box; it has a public, discoverable address.

2. A Tool for Dynamic Discovery:
An AssistantAgent can be equipped with a new, powerful tool for discovery.

Consider this tool implementation:

# A new tool that could be registered with an AssistantAgent
from aid_client import AIDClient # Hypothetical client library

def discover_and_call_agent(domain: str, task: str) -> str:
    """Discovers an agent by its domain and delegates a task to it."""
    try:
        # 1. AID client performs DNS lookup for _agent.<domain>
        discovery_result = AIDClient.discover(domain)
        
        # 2. Connect to the discovered URI and send the task
        # (This would use a standard HTTP client based on the discovered protocol, e.g., 'openapi')
        response = make_api_call(discovery_result.uri, task, auth=discovery_result.auth)
        
        return response.text
    except Exception as e:
        return f"Failed to connect to agent at {domain}: {e}"

An agent with this tool can now be given a prompt like: "Get the Q3 sales forecast from the agent at sales-team.mycorp.com." The agent can now find and communicate with a completely separate GroupChat without any pre-configured connection.

The Immediate Benefits

• Decoupled Systems: The "research" and "sales" agent teams can be developed and deployed independently. As long as they have an AID record, they can find each other.
• True Interoperability: AutoGen agents are no longer limited to speaking only to other AutoGen agents. They can discover and interact with any AID-compliant service (MCP, A2A, etc.), truly breaking out of the framework's boundaries.
• Solves "Agent as a Service": This provides the missing discovery primitive that discussions like "Agent as a service" are calling for.

This standardizes the very first step of inter-agent communication, making the entire AutoGen ecosystem more modular, scalable, and powerful.

The spec is complete and ready to be used. I believe this is the architectural primitive AutoGen needs to scale its vision to the whole internet.

Explore the spec and live workbench: aid.agentcommunity.org