AI applications are increasingly moving from a single agent to multiple agents that work together.
One agent may handle customer questions, another may search internal documentation, and another may perform an action in a business system. Once these agents start communicating with each other, the application needs a reliable way to exchange messages, maintain state, and coordinate work.
This is where an agent mesh can be useful.
A Redis-based agent mesh provides an infrastructure layer through which multiple AI agents can communicate without being tightly coupled to each other. Redis can help with message delivery, shared state, task coordination, and short-lived agent information.
The important idea is that agents should not need to know the internal implementation of every other agent. They can communicate through well-defined messages and routing rules.
What Is an Agent Mesh?
An agent mesh is a communication layer connecting multiple AI agents.
Consider a customer-support application with these agents:
User
|
v
Orchestrator Agent
|
+----> Knowledge Agent
|
+----> Order Agent
|
+----> Billing Agent
|
+----> Notification AgentThe orchestrator does not need to implement every capability itself.
Instead, it determines which agent should handle each task.
For example:
Customer asks about an order
|
v
Orchestrator Agent
|
v
Order Agent
|
v
Order ServiceThe response can then return through the same communication layer.
Redis can act as part of this communication infrastructure.
Why Use Redis for Agent Communication?
AI agents often need communication that is faster and more dynamic than traditional request-response APIs.
Redis is useful for this type of workload because applications can use it for:
- Message queues
- Pub/Sub communication
- Shared state
- Task coordination
- Temporary context
- Event notifications
- Rate limiting
- Agent status
- Session information
The exact Redis feature used should depend on the communication pattern.
For example, Pub/Sub is useful when multiple consumers need to receive an event, while a queue-oriented design is better when a task should be processed by a worker.
A Simple Agent Mesh Architecture
A basic architecture can look like this:
+----------------+
| API / Client |
+-------+--------+
|
v
+-------------------+
| Orchestrator Agent|
+---------+---------+
|
+---------v---------+
| Redis Agent |
| Communication |
+----+----+----+----+
| | |
v v v
Agent Agent Agent
A B CEach agent can have its own responsibility.
For example:
Agent A → Customer Support
Agent B → Order Processing
Agent C → Knowledge Search
Agent D → NotificationThe agents do not need direct connections to every other agent.
This reduces the number of dependencies between services.
Defining Agent Messages
The first step in building an agent mesh is defining the message format.
A message should contain enough information for the receiving agent to understand the request.
For example:
{
"messageId": "msg-1024",
"sourceAgent": "support-agent",
"targetAgent": "order-agent",
"task": "get-order-status",
"conversationId": "conv-501",
"payload": {
"orderId": "ORD-10045"
}
}The message contains several important fields.
The messageId helps identify a particular message.
The sourceAgent identifies the sender.
The targetAgent identifies the intended receiver.
The task describes the requested operation.
The conversationId allows related messages to be associated with the same interaction.
The payload contains task-specific information.
A consistent message contract becomes especially important when the number of agents increases.
Sending Agent Tasks Through Redis
A simplified Node.js example can use Redis to publish an agent message.
const message = {
messageId: crypto.randomUUID(),
sourceAgent: "support-agent",
targetAgent: "order-agent",
task: "get-order-status",
conversationId: "conv-501",
payload: {
orderId: "ORD-10045"
}
};
await redis.publish(
"agent:order",
JSON.stringify(message)
);The support agent does not need to know how the order agent retrieves the order.
It only needs to know the communication contract.
The order agent can subscribe to its communication channel and process incoming messages.
Receiving Messages in an Agent
A receiving agent can subscribe to its designated channel.
For example:
await subscriber.subscribe("agent:order");
await subscriber.on("message", async (channel, rawMessage) => {
const message = JSON.parse(rawMessage);
if (message.targetAgent !== "order-agent") {
return;
}
await processOrderTask(message);
});The processOrderTask function can then perform the actual business operation.
A simplified implementation might look like this:
async function processOrderTask(message) {
if (message.task === "get-order-status") {
const order = await getOrder(message.payload.orderId);
await redis.publish(
"agent:responses",
JSON.stringify({
messageId: crypto.randomUUID(),
sourceAgent: "order-agent",
targetAgent: message.sourceAgent,
conversationId: message.conversationId,
task: "order-status-result",
payload: order
})
);
}
}This creates a simple request-and-response flow between agents.
Pub/Sub Is Not the Same as a Task Queue
One common design mistake is treating every Redis communication pattern as a queue.
Pub/Sub works well for broadcasting events.
For example:
Order Updated
|
+----> Support Agent
+----> Analytics Agent
+----> Notification AgentEach subscriber can receive the event.
However, a task-processing system may require a different pattern.
For example:
Generate Report
|
v
Task Queue
|
+----> Worker AgentThe goal here is to have a worker process the task rather than broadcast it to every subscriber.
The communication mechanism should therefore match the required delivery behavior.
Adding an Orchestrator Agent
A multi-agent system usually benefits from an orchestrator.
The orchestrator determines which agent should handle a task.
For example:
User Request
|
v
Orchestrator
|
+---- Customer question → Support Agent
|
+---- Order question → Order Agent
|
+---- Documentation → Knowledge Agent
Join the conversation! Your thoughts help the community grow.