Dynamic Multi-agent Secured Collaboration Infrastructure Architecture

Intelligent agents have evolved rapidly in recent years, driven by advances in artificial intelligence models, computing platforms, and network connectivity. Early forms of agents were typically embedded within isolated systems and designed to perform narrowly defined tasks under predefined conditions. Their interactions with external entities were limited and often mediated by tightly coupled application logic . With the increasing availability of large-scale AI models, edge computing resources, and programmable network infrastructures, agents are becoming more autonomous, adaptive, and capable of operating across distributed environments. Modern agents can perceive changes in their environment, make decisions based on local or shared information, and interact with other agents and tools in order to achieve complex objectives. These interactions are no longer confined to static configurations or single administrative domains, but increasingly span devices, networks, and application platforms. As agents continue to proliferate, they are forming large-scale collaborative systems in which multiple agents dynamically discover each other, exchange information, and coordinate actions. Such systems exhibit highly dynamic behavior, including frequent changes in agent population, roles, and interaction patterns. The resulting agent ecosystems resemble an open, interconnected environment rather than a collection of isolated applications. The evolution toward large-scale, dynamic agent ecosystems introduces new challenges for the underlying network infrastructure. While agents are capable of sophisticated reasoning and decision-making, their ability to collaborate effectively depends on the availability of common, scalable, and interoperable networking support. This document focuses on the architectural aspects of enabling dynamic multi-agent collaboration from a network and infrastructure perspective. It examines how network control and forwarding functions can be extended to recognize agents as first-class entities and provide generic support for agent identification, discovery, semantic routing, and coordination. The architecture is intended to support a wide range of agent types, including on-device agents, network-resident agents, and third-party agents, without imposing assumptions about their internal implementation. The scope of this document is limited to architectural concepts and functional building blocks. It does not define specific protocols, data models, or security mechanisms, nor does it prescribe particular deployment scenarios or application workflows. Instead, it provides a foundational framework upon which more detailed specifications, including protocol designs and security architectures, can be developed in subsequent documents.

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 .

The following terms are defined in this draft: DMSC: Dynamic Multi-agent Secured Collaboration. The framework and infrastructure enabling secure and efficient collaboration among dynamic agents. Agent: An automated intelligent entity capable of e.g interacting with its environment, acquiring contextual information, reasoning, self-learning, decision-making, executing tasks (autonomously or in collaboration with other Al Agents) to achieve a specific goal. Agent Gateway: The Agent Gateway is a functional entity that serves as the infrastructure for enabling interconnection and collaboration among agents. While its core role remains consistent, it is inherently flexible in deployment and can be realized in various forms—ranging from a network service to a dedicated gateway—depending on the architectural and operational requirements of different network environments. Agent Management Center (AMC): It is the trusted infrastructure service responsible for agent identity lifecycle management and credential issuance.

The proliferation of intelligent agents fundamentally reshapes interaction patterns and control dynamics in future networks. Agent interactions are typically short-lived, context-dependent, and driven by task semantics rather than static endpoints. Moreover, agents may dynamically join or leave collaborative groups, migrate across administrative domains, or change roles over time. These characteristics introduce new requirements for network infrastructures, including agent-level identity management, capability-aware communication, scalable registration and discovery, cross-domain collaboration support, and adaptive routing, as also reflected in [draft-yu-ai-agent-use-cases-in-6g]. Collectively, these requirements indicate that future networks must go beyond passive connectivity and actively support dynamic multi-agent collaboration. The core idea of Dynamic Multi-agent Secured Collaboration (DMSC) is to elevate key collaboration-related functions into the network infrastructure. Instead of embedding all coordination logic within applications or agent frameworks, DMSC leverages infrastructure-level capabilities exposed through control-plane and forwarding-plane functions. This approach enables the network to recognize agents as first-class entities, maintain high-level collaboration context, and make informed decisions on discovery, routing, and coordination support in a scalable and interoperable manner.

Figure 1 illustrates the overall architecture for dynamic multi-agent collaboration from an infrastructure-centric perspective. The architecture positions the network infrastructure as an active participant in agent collaboration, while preserving the autonomy and task-level reasoning of individual agents. In this architecture, the network does not execute agent logic or interpret task semantics. Instead, it provides generic support functions that enable agents to collaborate more efficiently and reliably. Agents remain autonomous, while the network supplies shared infrastructure capabilities. From an infrastructure perspective, the architecture is organized into three logical layers: Management Plane: governs authentication, capability taxonomy, observability and policy aspects. Control Plane: Manages agent registration, discovery, invocation, lifecycle, and capability information maintenance and so on. Forwarding Plane: Supports semantic routing for agent interactions.

| - Agent Registration |<--> | ... | | | | | | - Agent Invocation | | - Agent Invocation | | | | | | | | - Agent Discovery | | - Agent Discovery | | | | | | | | - Capability Directory | | - Capability Directory | | | | | | | +-------------------------+ +-------------------------+ +--------------------+ | | | | | Control & Policy | Control | Control | | | | v v & Policy v & Policy | | | | +------------------------+ +-------------------------+ +-------------------+ | | | | | Forwarding Plane | | Forwarding Plane | | Forwarding Plane | | | | | |------------------------+ +-------------------------+ +-------------------+ | | | | | - Semantic Routing | | ... | | ... | | | | | | - ... | | | | | | | | | +------------------------+ +-------------------------+ +-------------------+ | | | +---------------------------------------------------------------------------------------+ | +------------------^ ------------------------^ ------------------------------^ ------------+ |Registration | Registration |Registration | | | +--------------------+ +--------------------+ +--------------------+ | Agent A | | Agent B | | Agent C | |--------------------| |--------------------| |--------------------| | - Capabilities | | - Capabilities | | - Capabilities | ... | - Local Reasoning | | - Local Reasoning | | - Local Reasoning | +--------------------+ +--------------------+ +--------------------+ Figure 1 The infrastructure architecture of dynamic multi-agent collaboration ]]> On top of this architecture, agents engage in collaborative activities driven by task intents, shared goals, and capability information. Agents are responsible for local reasoning, decision-making, and execution of task-specific logic. The network does not interpret agent semantics or execute agent logic; instead, it provides common infrastructure capabilities that support efficient and scalable collaboration among agents. Above the network infrastructure, a Management and Orchestration Plane provides non-real-time management functions, including agent authentication, agent capability taxonomy management, policy management, observability and analytics. This plane supplies policy, trust, and state-related inputs to the network infrastructure. The network infrastructure itself is composed of multiple agent gateways, each implementing a common set of logical functions, and the gateways support hierarchical deployment. Within each gateway, the Control Plane provides agent-aware control functions, including agent identity management, capability directory maintenance, registration, and discovery control. These functions enable the network to recognize agents as first-class entities and maintain a consistent view of agent-related information across the infrastructure. By decoupling agent identity from physical location through capability identifiers, the control plane supports dynamic agent lifecycle events such as mobility, instantiation, and termination. The Forwarding Plane supports semantic routing by forwarding requests based on capability identifiers—such as /capability/ocr—rather than static IP addresses. When multiple instances of a capability are available, the forwarding plane may select a target based on real-time health and availability information—such as liveness or load—provided by the control plane. In the event of failure, it can perform fast failover to an alternative instance within the same capability group, ensuring continuity of service. When an agent joins the network, it authenticates and obtains trusted authorization through network controller; only verified agents may register their capabilities—such as “supports high-precision OCR” or “performs GDPR-compliant de-identification”—which are stored locally to form a capability directory. When another agent issues a capability-based discovery request (e.g., “find an OCR agent”), the local agent gateway either responds directly or securely synchronizes capability information with other agent gateways—including across domains or clouds—to locate eligible candidates. Once a target is identified, the request is forwarded via semantic routing (e.g., using /capability/ocr) to the appropriate instance. Overall, this architecture establishes a clear division of responsibilities: agents focus on intelligent behavior and task execution, while the network infrastructure provides capability-based control, semantic forwarding, and secure coordination mechanisms. This separation enables dynamic multi-agent collaboration to scale across heterogeneous environments—on-premises, at the edge, or in the cloud—while allowing agents and the network to evolve independently.

In large-scale dynamic multi-agent environments, agents cannot be effectively supported using traditional host- or service-based identifiers alone. Agents may be instantiated dynamically, migrate across network locations, or operate concurrently on the same physical node. As a result, the network requires a mechanism to identify agents as logical entities that are decoupled from network topology. The proposed architecture introduces network-visible agent identifiers that represent agents independently of their physical location or hosting environment. These identifiers enable the network to consistently recognize agents across control and forwarding functions, even as underlying network bindings change. Beyond basic identification, the architecture supports forming an agent capability directory on agent gateways.

Agent discovery is a fundamental prerequisite for collaboration, yet traditional discovery mechanisms are typically designed for relatively static services or tightly scoped environments. In contrast, multi-agent collaboration requires discovery mechanisms that can operate across heterogeneous platforms, adapt to dynamic agent populations, and respect administrative boundaries. In DMSC architecture, agent discovery is provided as an infrastructure-level function, rather than being entirely implemented within agent frameworks. The network supports discovery queries based on agent identifiers, advertised capabilities. This allows agents to locate suitable collaborators without requiring global knowledge or centralized coordination.

Traditional routing mechanisms forward packets based on destination addresses without awareness of application intent. In dynamic multi-agent collaboration, however, interactions are driven by *what* is needed—such as a specific capability—rather than *where* a fixed endpoint resides. The DMSC architecture addresses this by introducing semantic routing: requests are expressed in terms of agent capabilities (e.g., "/capability/ocr"). Semantic routing enables flexible agent invocation without hard-coded endpoints. A request for a given capability can be routed to any authorized and available instance that has declared that capability. If the selected instance becomes unavailable, the network may fail over to another instance within the same capability group, provided such redundancy exists.

Effective collaboration among dynamic agents requires consistent handling of capabilities and policies, especially when interactions span multiple domains or network segments. The DMSC architecture supports secure synchronization of capability declarations and policy constraints at the infrastructure level. Capability information associated with an agent—such as its declared functions (e.g., OCR, payment validation) and security attributes (e.g., GDPR compliance, authentication requirements)—can be registered with the control plane and synchronized across domains. Where appropriate, these capability descriptions may be bound to policy rules that govern access and interaction. Security-related attributes, such as authorization scope or domain-specific constraints, can be attached to capability entries to ensure that interactions remain compliant with local regulations and trust boundaries. In cross-domain scenarios, policy abstraction mechanisms support controlled translation or normalization to enable interoperability while respecting local governance.

As multi-agent systems scale, gaining visibility into collaboration-level behavior becomes essential for effective operation and troubleshooting. Traditional network observability focuses on flows and endpoints, offering limited insight into agent interactions and coordination dynamics. The DMSC architecture introduces operational visibility at the collaboration level by enabling controlled observation of key interaction events. Observable entities may include: Agent registration and abstract capability advertisements. Capability-based discovery activities and outcomes. Semantic routing decisions and high-level invocation outcomes. Association with network resources and applied policy controls. This visibility is not intended to expose agent internals or infer application logic, but to provide sufficient information for monitoring, auditing, root cause analysis, and performance optimization. The collected telemetry can be used by management and orchestration systems to support long-term optimization—such as identifying underutilized capabilities or detecting policy violations. It may also inform policy refinement and infrastructure planning, but does not drive real-time control-plane decisions or forwarding-plane behavior. To address privacy and security concerns, exposure of observable data is controlled through policy mechanisms, ensuring that only authorized parties can access relevant information.

This section presents two deployment cases for fixed network and mobile network environments respectively, illustrating the practical implementation of the proposed architecture. This is not intended to restrict implementation solutions, but to demonstrate how network infrastructure defined in the architecture can be deployed by leveraging existing or upgraded network elements.

In a fixed broadband network, gateways can be implemented as enhanced agent gateways deployed at aggregation layers or service edge nodes. These AGWs are positioned logically between access networks and service domains, enabling them to perform registration, authorization mediation, capability abstraction, and semantic routing functions without requiring changes to end-user access infrastructure. In such deployments as shown in figure 6: Agent registration and authentication are performed via the AGW and Agent Management Center (AMC). Capability digest exchange occurs between AGWs. Semantic resolution is handled hop-by-hop across AGWs. Agents establish peer-to-peer semantic sessions after gateway-mediated coordination. This example shows that agent gateways in fixed network can be equipped with logical coordination functions to serve as functional gateways, enabling agent registration, synchronization, scheduling and other related operations.

| AGW 2 |---| Agent B | +----------+ +---------+ | | +---------+ +---------+ | | +------------+ | Routers | +------------+ Figure 2 Deployment Example: Fixed Network with Agent Gateway Realization ]]>

In a mobile operator network (e.g., a 6G network), AI capabilities and technologies are expected to be leveraged subject to operator policies and configurations. AI Agents, which refer generally to agents that autonomously perform tasks on behalf of users, systems, and/or applications, can understand complex requests and improve network efficiency. In addition, capabilities and services such as sensing, real-time data processing, telemetry, analytics, and others within a 6G network may also be provided as “Tools” to third-party applications. Below figure shows an example of AI agents, an Agent Management Center and an Agent Gateway deployed in the mobile operator network. The architecture of 6G is still in discussion, thus some functionalities are described by using some 5G NFs as typical examples. User initiates intent in nature language and receive human-readable result. Intent analysis takes place at two stages: (Optional, based on UE capabilities) The UE converts natural-language intent to operator-defined intent and also translates operator-defined results to human-readable results based on internal implementation. (Mandatory) The network function (NF) with agent capability in the mobile operator core network comprehends and analyzes the intent. Based on the analyzed intent, a subsequent workflow is generated. Typically, the NF that terminates NAS messages (e.g., AMF in 5G) can either comprehend the intent (when the AMF includes agent capability) or forward the intent to an agent-enabled NF in the core network (when the AMF does not include agent capability). Agent-enabled NFs request AIC allocation from the Agent Gateway. The NF (e.g., AMF in 5G) that terminates NAS messages and manages UE registration may request AIC from the Agent Gateway on behalf of the agent in the UE. The Agent Management Center is responsible for agent authentication and authorization. The authentication and authorization procedure for agents (Agents ↔ Agent Gateway ↔ Agent Management Center) may reference the authentication and authorization procedure for UEs (e.g., UEs <-> AMF <-> UDM <-> AUSF in 5G). Agent-enabled NFs register with the Agent Gateway and discover each other by querying the Agent Gateway. The registration and discovery mechanism is similar to the functionality provided by the NRF in 5G networks. However, standardization of agent capabilities is essential for the accuracy and efficiency of agent discovery. The NF (e.g., AMF in 5G) that terminates NAS messages and manages UE registration may interact with the Agent Gateway on behalf of the agent in the UE. However, the discovery of the agent on the UE takes the UE connection state into account. Service-based interfaces may be enhanced to support agent communication, or agent-based interfaces may be introduced to support AI traffic carrying Agent-to-Agent semantic data. The AI capabilities supported by the mobile operator network may be exposed as agent tools and invoked by third-party AI agents via the Agent Gateway, which performs protocol conversion for different agent communication protocols if necessary, while AI traffic transmitted through the mobile operator network may be identified to guarantee performance requirements. The NF supporting session management (e.g., SMF in 5G) can be enhanced, or a new NF may be introduced to support the management of Agent-to-Agent semantic sessions between the agent residing in the UE and the agent residing in the operator core network.

| +--------+ +-----------+ +----------+ |<-------------> | +------+ | | +--+--------+ | | | NF | | NF with | | Agent | | | | Agent| | | | ^ | | | | | Agent | | Gateway | | | +------+ | | v | | | +---+----+ +-----+-----+ +-----+----+ | | | | +------+----+ | | | | | | | +------+ | | | UE OS Layer | | | | | | | | Agent| | | | Agent | | | | | | Service Based Interface| | +------+ | | +--+--------+ | Intent Execution| | | | (Agent Enhancement) | | | | | ^ | <-------------> |--------+----+----------+----+-----------+----+------------------ | <------------->| . | | | | | Result | | | | | | . | | | | | | | | | | | . | | v | | | | | | | | . | | +------+----+ | | +------+----+ +----+---+ +-------+-----+ | | . | | | UE Modem | | | | NF with | | NF | | Agent | | | | | | | | | | Agent | | | | Management | | | +------+ | | +-----------+ | AI traffic | +-----------+ +--------+ | Center | | AI Traffic | | Agent| | | | <-------------> | +-------------+ | <------------->| +------+ | | | Transfer | | Transfer | | | UE | | | | | +-----------------+ +----------------------------------------------------------------------+ +------------+ Figure 3 Deployment Example: Mobile Operator Network ]]>

This architecture introduces several security considerations, including risks related to agent identity spoofing, capability misrepresentation, semantic routing manipulation, cross-domain trust inconsistencies, and information leakage through enhanced observability. Detailed security mechanisms are outside the scope of this document.

TBD