An Overview of Messaging Systems and Their Applicability to Agentic AI

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 when, and only when, they appear in all capitals, as shown here.

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, a designer of such systems will require 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 messaging protocols—AMQP, MQTT, NATS, AMQP over WebSockets, Kafka, and 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.

Protocol Analysis for Agentic AI Systems The following sections provide detailed analysis of each messaging protocol in the context of agentic AI requirements.

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.

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. 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.

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.

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. 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.

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 ksqlDB 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.

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 , MCP , and ACP . 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 carries Protocol Buffers messages over streaming gRPC on HTTP/2 or over WebSocket. HTTP/2 supports multiplexed streams; latency, throughput, and connection costs depend on the implementation, network path, and workload and should be measured in the target deployment. 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. SLIM session delivery retries and acknowledgements are configurable and are not guaranteed for every session. Applications should select and test the behavior they require; they should not infer exactly-once processing from transport retries. Idempotent handlers and application-level deduplication remain useful when operations may be retried. SLIM separates hop-by-hop transport protection from optional session-layer content protection. TLS may protect a transport hop. When MLS is enabled for a session, application content is protected between session members while routing nodes forward it using message metadata. Without MLS, transport security alone does not hide content from a routing node that terminates the protected hop. Authentication and authorization use configured identity providers and session policies. MLS group membership and identity-provider credentials serve related but distinct purposes; deployments define how identity changes affect session membership. Revoking an application credential does not by itself establish that a participant has been removed from an existing MLS group. 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.

Agent-Network Overlays Agent-network overlays combine service discovery, identity, authorization, and connectivity across networks. They operate at the service-network layer and can work alongside messaging protocols and agent interaction protocols. Google Agent Mesh is a service-network overlay with a control plane, routers, and nodes . The control plane admits nodes, issues credentials, distributes policy, and provides router configuration. A node runs alongside an agent or service and connects that workload to the mesh. Routers provide a directory for service discovery and relay traffic between nodes when a direct connection is unavailable.

Enrollment and Identity A node can enroll using an OpenID Connect identity token or an operator-issued bootstrap token, and proves possession of its node key during enrollment. The control plane issues a signed Biscuit credential containing the node identity and authorization facts, such as roles and identity-provider claims. Nodes and routers verify these credentials using the control plane's public key. The control plane also holds mesh policy and distributes it to the nodes that enforce that policy.

Service Discovery and Calls Nodes publish services under typed names, including MCP, A2A, and inference services. A node queries a router to discover the provider for a service name; routers maintain and exchange directory records. Nodes connect directly when network reachability permits, or use a router relay when it does not. Agent Mesh uses libp2p for node connectivity, with QUIC or TCP transports; hole punching can establish a direct path when the network permits it. An agent uses the local node API rather than addressing remote nodes itself. The API includes an MCP server for discovering and calling remote tools, an OpenAI-compatible endpoint for inference services, and proxy routes for individual services, including A2A agents. For a service call, the connecting node authenticates to the provider with its credential. The provider verifies the credential and evaluates the service policy before forwarding the request to its local backend. The caller can also verify the provider's credential and attested labels before sending request data. The documented service-call path is point-to-point: a caller discovers one or more providers and addresses a call to a selected provider . Authorization policy can use identity groups when deciding which peer nodes a caller may reach, but such a group is not a multicast destination or shared message channel . Routers also distribute signed mesh-control events through gossip; those events manage mesh state and are distinct from application messages. The documented Agent Mesh APIs do not describe an application-level group messaging channel.

Transport Security and Trust Boundaries Node-to-node connections use authenticated encrypted channels over libp2p. The documented implementations use TLS 1.3 or Noise; routers relay encrypted traffic when they are on the path. The control plane handles enrollment, credentials, and policy distribution, while application requests travel between nodes. The control plane is the trust root for credentials and mesh policy; service nodes make the authorization decision for their hosted services. Agent Mesh describes service discovery, identity, authorization, and network connectivity. Messaging protocols describe message delivery and session semantics. The Agent Mesh node APIs expose MCP and A2A services to applications; this section describes that integration boundary without treating the overlay as a broker protocol.

Security Analysis 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: MLS defines forward secrecy and post-compromise security properties for group key evolution. These properties depend on correct MLS operation and group updates; recovery after a compromise is not automatic merely because MLS is enabled. Deployments also need procedures to remove or re-authenticate compromised participants. Post-Quantum Cryptography: MLS does not by itself imply post-quantum protection. The algorithms negotiated by an implementation determine whether a deployment has classical, hybrid, or post-quantum security. The same applies to the other systems discussed here; deployments should verify the algorithms actually supported and enabled. Multi-Domain Operations: Agentic AI systems can span organizational and security domains. Optional MLS protection can limit intermediary access to application content, but it does not replace identity federation, authorization, endpoint security, or operational trust decisions. 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.

Performance Characteristics 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. Latency Sensitivity: Many AI agent interactions are latency-sensitive. SLIM supports streaming over HTTP/2 or WebSocket with Protocol Buffers encoding, but protocol choice alone does not determine end-to-end latency. Implementations should benchmark representative payloads, fan-out patterns, and network paths. 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.

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 broker infrastructure, while Kafka deployments typically use a distributed cluster. SLIM deployments use a network of routing nodes; the required topology depends on deployment scale and availability goals. 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 balancers, API gateways, and observability services, while specialized messaging protocols may require additional integration layers. Compliance and Auditing: Regulated deployments need explicit audit, retention, and access-control policies. SLIM's optional session-state persistence is not a message archive or audit log, and encryption alone does not establish regulatory compliance.

Connectivity for Agents Behind NAT Messaging semantics and network reachability are separate concerns. An agent that cannot accept inbound connections can still participate as a client when it can establish an outbound connection to a reachable broker or routing node. The established connection carries traffic in both directions, so replies and subscribed messages can return without opening an inbound firewall port at the agent. Long-lived connections require suitable keepalive settings and network policy that permits egress to the service endpoint. This client-connection pattern does not, by itself, make a private agent service directly reachable by another agent. For direct RPC to a service behind NAT, deployments need a reachable gateway, relay, reverse connection, or network overlay. Alternatively, the private agent can subscribe to requests on a broker and publish replies over its existing outbound connection. The latter uses the messaging system's request/reply conventions and requires application logic for correlation, timeouts, retries, and authorization.

Patterns by System AMQP: An AMQP client initiates a TCP connection to an AMQP listener on a broker. An agent in a private network can connect outward to a broker reachable from that network; the broker mediates communication with other connected clients. Where the broker is private as well, network routing, a VPN, or an implementation-specific broker bridge is needed between the agent network and the broker network. RabbitMQ documents separate client listeners and inter-node ports; cluster inter-node access is an operator networking concern and is distinct from client connectivity . MQTT: MQTT defines the client as opening a bidirectional connection to a server, then publishing and subscribing through that connection . This fits devices or agents behind NAT when they can reach the broker outbound. MQTT 5.0 supports TCP-based transports and WebSocket; a broker's WebSocket listener can be used by browser clients, subject to the broker implementation and its network configuration . A local MQTT broker or bridge can aggregate clients on a private network and forward configured topic traffic to an upstream broker. NATS: Clients connect to a NATS server. For an edge network that permits outbound connections only, a local NATS leaf node can dial a hub and bridge subject interest and matching messages in both directions over that link. Local agents then connect to the leaf on the private network; they do not each need a public address or a direct connection to the hub . NATS gateways connect separate NATS clusters, while leaf nodes connect edge servers to a hub . Kafka: A Kafka client can initiate its connections outbound, but connecting to the bootstrap address is not sufficient if broker metadata advertises addresses the client cannot reach. Every broker address returned through advertised.listeners must be reachable from the agent's network, directly or through configured network paths such as private routing or a VPN . Kafka's broker topology is therefore an explicit part of the connectivity design for clients in separate private networks. AMQP over WebSockets: A WebSocket binding can let browser-based clients connect through networks that permit HTTP(S) egress, when the chosen broker or gateway implements that binding. WebSockets change how the client reaches the service; they do not remove the need for a reachable broker endpoint or provide an inbound route to a private agent. SLIM: A SLIM endpoint can initiate a streaming gRPC connection over HTTP/2 or a WebSocket connection to an accessible routing node. Messages are then routed by name through the interconnected routing-node network, rather than requiring every application endpoint to expose an Internet-reachable listener. Deployments still need reachable routing nodes and connectivity between the routing nodes that carry the route. Agent Mesh: An Agent Mesh node runs beside an agent or service and connects to routers; nodes can communicate directly when network conditions permit and use router relays otherwise. This lets a node behind NAT participate without publishing its own reachable service address. Its service discovery and authorization behavior is described in the Agent-Network Overlays section . These patterns place a reachable broker, edge bridge, gateway, or router on the network boundary and keep end-device connectivity outbound. They differ in what that boundary component provides: message brokering, topic or subject bridging, log access, or name-routed service connectivity. Deployments should also account for the trust boundary at that component, connection loss and reconnection behavior, and whether messages are buffered while an endpoint is offline.

Agent Gateways for Inspection An Agent Gateway can enforce content policy when it is placed inline on a request path and receives the application protocol in a form it can parse. For example, a gateway between an agent and an MCP server, A2A agent, or LLM API can inspect requests and responses, apply authorization and content guardrails, and forward permitted traffic to a backend. Agent Gateway documents HTTP and gRPC proxying, native MCP and A2A routing, and request/response guardrails for those protocols . For inspection, the gateway must be an actual data-path hop. TLS therefore terminates at the gateway, which establishes a separate protected connection to the upstream service. This makes the gateway a trusted plaintext-handling component; deployment policy should cover credential forwarding, payload logging, redaction, audit retention, and failure behavior. A generic TCP proxy can forward a connection, but application-level inspection requires a protocol-aware gateway or adapter.

Synchronous Enforcement and Streaming Content enforcement is an inline decision, not a passive copy of traffic. For a request-phase check, the gateway receives and parses the request, evaluates the policy locally or calls a policy service, and holds the request until it has a decision. It then forwards the original or modified request, or rejects it without contacting the backend. A response-phase check runs after the backend returns and before the gateway releases the response to the client. Agent Gateway documents request and response phases for MCP guardrail processors, including pass, mutate, and deny outcomes . This introduces enforcement latency and may require buffering the content being checked. Local deterministic rules can reduce this delay; remote classifiers or policy services add their processing and network time. Deployments should set body-size limits, timeouts, concurrency limits, and an explicit failure mode. Fail-closed behavior preserves the policy when the checker is unavailable but can make the service unavailable; fail-open behavior preserves availability but allows unchecked traffic. Audit-only evaluation can help tune policies, but it does not block or redact content. Streaming makes response enforcement different from request enforcement. A gateway can hold a complete buffered response, inspect or redact it, and then release it, at the cost of delaying the first response byte and storing the response while it is checked. Alternatively, it can inspect a response stream incrementally, but bytes already sent cannot be retracted. Agent Gateway's LLM guardrail documentation states that streamed responses can be rejected when a guardrail matches, but response masking does not apply to content already sent; buffered responses support masking . Applications that require redaction before any content reaches the caller therefore need buffering or an endpoint-side policy, rather than relying on post-send inspection. The integration depends on the messaging system:

HTTP-based A2A, MCP, or model APIs: Configure clients or service routing to send requests through the gateway. The gateway can apply protocol-aware policy before forwarding to a public or privately reachable backend.
AMQP, MQTT, NATS, or Kafka: A gateway can be placed at the client/broker boundary, but a generic TCP listener does not interpret broker frames or message payloads. Prompt inspection therefore requires a protocol-aware proxy, broker extension, or application adapter. An alternative is to inspect messages at the producer before publishing and at the consumer after delivery.
SLIM: A generic gateway attached to a routing node does not parse SLIM's Protocol Buffers message envelope. Relay inspection requires a SLIM-aware integration. If MLS is enabled, application content remains opaque to routing nodes; inspect before MLS encryption at the sending endpoint, after decryption at the receiving endpoint, or make the inspection gateway an explicitly trusted session participant.
Agent Mesh: Agent Mesh documents an integration with Agent Gateway in front of an agentmesh-node . The client sends its identity-provider token to Agent Gateway. The gateway validates the token, exchanges it at the node's /oauth/token endpoint for a caller-bound mesh credential, then forwards the request to the node's /mesh/<peer-id>/<type>/<name>/ proxy with that credential. The node connects to the selected mesh provider, and the provider node enforces its service policy. This places supported application-layer checks at Agent Gateway before the request enters the mesh and before the response returns to the client. The gateway is not inserted into the Agent Mesh router's relay or peer-link path. Those links carry authenticated encrypted traffic, whether relayed or direct, and are not readable by a gateway attached only to a router. To make gateway policy mandatory, clients must use the gateway-facing endpoint rather than bypassing it and calling a node API directly.

Colocating an Agent Gateway with a relay does not by itself enable inspection: the gateway must terminate or receive the application-level plaintext, and the system must route every applicable path through it. If end-to-end encryption is required, inspection belongs at a trusted endpoint or authorized group member; adding an intermediary that can decrypt changes the trust model.

RPC in Agentic Protocols and Relationship to Messaging Agentic AI systems are predominantly built around Remote Procedure Call (RPC)-oriented protocols. A2A , the Model Context Protocol (MCP) , and the Agent Client Protocol (ACP) all expose synchronous request/response semantics: a caller issues a structured request, awaits a response within a bounded time, and receives an explicit result or error. This design provides well-defined interfaces, typed contracts, and composable error handling that make agents discoverable and interoperable across heterogeneous systems. However, pure point-to-point RPC does not scale to all coordination demands of multi-agent systems. Fan-out invocations, asynchronous event delivery, streaming responses, dynamic group membership, and multi-domain security are capabilities that RPC protocols delegate to the underlying transport. This section examines how RPC and messaging interoperate in agentic systems, and how SLIM's SRPC capability provides a purpose-built solution.

Agentic Protocols Are RPC-Oriented The three leading agentic coordination protocols each define an RPC-based interaction model: Model Context Protocol (MCP) defines a JSON-RPC interface between LLM hosts and tools or resources. A host invokes tools by name with typed parameters and receives typed results or streaming token outputs. MCP is designed for synchronous tool calls with optional server-side streaming for partial results. Agent2Agent (A2A) is an HTTP-based protocol for delegating tasks between agents. An orchestrator submits task requests to worker agents and receives structured results or a stream of progress events. Agent capabilities are advertised via Agent Cards, enabling dynamic discovery without pre-configuration. Agent Client Protocol (ACP) standardizes JSON-RPC communication between code editors and coding agents, operating over stdio for local agents or HTTP and WebSocket for remote agents. It enables editors to invoke coding agents and receive structured responses, following a pattern analogous to the Language Server Protocol for language tools. All three share a fundamental structure: a caller invokes a named callee with parameters and awaits a response within a bounded time. SLIM is designed to serve as the transport layer beneath all three.

RPC vs. Messaging: Synchronous vs. Asynchronous

RPC (A2A, MCP, ACP): The caller issues a request and blocks or awaits a timely response. Semantics emphasize tightly scoped operations with bounded latency and explicit error contracts.
Messaging (AMQP, MQTT, NATS, Kafka, SLIM): Decoupled producers and consumers communicate via topics, subjects, or 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.

Challenges of Running RPC over Messaging Layering RPC semantics onto an asynchronous messaging substrate introduces several non-trivial challenges:

Request/response correlation: Messaging systems are decoupled by design and provide no direct return path. Implementing RPC requires correlating requests and responses using unique identifiers and temporary reply channels.
Latency and ordering: Messaging layers may introduce variable delivery latency and do not guarantee strict ordering, which can conflict with synchronous RPC contracts.
Error propagation: Messaging systems may buffer, retry, or drop messages, making it difficult to propagate errors and timeouts in a way that matches RPC error contracts.
Streaming and multiplexing: Supporting streaming RPC (server streaming, client streaming, bidirectional) over messaging requires careful management of stream lifecycles, backpressure, and multiplexing multiple logical RPCs over shared channels.
Security and authorization: Ensuring that only authorized callers can invoke specific methods, and that all messages are authenticated and encrypted end-to-end, is more complex in a distributed, group-based messaging environment.

SRPC resolves all of these challenges natively, as described below.

When Asynchronous Feels Synchronous Asynchronous transports can provide an interactive, RPC-like experience when:

A request message carries a correlation ID and a reply-to destination.
The callee publishes a response to the reply destination within a short SLA.
Client libraries surface responses as futures or promises and manage timeouts and retries.

This pattern underpins agent UIs where a user triggers an action and expects prompt, possibly streaming, results.

Bridging Patterns: RPC over Messaging

Request/Reply over Pub/Sub: Implement RPC by publishing a command event and awaiting a correlated reply event (applicable to AMQP, NATS, MQTT, and SLIM topics).
Streaming RPC: Use bidirectional streams (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 compensating transactions.
Backpressure and Flow Control: Prefer streaming transports (HTTP/2/3, gRPC) or messaging systems with flow control when returning large or continuous results.

SLIM RPC (SRPC) SRPC layers request/response semantics directly onto SLIM's secure messaging fabric, addressing all of the challenges enumerated above:

Correlation and reply routing: SRPC manages correlation IDs and reply channel lifecycle automatically, with no application-level plumbing required.
Idempotency and deduplication: SRPC idempotency keys make retries safe without duplicating side effects.
Ordering and synchronization: Lightweight ordering guarantees for both request/response and streaming patterns.
All four gRPC interaction patterns: Unary, server streaming, client streaming, and bidirectional streaming are all supported, enabling direct mapping of A2A, MCP, and ACP interaction models onto SLIM.
Integrated security: Every SRPC call inherits SLIM's MLS end-to-end encryption and OAuth-based authorization without additional configuration.

See the SRPC specification for details .

Advantages of SLIM for Agentic Protocols SLIM augments the point-to-point RPC model of A2A, MCP, and ACP with capabilities that are difficult to achieve over plain request/response transports:

Scatter-gather RPC: Invoke a single RPC across many agents simultaneously (by topic, group, or label) and aggregate responses (first-success, quorum, or all-success) using correlation IDs.
Group addressing and dynamic membership: Target MLS-secured groups; add or remove agents without reconfiguring endpoints or updating caller code.
Streaming responses: Return partial results or token streams from each agent over a single multiplexed connection.
Idempotency and safe retries: SRPC idempotency keys enable robust retry without duplicating effects—critical for expensive or stateful agent operations.
QoS, deadlines, and backpressure: Apply delivery guarantees, per-call timeouts, and flow control to avoid overload while maintaining interactivity.
End-to-end security: MLS encryption and OAuth-based policy apply uniformly across both RPC and messaging channels.
Observability: Correlation and causation IDs, combined with standard HTTP/2 transport, enable distributed tracing and per-agent metrics with existing tooling.

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

Security Implications

Unified identity: OAuth tokens are reused across RPC calls and messaging channels for consistent policy enforcement. An agent's identity and authorization scope apply uniformly to tool calls and subscription channels.
End-to-end encryption: MLS-backed channels ensure that RPC requests, responses, and streaming payloads are encrypted end-to-end, independently of transport hops. Routing nodes cannot inspect RPC call content.
Caller authentication: SRPC carries MLS group membership proofs with each call, allowing callees to verify that the caller is an authorized group member before executing the requested operation.

Guidance: When to Choose What

Use RPC (A2A, MCP, ACP) 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 SRPC over SLIM for any of the above when end-to-end security, scatter-gather invocation, streaming responses, or multi-organization deployment is required.

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

Feature	AMQP (e.g. RabbitMQ)	MQTT	NATS
Protocol Type	Message queueing (queues/exchanges)	Lightweight pub/sub for IoT	Lightweight messaging (pub/sub, req/reply, queue groups)
Transport	TCP (optionally TLS)	TCP (optionally TLS)	TCP (optionally TLS)
Message Model	Queues, exchanges, routing keys	Topic-based	Subjects (pub/sub), queue groups, request/reply
QoS / Delivery	At-least-once, exactly-once (AMQP 1.0)	QoS 0 (at-most-once), 1, 2 (exactly-once)	At-most-once (core), at-least-once with JetStream
Streaming	Via extensions/plugins (e.g. RabbitMQ Streams)	Not native (requires broker extensions)	Native with JetStream
Persistence	Yes (durable queues)	Broker-dependent	Optional via JetStream
Protocol Overhead	Higher (rich feature set)	Very low	Very low
Broker Required	Yes	Yes	Optional (but common)
Authentication	User/password, SASL (e.g., LDAP, Kerberos)	Username/password or custom tokens	NKey, JWT, token, user/password
Transport Security	TLS	TLS	TLS
Message Security	Typically broker-level or plugin-based encryption	Usually none at message level; rely on TLS	None in core (TLS in transit), JetStream can encrypt at rest
Binary or Text	Binary framing	Binary framing	Text-based protocol (core), binary clients available
Use Cases	Enterprise messaging, financial transactions, RPC	IoT, mobile, sensor networks	Cloud-native microservices, real-time communications
Real-World Usage	Very widely used via RabbitMQ (top open-source broker) in enterprises of all sizes	Dominant in IoT ecosystems; supported by many device/broker vendors	Gaining traction in cloud-native (CNCF project), used by major tech companies

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

Feature	AMQP over WebSockets	Kafka	SLIM
Protocol Type	AMQP tunneled through WebSockets	Distributed commit log, high-throughput pub/sub	Secure low-latency interactive messaging
Transport	WebSockets over TLS	TCP (optionally TLS)	Streaming gRPC over HTTP/2 or WebSocket
Message Model	Same as AMQP (depends on the broker's AMQP model)	Topics with partitions, consumer groups, offset-based consumption	Hierarchical names (`org/namespace/service/instance`), point-to-point and group sessions
QoS / Delivery	Same as AMQP	At-least-once default; exactly-once possible via transactions	Configurable retries and acknowledgements; not guaranteed for every session
Streaming	Same as AMQP if broker supports streaming	Native log-based streaming (Kafka Streams, ksqlDB, etc.)	Native gRPC support via HTTP/2/3 client streaming, server streaming
Persistence	Same as AMQP	Built-in: messages persist on disk across clusters	Not supported
Protocol Overhead	Higher (AMQP + WebSockets handshake)	Moderate (custom binary protocol, but optimized for high throughput)	Low: binary Protocol Buffers wire format; native support for both binary (bytes) and text payloads
Broker Required	Yes	Yes (distributed cluster)	Routed through SLIM nodes; topology is deployment-specific
Authentication	Same as AMQP (broker-based)	SASL/PLAIN, SASL/SCRAM, Kerberos, OAuth	Configured identity providers and session policies
Transport Security	WSS (WebSocket Secure)	TLS	TLS
Message Security	Same as AMQP (depends on the broker's encryption at rest/in-transit)	TLS in-flight encryption, optional at-rest encryption (broker config)	Optional MLS end-to-end content protection, independent of transport
Binary or Text	Binary AMQP frames over WebSockets	Binary protocol (common payloads: Avro, JSON, Protobuf)	Binary or Text
Use Cases	Browser-based apps needing AMQP behind firewalls	High-throughput data pipelines, streaming analytics, event sourcing	Group messaging, one-to-many, many-to-many, cloud-native microservices, real-time communications, streaming
Real-World Usage	Less common, mainly for browser/firewall scenarios using RabbitMQ or similar	Extremely widespread across industries; de facto standard for large-scale event streaming	New entrant; reference implementations in Python and Go available; early production deployments

Security Considerations This document is an informational comparison of messaging protocols for agentic AI systems. Security properties specific to each protocol are discussed in the Security Analysis section of this document. Readers deploying any of the protocols described SHOULD consult the security considerations sections of the respective protocol specifications. Among the systems analyzed, SLIM explicitly integrates optional MLS-based end-to-end protection for session content. The other protocols and systems do not provide that same integrated MLS model, although applications can add message-level encryption or other end-to-end protections. Transport-layer TLS alone protects a hop and does not hide content from an intermediary that terminates that hop.

IANA Considerations This document has no IANA actions.