Decoding AI Agent Collaboration: RocketMQ Lite Topic Makes Messaging as Easy as Creating a File

AI Assistant Query and Communication Challenges

When a user asks an AI assistant for weather, flight price, and schedule, the request is split by a primary orchestration Agent into three sub‑tasks handled by separate service Agents. A naïve synchronous implementation blocks the user, suffers from slow APIs, token loss on network drop, and queue contention under load.

Core Communication Problems of AI‑Native Applications

Asynchronous communication is dominant; tasks may last seconds to minutes.

Session context must be isolated per user.

Millions of independent channels are required—each conversation, long‑running task, or knowledge base needs its own isolated path.

Traditional message‑queue models that pre‑create topics and use shared consumer groups cannot scale to millions of topics, cannot guarantee per‑session isolation, and block on synchronous RPC calls.

RocketMQ Lite Topic

Lite Topic adds the ability to create a message channel as easily as creating a file, with automatic reclamation, strict ordering, and no loss on disconnect.

Scenario 1 — Parallel Agent Communication + Break‑Resume

Pain points : synchronous blocking, limited extensibility, system fragility, and loss of streamed tokens on network drop.

Solution : split the workflow into a request side (orchestration Agent dispatch) and a response side (streamed answer).

Preparation

Create a first‑level topic for each service Agent (e.g., weather, flight, calendar) to receive tasks.

Create a first‑level topic reply for the primary Agent to collect results.

For each user task, automatically create a second‑level Lite Topic under the appropriate first‑level topic (e.g., weather.{taskId}) with a TTL (e.g., 12 h) so the channel is discarded when idle.

Request chain

The primary Agent publishes the task to weather.{taskId} (similarly for other services). The Lite Topic expires automatically if no new messages arrive.

Each service Agent subscribes once with a wildcard: subscribeLite("*"), which consumes all second‑level topics under its first‑level topic without knowing individual task IDs.

Response chain

After processing, a service Agent writes its result to reply.{taskId}.

The primary Agent precisely subscribes to subscribeLite(taskId), gathers the three replies, aggregates them, and pushes the answer to the frontend via SSE. TTL ensures the response channel is reclaimed after use.

Break‑resume streaming

The service Agent continuously appends tokens to the response Lite Topic; the client records the last offset received ( lastReceivedOffset).

If the network drops, the writer continues unaware; tokens keep being persisted.

When the client reconnects, it supplies the last offset (e.g., lastReceivedOffset=50) and the new gateway subscribes exclusively, kicking out the old connection (“latest connection wins”).

The gateway resumes consumption from the stored offset, delivering the missing tokens seamlessly.

When the session ends, TTL triggers automatic deletion of the Lite Topic and its subscription state.

Scenario 2 — Large‑Model Memory Write Service

When AI products need to “remember” user preferences, a long‑term memory service writes per‑user facts into a store for later retrieval.

Challenges : strict ordering per user (e.g., “Monday: likes coffee” then “Tuesday: switched to tea”) and isolation among millions of concurrent users.

Lite Topic solution :

For each user, automatically create a second‑level Lite Topic under the first‑level topic mem, named mem.{userId}. This provides natural FIFO ordering, physical isolation, and independent consumption per user.

Parallelism is achieved by multiple worker instances; each worker handles a subset of users, but a single user’s messages are always processed by the same worker to preserve order.

Millions of such lightweight channels are supported; they are created on demand and reclaimed automatically via TTL.

Producer / Consumer usage :

Producer (memory‑write service) publishes to mem.{userId}, writing the user’s memory events.

Consumer (memory‑processing service) subscribes with subscribeLite("mem.{userId}") to consume the user’s stream, perform embedding, evolve the memory, and write to a vector store or KV.

New users are discovered automatically because the consumer can also use a wildcard subscription subscribeLite("*") on the first‑level mem topic; new per‑user Lite Topics appear and are consumed without extra notification.

Key Capabilities Provided by Lite Topic

Async request handling with millions of isolated channels.

Strict FIFO ordering and physical isolation per channel.

Persistent storage with automatic TTL‑based reclamation.

Exclusive consumption mode (“latest connection wins”) for break‑resume streaming.

Wildcard subscription to discover newly created channels without manual registration.