



Network Working Group                                     L. Muscariello
Internet-Draft                                               M. Papalini
Intended status: Informational                                M. Sardara
Expires: 28 August 2026                                         S. Betts
                                                                   Cisco
                                                        24 February 2026


 An Overview of Messaging Systems and Their Applicability to Agentic AI
                     draft-mpsb-agntcy-messaging-01

Abstract

   Agentic AI systems require messaging infrastructure that supports
   real-time collaboration, high-volume streaming, and dynamic group
   coordination across distributed networks.  Traditional protocols like
   AMQP, MQTT, and NATS address some requirements but fall short on
   security, particularly regarding [AMQP] [MQTT] [NATS] post-compromise
   protection and quantum-safe encryption essential for autonomous
   agents handling sensitive data.

   This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP
   over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical
   for GenAI agent systems: streaming performance, delivery guarantees,
   security models, and operational complexity.  We examine how each
   protocol's design decisions impact agentic AI deployments, from
   lightweight edge computing scenarios to large-scale multi-
   organizational collaborations.

   AGNTCY SLIM emerges as a purpose-built solution, integrating Message
   Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC7540]
   to provide quantum-safe end-to-end encryption, efficient streaming,
   and OAuth-based authentication [RFC6749].  Unlike transport-layer
   security approaches, SLIM's MLS implementation ensures secure
   communication even through untrusted intermediaries while supporting
   dynamic group membership changes essential for collaborative AI
   agents.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/agntcy/slim-spec.







Muscariello, et al.      Expires 28 August 2026                 [Page 1]

Internet-Draft            agncty-messaging-eco             February 2026


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 28 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Analysis for Agentic AI Systems  . . . . . . . . . .   4
     3.1.  Traditional Enterprise Messaging: AMQP  . . . . . . . . .   4
     3.2.  IoT-Optimized Messaging: MQTT . . . . . . . . . . . . . .   4
     3.3.  Cloud-Native Messaging: NATS  . . . . . . . . . . . . . .   5
     3.4.  Browser Integration: AMQP over WebSockets . . . . . . . .   5
     3.5.  High-Throughput Streaming: Apache Kafka . . . . . . . . .   6
     3.6.  Next-Generation Agent Messaging: SLIM . . . . . . . . . .   7
     3.7.  Security Considerations for Agentic AI  . . . . . . . . .   9
     3.8.  Performance Implications  . . . . . . . . . . . . . . . .   9
     3.9.  Deployment and Operational Considerations . . . . . . . .  10
   4.  RPC in Agentic Protocols and Relationship to Messaging  . . .  11
     4.1.  RPC vs. Messaging: Synchronous vs. Asynchronous . . . . .  11
     4.2.  When Asynchronous Feels Synchronous (Interactive
           Real-Time)  . . . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  Bridging Patterns: RPC over Messaging and Streaming
           RPC . . . . . . . . . . . . . . . . . . . . . . . . . . .  12



Muscariello, et al.      Expires 28 August 2026                 [Page 2]

Internet-Draft            agncty-messaging-eco             February 2026


     4.4.  A2A and MCP in Context  . . . . . . . . . . . . . . . . .  12
     4.5.  SLIM RPC (SRPC) . . . . . . . . . . . . . . . . . . . . .  12
     4.6.  Advantages of SLIM for A2A APIs . . . . . . . . . . . . .  13
     4.7.  Security Implications . . . . . . . . . . . . . . . . . .  13
   5.  Comparison  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction

   When designing a multi-agent system for generative AI, the messaging
   layer becomes a critical piece of infrastructure.  GenAI agents—built
   with frameworks like LangGraph, AutoGen, or LlamaIndex—often need to
   collaborate in real time, exchange high volumes of streaming data
   (e.g., token-by-token outputs), and coordinate complex tasks such as
   voting or consensus.  Moreover, security requirements extend well
   beyond basic TLS; in scenarios where agents share sensitive models or
   partial computations, post-compromise security and robust end-to-end
   encryption are essential.

   In practice, you’ll want a protocol that efficiently handles one-to-
   many or many-to-many communication, supports dynamic membership (with
   agents joining or leaving on the fly), and scales to accommodate a
   “forest” of agents spread across global networks.  Some protocols
   excel at ultra-low-latency, high-throughput streaming—critical for
   continuous token streams or aggregated embeddings—while others
   emphasize strong consistency and durability.  Additionally, advanced
   cryptographic features such as automatic key rotation and forward
   secrecy are vital when compromised credentials must not enable an
   attacker to decrypt future communications.

   Below, we compare six popular messaging protocols—AMQP, MQTT, NATS,
   AMQP over WebSockets, Kafka, and the emerging AGNTCY SLIM (Secure
   Low-Latency Interactive Messaging)—across dimensions that matter for
   GenAI agent systems: streaming performance, delivery guarantees,
   flexible pub/sub patterns, agent coordination, security (including
   end-to-end encryption and zero-trust support), and real-world
   adoption.



Muscariello, et al.      Expires 28 August 2026                 [Page 3]

Internet-Draft            agncty-messaging-eco             February 2026


3.  Protocol Analysis for Agentic AI Systems

   The following sections provide detailed analysis of each messaging
   protocol in the context of agentic AI requirements.

3.1.  Traditional Enterprise Messaging: AMQP

   The Advanced Message Queuing Protocol (AMQP), most commonly
   implemented through RabbitMQ, represents the gold standard for
   enterprise messaging systems.  AMQP's strength lies in its
   sophisticated message routing capabilities through exchanges, queues,
   and routing keys, enabling complex message flow patterns essential
   for enterprise applications.

   For agentic AI systems, AMQP offers several advantages.  Its support
   for both at-least-once and exactly-once delivery semantics
   (particularly in AMQP 1.0) ensures reliable message delivery between
   AI agents, which is crucial when agents are coordinating critical
   tasks or sharing expensive computational results.  The protocol's
   durable queue support means that agent messages can persist across
   system restarts, preventing loss of important coordination data.

   However, AMQP's enterprise focus comes with trade-offs.  The protocol
   carries higher overhead due to its rich feature set, which may impact
   performance in high-frequency agent communication scenarios.
   Streaming capabilities require extensions like RabbitMQ Streams,
   adding complexity to deployments focused on real-time agent
   collaboration.

   Authentication in AMQP relies on traditional enterprise mechanisms
   like SASL, LDAP, and Kerberos, which integrate well with existing
   corporate identity systems but may not align with modern cloud-native
   authentication patterns preferred in AI infrastructure.

3.2.  IoT-Optimized Messaging: MQTT

   Message Queuing Telemetry Transport (MQTT) emerged from the IoT world
   with a focus on lightweight, efficient communication over constrained
   networks.  Its topic-based publish-subscribe model maps naturally to
   many agent communication patterns, where agents subscribe to topics
   representing different types of events or data streams.

   MQTT's three Quality of Service levels (QoS 0, 1, and 2) provide
   flexibility in balancing performance versus reliability.  For agentic
   AI systems, QoS 0 (at-most-once) works well for frequent status
   updates or non-critical notifications, while QoS 2 (exactly-once)
   ensures critical agent coordination messages are delivered reliably.




Muscariello, et al.      Expires 28 August 2026                 [Page 4]

Internet-Draft            agncty-messaging-eco             February 2026


   The protocol's very low overhead makes it attractive for scenarios
   involving large numbers of lightweight AI agents or edge computing
   deployments where bandwidth is constrained.  However, MQTT's IoT
   heritage shows in its limitations for agentic AI use cases.  Native
   streaming support requires broker extensions, and message-level
   security typically relies entirely on transport-layer TLS rather than
   end-to-end encryption.

   MQTT's authentication mechanisms, while sufficient for IoT devices,
   may not provide the sophisticated identity and access management
   features required for complex multi-agent AI systems involving
   different trust domains.

3.3.  Cloud-Native Messaging: NATS

   NATS represents a modern approach to messaging designed for cloud-
   native architectures.  Its lightweight design and support for
   multiple communication patterns—publish-subscribe, request-reply, and
   queue groups—make it particularly well-suited for microservices-based
   AI agent deployments.

   The protocol's core at-most-once delivery semantics align well with
   scenarios where AI agents can tolerate occasional message loss in
   favor of high performance.  For use cases requiring stronger
   guarantees, NATS JetStream provides at-least-once delivery and
   streaming capabilities, though this requires additional
   infrastructure complexity.

   NATS's optional broker architecture offers interesting deployment
   flexibility for agentic AI systems.  While most deployments use a
   broker for efficiency, the protocol can support peer-to-peer
   communication, potentially enabling direct agent-to-agent
   communication in specialized scenarios.

   Authentication in NATS includes modern options like JWT tokens and
   NKey cryptographic authentication, aligning better with cloud-native
   security practices.  However, like MQTT, NATS relies primarily on
   transport-layer security rather than providing built-in end-to-end
   message encryption.

3.4.  Browser Integration: AMQP over WebSockets

   AMQP over WebSockets addresses a specific deployment challenge:
   enabling browser-based AI agents or user interfaces to participate in
   AMQP-based agent coordination systems.  This approach tunnels
   standard AMQP protocols through WebSocket connections, allowing web
   applications to overcome firewall restrictions and network topology
   limitations.



Muscariello, et al.      Expires 28 August 2026                 [Page 5]

Internet-Draft            agncty-messaging-eco             February 2026


   For agentic AI systems that include web-based components—such as
   user-facing AI assistants that need to coordinate with backend AI
   agents—this protocol variant provides a bridge between browser
   environments and enterprise messaging infrastructure.  The WebSocket
   Secure (WSS) transport ensures encrypted communication from browser
   to broker.

   However, the additional protocol layers (AMQP within WebSockets)
   introduce higher overhead compared to native AMQP or other
   lightweight protocols.  This makes AMQP over WebSockets primarily
   suitable for scenarios where browser integration is essential rather
   than for high-performance agent-to-agent communication.

3.5.  High-Throughput Streaming: Apache Kafka

   Apache Kafka represents a fundamentally different approach to
   messaging, based on distributed commit logs rather than traditional
   message queues.  This architecture provides exceptional throughput
   and built-in streaming capabilities that align well with certain
   agentic AI use cases.

   Kafka's partition-based topic model enables massive horizontal
   scaling, making it suitable for AI systems that need to process large
   volumes of training data, model updates, or inference results across
   distributed agent networks.  The platform's native streaming
   capabilities through Kafka Streams and KSQL provide powerful tools
   for real-time processing of agent-generated data.

   The protocol's built-in persistence across distributed clusters
   ensures that agent communication history is preserved and can be
   replayed, which is valuable for AI systems that need to audit agent
   decisions or retrain models based on historical interactions.
   Consumer groups enable multiple agents to process different
   partitions of the same topic concurrently, supporting parallel AI
   workloads.

   However, Kafka's strengths come with complexity costs.  The
   requirement for a distributed cluster infrastructure may be overkill
   for simpler agent coordination tasks.  While Kafka provides exactly-
   once semantics through transactions, the default at-least-once
   delivery may require additional deduplication logic in agent
   implementations.

   Kafka's security model, while comprehensive, relies primarily on
   transport-layer encryption and broker-based access controls rather
   than end-to-end message encryption, which may not meet the security
   requirements of AI systems handling sensitive model data or
   proprietary algorithms.



Muscariello, et al.      Expires 28 August 2026                 [Page 6]

Internet-Draft            agncty-messaging-eco             February 2026


3.6.  Next-Generation Agent Messaging: SLIM

   AGNTCY SLIM (Secure Low-Latency Interactive Messaging) represents a
   purpose-built protocol for modern agentic AI systems, designed to
   address the specific security, performance, and coordination
   requirements that existing protocols cannot fully satisfy.

   SLIM is intended as a transport layer for agent protocols like A2A
   and MCP.  It handles secure routing, group messaging, and end-to-end
   encryption so protocol implementations can focus on agent semantics.
   A registration-based model lets agents become reachable through the
   SLIM network without exposing server ports, while only routing nodes
   need to be publicly reachable.  This simplifies deployment for agents
   behind NATs and firewalls.

   SLIM's foundation on gRPC over HTTP/2 and HTTP/3 provides several
   immediate advantages for AI agent communication.  The binary protocol
   buffer wire format minimizes serialization overhead while supporting
   both binary and text data types essential for AI workloads.  HTTP/2's
   multiplexing capabilities allow a single connection to carry multiple
   concurrent agent conversations, reducing connection overhead in
   systems with many interacting agents.

   SLIM is architected as a distributed system with a clear separation
   of concerns:

   *  *Data plane*: Routes messages across SLIM nodes using only
      metadata for efficient forwarding and topology management.

   *  *Session layer*: Provides reliable delivery, MLS-based end-to-end
      encryption, and secure group management (create, invite, join,
      remove).

   *  *Control plane*: Orchestrates routing nodes, configuration, and
      administrative operations.

   Routing nodes run only the data plane, keeping infrastructure
   lightweight, while language bindings include the data-plane client
   plus the session layer for full security and reliability.

   The protocol's quality of service model explicitly addresses the
   diverse communication patterns found in agentic AI systems.  Fire-
   and-forget messaging supports high-frequency status updates and non-
   critical notifications, while reliable exactly-once delivery ensures
   critical coordination messages and expensive computational results
   are never lost.  This extends consistently across request-reply
   patterns and streaming communications.




Muscariello, et al.      Expires 28 August 2026                 [Page 7]

Internet-Draft            agncty-messaging-eco             February 2026


   Perhaps most significantly, SLIM's integration of Message Layer
   Security (MLS) provides quantum-safe, end-to-end encryption
   specifically designed for group communications.  Unlike transport-
   layer security approaches used by other protocols, MLS ensures that
   messages remain secure even when transmitted through potentially
   compromised intermediaries—a critical requirement for AI systems
   operating across multiple trust domains.

   The protocol's authentication model demonstrates particular
   innovation in addressing agentic AI security requirements.  By
   transporting MLS credentials and cryptographic proofs within OAuth
   bearer tokens over HTTP/2, SLIM achieves several important
   properties:

   *  *Interoperability*: Leverages standard HTTP/2 and OAuth libraries,
      reducing implementation complexity and improving compatibility
      with existing infrastructure

   *  *Scalability*: Single persistent HTTP/2 connections efficiently
      carry many MLS-secured messages between agents

   *  *Immediate revocation*: Malicious or compromised agents can be
      immediately ejected by revoking their OAuth tokens without
      requiring complex ratchet tree rebalancing operations

   SLIM's naming system is hierarchical and DID-inspired, for example:
   organization/namespace/service/instance.  This supports anycast
   routing (to any available instance), unicast routing (to a specific
   instance), and service discovery without hardcoded endpoints or
   external registries.  The structure maps cleanly to organizational
   boundaries and multi-tenant deployments.

   The protocol's support for both broker-based and peer-to-peer
   operation offers deployment flexibility.  While broker-based
   operation provides efficiency for multi-party group communications
   typical in agent coordination scenarios, peer-to-peer capabilities
   enable direct agent-to-agent communication when appropriate.  SLIM
   exposes two session types that map to common agent patterns: point-
   to-point sessions for tool calls and group sessions for coordination
   and broadcast.

   SLIM provides multi-language bindings.  Python and Go bindings are
   available today, with JavaScript/TypeScript, C#, and Kotlin in
   progress, enabling heterogeneous agent systems to interoperate on the
   same transport.






Muscariello, et al.      Expires 28 August 2026                 [Page 8]

Internet-Draft            agncty-messaging-eco             February 2026


3.7.  Security Considerations for Agentic AI

   Security requirements for agentic AI systems extend well beyond the
   capabilities provided by traditional messaging protocols.  The
   autonomous nature of AI agents, combined with their access to
   sensitive data and computational resources, creates unique threat
   models that messaging infrastructure must address.

   *Post-Compromise Security*: In traditional systems, credential
   compromise typically requires immediate revocation and re-
   authentication.  However, AI agents may operate for extended periods
   with limited human oversight.  SLIM's MLS implementation provides
   forward secrecy, ensuring that compromise of current credentials
   cannot decrypt past communications, and post-compromise security,
   guaranteeing that future communications remain secure even after
   credential compromise.

   *Quantum-Safe Cryptography*: As quantum computing advances threaten
   current cryptographic standards, AI systems—which may operate for
   years with the same cryptographic keys—need protection against future
   quantum attacks.  SLIM's quantum-safe MLS implementation provides
   this protection, while traditional protocols rely on classical
   cryptographic assumptions that may become vulnerable.

   *Multi-Domain Operations*: Agentic AI systems often span multiple
   organizational and security domains, with agents from different
   organizations collaborating on shared tasks.  Traditional protocols
   typically assume trust in messaging infrastructure, but SLIM's end-
   to-end encryption ensures secure communication even when messages
   transit through potentially untrusted intermediaries.

   *Dynamic Group Membership*: AI agent groups frequently change as
   agents join collaborations, complete tasks, or become unavailable.
   MLS's efficient group key management handles these membership changes
   while maintaining security properties, unlike approaches that require
   complete cryptographic context regeneration.

3.8.  Performance Implications

   The performance characteristics of messaging protocols significantly
   impact the behavior and capabilities of agentic AI systems,
   particularly as the number of agents and frequency of interactions
   scale.








Muscariello, et al.      Expires 28 August 2026                 [Page 9]

Internet-Draft            agncty-messaging-eco             February 2026


   *Latency Sensitivity*: Many AI agent interactions are latency-
   sensitive, particularly in real-time decision-making scenarios or
   when agents are coordinating time-critical tasks.  SLIM's HTTP/2
   foundation provides header compression and multiplexing that reduce
   per-message overhead, while the binary protocol buffer encoding
   minimizes serialization costs.

   *Throughput Requirements*: Large-scale agentic AI systems may involve
   thousands of agents generating substantial message volumes.  While
   protocols like Kafka excel at raw throughput, they may introduce
   latency through their log-based architecture.  SLIM balances
   throughput and latency through efficient connection reuse and
   optional reliability levels.

   *Connection Efficiency*: Traditional protocols often require separate
   connections for each communication pattern or security context.
   SLIM's connection multiplexing allows a single HTTP/2 connection to
   handle diverse communication patterns between agents, reducing
   resource consumption and connection establishment overhead.

   *Streaming Performance*: AI agents frequently exchange streaming
   data—such as token-by-token language model outputs or real-time
   sensor data.  SLIM's native gRPC streaming support over HTTP/2
   provides efficient bidirectional streaming without the overhead of
   connection-per-stream approaches.

3.9.  Deployment and Operational Considerations

   The operational characteristics of messaging protocols significantly
   impact the total cost of ownership and operational complexity of
   agentic AI systems.

   *Infrastructure Requirements*: Traditional enterprise protocols like
   AMQP require dedicated message broker infrastructure with high
   availability and clustering capabilities.  Kafka requires even more
   complex distributed infrastructure.  SLIM's optional broker
   architecture allows deployments to scale infrastructure complexity
   with system requirements.

   *Monitoring and Observability*: Debugging distributed agentic AI
   systems requires comprehensive visibility into agent communications.
   SLIM's foundation on standard HTTP/2 infrastructure enables use of
   existing observability tools and practices, while proprietary
   protocols may require specialized monitoring solutions.

   *Integration with Cloud Services*: Modern AI deployments increasingly
   rely on cloud services for scalability and managed operations.
   SLIM's HTTP/2 foundation integrates naturally with cloud load



Muscariello, et al.      Expires 28 August 2026                [Page 10]

Internet-Draft            agncty-messaging-eco             February 2026


   balancers, API gateways, and observability services, while
   specialized messaging protocols may require additional integration
   layers.

   *Compliance and Auditing*: AI systems in regulated industries require
   comprehensive audit trails and compliance capabilities.  SLIM's
   structured topic hierarchy and optional message persistence support
   regulatory requirements, while the end-to-end encryption provides
   compliance with data protection regulations.

4.  RPC in Agentic Protocols and Relationship to Messaging

   Most agent-facing interfaces in use today — notably A2A and the Model
   Context Protocol (MCP) — are Remote Procedure Call (RPC) oriented.
   They expose synchronous request/response semantics for tool
   invocation, resource listing, and capability execution.  This section
   clarifies how RPC relates to asynchronous messaging and how the two
   paradigms interoperate in agentic systems.

4.1.  RPC vs. Messaging: Synchronous vs. Asynchronous

   *  *RPC (A2A, MCP)*: Caller issues a request and blocks/awaits a
      timely response.  Semantics emphasize tightly scoped operations
      (for example, “call tool X with parameters Y”) with bounded
      latency and explicit error contracts.

   *  *Messaging (AMQP, MQTT, NATS, Kafka, SLIM)*: Decoupled producers/
      consumers communicate via topics/subjects/queues.  Delivery can be
      one-to-one, one-to-many, or many-to-many with loose coupling,
      buffering, and retries.  Producers are not inherently blocked by
      consumers.

   In practice, agentic applications need both: synchronous tool
   invocations for interactivity and asynchronous channels for streaming
   output, progress, coordination, and fan-out/fan-in patterns.

4.2.  When Asynchronous Feels Synchronous (Interactive Real-Time)

   Asynchronous transports can provide an interactive, “RPC-like”
   experience when: - A request message includes a correlation ID and
   reply-to destination. - The callee publishes a response on the
   indicated reply destination within a short SLA. - Client libraries
   surface responses as futures/promises and manage timeouts/retries.

   This underpins instant messaging UX and maps well to agent UIs where
   a user triggers an action and expects prompt, possibly streaming,
   results.




Muscariello, et al.      Expires 28 August 2026                [Page 11]

Internet-Draft            agncty-messaging-eco             February 2026


4.3.  Bridging Patterns: RPC over Messaging and Streaming RPC

   *  *Request/Reply over Pub/Sub*: Implement RPC by publishing a
      command event and awaiting a correlated reply event (applies to
      AMQP, NATS, MQTT, and SLIM topics).

   *  *Streaming RPC*: Use bidirectional streams (for example, gRPC over
      SLIM HTTP/2/3) to deliver token streams, partial results, or
      progress updates while retaining an RPC caller experience.

   *  *Sagas and CQRS*: For multi-step workflows across agents,
      coordinate via asynchronous orchestration with idempotency keys,
      correlation/causation IDs, and compensations.

   *  *Backpressure and Flow Control*: Prefer streaming transports
      (HTTP/2/3, gRPC) or messaging systems with flow control when
      returning large/continuous results.

4.4.  A2A and MCP in Context

   *  *A2A Agent Cards*: Describe capabilities/endpoints commonly
      invoked via RPC-style calls (tool execution, configuration).  They
      benefit from messaging for discovery, eventing, and long-running
      workflows.

   *  *MCP*: Standardizes RPC-like interactions (resources, tools,
      prompts).  For multi-party sessions, combine MCP RPC with a
      messaging layer for broadcast, presence, and coordination.

4.5.  SLIM RPC (SRPC)

   SLIM also supports a native RPC style via SRPC (Slim RPC), which
   layers request/response semantics on top of SLIM's interactive, real-
   time messaging.  SRPC addresses practical RPC concerns in distributed
   agent systems:

   *  Correlation and reply routing for synchronous calls over an async
      transport

   *  Idempotency keys and deduplication to make retries safe

   *  Lightweight synchronization/ordering guarantees for request/
      response and streaming

   *  Seamless fit for A2A/MCP-style tool calls while retaining SLIM's
      MLS security and multiplexing





Muscariello, et al.      Expires 28 August 2026                [Page 12]

Internet-Draft            agncty-messaging-eco             February 2026


   *  Supports all four gRPC interaction patterns (unary, server
      streaming, client streaming, bidirectional streaming)

   See SRPC reference and examples: SLIM RPC (SRPC) README
   (https://github.com/agntcy/slim/blob/main/data-
   plane/python/integrations/slimrpc/README.md).

4.6.  Advantages of SLIM for A2A APIs

   SLIM augments existing A2A-style RPC with capabilities that are
   difficult to achieve over plain request/response transports:

   *  *Simultaneous fan-out RPC (scatter-gather)*: Invoke a single RPC
      across many agents (by topic/group/labels) concurrently and
      aggregate responses (first-success, quorum, all-success) with
      correlation IDs.

   *  *Group addressing and dynamic membership*: Target MLS-secured
      groups; add/remove agents without reconfiguring endpoints.

   *  *Streaming responses*: Return partial results or token streams
      from each agent over a single multiplexed connection (gRPC over
      HTTP/2/3).

   *  *Idempotency and safe retries*: SRPC supports idempotency keys and
      deduplication, enabling robust retry without duplicating effects.

   *  *QoS, deadlines, and backpressure*: Apply delivery guarantees,
      per-call timeouts, and flow control to avoid overload while
      maintaining interactivity.

   *  *End-to-end security and multi-tenant isolation*: MLS E2E
      encryption and OAuth-based policy across both RPC and messaging
      channels.

   *  *Observability and tracing*: Correlation/causation IDs and
      standardized transport enable distributed tracing and per-agent
      metrics.

   These capabilities let A2A-style tool calls scale beyond one-to-one
   interactions, enabling broadcast queries, coordinated multi-agent
   actions, and efficient collection of results in real time.

4.7.  Security Implications

   *  *Identity and Authorization*: Reuse OAuth tokens across RPC (gRPC)
      and messaging (SLIM channels as topics) for consistent policy
      enforcement.



Muscariello, et al.      Expires 28 August 2026                [Page 13]

Internet-Draft            agncty-messaging-eco             February 2026


   *  *End-to-End Security*: MLS-backed secure channels (SLIM) so both
      RPC and messaging inherit end to end message encryption. ##
      Guidance: When to Choose What

   *  Use *RPC (A2A/MCP)* for low-latency, point operations with
      immediate feedback and well-defined error contracts.

   *  Use *Messaging* for broadcast/fan-out, decoupling, retries,
      buffering, and multi-party coordination.

   *  Use *Streaming RPC or RPC over Messaging* for interactive UX with
      partial/continuous results or uncertain duration operations.

5.  Comparison

   Table 1 provides a detailed comparison of three popular messaging
   protocols commonly considered for agent communication systems:

   +================+================+==================+==============+
   |Feature         | AMQP (e.g.     | MQTT             |NATS          |
   |                | RabbitMQ)      |                  |              |
   +================+================+==================+==============+
   |*Protocol Type* | Message        | Lightweight pub/ |Lightweight   |
   |                | queueing       | sub for IoT      |messaging     |
   |                | (queues/       |                  |(pub/sub, req/|
   |                | exchanges)     |                  |reply, queue  |
   |                |                |                  |groups)       |
   +----------------+----------------+------------------+--------------+
   |*Transport*     | TCP            | TCP (optionally  |TCP           |
   |                | (optionally    | TLS)             |(optionally   |
   |                | TLS)           |                  |TLS)          |
   +----------------+----------------+------------------+--------------+
   |*Message Model* | Queues,        | Topic-based      |Subjects (pub/|
   |                | exchanges,     |                  |sub), queue   |
   |                | routing keys   |                  |groups,       |
   |                |                |                  |request/reply |
   +----------------+----------------+------------------+--------------+
   |*QoS / Delivery*| At-least-once, | QoS 0 (at-most-  |At-most-once  |
   |                | exactly-once   | once), 1, 2      |(core), at-   |
   |                | (AMQP 1.0)     | (exactly-once)   |least-once    |
   |                |                |                  |with JetStream|
   +----------------+----------------+------------------+--------------+
   |*Streaming*     | Via            | Not native       |Native with   |
   |                | extensions/    | (requires broker |JetStream     |
   |                | plugins (e.g.  | extensions)      |              |
   |                | RabbitMQ       |                  |              |
   |                | Streams)       |                  |              |
   +----------------+----------------+------------------+--------------+



Muscariello, et al.      Expires 28 August 2026                [Page 14]

Internet-Draft            agncty-messaging-eco             February 2026


   |*Persistence*   | Yes (durable   | Broker-dependent |Optional via  |
   |                | queues)        |                  |JetStream     |
   +----------------+----------------+------------------+--------------+
   |*Protocol       | Higher (rich   | Very low         |Very low      |
   |Overhead*       | feature set)   |                  |              |
   +----------------+----------------+------------------+--------------+
   |*Broker         | Yes            | Yes              |Optional (but |
   |Required*       |                |                  |common)       |
   +----------------+----------------+------------------+--------------+
   |*Authentication*| User/password, | Username/        |NKey, JWT,    |
   |                | SASL (e.g.,    | password or      |token, user/  |
   |                | LDAP,          | custom tokens    |password      |
   |                | Kerberos)      |                  |              |
   +----------------+----------------+------------------+--------------+
   |*Transport      | TLS            | TLS              |TLS           |
   |Security*       |                |                  |              |
   +----------------+----------------+------------------+--------------+
   |*Message        | Typically      | Usually none at  |None in core  |
   |Security*       | broker-level   | message level;   |(TLS in       |
   |                | or plugin-     | rely on TLS      |transit),     |
   |                | based          |                  |JetStream can |
   |                | encryption     |                  |encrypt at    |
   |                |                |                  |rest          |
   +----------------+----------------+------------------+--------------+
   |*Binary or Text*| Binary framing | Binary framing   |Text-based    |
   |                |                |                  |protocol      |
   |                |                |                  |(core), binary|
   |                |                |                  |clients       |
   |                |                |                  |available     |
   +----------------+----------------+------------------+--------------+
   |*Use Cases*     | Enterprise     | IoT, mobile,     |Cloud-native  |
   |                | messaging,     | sensor networks  |microservices,|
   |                | financial      |                  |real-time     |
   |                | transactions,  |                  |communications|
   |                | RPC            |                  |              |
   +----------------+----------------+------------------+--------------+
   |*Real-World     | Very widely    | Dominant in IoT  |Gaining       |
   |Usage*          | used via       | ecosystems;      |traction in   |
   |                | RabbitMQ (top  | supported by     |cloud-native  |
   |                | open-source    | many device/     |(CNCF         |
   |                | broker) in     | broker vendors   |project), used|
   |                | enterprises of |                  |by major tech |
   |                | all sizes      |                  |companies     |
   +----------------+----------------+------------------+--------------+

                                  Table 1





Muscariello, et al.      Expires 28 August 2026                [Page 15]

Internet-Draft            agncty-messaging-eco             February 2026


   Table 2 extends the comparison to include additional protocols
   relevant to modern agentic AI systems:

   +================+==========+============+==========================+
   |Feature         |AMQP over |Kafka       | SLIM                     |
   |                |WebSockets|            |                          |
   +================+==========+============+==========================+
   |*Protocol Type* |AMQP      |Distributed | Secure low-latency       |
   |                |tunneled  |commit log, | interactive messaging    |
   |                |through   |high-       |                          |
   |                |WebSockets|throughput  |                          |
   |                |          |pub/sub     |                          |
   +----------------+----------+------------+--------------------------+
   |*Transport*     |WebSockets|TCP         | gRPC (over               |
   |                |over TLS  |(optionally | HTTP/2-HTTP/3)           |
   |                |          |TLS)        |                          |
   +----------------+----------+------------+--------------------------+
   |*Message Model* |Same as   |Topics with | Hierarchical names       |
   |                |AMQP      |partitions, | (org/namespace/service/  |
   |                |(depends  |consumer    | instance), point-to-     |
   |                |on the    |groups,     | point and group          |
   |                |broker's  |offset-based| sessions                 |
   |                |AMQP      |consumption |                          |
   |                |model)    |            |                          |
   +----------------+----------+------------+--------------------------+
   |*QoS / Delivery*|Same as   |At-least-   | Fire&Forget unreliable   |
   |                |AMQP      |once        | (at-most-once),          |
   |                |          |default;    | unreliable and reliable  |
   |                |          |exactly-once| (exactly-once).  This    |
   |                |          |possible via| extends to request/      |
   |                |          |transactions| reply and streaming as   |
   |                |          |            | well.                    |
   +----------------+----------+------------+--------------------------+
   |*Streaming*     |Same as   |Native log- | Native gRPC support via  |
   |                |AMQP if   |based       | HTTP/2/3 client          |
   |                |broker    |streaming   | streaming, server        |
   |                |supports  |(Kafka      | streaming.  Notice that  |
   |                |streaming |Streams,    | Server Sent Events       |
   |                |          |KSQL, etc.) | (SSE) with HTTP/1.1      |
   |                |          |            | cannot carry binary nor  |
   |                |          |            | compressed data.         |
   +----------------+----------+------------+--------------------------+
   |*Persistence*   |Same as   |Built-in:   | Not supported            |
   |                |AMQP      |messages    |                          |
   |                |          |persist on  |                          |
   |                |          |disk across |                          |
   |                |          |clusters    |                          |
   +----------------+----------+------------+--------------------------+



Muscariello, et al.      Expires 28 August 2026                [Page 16]

Internet-Draft            agncty-messaging-eco             February 2026


   |*Protocol       |Higher    |Moderate    | Low: Wire format uses    |
   |Overhead*       |(AMQP +   |(custom     | protocol buffer.         |
   |                |WebSockets|binary      | Supports also binary     |
   |                |handshake)|protocol,   | (byte type in protobuf)  |
   |                |          |but         |                          |
   |                |          |optimized   |                          |
   |                |          |for high    |                          |
   |                |          |throughput) |                          |
   +----------------+----------+------------+--------------------------+
   |*Broker         |Yes       |Yes         | Yes for efficient        |
   |Required*       |          |(distributed| multi-party.  P2P is     |
   |                |          |cluster)    | also possible.           |
   +----------------+----------+------------+--------------------------+
   |*Authentication*|Same as   |SASL/PLAIN, | Transports MLS           |
   |                |AMQP      |SASL/SCRAM, | credentials and proofs   |
   |                |(broker-  |Kerberos,   | inside OAuth bearer      |
   |                |based)    |OAuth       | tokens over HTTP/2.      |
   |                |          |            | This gives you:          |
   |                |          |            | Interoperability:        |
   |                |          |            | Leverage standard        |
   |                |          |            | HTTP/2 and OAuth         |
   |                |          |            | libraries.               |
   |                |          |            | Scalability: One         |
   |                |          |            | persistent HTTP/2        |
   |                |          |            | connection carries many  |
   |                |          |            | MLS messages.            |
   |                |          |            | Immediate revocation:    |
   |                |          |            | Eject bad actors by      |
   |                |          |            | revoking their OAuth     |
   |                |          |            | tokens—no need to        |
   |                |          |            | rebalance the ratchet    |
   |                |          |            | tree first.              |
   +----------------+----------+------------+--------------------------+
   |*Transport      |WSS       |TLS         | TLS                      |
   |Security*       |(WebSocket|            |                          |
   |                |Secure)   |            |                          |
   +----------------+----------+------------+--------------------------+
   |*Message        |Same as   |TLS in-     | MLS (Quantum safe,       |
   |Security*       |AMQP      |flight      | Secure end-to-end, even  |
   |                |(depends  |encryption, | across insecure hops,    |
   |                |on the    |optional at-| post-compromise          |
   |                |broker's  |rest        | security)                |
   |                |encryption|encryption  |                          |
   |                |at rest/  |(broker     |                          |
   |                |in-       |config)     |                          |
   |                |transit)  |            |                          |
   +----------------+----------+------------+--------------------------+
   |*Binary or Text*|Binary    |Binary      | Binary or Text           |



Muscariello, et al.      Expires 28 August 2026                [Page 17]

Internet-Draft            agncty-messaging-eco             February 2026


   |                |AMQP      |protocol    |                          |
   |                |frames    |(common     |                          |
   |                |over      |payloads:   |                          |
   |                |WebSockets|Avro, JSON, |                          |
   |                |          |Protobuf)   |                          |
   +----------------+----------+------------+--------------------------+
   |*Use Cases*     |Browser-  |High-       | Group messaging, one-    |
   |                |based apps|throughput  | to-many, many-to-many,   |
   |                |needing   |data        | Cloud-native             |
   |                |AMQP      |pipelines,  | microservices, real-     |
   |                |behind    |streaming   | time communications,     |
   |                |firewalls |analytics,  | streaming                |
   |                |          |event       |                          |
   |                |          |sourcing    |                          |
   +----------------+----------+------------+--------------------------+
   |*Real-World     |Less      |Extremely   | New Entrant, low         |
   |Usage*          |common,   |widespread  |                          |
   |                |mainly for|across      |                          |
   |                |browser/  |industries; |                          |
   |                |firewall  |de facto    |                          |
   |                |scenarios |standard for|                          |
   |                |using     |large-scale |                          |
   |                |RabbitMQ  |event       |                          |
   |                |or similar|streaming   |                          |
   +----------------+----------+------------+--------------------------+

                                  Table 2

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7540>.






Muscariello, et al.      Expires 28 August 2026                [Page 18]

Internet-Draft            agncty-messaging-eco             February 2026


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9420]  Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
              Omara, E., and K. Cohn-Gordon, "The Messaging Layer
              Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
              July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

6.2.  Informative References

   [AMQP]     OASIS, "OASIS Advanced Message Queuing Protocol (AMQP) 1.0
              Specification", n.d.,
              <https://www.oasis-open.org/standards#amqp>.

   [gRPC]     CNCF, "gRPC Documentation", n.d., <https://grpc.io/docs/>.

   [Kafka]    Foundation, A. S., "Apache Kafka Documentation", n.d.,
              <https://kafka.apache.org/documentation/>.

   [MQTT]     OASIS, "OASIS MQTT Version 5.0 Specification", n.d.,
              <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
              v5.0.html>.

   [NATS]     Communications, S., "NATS Documentation", n.d.,
              <https://docs.nats.io/>.

   [SLIM]     AGNTCY, "AGNTCY SLIM Specification", n.d.,
              <https://spec.slim.agntcy.org>.

Authors' Addresses

   Luca Muscariello
   Cisco
   Email: lumuscar@cisco.com


   Michele Papalini
   Cisco
   Email: micpapal@cisco.com


   Mauro Sardara
   Cisco
   Email: msardara@cisco.com






Muscariello, et al.      Expires 28 August 2026                [Page 19]

Internet-Draft            agncty-messaging-eco             February 2026


   Sam Betts
   Cisco
   Email: sambetts@cisco.com
















































Muscariello, et al.      Expires 28 August 2026                [Page 20]
