What Is SLIM? The Beginner's Guide to Secure Low-Latency Messaging for AI Agents
CodexFuse Team · 2026-11-05T13:23:02.780Z · 19 min read min read
What Is SLIM? The Beginner's Guide to Secure Low-Latency Messaging for AI Agents
What Is the SLIM Protocol?
If you are asking what is slim protocol, the short answer is that it is a messaging layer for AI agents, not a new way for agents to think. SLIM is short for secure low latency interactive messaging, and it carries messages between agents and their tools over name-routed paths. It sits underneath agent protocols such as A2A and MCP, moving their traffic securely instead of replacing them.
The current version is draft-mpsb-agntcy-slim-03, an Internet-Draft dated November 2, 2026. It is a work in progress with intended status Informational, and it expires on May 6, 2027. That makes this a slim ietf draft guide to a live document, not a finished standard.
SLIM comes from AGNTCY, the open-source "Internet of Agents" project started by Cisco. This page is slim agntcy explained in plain English: the name-routed data plane, the session layer, MLS encryption, and SLIMRPC. Every fact here comes from a source fetched on November 5, 2026, and all dates are as of that day.
Routing nodes forward ciphertext they cannot read when encryption is on, which is the point of the design. If you ever need to compare a value without revealing it — for example, checking a session identifier against a log entry — a free SHA-256 hash generator lets you compare hashes instead of pasting the value itself.
SLIM routing nodes are ordinary network services, and many agent deployments run them on rented machines. That setup is usually VPS hosting: you control the machine, and agents connect to it over the network like any AI app would. The rest of this guide walks through the naming, the three parts, the encryption, and the comparison with older messaging protocols.
| Fact | Detail |
|---|---|
| Full name | Secure Low-Latency Interactive Messaging |
| Current draft | draft-mpsb-agntcy-slim-03, November 2, 2026 |
| Status | Internet-Draft, work in progress; intended status Informational |
| Expires | May 6, 2027, 182 days after this article |
| Authors | Luca Muscariello, Michele Papalini, Mauro Sardara, Sam Betts (Cisco) |
| Carries | Protocol Buffers messages over streaming gRPC on HTTP/2 or WebSocket |
| Sits under | A2A, MCP, and other agent protocols |
| Encryption | Optional MLS (RFC 9420) end-to-end encryption |
The -03 revision is 3 days old at writing. It follows -02, posted July 18, 2026 — 110 days earlier — and the first version, -00, posted October 16, 2025, which is 385 days ago. The draft's six-month maximum life means -03 expires May 6, 2027, which is 182 days from now.
Why Do AI Agents Need a Messaging Layer Like SLIM?
A2A is how agents collaborate as peers, and MCP is how they reach tools and data. Neither one defines how a message physically travels between two machines that may sit in different organizations. That gap is what SLIM fills: it is the slim a2a mcp transport, the road under the conversation.
Agents do not live on one machine. One agent may run in a data center, another in a browser, and a third on a phone, and they still need to exchange streams of data, tool calls, and results. SLIM is built for exactly that shape: workloads in a data center, a browser, or a mobile device, connected through routing nodes.
The same need shows up in everyday agent coding. A developer running an agent coding assistant wants the agent's tool calls to travel reliably between the model, the tools, and the machine, and a guide to how to use Claude Code shows how that loop works in practice. SLIM answers the same question one layer down: how do those messages move once they leave the process.
AGTP is a sibling effort in the same family: it governs how an agent hands work to another agent. If you want the transfer side of the story, read what AGTP is — SLIM is the messaging side, and the two solve different halves of the same problem.
Without a shared messaging layer, every agent framework rebuilds the same plumbing: routing, retries, encryption, and group chat. SLIM's bet is that one open layer can carry all of them.
How Does SLIM Route Messages by Name?
SLIM names look like addresses, not network locations. Every endpoint gets a hierarchical name with exactly four parts: organization/namespace/service/id.
| Part | Meaning |
|---|---|
| organization | Who owns the service, for example a company or a team |
| namespace | A grouping inside the organization, such as a project or an environment |
| service | The service itself, such as a planner or a search tool |
| id | One specific running instance, derived from the application's authenticated identity |
The first three parts address a service, so a message to organization/namespace/service can reach any instance of that service. Adding the final id addresses one specific instance. That split is what makes anycast discovery possible: a sender names the service, and the network finds an instance.
Group channels use the same four-part form. A group's data and control channel names are derived from the moderator's identity and the channel name, and they share the same first three parts. One naming scheme therefore covers single agents, services, and whole groups.
A name is a routing identifier, not proof of identity. When identity binding is enabled, the session layer checks that a peer's verified identity actually matches the name it advertises. Decentralized identifiers may be used as application identities, but the -03 draft says they are not required as the wire form of a name.
What Are the Three Parts of SLIM?
At its core, SLIM has three components. Routing nodes forward messages by reading metadata, never by opening the payload.
Session-layer clients manage secure group state and reliability. Application endpoints publish and receive content, encrypted when MLS is on.
| Component | Job |
|---|---|
| Data-plane routing nodes | Forward messages using metadata; keep a connection table and a subscription table |
| Session-layer clients | Manage group state, reliability, discovery, join, and leave |
| Application endpoints | Publish and receive content; encrypt and decrypt when MLS is enabled |
Routing nodes keep two tables. The connection table tracks client-to-node and node-to-node connections, and the subscription table maps channel subscriptions to neighbouring nodes. A message is a SLIM header with source and destination names, a session header for session traffic, and the content itself.
The control plane is optional and separate, and it never sits in the message path. A deployment can configure routing nodes directly, or use a control plane to register nodes, manage topology, and distribute configuration. Node registration can be limited to nodes authorized for a claimed routing domain.
The docs site counts five components because it adds the controller, the channel manager, the slimctl command-line tool, and the SDK to the draft's three. That is the implementation count, not the protocol count, and the two lists describe the same system at different levels.
Reliability is configurable, not guaranteed. Delivery retries and acknowledgements can be turned on per session, but the draft states plainly that they are not guaranteed for every session. SLIM is a messaging layer, not a promise of exactly-once delivery.
How Does a SLIM Message Travel in 5 Steps?
The journey below follows the draft's own description of the data plane and the session layer. It is the shortest complete picture of a message moving from one agent to another.
- An application endpoint addresses its message by name, using the four-part form organization/namespace/service/id.
- The endpoint sends the message to an accessible routing node over streaming gRPC on HTTP/2 or a WebSocket connection.
- The routing node looks up its subscription table and forwards the message toward the destination by metadata, without inspecting the payload.
- Each routing node on the path repeats the lookup and forwards the message onward until it reaches the destination's node.
- The destination's session layer receives the message, verifies it, and decrypts the content when MLS is enabled, then hands it to the application.
Agents behind a firewall benefit from this shape. A message is routed by name, so an agent never needs an Internet-reachable listener of its own. Only the routing nodes need to be publicly reachable.
Before any routed message flows, neighbouring routing nodes negotiate their link. The negotiation exchanges a link identifier, the SLIM version, the node identity, and the connection type. Peers can also derive a per-link key for header integrity, and deployments can negotiate hybrid post-quantum key material.
What Is MLS, and Why Is It Optional in SLIM?
MLS is the Messaging Layer Security protocol, published as RFC 9420 in July 2023. It encrypts messages end to end for a group, so that even a routing node that forwards the ciphertext cannot read it. When MLS is on, a compromised node still cannot see the content.
In the -03 draft, MLS is optional. A deployment that does not enable it relies on configured transport security, which is hop-by-hop TLS.
Without MLS, the content is not protected from routing nodes beyond that transport encryption. The draft says plainly that SLIM's security properties depend on deployment configuration.
That is a deliberate change from -02, where a producer effectively had to belong to an MLS group. The -03 authors loosened the requirement so that deployments can choose their own trade-off between setup cost and end-to-end protection.
Two limits deserve a straight reading. MLS gives forward secrecy and post-compromise security only when the group is operated correctly, and recovery after a compromise is not automatic just because MLS is enabled.
MLS alone also does not imply post-quantum protection; the algorithms negotiated decide whether the security is classical, hybrid, or post-quantum. Hybrid post-quantum key material can be negotiated during link setup, but that is a deployment choice, not a property of the letters SLIM.
A group session has a moderator who invites and removes members. Removed members must not be able to decrypt messages sent after their removal, and a returning participant can rejoin with key material updated to reconcile any epoch mismatch. Participants send periodic one-way heartbeats so each member can track who is still alive.
What Is SLIMRPC, and What Can It Do?
SLIMRPC — called SRPC in the companion draft, the same facility under a shorter name — is an application-layer remote procedure call system that runs over SLIM sessions. It is not a data-plane message type. It lets one agent call a function on another agent and get the answer back over the same session.
| Pattern | How it works |
|---|---|
| Unary | One request, one response |
| Client-streaming | Many requests in, one response out |
| Server-streaming | One request in, many responses out |
| Bidirectional streaming | Both sides stream at the same time |
Services are defined with Protocol Buffers and invoked through generated client and server stubs, the same way gRPC services are defined. Concurrent calls share one persistent SLIM session, and each call carries its own unique RPC ID. The server subscribes to its base SLIM name, so callers reach it by name.
The most distinctive pattern is multicast RPC. A client builds a group channel from the names of the servers it wants to call, and on the first call the channel lazily creates a multicast session and invites those servers.
The client app acts as group moderator. The response stream completes when all members finish, and one member's error does not block the other members' responses.
That fan-out shape is why SLIMRPC matters for agents. A coordinator can ask five specialist agents the same question in one call and collect five answers, instead of opening five separate connections and stitching the answers together by hand.
The companion draft's guidance is practical. Use plain RPC for low-latency point operations, use messaging for broadcast, fan-out, and multi-party coordination, and use SRPC over SLIM when end-to-end security, scatter-gather calls, streaming responses, or a multi-organization deployment is required.
SLIM vs gRPC: What Does SLIM Add?
The question behind "slim vs grpc" has a short answer: SLIM is built on gRPC, not instead of it. The data plane carries Protocol Buffers messages over streaming gRPC, so every gRPC strength — multiplexed streams over one connection, efficient binary encoding — is already inside SLIM.
What SLIM adds is everything gRPC leaves to the application. gRPC connects a client to a known server address; SLIM routes by name, so the sender names a service and the network finds an instance.
gRPC has no group messaging; SLIM has group sessions with a moderator and separate data and control channels. gRPC has TLS; SLIM adds optional MLS end-to-end encryption that survives TLS termination at a middle node.
The transport question also has a second answer in the ecosystem. MCP itself can run over different transports, and one of them is Media over QUIC — read what MCP over MOQT is to see how the same protocol changes shape on a different wire. SLIM is the same idea at a different layer: keep the agent protocol, change how its messages travel.
In short, gRPC is the engine and SLIM is the road network on top of it. You would not replace gRPC with SLIM, because SLIM already uses gRPC, and you would not use bare gRPC where you need named routing, group sessions, or end-to-end group encryption.
SLIM vs AMQP, MQTT, NATS, and Kafka
The companion draft compares six messaging protocols across streaming, delivery, security, and operational complexity: AMQP, MQTT, NATS, AMQP over WebSockets, Kafka, and SLIM. The comparison is the draft's own answer to why a new protocol exists at all.
| Protocol | Streaming | Delivery | Security | Complexity |
|---|---|---|---|---|
| AMQP | Not native; needs extensions such as RabbitMQ Streams | At-least-once; exactly-once in AMQP 1.0 | SASL, LDAP, or Kerberos auth; TLS transport; message security usually broker-level | Higher overhead; enterprise standard, very widely used through RabbitMQ |
| MQTT | Not native; needs broker extensions | QoS 0 at-most-once, 1 at-least-once, 2 exactly-once | Username and password or tokens; TLS only; no end-to-end encryption | Very low overhead; dominant in IoT |
| NATS | Native with JetStream | At-most-once in core; at-least-once with JetStream | NKey, JWT, tokens, or passwords; TLS transport; no message-level end-to-end encryption in core | Very low overhead; broker optional but common; CNCF project |
| AMQP over WebSockets | Same as AMQP where the broker supports streaming | Same as AMQP | WSS transport; otherwise the same as AMQP | Higher overhead; mainly for browser and firewall scenarios |
| Kafka | Native log-based streaming | At-least-once by default; exactly-once possible with transactions | SASL, Kerberos, or OAuth; TLS in flight; no end-to-end message encryption | Moderate overhead; a distributed cluster is required |
| SLIM | Native gRPC streaming over HTTP/2 or WebSocket | Configurable retries and acknowledgements; not guaranteed for every session | Configured identity providers and session policies; TLS hop protection; optional MLS end-to-end protection | Low overhead; binary Protocol Buffers; routed through SLIM nodes |
SLIM is the only one of the six with integrated optional MLS end-to-end protection for session content. The other five protect a hop with TLS, which does not hide content from an intermediary that terminates that hop. That is the comparison's sharpest line, and it is also SLIM's clearest reason to exist.
The trade-offs are just as explicit. SLIM has no persistence, so it is not a message store or an event log the way Kafka is.
Its delivery is configurable rather than guaranteed. And it is a new entrant with early production deployments, while Kafka is the de facto standard for large-scale event streaming and AMQP is an enterprise standard.
One inconsistency is worth noting so nobody copies it blindly. The companion draft's Table 2 still describes SLIM streaming as gRPC over HTTP/2 and HTTP/3, but the SLIM draft itself says HTTP/2 or WebSocket, with HTTP/3 dropped from the -03 abstract. This article follows the SLIM draft's own wording.
What Changed Between SLIM -02 and -03?
The -03 revision is 3 days old at writing, dated November 2, 2026. It follows -02, posted July 18, 2026 — 110 days earlier — and the first version, -00, posted October 16, 2025, which is 385 days ago. The -01 revision in between was posted February 24, 2026, 254 days ago.
Four revisions in 385 days is a fast cadence for an IETF draft.
| Area | -02 | -03 |
|---|---|---|
| Transport in the abstract | gRPC over HTTP/2 and HTTP/3 | Streaming gRPC on HTTP/2 or WebSocket |
| MLS encryption | Effectively mandatory for producers | Optional; security depends on deployment configuration |
| Naming | Based on Decentralized Identifiers (DIDs) | DIDs optional; a name ID is a routing identifier, not proof of identity |
| Link negotiation | Not specified | Added: link ID, SLIM version, node identity, connection type, per-link integrity key |
| Title | Secure Low-Latency Interactive Messaging | Unchanged; the word "Real-Time" was already dropped in -02 |
| Expiry | January 8, 2027 | May 6, 2027 |
The direction of the changes is consistent: -03 makes SLIM more flexible and less prescriptive. HTTP/3 leaves the abstract while WebSocket enters it, which matches the project's cross-transport work for browsers.
MLS becomes a choice instead of a requirement. DIDs move from the foundation of naming to one option among others.
None of this changes the draft's status. It is still an Internet-Draft, valid for a maximum of six months, and it can be updated, replaced, or made obsolete at any time. The -03 revision expires May 6, 2027, which is 182 days from today.
How Mature Is SLIM Today?
The honest answer is early, active, and openly unfinished. The specification lives in the agntcy/slim-spec repository, which holds draft sources only and no implementation code. The implementation lives separately in agntcy/slim, written in Rust under the Apache 2.0 license.
The numbers show the split clearly: the spec repo has 55 stars and 27 commits, while the implementation repo has 233 stars and 1,322 commits — 178 more stars and 1,295 more commits on the code side than on the spec side.
Language bindings live in a third repository, slim-bindings. The companion draft says Python and Go bindings are available today, with JavaScript/TypeScript, C#, and Kotlin in progress.
The docs site lists all six languages as SDK languages. The two sources disagree on timing, so treat any single binding claim as source-dependent rather than settled.
SLIM is one piece of AGNTCY, the open-source collective building the "Internet of Agents." AGNTCY was initiated by Cisco, open-sourced in March 2025, and donated to the Linux Foundation on July 29, 2025. It brings together more than 75 organizations, including Dell, Google Cloud, Oracle, and Red Hat, and it is explicitly interoperable with A2A and MCP rather than a rival to them.
Independent coverage is thin. A HackerNoon explainer appeared September 14, 2026, a Splunk article on AGNTCY appeared September 9, 2026, and an AGNTCY blog post on cross-transport SLIM appeared August 11, 2026. There is no mainstream tech-press coverage, no independent benchmark, and no adoption figure in any source fetched for this article.
What the sources do state is modest and worth quoting exactly. The companion draft calls SLIM a new entrant with reference implementations in Python and Go available and early production deployments.
There are no user counts, download counts, or performance numbers anywhere in the drafts, and this article invents none of them. Low latency is in the name and the design goal; it is not a measured figure.
When Does SLIM Fit — and When Does It Not?
SLIM fits where agents talk across trust boundaries. Multi-organization agent teams, federated deployments, and groups of agents that need end-to-end encryption are the cases the draft is written for. The name-routed design also fits agents behind firewalls, since only routing nodes need public addresses.
| Situation | SLIM fits? |
|---|---|
| Agents across organizations that must not read each other's traffic at middle nodes | Yes — optional MLS encrypts content end to end |
| A coordinator fanning one call out to many specialist agents | Yes — multicast RPC is built for scatter-gather |
| Agents in browsers or on phones joining a group | Yes — WebSocket transport and WebAssembly bindings |
| A durable event log or message archive | No — SLIM has no persistence |
| Guaranteed exactly-once delivery | No — retries and acknowledgements are configurable, not guaranteed |
| A single app on one machine with no network | No — plain gRPC or in-process calls are simpler |
One more trap is worth naming once, because the word SLIM is heavily overloaded. The FitNesse Slim protocol is an acceptance-testing protocol, a research paper uses SLIM for simultaneous logic-in-memory computing, and slimproto is an audio-streaming crate.
None of them is this protocol. Every claim in this article is about the AGNTCY SLIM protocol, the IETF draft, and nothing else.
If you only need one agent talking to one tool on one machine, SLIM is the wrong tool. Its value appears when messages cross networks, organizations, and trust boundaries — and when losing that protection would cost more than running a routing node.
Sources
Every fact in this article comes from a source fetched on November 5, 2026. Vendor claims are the vendor's own words.
SLIM draft -03, full text — https://datatracker.ietf.org/doc/html/draft-mpsb-agntcy-slim-03
SLIM draft datatracker page, revision status — https://datatracker.ietf.org/doc/draft-mpsb-agntcy-slim/
SLIM draft revision history — https://datatracker.ietf.org/doc/draft-mpsb-agntcy-slim/history/
SLIM draft -02, full text — https://datatracker.ietf.org/doc/html/draft-mpsb-agntcy-slim-02
Companion draft -03, "An Overview of Messaging Systems and Their Applicability to Agentic AI" — https://datatracker.ietf.org/doc/draft-mpsb-agntcy-messaging/
Companion draft revision history — https://datatracker.ietf.org/doc/draft-mpsb-agntcy-messaging/history/
agntcy/slim-spec, specification repository — https://github.com/agntcy/slim-spec
agntcy/slim, implementation repository — https://github.com/agntcy/slim
SLIM docs, introduction — https://slim.agntcy.org/latest/slim/slim-overview/
Splunk, "AGNTCY: the open standard set to structure the Internet of Agents," September 9, 2026 — https://www.splunk.com/en_us/blog/artificial-intelligence/agntcy-structure-the-internet-of-agents.html
HackerNoon, "SLIM Explained: Why Agentic AI Need Secure Communication," September 14, 2026 — https://hackernoon.com/slim-explained-why-agentic-ai-need-secure-communication
AGNTCY blog, "SLIM Cross-Transport: WebSocket, gRPC, and the Browser," August 11, 2026 — https://blogs.agntcy.org/technical/2026/08/11/slim-cross-transport-browser-websocket-grpc.html
A2A protocol overview — https://google.github.io/A2A/
Model Context Protocol introduction — https://modelcontextprotocol.io/
Frequently Asked Questions
What does SLIM stand for?
SLIM stands for Secure Low-Latency Interactive Messaging. It is the name of the AGNTCY messaging protocol described in IETF draft draft-mpsb-agntcy-slim-03, dated November 2, 2026. Earlier versions included the word "Real-Time" in the title, but -02 and -03 dropped it.
Is SLIM an IETF standard?
No. SLIM is an Internet-Draft, which is a work in progress with intended status Informational. It expires on May 6, 2027 unless a newer revision replaces it, and it is not an RFC or an adopted standard.
Is SLIM a replacement for A2A or MCP?
No. SLIM is the transport layer underneath them: A2A is how agents collaborate as peers, MCP is how they reach tools and data, and SLIM is how their messages travel between machines. The draft and the AGNTCY project both describe SLIM as complementary to A2A and MCP.
Does SLIM guarantee message delivery?
No. Delivery retries and acknowledgements are configurable per session, and the draft states they are not guaranteed for every session. SLIM also has no persistence, so it cannot replay messages from a store the way Kafka can.
Where can I try SLIM today?
The implementation is the open-source agntcy/slim repository on GitHub, written in Rust under the Apache 2.0 license. Language bindings live in the separate slim-bindings repository, and the SLIM docs site at slim.agntcy.org covers setup. Expect an early project: the companion draft describes reference implementations in Python and Go and early production deployments.
