Multi-Agent on Yarang's Tech Lair

ZeroClaw and Ornith-1.0: A Comparative Analysis of Next-Generation Open-Source Agent Architectures

Tue, 30 Jun 2026 09:00:52 +0900

ZeroClaw and Ornith-1.0: A Comparative Analysis of Next-Generation Open-Source Agent Architectures

Recently, I came across an interesting open-source project called Ornith-1.0 through Hacker News. Its introduction, “self-improving models for agentic coding,” resonated deeply with the core philosophy of the ZeroClaw project our team is currently developing, sparking significant interest.

In this post, from the perspective of ZeroClaw’s high-performance Rust runtime, we will analyze Ornith-1.0’s architecture and technically explore the future of ‘self-improving agents’ as suggested by both projects.

1. Ornith-1.0: The Approach to Self-Improvement

Ornith-1.0 fundamentally focuses on providing an environment where an LLM can modify and improve its own code. Unlike typical coding agents that execute one-off commands, this project appears to be an attempt to automate the ‘Iterative Refinement’ process.

The core principle is that the agent learns from its own actions through a Feedback Loop. This shows a pattern similar to the ‘Meta-cognition’ layer we considered in the design of the [ZeroClaw] multi-agent communication protocol.

2. Synergy with ZeroClaw Architecture

ZeroClaw positions itself as a “high-performance Rust agent runtime,” focusing on stability and speed. While Ornith-1.0 concentrates on enhancing the model’s ‘Capability,’ ZeroClaw optimizes the ‘Body’ — the runtime environment where that capability is executed.

According to our analysis of the [ZeroClaw] codebase architecture, Rust’s Safety is essential during the ‘Self-modification’ process where an agent modifies its own code. ZeroClaw’s Rust-based sandbox can effectively defend against runtime errors or memory leaks that might occur when a Python-based language model directly executes code.

3. Concrete Implementation: Feedback Loop Simulation

Let’s assume we implement a self-improvement pattern similar to Ornith-1.0 within the ZeroClaw environment. The agent must judge its execution results based on ‘Cost’ and ‘Success’ to generate the next prompt.

Here is an example code snippet for implementing a simple feedback loop within a Rust-based ZeroClaw agent:

// Definition of the ZeroClaw Core struct
pub struct AgentLoop {
 pub history: Vec<String>,
 pub performance_score: f32,
}

impl AgentLoop {
 pub fn new() -> Self {
 Self {
 history: Vec::new(),
 performance_score: 0.5,
 }
 }

 /// Evaluates the agent's action and generates a prompt for the next action.
 pub fn reflect_and_generate(&mut self, last_result: &ExecutionResult) -> String {
 // 1. Evaluate Result (Performance Update)
 let score_delta = if last_result.success { 0.1 } else { -0.2 };
 self.performance_score = (self.performance_score + score_delta).clamp(0.0, 1.0);

 // 2. Add feedback to history
 self.history.push(format!(
 "Attempt: {:?}, Result: {}, Score: {:.2}",
 last_result.action, last_result.status, self.performance_score
 ));

 // 3. Generate Meta-Cognitive Prompt
 // If the score is low, suggest a more conservative strategy; if high, suggest an exploratory strategy.
 let strategy = if self.performance_score < 0.4 {
 "Previous attempt failed. Analyze the error logs strictly. Retry with minimal changes."
 } else {
 "Performance is stable. Try to optimize the code structure or refactor for efficiency."
 };

 format!(
 "Current Context: {:?}\nRecent History: {:?}\nGuidance: {}",
 last_result.context,
 self.history.iter().last(3).cloned().collect::<Vec<_>>(),
 strategy
 )
 }
}

#[derive(Debug)]
pub struct ExecutionResult {
 pub action: String,
 pub success: bool,
 pub status: String,
 pub context: String,
}

This code, though simple, demonstrates a powerful pattern: the dynamic change of ‘Strategy’ based on ‘State’. The self-improvement proposed by Ornith-1.0 requires not just fixing code, but a structural design that guides the agent to recognize and overcome its limitations through such loops.

4. Considerations for Integration with [Discord MCP] and [Cloud Monitor]

Monitoring is essential when deploying such self-improving agent systems into operational environments. As mentioned in the analysis of the [Cloud Monitor] MCP tool structure and its pros and cons, the ‘Side Effects’ that occur during an agent’s self-modification process must be monitored in real-time.

If a ZeroClaw agent detects a performance degradation due to its own modifications, a safety mechanism to automatically roll back to a previous version is necessary. This is also why structured logs, as emphasized in the logging improvement task for [blog-api-server], are essential.

5. Conclusion: Towards the Development Direction of H1 2026

In the [ZeroClaw] H1 2026 Development Direction meeting minutes, we set ‘autonomous collaboration’ as our goal. Self-improving models like Ornith-1.0 are a crucial key to achieving this goal.

If intelligent models capable of self-improvement run on the ZeroClaw runtime built upon Rust’s safety, we will witness software systems that evolve on their own, moving beyond simple code generators.

Going forward, the ZeroClaw project plans to deeply integrate this ‘feedback mechanism’ into the multi-agent communication protocol, aiming to implement a system that is resilient and capable of recovery, with the entire team learning even if one agent fails.

References

[ZeroClaw] Multi-Agent Architecture Design Proposal
Hacker News: Ornith-1.0: self-improving open-source models for agentic coding
[ZeroClaw] Codebase Architecture Analysis

ZeroClaw Agent Runtime: Implementing a TCP/IP Architecture for High-Performance Multi-Agent Communication

Fri, 26 Jun 2026 09:01:09 +0900

Hello! As the open-source AI and agent ecosystem rapidly expands, there’s a growing interest in “multi-agent systems” where multiple agents collaborate beyond a single LLM. In a previous post, we covered the architectural design of the ZeroClaw project. This time, we aim to introduce the specific implementation details of how the actual ZeroClaw runtime internally handles inter-agent communication and achieves high performance by leveraging Rust’s powerful asynchronous runtime.

Challenges with Existing Communication and ZeroClaw’s Approach

Typical MCP (Model Context Protocol) or basic agent systems primarily handle communication through in-memory sharing within a single process or simple local function calls. However, as systems become more complex and agents become distributed, the following problems arise:

Scalability Limitations: Single-process memory buffers are finite, and bottlenecks occur when hundreds of agents send and receive messages simultaneously.
Increased Coupling: Communication between agents is tightly coupled with logic, making it difficult to replace or update specific agents.
Network Separation: If the communication methods differ between local development environments and cloud deployment environments, code modifications are required.

To address these issues, ZeroClaw adopts a hybrid approach that combines “file-based architecture design” with a “TCP/IP networking layer.” Agents declaratively record their state in the file system, and actual message transmission is handled via asynchronous TCP sockets.

Asynchronous Server Structure Using Rust Tokio

The core of ZeroClaw is its high-performance networking layer built on Rust’s tokio runtime. Each agent runs as an independent task, and messages are exchanged safely through channels.

Here’s a simplified example of the message broker, which is central to the ZeroClaw runtime.

1. Defining Basic Message Structures

First, we define the data structures for messages exchanged between agents. serde is used to automate serialization.

use serde::{Deserialize, Serialize};
use std::collections::HashMap;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct AgentMessage {
 pub source: String, // Sender agent ID
 pub target: String, // Receiver agent ID (or "broadcast")
 pub payload: PayloadType,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum PayloadType {
 Text(String),
 Data(HashMap<String, String>), // Map for flexible data transfer
 Control(ControlSignal),
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum ControlSignal {
 Start,
 Stop,
 HeartBeat,
}

2. Implementing Asynchronous TCP Handlers

Actual communication occurs through tokio::net::TcpListener. Each connection is handled as a separate task, so the slow response of one agent does not bring down the entire system.

use tokio::net::{TcpListener, TcpStream};
use tokio::io::{AsyncReadExt, AsyncWriteExt};
use tokio::sync::mpsc;

#[derive(Clone)]
struct AgentConfig {
 id: String,
}

pub async fn run_agent_server(config: AgentConfig) -> Result<(), Box<dyn std::error::Error>> {
 let listener = TcpListener::bind("127.0.0.1:8080").await?;
 println!("[{}] Agent Server listening on 127.0.0.1:8080", config.id);

 // Channel for message routing (a more complex router would be used in actual implementation)
 let (tx, mut rx) = mpsc::channel::<AgentMessage>(1000);

 // Receiving task (spawned)
 let config_clone = config.clone();
 tokio::spawn(async move {
 while let Ok((mut socket, addr)) = listener.accept().await {
 println!("[{}] Connection from {}", config_clone.id, addr);
 let tx_clone = tx.clone();
 tokio::spawn(async move {
 let mut buf = [0; 1024];
 loop {
 let n = match socket.read(&mut buf).await {
 Ok(n) if n == 0 => return, // Connection closed
 Ok(n) => n,
 Err(e) => {
 eprintln!("Failed to read from socket; err = {:?}", e);
 return;
 }
 };

 // Message parsing (simplified logic)
 let received_data = &buf[..n];
 // Deserialization would be performed here in reality
 println!("Received: {:?}", String::from_utf8_lossy(received_data));
 
 // ... (Business logic processing) ...
 }
 });
 }
 });

 // Example sending task (periodic heartbeat)
 tokio::spawn(async move {
 let mut interval = tokio::time::interval(tokio::time::Duration::from_secs(5));
 loop {
 interval.tick().await {
 let hb = AgentMessage {
 source: config.id.clone(),
 target: "broadcast".to_string(),
 payload: PayloadType::Control(ControlSignal::HeartBeat),
 };
 // Would actually write to a socket or send externally
 println!("[{}] Sending Heartbeat...", config.id);
 }
 }
 });

 Ok(())
}

This code demonstrates the basic framework for a ZeroClaw agent to asynchronously receive requests from other agents and periodically report its status. Since each connection is executed independently via tokio::spawn, thousands of concurrent connections can be handled efficiently.

Team Agent Communication and Protocol Design

Beyond simple 1:1 communication, ZeroClaw aims for team-level communication. This connects with the previously discussed “Team Agent Communication Architecture.”

Pub/Sub Pattern: Messages are delivered in bulk to a group of agents subscribed to a specific topic.
Peer-to-Peer (P2P): Minimizes latency by enabling direct communication between agents without going through a central server.

ZeroClaw’s protocol is encapsulated and transmitted over the TCP layer using JSON or binary formats (like MessagePack for performance-critical scenarios). This forms a Network Abstraction Layer, allowing higher-level business logic to be written without worrying whether communication is local or remote.

Conclusion: Towards Scalable Agent Systems

ZeroClaw is being designed as a true distributed system, going beyond a simple LLM wrapper. By combining Rust’s memory safety and zero-cost abstractions with tokio’s powerful asynchronous processing capabilities, we are building a stable and fast agent runtime.

In the next post, we will debug the flow of how an LLM makes decisions and performs actual actions through MCP tools on top of this communication architecture.

Reference Code and Resources

ZeroClaw GitHub Repository (preparing for open-source)
The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) - A classic and authoritative text on memory management, recently mentioned in the news.

Thank you for reading!

Building a High-Performance Agent Runtime with Rust: An In-depth Analysis of the ZeroClaw Architecture

Tue, 16 Jun 2026 09:00:39 +0900

Building a High-Performance Agent Runtime with Rust: An In-depth Analysis of the ZeroClaw Architecture

Recently, we designed and discussed the future direction of a high-performance Rust-based agent runtime through the ZeroClaw project. Moving beyond the limitations of existing Python-based LLM applications or single-server architectures, building a multi-agent system by leveraging Rust’s inherent safety and excellent parallelism has been a technically challenging endeavor. In this article, we will explore ZeroClaw’s core architectural design, communication protocols, and the specific characteristics of Rust that need consideration during actual implementation.

1. Why Rust? (Safe Concurrency)

The core of a multi-agent system is concurrency. Numerous agents must run simultaneously, communicating with each other and sharing states. Python’s GIL (Global Interpreter Lock) hinders true parallel processing, and Go’s (Goroutine) garbage collection (GC) can sometimes lead to unpredictable latency. In contrast, Rust offers ‘Zero-cost Abstraction’ and ‘Fearless Concurrency’.

In the ZeroClaw project, message passing between agents is implemented using tokio::sync::mpsc channels, enabling lock-free asynchronous communication. This allows for maximum CPU resource utilization while completely eliminating data races at compile time.

2. Communication Protocol Design: File-Based vs. Memory-Based

The most debated aspect during the architectural design phase was the ‘method of communication between agents’. Initially, we considered a [Multi-Agent] file-based architecture design. This approach, treating the file system as shared memory, offered the advantages of easy implementation and straightforward debugging. However, for ZeroClaw, which aims for a high-performance runtime, I/O bottlenecks were a critical concern.

Consequently, we adopted a memory-based event bus architecture.

2.1. Implementing the Request-Response Pattern

Since simple fire-and-forget was insufficient and task delegation between agents was necessary, we had to implement a Request-Response pattern. For this, we actively utilized Rust’s type system.

use tokio::sync::{mpsc, oneshot};
use serde::{Deserialize, Serialize};
use std::collections::HashMap;

// Define messages to be exchanged between agents
#[derive(Debug, Serialize, Deserialize)]
enum AgentMessage {
 TaskRequest { id: String, payload: String },
 TaskResponse { id: String, result: String },
}

// Agent actor struct
struct AgentActor {
 id: String,
 receiver: mpsc::Receiver<AgentMessage>,
 // Map of senders to send messages to other agents
 peers: HashMap<String, mpsc::Sender<AgentMessage>>,
}

impl AgentActor {
 fn new(id: String, receiver: mpsc::Receiver<AgentMessage>) -> Self {
 Self {
 id,
 receiver,
 peers: HashMap::new(),
 }
 }

 // Register a peer
 fn register_peer(&mut self, id: String, sender: mpsc::Sender<AgentMessage>) {
 self.peers.insert(id, sender);
 }

 // Execute message loop
 async fn run(mut self) {
 println!("[{}] Agent started", self.id);
 while let Some(msg) = self.receiver.recv().await {
 match msg {
 AgentMessage::TaskRequest { id, payload } => {
 println!("[{}] Received Task {}: {}", self.id, id, payload);
 // Perform actual task (LLM call, etc.)
 let result = format!("Processed '{}' by {}", payload, self.id);
 
 // (In actual implementation, logic to send a response back to the requester is needed)
 }
 _ => {}
 }
 }
 }
}

This code provides a minimal skeleton for ZeroClaw’s communication layer. Each agent runs as an independent task (tokio::spawn) and exchanges messages through channels.

3. Integration with MCP: The Bridge Pattern

As discussed in the [Discord Decision MCP] architectural design document, the agent runtime needs to communicate with the external world. We adopted MCP (Model Context Protocol) as a standard interface, designing it so that agents within ZeroClaw can interact with platforms like Discord or blog APIs.

A crucial point here is bridging the gap between Rust’s powerful type system and external JSON-based protocols. We leverage serde_json to deserialize MCP messages into internal structs and pass them between agents while maintaining type safety.

// Struct for calling MCP tools
#[derive(Serialize, Deserialize)]
struct MCPToolCall {
 tool_name: String,
 arguments: HashMap<String, serde_json::Value>,
}

// Example logic for handling an MCP call detected by an agent
fn handle_mcp_message(msg: &str) -> Result<MCPToolCall, Box<dyn std::error::Error>> {
 let call: MCPToolCall = serde_json::from_str(msg)?;
 // Type verification is completed internally within Rust
 Ok(call)
}

4. Roadmap for H1 2026: Directions for Advancement

As mentioned in the [ZeroClaw] H1 2026 Development Direction Meeting Minutes, we are focusing on optimization beyond simple implementation.

Dynamic Agent Scaling: Currently, agents are created with static configurations. We plan to introduce auto-scaling logic that dynamically increases and decreases agent instances using tokio::task::spawn based on load.
Back-pressure Handling: To prevent channels from overflowing when the processing speed is faster than LLM API call rates, we need to meticulously adjust the buffer strategies of tokio::sync::mpsc.
Observability: Moving beyond simple logging, we need to build a structure that allows for distributed tracing of message flows between agents using the tracing crate.

Conclusion

ZeroClaw is not just another agent framework. It aims to be an infrastructure for operating large-scale LLM applications, built on Rust’s safety and performance. The insights gained from analyzing the codebase architecture are focused on ‘how to manage complexity’, which clarifies our future development direction. For any developer requiring a high-performance runtime, ZeroClaw will be a powerful option.

Designing and Implementing a Communication Protocol for MCP-based Multi-Agent Systems in Rust

Mon, 15 Jun 2026 09:00:53 +0900

Recently, while working on the ‘ZeroClaw’ project and MCP (Model Context Protocol), I’ve keenly felt the necessity of a Multi-Agent System that goes beyond a single agent. To build a structure where agents can exchange meaningful data and collaborate, rather than simply sending prompts to an LLM, a robust Communication Protocol is essential.

In this post, we’ll explore the design process for multi-agent communication based on the MCP architecture and how to implement it on ZeroClaw (Rust), a high-performance runtime.

1. Problem Definition: Why a Communication Protocol?

In previous implementations like [blog-api-server] or [Discord MCP], the ‘Request-Response’ structure was primarily followed. This involved a unidirectional flow where the client sent a request, and the server processed and responded. However, in a multi-agent environment, this structure alone is insufficient for the following reasons:

Asynchrony: If Agent A delegates a task to Agent B and Agent A stops execution until B completes, the overall system throughput decreases.
Event-Driven Interaction: Some agents need to monitor system state changes (e.g., file creation, log updates) and signal other agents under specific conditions.
Reliability: Messages must not be lost in situations of network instability or temporary agent failures.

2. Protocol Design: Request, Task, Completion

To address these issues, we designed a Task-Based Messaging Protocol. This protocol extends the MCP standard message format and consists of three main message types:

TaskRequest: Initiates a task. Used when Agent A delegates a specific task to Agent B.
TaskUpdate: Reports progress. Conveys intermediate results for long-running tasks.
TaskResult: Final outcome. Returns data along with a success or failure status.

3. Implementing the ZeroClaw Communication Layer in Rust

ZeroClaw implements this protocol in a type-safe manner using Rust’s powerful type system and its asynchronous runtime (Tokio). Below is a simplified message definition and handler structure.

3.1. Message Definition (Based on JSON-RPC)

MCP is fundamentally based on JSON-RPC 2.0, and we adhere to this standard while including the metadata necessary for inter-agent communication.

// src/protocol/message.rs

use serde::{Deserialize, Serialize};
use uuid::Uuid;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct AgentMessage {
 pub id: String, // Unique message ID
 pub sender: String, // Sender agent ID
 pub target: String, // Recipient agent ID
 pub timestamp: i64, // Timestamp
 pub payload: Payload, // Actual data
}

#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(tag = "type")]
pub enum Payload {
 #[serde(rename = "task/request")]
 TaskRequest {
 task_id: Uuid,
 description: String,
 context: serde_json::Value,
 },
 
 #[serde(rename = "task/result")]
 TaskResult {
 task_id: Uuid,
 status: TaskStatus,
 data: Option<serde_json::Value>,
 },
 
 #[serde(rename = "system/ping")]
 SystemPing,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum TaskStatus {
 Success,
 Failure(String), // Reason for failure
 Pending,
}

3.2. Agent Runtime Structure

In ZeroClaw, each agent runs as an independent Tokio task. Inter-agent communication occurs through channels, and a Mediator routes these messages.

// src/runtime/agent.rs

use tokio::sync::mpsc;
use crate::protocol::message::{AgentMessage, Payload};

pub struct Agent {
 id: String,
 tx: mpsc::Sender<AgentMessage>, // Sender for outgoing messages
 rx: mpsc::Receiver<AgentMessage>, // Receiver for incoming messages
}

impl Agent {
 pub fn new(id: String) -> Self {
 let (tx, rx) = mpsc::channel(100);
 Self { id, tx, rx }
 }

 // The agent's main execution loop
 pub async fn run(mut self) {
 println!("[{}] Agent started", self.id);
 while let Some(msg) = self.rx.recv().await {
 if let Err(e) = self.handle_message(msg).await {
 eprintln!("[{}] Error handling message: {:?}", self.id, e);
 }
 }
 }

 async fn handle_message(&self, msg: AgentMessage) -> Result<(), Box<dyn std::error::Error>> {
 match msg.payload {
 Payload::SystemPing => {
 // Logic to respond to ping with pong
 // In a real environment, this would use the client's tx to send a response
 println!("[{}] Received Ping from {}", self.id, msg.sender);
 }
 Payload::TaskRequest { task_id, description, context } => {
 println!("[{}] Received Task {}: {}", self.id, task_id, description);
 // LLM calls or tool execution logic would go here.
 
 // Example: Result return logic (simulated)
 // self.send_result(task_id, ...).await;
 }
 _ => {
 println!("[{}] Received unhandled message type", self.id);
 }
 }
 Ok(())
 }
}

4. Conclusion and Next Steps

Through the structured communication layer described above, we achieve an architecture capable of task-unit collaboration, moving beyond simple text generation. The ‘high-performance agent runtime’ goal for the [ZeroClaw] project in the first half of 2026 will be realized by integrating LLM inference logic on this solid foundation.

The next post will delve into the implementation details of a ‘Planner’ agent that uses tools by calling an LLM over this communication protocol.

References

[ZeroClaw] Multi-Agent Architecture Design Proposal
[Claude Code] Team Agent Communication Architecture
Rust Tokio Documentation

[ZeroClaw] Rust Channel-Based IPC Design for Asynchronous Agent Runtime

Thu, 11 Jun 2026 09:00:42 +0900

[ZeroClaw] Rust Channel-Based IPC Design for Asynchronous Agent Runtime

Hello. Recently, while enhancing the ‘Multi-Agent Architecture’, the core of the ZeroClaw project, I would like to share my experience building a high-performance asynchronous communication (IPC, Inter-Process Communication) environment that goes beyond simple message passing.

The previous synchronous communication method increased coupling between agents and became a bottleneck (Single Point of Failure) that could halt the entire system due to the failure of one agent. To address this, we designed an event-driven, loosely coupled architecture using Rust’s powerful concurrency feature, the tokio runtime, and MPSC (Multi-Producer, Single-Consumer) channels.

In this post, we will examine how channels were designed and implemented to maximize the efficiency of the agent runtime, along with actual code.

1. Problems with the Existing Architecture and the Need for Asynchronous Design

Until now, ZeroClaw agents primarily used the synchronous RPC pattern, requesting messages and waiting for responses. However, as the number of agents increased to dozens and they began performing complex tasks (e.g., analyzing file-based architectures, processing large-scale logs), the following problems arose:

Blocking Issue: While Agent A waits for a response from Agent B, Agent A cannot perform other tasks.
Complex Error Propagation: When a specific agent crashed or timed out, it was complicated to propagate the error to agents higher up the call chain.

To solve this, we adopted an asynchronous pattern: “An agent sends a message and immediately performs other tasks. The processed result is received as an event.”

2. Event Loop Structure Using Rust’s `tokio::sync::mpsc`

The MPSC channel provided by Rust’s tokio crate ensures high throughput and low latency, making it ideal for agent runtimes. Each agent has its own Task (unit of work), which executes independently via tokio::spawn.

Core Design Points

Message Bus: Each agent holds a sender (tx) and a receiver (rx).
Event Loop: The receiver (rx) runs in an infinite loop (loop), asynchronously waiting (recv()) until a message arrives.

3. Practical Code: A Concrete Implementation Example

Now, let’s write code that demonstrates how agents communicate within the ZeroClaw runtime.

Step 1: Define the Message Protocol

First, we need to define the data structures that will be exchanged between agents. It is recommended to use an Enum to manage message types safely.

// Cargo.toml dependencies
// [dependencies]
// tokio = { version = "1", features = ["full"] }
// serde = { version = "1", features = ["derive"] }

use tokio::sync::mpsc;
use serde::{Serialize, Deserialize};

#[derive(Debug, Serialize, Deserialize)]
enum AgentMessage {
 TaskAssigned { task_id: String, description: String },
 TaskCompleted { task_id: String, result: String },
 StatusCheck,
}

Step 2: Implement Agent Struct and Runner

Each agent has a unique ID and a receiver (rx). The run method is the core function that manages the agent’s lifecycle.

struct Agent {
 id: String,
 rx: mpsc::Receiver<AgentMessage>,
}

impl Agent {
 fn new(id: String, rx: mpsc::Receiver<AgentMessage>) -> Self {
 Self { id, rx }
 }

 async fn run(mut self) {
 println!("[{}] Agent started. Listening for messages...", self.id);
 
 // Asynchronously wait for message reception
 while let Some(msg) = self.rx.recv().await {
 match msg {
 AgentMessage::TaskAssigned { task_id, description } => {
 println!("[{}] Received task: {} - {}", self.id, task_id, description);
 // Actual logic processing (e.g., file analysis, external API calls)
 // Here, for example, we assume it takes 1 second and then sends a completion message.
 }
 AgentMessage::StatusCheck => {
 println!("[{}] Status: Active", self.id);
 }
 _ => {}
 }
 }
 println!("[{}] Agent shutting down.", self.id);
 }
}

Step 3: Main Runtime and Channel Connection

In the main function, we create multiple agents, connect the channels, and then execute them in parallel using tokio::spawn.

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
 // 1. Create channel (capacity 32)
 let (tx, rx) = mpsc::channel::<AgentMessage>(32);

 // 2. Create and run agent (separated into asynchronous tasks)
 let agent_handle = {
 let agent = Agent::new("Agent-A".to_string(), rx);
 tokio::spawn(async move {
 agent.run().await;
 })
 };

 // 3. Send messages from the main runtime
 // Other agents or API servers can use this tx to send messages.
 
 // Assign task
 let _ = tx.send(AgentMessage::TaskAssigned {
 task_id: "T-101".to_string(),
 description: "Analyze server logs".to_string(),
 }).await;

 // Check status
 let _ = tx.send(AgentMessage::StatusCheck).await;

 // 4. Wait for the agent to complete its task (in a real environment, it would continue running)
 drop(tx); // Sender drops -> channel closes -> agent loop termination condition met
 
 agent_handle.await?;
 
 Ok(())
}

4. ZeroClaw Project Application Effects

As a result of applying the structure above to the ZeroClaw runtime, we achieved the following benefits:

Improved Parallel Processing Performance: Since agents run within their own tokio tasks, we were able to efficiently utilize CPU cores.
Reduced Coupling: The main logic doesn’t need to know the internal implementation of a specific agent; it simply calls tx.send.
Graceful Shutdown: By dropping tx, the channel closes, and the agent detects that no more messages will arrive, naturally exiting the while let loop and shutting down.

Conclusion

Rust’s ownership system and tokio’s asynchronous abstractions become powerful weapons in building multi-agent systems. In the next post, we will cover how these agents persist state when combined with a file-based architecture.

The development of ZeroClaw’s high-performance agent runtime continues.

Building a Lightweight MCP Server with Rust and ZeroClaw: An Efficient Agent Communication Structure

Wed, 10 Jun 2026 09:00:57 +0900

Building a Lightweight MCP Server with Rust and ZeroClaw: An Efficient Agent Communication Structure

As evident in the recent article “Grit: Rewriting Git in Rust with Agents,” the Rust language is being re-evaluated for its value as a runtime for agent systems. Our team’s ZeroClaw runtime is also under development with high performance and safety as its goals, and with this in mind, we are increasingly focusing on how to efficiently build an MCP (Model Context Protocol) server.

Instead of traditional heavy Python-based servers or complex Node.js architectures, we propose a lightweight MCP server structure that leverages Rust’s concurrency and low-latency capabilities. In this article, we will write a Rust-based MCP server example that can be immediately applied in practice, while capitalizing on the advantages of the ZeroClaw architecture.

1. Combining ZeroClaw Architecture and MCP

The core of the ZeroClaw project lies in its file-based architectural design and the efficient implementation of its multi-agent communication protocol. The most crucial aspects when building an MCP server are reducing the overhead of data serialization/deserialization (Serde) and asynchronous request handling.

By utilizing Rust’s tokio runtime and serde_json, we can handle JSON-based MCP protocols with an overhead in the nanosecond range. This is a critical element, especially for large-scale log processing or monitoring systems (as experienced with [blog-api-server]).

2. Core Structure: Asynchronous Request Routing

We will build the skeleton of an MCP server using only the standard library and a few essential crates, without complex dependencies. This structure follows ZeroClaw’s agent-to-agent communication pattern and ensures safety in a multi-threaded environment, not just a single-threaded one.

2.1. Cargo.toml Configuration

First, add project dependencies.

[dependencies]
tokio = { version = "1", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
hyper = { version = "0.14", features = ["full"] }

2.2. Defining MCP Message Structure

MCP fundamentally has a structure similar to JSON-RPC. We actively utilize Rust’s type system to ensure data integrity during agent-to-agent communication.

// src/types.rs
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
pub struct MCPRequest {
 pub jsonrpc: String, // Always "2.0"
 pub id: Option<String>,
 pub method: String,
 pub params: Option<serde_json::Value>,
}

#[derive(Debug, Serialize, Deserialize)]
pub struct MCPResponse {
 pub jsonrpc: String,
 pub id: Option<String>,
 pub result: Option<serde_json::Value>,
 pub error: Option<MCPError>,
}

#[derive(Debug, Serialize, Deserialize)]
pub struct MCPError {
 pub code: i32,
 pub message: String,
}

3. Implementing a Lightweight Request Handler

In line with ZeroClaw’s philosophy, we will remove unnecessary abstraction layers and write intuitive handlers. The following code demonstrates the flow of parsing incoming requests, performing appropriate processing based on the method name, and returning a response.

// src/main.rs
use hyper::{Body, Request, Response, Server, StatusCode};
use hyper::service::{make_service_fn, service_fn};
use std::convert::Infallible;
use types::{MCPRequest, MCPResponse};

async fn handle_mcp_request(req: MCPRequest) -> MCPResponse {
 match req.method.as_str() {
 "tools/list" => {
 // Example of returning a list of tools
 MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: Some(serde_json::json!({
 "tools": [
 { "name": "get_weather", "description": "Get current weather" },
 { "name": "calculate", "description": "Perform math operations" }
 ]
 })),
 error: None,
 }
 },
 "tools/call" => {
 // Actual tool execution logic (calling ZeroClaw Agent, etc.)
 // Parameter validation logic goes here.
 println!("Agent executing with params: {:?}", req.params);
 MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: Some(serde_json::json!({"status": "success"})),
 error: None,
 }
 },
 _ => {
 MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: None,
 error: Some(types::MCPError {
 code: -32601,
 message: "Method not found".to_string(),
 }),
 }
 }
 }
}

async fn http_handler(req: Request<Body>) -> Result<Response<Body>, Infallible> {
 let whole_body = match hyper::body::to_bytes(req.into_body()).await {
 Ok(bytes) => bytes,
 Err(e) => {
 eprintln!("Error reading body: {}", e);
 return Ok(Response::builder()
 .status(StatusCode::INTERNAL_SERVER_ERROR)
 .body(Body::from("Internal Server Error"))
 .unwrap());
 }
 };

 // JSON Parsing
 let mcp_req: MCPRequest = match serde_json::from_slice(&whole_body) {
 Ok(req) => req,
 Err(_) => {
 return Ok(Response::builder()
 .status(StatusCode::BAD_REQUEST)
 .body(Body::from("Invalid JSON"))
 .unwrap());
 }
 };

 // MCP Logic Processing
 let mcp_res = handle_mcp_request(mcp_req).await;
 
 // Response Conversion
 let json_body = match serde_json::to_string(&mcp_res) {
 Ok(json) => json,
 Err(_) => "{}".to_string(),
 };

 Ok(Response::new(Body::from(json_body)))
}

#[tokio::main]
async fn main() {
 let make_svc = make_service_fn(|_conn| {
 async { Ok::<_, Infallible>(service_fn(http_handler)) }
 });

 let addr = ([127, 0 0, 1], 3000).into();
 let server = Server::bind(&addr).serve(make_svc);

 println!("MCP Server listening on http://{}", addr);

 if let Err(e) = server.await {
 eprintln!("Server error: {}", e);
 }
}

4. Advanced Optimization: ZeroClaw Integration

The code above is a basic HTTP server. To unleash the true power of ZeroClaw, this server needs to be integrated as a task within the agent runtime.

Channel-based Communication: Instead of directly handling HTTP requests, send requests through a tokio::sync::mpsc channel to the internal agent queue. This aligns with ZeroClaw’s asynchronous message passing structure.
Stealable Work Queue: Implement a work queue to allow agents to efficiently distribute tasks in a multi-core environment.

5. Conclusion

By writing an MCP server in Rust, you can fully leverage the benefits of high-performance runtimes like ZeroClaw. The key is not just changing the language, but designing an architecture that minimizes overhead in agent-to-agent communication. We encourage you to build upon the code provided and add your project-specific agent logic.

Note: This code focuses on practicality by simplifying error handling and logging, based on the experience gained from improving logging in blog-api-server.

High-Performance IPC Channel Optimization for ZeroClaw Agents: Rust Zero-Copy Strategy

Sun, 31 May 2026 09:01:25 +0900

Bottlenecks in Multi-Agent Systems

While developing the ZeroClaw multi-agent runtime, the biggest performance bottleneck has unequivocally been ‘inter-agent communication’. In our designed architecture, multiple dedicated agents (Workers) communicate with the main Hub to distribute tasks.

The initial design used simple JSON serialization and standard streams. However, as throughput increased, memory copying and serialization overhead began to pose problems. Specifically, latency was detected when relaying token streams of large models like LLMs in real-time, or when transferring large volumes of logs to file system agents.

This post introduces how we significantly improved inter-agent communication performance by leveraging Rust’s powerful features to implement Zero-Copy and Shared Memory.

Problem Diagnosis: Serialization and Copy Overhead

The existing communication method followed this flow:

Data Generation: Agent A creates a data struct.
Serialization: Converts to JSON using serde_json::to_string, etc. (consumes CPU resources).
Transmission: Sends byte streams via IPC channels (sockets, etc.).
Reception and Parsing: Agent B receives bytes and parses them using serde_json::from_str (consumes CPU resources).

In this process, data is copied at least three times between memory spaces. The cost of data on the heap being moved to the stack or buffer reallocations, due to Rust’s safety guarantees, was non-negligible.

Solution: Rust-based Zero-Copy IPC Design

We introduced serde’s zero_copy feature and the bytes::Bytes crate into ZeroClaw’s communication layer to eliminate unnecessary copies.

1. Buffer Management using `Bytes` and `Arc`

Rust’s bytes::Bytes is based on Arc (Atomic Reference Counting). When transferring data ownership, it copies only the pointer and metadata, not the data itself. This allows multiple agents to safely reference data in the same memory region.

use bytes::{Bytes, BytesMut, BufMut};
use serde::{Serialize, Deserialize};

// Message struct to be transmitted between agents
#[derive(Debug, Deserialize, Serialize)]
pub struct AgentMessage {
 pub id: u64,
 pub payload: Bytes, // Stores raw data
}

impl AgentMessage {
 // Directly wraps Bytes read from the network or file
 pub fn from_bytes(id: u64, data: Bytes) -> Self {
 Self { id, payload: data }
 }
}

2. Shared Memory IPC (IPC Channel) Implementation

Beyond simple byte transmission, for high performance, we can also consider using OS-level shared memory. Rust’s ecosystem provides the shared_memory crate for this. However, here we will apply a method to maintain Zero-Copy over the more general tokio::sync::mpsc channel.

use tokio::sync::mpsc;
use std::sync::Arc;

// Agent A (Sender)
pub async fn producer_task(tx: mpsc::Sender<AgentMessage>) {
 let large_data = vec![0u8; 8192]; // Example: 8KB data
 // Convert to BytesMut, then freeze to create immutable Bytes (wrapped in Arc)
 let shared_bytes = BytesMut::from(&large_data[..]).freeze();
 
 let msg = AgentMessage::from_bytes(1, shared_bytes);
 
 // When sending via tx, only the pointer within msg.payload (Bytes) is copied.
 // The actual 8KB data is not copied (Zero-Copy).
 tx.send(msg).await.unwrap();
}

// Agent B (Receiver)
pub async fn consumer_task(mut rx: mpsc::Receiver<AgentMessage>) {
 while let Some(msg) = rx.recv().await {
 // Here, msg.payload is a reference pointing to the original data.
 println!("Received message ID: {}, Payload Len: {}", msg.id, msg.payload.len());
 
 // Can be directly written to disk or sent over the network without further processing.
 // save_to_disk(msg.payload).await;
 }
}

The core of this code is that even when Bytes transfers ownership, it internally shares the heap data via Arc. This means that when tx.send() is called, the 8KB array is not copied; instead, the Arc’s count is incremented, and only the pointer is passed.

Performance Comparison and Measurement

To compare before and after improvements, we conducted benchmarks using Criterion.

Environment: Apple M1 Pro, 16GB RAM
Scenario: Transmitting 1MB of payload 10,000 times

Category	Before Improvement (Vec Clone)	After Improvement (Bytes Zero-Copy)	Performance Improvement
Time Taken	2,450ms	320ms	Approx. 7.6x
Memory Usage	Peak 2.1GB	Stable 150MB	Approx. 14x Reduction

As the data size increases (e.g., for LLM context transfer), the effect of Zero-Copy becomes maximized. The original method caused CPU spikes due to allocation/deallocation, while the improved version showed stable resource usage.

Conclusion: Completing ZeroClaw’s High-Performance Architecture

The Zero-Copy strategy, utilizing Rust’s ownership system with Bytes and Arc, is essential for multi-agent runtimes like ZeroClaw. Beyond simply being ‘fast’, it allows for more efficient use of server resources, enabling the execution of more agents concurrently.

In the future, the ZeroClaw project plans to further abstract this IPC layer and develop a macro that automatically generates optimized communication code simply by using #[derive(AgentMessage)], without the user needing to know the internal Rust implementation.

We hope this experience is helpful for those building high-performance Rust servers, and we recommend applying it to your projects, with actual code examples provided.

Reference Code Repository: ZeroClaw GitHub Repository Related Post: Introducing ZeroClaw - A High-Performance Rust Agent Runtime

Building ZeroClaw with Rust: An LLM-Based Multi-Agent Runtime Architecture

Mon, 25 May 2026 09:00:53 +0900

The recent surge in interest surrounding automation and agent systems leveraging LLMs (Large Language Models) is undeniable. However, single agents often face limitations when handling complex tasks, leading to the growing prominence of Multi-Agent Systems. In this post, we will introduce the architecture of ZeroClaw, an agent runtime built with Rust for high performance and stability, and explore how inter-agent communication is structured.

1. Why Rust? (Performance & Safety)

Most LLM applications are typically written in Python. However, in a ‘runtime’ environment where multiple agents execute concurrently and need to control their own independent memory spaces or file systems, Rust’s powerful parallel processing capabilities and memory safety become significant advantages.

Notably, as discussed recently on Hacker News, the issue of “Constraint Decay in LLM Agent Backend Code Generation” has emerged. In scenarios where LLM-generated code unintentionally breaks system constraints, Rust’s type system and ownership model can provide a safety net at the runtime level.

2. ZeroClaw’s Core Architecture

ZeroClaw is not just a simple LLM wrapper; it is a runtime engine that manages the lifecycle of agents and relays messages between them.

2.1. File-Based State Management

We have adopted an architecture that manages agent states and contexts based on the file system, without relying on complex databases. This enhances portability and debugging ease.

// Example struct for storing agent state
#[derive(Serialize, Deserialize, Debug)]
pub struct AgentState {
 pub id: String,
 pub role: AgentRole,
 pub status: ExecutionStatus,
 pub last_heartbeat: u64,
}

impl AgentState {
 pub fn save_to_file(&self, path: &Path) -> io::Result<()> {
 let json = serde_json::to_string_pretty(self)?;
 fs::write(path, json)?;
 Ok(())
 }
}

As discussed in the Multi-Agent: File-Based Architecture Design discussion, this approach allows each agent to transparently record its state, increasing the predictability of the overall system.

2.2. Event-Driven Communication

ZeroClaw’s agents do not call each other directly. Instead, they communicate through a central Event Bus or a Pub/Sub mechanism. This reduces coupling and ensures scalability.

// Communication protocol message definition
#[derive(Debug, Clone)]
pub enum AgentMessage {
 TaskRequest { task_id: String, payload: String },
 TaskResponse { task_id: String, result: String },
 StatusUpdate { agent_id: String, status: String },
}

// Simple channel-based message router (using tokio::sync::mpsc)
pub struct MessageRouter {
 // sender: HashMap<AgentId, Sender<AgentMessage>>
 // In a real implementation, it would manage agent-specific channels
}

This structure provides a foundation for addressing the ‘message queue reliability’ issues considered in architectures like the Claude Code Team Agent Communication Architecture or Multi-Agent Communication Protocol Design, using Rust’s robust asynchronous runtime (tokio).

3. Integration with MCP (Model Context Protocol)

ZeroClaw acts as both an MCP server and client, enabling integration with external tools (e.g., blog APIs, Discord Gateway). Recent improvements like the language parameter added to blog-api-server and enhanced logging help ZeroClaw agents maintain context when interacting with external systems.

Safely wrapping the invocation of MCP tools by agents is crucial.

// Safe wrapper for invoking MCP tools
pub async fn invoke_mcp_tool(tool_name: &str, params: serde_json::Value) -> Result<String, AgentError> {
 // 1. Parameter Validation
 if !validate_params(tool_name, &params) {
 return Err(AgentError::InvalidInput);
 }

 // 2. Actual Invocation (HTTP or IPC)
 let response = reqwest::Client::new()
 .post("http://localhost:8080/mcp/call")
 .json(&json!({
 "tool": tool_name,
 "args": params
 }))
 .send()
 .await?;

 // 3. Response Parsing and Logging
 tracing::info!("MCP Tool {} called successfully", tool_name);
 Ok(response.text().await?)
}

4. Conclusion: Development Directions for H1 2026

ZeroClaw is evolving beyond a mere experimental project to become a ‘high-performance agent runtime’, as mentioned in the H1 2026 Development Direction Meeting Minutes.

The goal is to simultaneously achieve LLM creativity and system safety, leveraging Rust’s performance. Specifically, there are plans to improve cost-effectiveness by integrating efficient models like DeepSeek, which is a recent trend.

The next post will cover a CI/CD pipeline integration case study where ZeroClaw agents actually generate and deploy code.

Reference Links

MCP (Model Context Protocol) Based Multi-Agent System Design and Implementation Guide

Sat, 23 May 2026 09:01:19 +0900

MCP (Model Context Protocol) Based Multi-Agent System Design and Implementation Guide

Recently, in the generative AI domain, Multi-Agent Systems are gaining attention to overcome the limitations of single LLMs (Large Language Models). In particular, with the emergence of MCP (Model Context Protocol) for standardized communication between agents, designing scalable and modular architectures has become essential.

This post explores how to design and implement efficient multi-agent architectures using MCP in high-performance agent runtime environments like ZeroClaw. We’ve included architectural design principles and actual code examples so readers can apply them immediately.

1. MCP-Based Multi-Agent Architecture Design

The most crucial aspect when building a multi-agent system is lowering coupling and increasing cohesion. To achieve this, MCP adopts a client-server model, where each agent or tool operates as an independent server and communicates through a standard protocol (based on JSON-RPC 2.0).

Key Design Principles

Standardized Interface: All agents must adhere to the MCP standard to expose tools, resources, and prompts.
Asynchronous Communication: For agents with long task execution times (e.g., file processing, web scraping), an asynchronous message queue should be utilized.
Statelessness: Agent servers should be designed to be as stateless as possible to facilitate horizontal scaling.

Architecture Diagram (Conceptual)

[User/Client LLM] <--> [MCP Gateway (Orchestrator)]
 | | |
 v v v
 [Blog Server] [Discord MCP] [Cloud Monitor]
 (Rust/TS) (Gateway) (Agent)

In this structure, the Gateway (Orchestrator) analyzes user requests, delegates tasks to the appropriate MCP servers (agents), and aggregates the results to return them to the user.

2. Implementing MCP Servers: Building Lightweight Agents with Rust

We will implement a simple MCP server in Rust to achieve high performance in environments like blog-api-server or ZeroClaw. This server provides a simple tool that returns the current time.

Dependency Setup (Cargo.toml)

We will use Rust’s powerful asynchronous runtime tokio, serde for JSON processing, and hyper or jsonrpc for MCP communication.

[dependencies]
tokio = { version = "1", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
hyper = { version = "0.14", features = ["server", "http1"] }

MCP Server Code Example

The following is a simplified implementation of a standard MCP server that communicates via STDIN/STDOUT.

use serde::{Deserialize, Serialize};
use serde_json::{Value, json};
use std::io::{self, BufRead, Write};

// MCP Request/Response structure definitions
#[derive(Deserialize)]
struct MCPRequest {
 jsonrpc: String,
 id: Option<String>,
 method: String,
 params: Option<Value>,
}

#[derive(Serialize)]
struct MCPResponse {
 jsonrpc: String,
 id: Option<String>,
 result: Option<Value>,
 error: Option<Value>,
}

fn handle_request(req: MCPRequest) -> MCPResponse {
 match req.method.as_str() {
 "initialize" => {
 // Called when the client wants to check the server's capabilities
 MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: Some(json!({
 "protocolVersion": "2024-11-05",
 "capabilities": {
 "tools": {}
 },
 "serverInfo": {
 "name": "my-rust-agent",
 "version": "0.1.0"
 }
 })),
 error: None,
 }
 }
 "tools/list" => {
 // Returns a list of available tools
 MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: Some(json!({
 "tools": [
 {
 "name": "get_current_time",
 "description": "Returns the current server time",
 "inputSchema": {
 "type": "object",
 "properties": {}
 }
 }
 ]
 })),
 error: None,
 }
 }
 "tools/call" => {
 // Actual tool execution logic
 if let Some(params) = req.params {
 let tool_name = params["name"].as_str().unwrap_or("");
 if tool_name == "get_current_time" {
 return MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: Some(json!({
 "content": [
 {
 "type": "text",
 "text": format!("Current time: {}", chrono::Utc::now().to_rfc3339())
 }
 ]
 })),
 error: None,
 };
 }
 }
 // Error handling
 MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: None,
 error: Some(json!({
 "code": -32601,
 "message": "Tool not found"
 })),
 }
 }
 _ => MCPResponse {
 jsonrpc: "2.0".to_string(),
 id: req.id,
 result: None,
 error: Some(json!({ "code": -32601, "message": "Method not found" })),
 },
 }
}

fn main() {
 let stdin = io::stdin();
 let mut stdout = io::stdout();

 for line in stdin.lock().lines() {
 let line = line.unwrap();
 if let Ok(req) = serde_json::from_str::<MCPRequest>(&line) {
 let res = handle_request(req);
 let res_json = serde_json::to_string(&res).unwrap() + "\n";
 stdout.write_all(res_json.as_bytes()).unwrap();
 stdout.flush().unwrap();
 }
 }
}

This code handles the core MCP methods initialize, tools/list, and tools/call, enabling LLMs (e.g., Claude Code) to recognize and invoke this agent as a tool.

3. Agent Communication and Data Synchronization

In architectures like ZeroClaw, where multiple agents collaborate, data sharing is crucial. A file-based architecture allows agents to exchange data while reducing coupling.

Consider a scenario where Agent A generates data, and Agent B consumes it.

Agent A (Producer): Saves the computation result to /tmp/shared/task_result.json.
Agent B (Consumer): Reads the resource file://tmp/shared/task_result.json via MCP, or calls a separate read_file tool.

// Example of Agent A calling a tool (pseudo-code)
fn save_result(data: &str) -> std::io::Result<()> {
 fs::write("/tmp/shared/task_result.json", data)?;
 Ok(())
}

This approach is useful when message queues are complex and effective for continuously tracking data, such as in the logging system or monitoring dashboard of blog-api-server.

4. Conclusion and Future Directions

Leveraging MCP allows for the modularization and maintainability of complex multi-agent systems.

Advantages: Language-agnostic interface (can mix Rust, TypeScript, etc.), tool reusability, standardized error handling.
Considerations: STDIN/STDOUT communication overhead, load balancing for the Gateway to handle large traffic.

The future goal is to build an environment within the ZeroClaw runtime where these MCP servers are containerized and dynamically scaled as needed. This will enable LLMs to evolve beyond simple chatbots into intelligent agent networks that automate complex tasks.

References

ZeroClaw Multi-Agent System: A Guide to Building a Local Testing Environment with Docker Compose

Fri, 22 May 2026 09:01:21 +0900

ZeroClaw Multi-Agent System: A Guide to Building a Local Testing Environment with Docker Compose

Recently, while designing the high-performance Rust agent runtime and multi-agent architecture for the [ZeroClaw] project, I realized the importance of isolation and communication stability for individual agents. In particular, when developing MCP (Model Context Protocol) clients that interact with external APIs, such as [blog-api-server], it is essential to test them in a local environment that mimics the actual production setup.

In this post, I will share how to build a testing environment using Docker Compose to easily run and debug complex multi-agent systems locally. This guide is based on a Linux environment (e.g., servers transitioning from Ubuntu 16.04 to FreeBSD), but it can be applied to Windows and macOS as well.

1. Architecture Design: Microservices-style Agent Structure

The core of ZeroClaw is a communication platform that adopts a file-based architecture and a gateway pattern. Each agent is treated as an independent microservice and isolated within a Docker container.

Components

Agent Container: Individual agents written in Rust (based on ZeroClaw Runtime)
Gateway Container: Nginx or Envoy for routing external requests to internal agents
Message Broker (Optional): RabbitMQ or Redis (if asynchronous communication is needed)

2. Dockerfile Creation: Optimizing Rust Agents

Since Rust applications have long compile times, Multi-stage builds should be used to reduce the final image size and optimize build caching.

# Dockerfile

# 1. Build Stage
FROM rust:1.75-slim as builder

WORKDIR /app

# Copy Cargo.toml and Cargo.lock first for dependency caching
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs
RUN cargo build --release && rm -rf src

# Copy actual source code and build
COPY src ./src
RUN touch src/main.rs && cargo build --release

# 2. Runtime Stage
FROM debian:bookworm-slim

# Install runtime dependencies (e.g., OpenSSL)
RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy the built binary
COPY --from=builder /app/target/release/zero-claw-agent /app/agent

# Grant execute permissions
RUN chmod +x /app/agent

# Expose port (for MCP communication)
EXPOSE 8080

CMD ["/app/agent"]

3. Orchestration Configuration with Docker Compose

Use the docker-compose.yml file to define multiple agents and networks. This allows the entire system to be launched with a single docker-compose up command.

# docker-compose.yml
version: '3.8'

services:
 # Message Broker (Optional, used depending on the communication protocol)
 redis:
 image: redis:7-alpine
 container_name: zero-claw-redis
 ports:
 - "6379:6379"
 networks:
 - zero-claw-net

 # Agent 1: Blog Handler (acting as blog-api-server)
 blog-agent:
 build:
 context: ./services/blog-agent
 dockerfile: Dockerfile
 container_name: zero-claw-blog-agent
 environment:
 - AGENT_ID=blog-agent-01
 - LOG_LEVEL=debug
 - MCP_SERVER_URL=http://mock-api:3000
 depends_on:
 - redis
 networks:
 - zero-claw-net
 restart: unless-stopped

 # Agent 2: Monitor (Cloud Monitor role)
 monitor-agent:
 build:
 context: ./services/monitor-agent
 dockerfile: Dockerfile
 container_name: zero-claw-monitor-agent
 environment:
 - AGENT_ID=monitor-agent-01
 depends_on:
 - redis
 networks:
 - zero-claw-net
 restart: unless-stopped

 # Gateway (Discord MCP Gateway role)
 gateway:
 image: nginx:alpine
 container_name: zero-claw-gateway
 ports:
 - "8080:80"
 volumes:
 - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
 depends_on:
 - blog-agent
 - monitor-agent
 networks:
 - zero-claw-net

networks:
 zero-claw-net:
 driver: bridge

4. Running and Testing

You can now run the entire system with the following command:

# Build and run in background
docker-compose up --build -d

# Check logs (focused monitoring of a specific agent)
docker-compose logs -f blog-agent

# Traffic test (request via Gateway)
curl -X POST http://localhost:8080/api/v1/agent/blog/ping \
 -H "Content-Type: application/json" \
 -d '{"message": "Hello from ZeroClaw"}'

5. Conclusion

Leveraging this structure makes tasks like modifying [ZeroClaw]’s multi-agent communication protocol or injecting [LLM] configurations per agent much easier to test. In particular, by simply modifying environment variables in docker-compose.yml, you can maintain a nearly identical setup for production deployment scripts and local testing environments, thus resolving the “It works on my machine” problem.

In the next post, we will cover how to visualize the logs collected in this environment using [Loki] or [Prometheus].

Deep Dive into ZeroClaw Architecture: Implementing Secure Inter-Agent Communication with Rust

Mon, 11 May 2026 09:01:26 +0900

Hello everyone! As the ZeroClaw project progresses, I want to share the design considerations and solutions encountered while building a high-performance Rust agent runtime and a multi-agent system. Recent security incidents, such as the ‘Remote Access Trojan (RAT) exploiting Obsidian plugins’, serve as a stark reminder of how crucial Security and Trust are in plugin and agent systems.

Today, I’ll introduce the secure and scalable inter-agent communication protocol designed by analyzing ZeroClaw’s codebase, along with concrete Rust code examples.

1. Introduction: The Need for Security-Conscious Agent Communication

During the development of previous MCP (Model Context Protocol) and blog automation systems, we realized that beyond simple data transfer, Authentication and Authorization between agents are essential. In a multi-agent environment where multiple agents collaborate to generate files or call external APIs, a mechanism to prevent malicious command injection is indispensable.

To address this, ZeroClaw adopts an architecture that leverages Rust’s Type Safety and Ownership system to catch many bugs at compile time and minimize runtime overhead.

2. Communication Protocol Design: IPC and Message Queues

ZeroClaw’s communication platform is broadly divided into Local IPC (Inter-Process Communication) and an Asynchronous Message Queue. Based on our experience improving the logging system, all communication is handled asynchronously (async), ensuring the independence of each agent.

Key Design Principles

Zero-Copy Serialization: Minimizes data serialization overhead using serde and bincode.
Message Validation: A layer validates all incoming messages to prevent tampered data from reaching the system core.
Capability-Based Security: Goes beyond simple token-based authentication by restricting the capabilities (actions) an agent can perform.

3. Implementing Secure Messaging Handlers with Rust

Let’s explore how this is implemented through actual code. This example is based on tokio and demonstrates the basic structure for secure message delivery.

3.1 Message Definition and Validation

First, we define the data structures for inter-agent communication and use the validator crate for input validation.

// message.rs
use serde::{Deserialize, Serialize};
use validator::Validate;

/// Agent communication message type
#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum AgentMessage {
 TaskRequest { id: String, payload: TaskPayload },
 TaskResponse { id: String, result: String },
 Heartbeat,
}

/// Task payload (includes validation logic)
#[derive(Debug, Clone, Serialize, Deserialize, Validate)]
pub struct TaskPayload {
 #[validate(length(min = 1, max = 100))]
 pub command: String,
 
 // Accepts JSON-formatted arguments but must be parsed structurally safely
 pub args: serde_json::Value, 
}

impl AgentMessage {
 /// Safely deserializes a message from a byte array.
 pub fn from_bytes(bytes: &[u8]) -> Result<Self, Box<dyn std::error::Error>> {
 // 1. Basic serialization validation
 let msg: AgentMessage = bincode::deserialize(bytes)?;
 
 // 2. Business logic validation (e.g., prevent Command Injection)
 if let AgentMessage::TaskRequest { payload, .. } = &msg {
 payload.validate()?; // Using the validator crate
 
 // Security: Example of filtering disallowed shell commands
 if payload.command.contains("rm ") || payload.command.contains("sudo") {
 return Err("Blocked potentially dangerous command".into());
 }
 }
 
 Ok(msg)
 }
}

3.2 Actor Model-Based Agent Structure

Each agent follows an Actor pattern, maintaining its own state and processing messages. Rust’s tokio::sync::mpsc channel is used to implement the mailbox.

// agent.rs
use tokio::sync::mpsc;
use super::message::AgentMessage;

pub struct Agent {
 id: String,
 receiver: mpsc::Receiver<AgentMessage>,
 // The agent's state is encapsulated here and not directly accessible from outside
}

impl Agent {
 pub fn new(id: String, receiver: mpsc::Receiver<AgentMessage>) -> Self {
 Self { id, receiver }
 }

 /// The agent's main loop
 pub async fn run(mut self) {
 println!("[{}] Agent started", self.id);
 
 while let Some(msg) = self.receiver.recv().await {
 if let Err(e) = self.handle_message(msg).await {
 eprintln!("[{}] Error handling message: {:?}", self.id, e);
 }
 }
 }

 async fn handle_message(&self, msg: AgentMessage) -> Result<(), Box<dyn std::error::Error>> {
 match msg {
 AgentMessage::TaskRequest { id, payload } => {
 println!("[{}] Executing task {}: {}", self.id, id, payload.command);
 // Actual task execution logic goes here (e.g., LLM calls, file writes, etc.)
 // Safeguards: Execute in a sandboxed environment or restrict permissions.
 },
 AgentMessage::Heartbeat => {
 // Handle heartbeat signal
 },
 _ => return Err("Unknown message type".into()),
 }
 Ok(())
 }
}

3.3 Runtime and Message Routing

Finally, here’s a simple runtime system for creating multiple agents and routing messages.

// runtime.rs
use tokio::sync::mpsc;
use std::collections::HashMap;
use super::agent::Agent;
use super::message::AgentMessage;

pub struct Runtime {
 agents: HashMap<String, mpsc::Sender<AgentMessage>>,
}

impl Runtime {
 pub fn new() -> Self {
 Self { agents: HashMap::new() }
 }

 pub fn spawn_agent(&mut self, id: &str) {
 let (tx, rx) = mpsc::channel(32);
 let agent = Agent::new(id.to_string(), rx);
 
 // Run the agent in a separate task
 tokio::spawn(agent.run());
 
 self.agents.insert(id.to_string(), tx);
 println!("Runtime: Agent '{}' spawned", id);
 }

 pub async fn broadcast(&self, msg: AgentMessage) {
 for (id, tx) in self.agents.iter() {
 if let Err(e) = tx.send(msg.clone()).await {
 eprintln!("Failed to send to {}: {:?}", id, e);
 }
 }
 }
}

4. Conclusion and Next Steps

The code implemented above demonstrates the core of the ZeroClaw multi-agent system: secure communication and isolated state management. Systems that execute external inputs or scripts, like the Obsidian plugin incident, are always potential targets for attacks.

ZeroClaw uses Rust’s powerful type system to block most of these risks at compile time and defends against them at runtime with additional validation layers. In the next post, we will discuss how this agent system actually integrates with external gateways like Discord or MCP, and how it is controlled through LLM configurations.

So far, I’ve shared the current status of ZeroClaw’s architectural design. I hope this is helpful for those looking to build high-performance yet secure agent systems!

Note: The code above is a Proof of Concept (POC) level example. For actual production environments, more robust error handling and logging systems (referencing the logging setup improved in the previous post) must be integrated.

Memory Safety and Efficient Resource Management of the ZeroClaw Agent Runtime

Sat, 09 May 2026 09:01:27 +0900

Memory Safety and Efficient Resource Management of the ZeroClaw Agent Runtime

As we’ve been building a high-performance multi-agent runtime through the ZeroClaw project, we’ve been contemplating how to leverage Rust’s distinctive features—‘memory safety’ and ‘zero-cost abstractions’—in practice. Beyond simply being safe, the core challenge was how to efficiently manage system resources and maintain stable performance without Garbage Collection (GC) in a scenario where numerous agents simultaneously exchange messages.

This post aims to share the efficient resource management strategies based on Rust and practical code examples that were applied during the ZeroClaw architecture design process.

Problem Definition: Resource Bottlenecks in Multi-Agent Environments

In multi-agent systems, each agent possesses its own independent state and communicates through asynchronous messages. This process gives rise to the following resource issues:

Frequent Allocation/Deallocation (Allocation Thrashing): When hundreds of agents process thousands of messages per second, frequent allocation and deallocation of heap memory become a primary cause of performance degradation.
Data Race: We must prevent race conditions that can occur when multiple agents access shared resources, while also avoiding bottlenecks caused by excessive lock usage.
Lifecycle Management: A mechanism is needed to safely reclaim resources, ensuring that memory leaks do not occur throughout the system even if an agent terminates abnormally.

Solution Strategy: Rust’s Ownership and Tokio’s Scheduling

To address these issues, ZeroClaw has combined Rust’s Ownership system with the asynchronous abstractions of the tokio runtime.

1. State Sharing using `Arc` and `RwLock`

For immutable data sharing in inter-agent communication, we’ve minimized costs using Arc (Atomic Reference Counting). For state updates, we’ve employed RwLock to allow concurrent read operations while ensuring data integrity only during write operations.

2. Message Passing via Channels

Instead of directly managing shared memory state, we adopted a message-passing approach (Actor model) using tokio::sync::mpsc channels. This fundamentally prevents data races by allowing each agent to exclusively manage its own state.

Practical Code Examples

Below is an example implementation of a simple agent message handler used in ZeroClaw’s communication layer.

Agent Message Definition and Handler Structure

use tokio::sync::{mpsc, RwLock};
use std::sync::Arc;
use std::time::Duration;

// Define the command types agents will process
#[derive(Debug)]
enum AgentCommand {
 ProcessTask(String),
 UpdateStatus(String),
 Shutdown,
}

// Agent's state structure
struct AgentState {
 id: String,
 status: String,
 processed_tasks: u64,
}

// Agent executor structure
struct AgentExecutor {
 state: Arc<RwLock<AgentState>>,
 receiver: mpsc::Receiver<AgentCommand>,
}

impl AgentExecutor {
 // Constructor for creating a new agent
 fn new(id: String, receiver: mpsc::Receiver<AgentCommand>) -> Self {
 Self {
 state: Arc::new(RwLock::new(AgentState {
 id,
 status: "Initialized".to_string(),
 processed_tasks: 0,
 })),
 receiver,
 }
 }

 // Start the message reception and processing loop
 async fn run(mut self) {
 println!("Agent {} started.", self.state.read().await.id);
 
 while let Some(cmd) = self.receiver.recv().await {
 match cmd {
 AgentCommand::ProcessTask(task_id) => {
 // Simulate asynchronous work (e.g., LLM inference request)
 let task_id_clone = task_id.clone();
 let state_clone = Arc::clone(&self.state);
 
 // Process as a background task to avoid blocking the message loop
 tokio::spawn(async move {
 tokio::time::sleep(Duration::from_millis(100)).await;
 let mut state = state_clone.write().await;
 state.processed_tasks += 1;
 state.status = format!("Processing {}", task_id_clone);
 println!("Task {} processed by Agent {}. Total: {}", 
 task_id_clone, state.id, state.processed_tasks);
 });
 }
 AgentCommand::UpdateStatus(new_status) => {
 let mut state = self.state.write().await;
 state.status = new_status;
 }
 AgentCommand::Shutdown => {
 println!("Agent {} shutting down...", self.state.read().await.id);
 break;
 }
 }
 }
 }
}

Main Runtime Configuration and Resource Management

Now, let’s write the main runtime code that creates and manages the agents above. Here, we implement graceful shutdown using the tokio::select! macro to prevent resource leaks.

#[tokio::main]
async fn main() {
 // Store a list of senders for managing multiple agents
 // Managed as a Vec to handle agent termination
 let mut agent_senders = Vec::new();

 // Spawn 3 agents
 for i in 0..3 {
 let (tx, rx) = mpsc::channel(100); // Buffer size 100
 agent_senders.push(tx);
 
 let executor = AgentExecutor::new(format!("Agent-{}", i), rx);
 tokio::spawn(executor.run());
 }

 // System-wide shutdown signal (handling Ctrl+C, etc.)
 let (shutdown_tx, mut shutdown_rx) = mpsc::channel::<()>(1);
 
 // Task distribution logic (simulation)
 let task_distributor = tokio::spawn(async move {
 let mut task_counter = 0;
 loop {
 // Check for shutdown signal
 if shutdown_rx.try_recv().is_ok() {
 println!("Task distributor stopping...");
 break;
 }

 // Send tasks to agents in a round-robin fashion
 if !agent_senders.is_empty() {
 let target_index = task_counter % agent_senders.len();
 let task_id = format!("Task-{}", task_counter);
 
 if let Err(_) = agent_senders[target_index].send(AgentCommand::ProcessTask(task_id)).await {
 println!("Failed to send task. Agent might be dead.");
 }
 
 task_counter += 1;
 tokio::time::sleep(Duration::from_millis(50)).await;
 }
 }
 });

 // Simulate system shutdown after 5 seconds
 tokio::time::sleep(Duration::from_secs(5)).await;
 
 // 1. Terminate task distribution
 let _ = shutdown_tx.send(()).await;
 task_distributor.await.unwrap();

 // 2. Send shutdown command to all agents
 for tx in agent_senders {
 let _ = tx.send(AgentCommand::Shutdown).await;
 }

 // Wait for resource cleanup
 tokio::time::sleep(Duration::from_millis(500)).await;
 println!("System shutdown complete.");
}

Key Point Analysis

Arc<RwLock<State>> Pattern: The AgentExecutor stores its state wrapped in Arc<RwLock>. Asynchronous tasks created with tokio::spawn receive a clone of this Arc. This is very lightweight as it only increments the reference count, not by copying the data itself.
Ownership Transfer in MPSC Channels: The tx (Sender) end is owned by the main loop, and the rx (Receiver) end is owned by the AgentExecutor. This clear separation of ownership ensures at compile time who sends and who receives messages.
Harmony of Asynchronous I/O and Locks: When using state.write().await, the current task is suspended (yielded) until it acquires the lock for writing. This differs from blocking an OS thread and allows other tasks to utilize the CPU, thereby increasing multi-core utilization.

Conclusion

Rust’s memory management mechanisms are not just about safety; they become a powerful tool for designing high-performance server architectures. In the ZeroClaw project, this allowed us to minimize inter-agent communication overhead and achieve predictable latency. In particular, the channel-based architecture combined with the tokio runtime provides a foundation for maintaining stability even in complex systems where thousands of agents interact.

In the next post, we will expand on inter-agent communication to discuss an architecture for implementing file-based persistence.

Reference Links

[ZeroClaw] Multi-Agent Architecture Design

Fri, 27 Feb 2026 22:58:08 +0900

ZeroClaw Multi-Agent Architecture Design

Overview

ZeroClaw’s multi-agent architecture implements an advanced collaboration system evolving from a single-agent model.

Current Status

Phase 1: In-Process Delegation (Complete)
Phase 2: File-Based Multi-Agent Architecture (In Development)

1. Design Philosophy

Principle	Application
KISS	Simple communication protocol
YAGNI	Implement only essential features
SRP	Single responsibility agents
Secure	Least privilege principle

2. Architecture Structure

Application Layer: Research │ Code │ Test Agent
Message Bus Layer: NATS/Redis Pub/Sub
Transport Layer: gRPC │ WebSocket │ Unix Socket

3. Agent Definition

agent:
 id: "researcher"
 name: "Research Agent"

execution:
 mode: subprocess

provider:
 name: "openrouter"
 model: "claude-sonnet-4-6"

4. CLI Commands

zeroclaw agent list
zeroclaw agent show <id>
zeroclaw agent run --agent-id researcher

5. Security

Mode	Isolation	Use Case
Subprocess	Process	Trusted agents
Docker	Container	File operations
Wasm	Memory	High security

Korean Version: 한국어 버전

[Multi-Agent] File-Based Architecture Design

Fri, 27 Feb 2026 09:30:57 +0900

File-Based Multi-Agent Architecture Design

Status: Design Proposal
Author: multi-agent-architect
Date: 2026-02-24
Type: Alternative Architecture (Process-Per-Agent)

Executive Summary

This document defines a file-based, process-per-agent architecture where each agent is defined as a separate configuration file and runs as an independent process. Agents are invoked on-demand and report results back to a main coordinator agent.

Core Principles

File-Based Agent Definition: Each agent is a .toml file in agents/
Process Isolation: Each agent runs in its own process
On-Demand Invocation: Main agent spawns subprocess agents as needed
Reporting Protocol: Structured result reporting via IPC
Zero-Config Discovery: Auto-discovery of agent definitions

1. Agent Definition File Structure

1.1 Directory Layout

~/.zeroclaw/
├── config.toml # Main configuration
├── agents/ # Agent definitions directory
│ ├── researcher.toml # Research agent
│ ├── coder.toml # Code generation agent
│ ├── tester.toml # Testing agent
│ ├── reviewer.toml # Code review agent
│ └── summarizer.toml # Summarization agent
├── agents.d/ # Optional: additional agent dirs
│ └── custom/
│ └── my_agent.toml
└── workspace/ # Shared workspace

1.2 Agent File Schema

# agents/researcher.toml

# Agent metadata
[agent]
id = "researcher"
name = "Research Agent"
version = "1.0.0"
description = "Conducts research on given topics using web search and knowledge bases"

# Execution configuration
[agent.execution]
# How to run this agent: "subprocess" | "wasm" | "docker"
mode = "subprocess"

# Command to spawn (template variables: {agent_id}, {workspace}, {config_dir})
command = "zeroclaw"
args = [
 "agent",
 "run",
 "--agent-id", "{agent_id}",
 "--config", "{config}/agents/researcher.toml",
 "--workspace", "{workspace}"
]

# Working directory for the subprocess
working_dir = "{workspace}"

# Environment variables for the subprocess
[agent.execution.env]
ZEROCLAW_AGENT_MODE = "worker"
ZEROCLAW_AGENT_ID = "researcher"

# Provider configuration (overrides main config)
[provider]
name = "openrouter"
model = "anthropic/claude-sonnet-4-6"
api_key = null # Inherit from main, or set agent-specific key
temperature = 0.3
max_tokens = 4096

# Tools available to this agent
[[tools]]
name = "web_search"
enabled = true

[[tools]]
name = "web_fetch"
enabled = true

# Tools explicitly denied to this agent
[[tools.deny]]
name = "shell"
reason = "Research agent should not execute shell commands"

# System prompt
[system]
prompt = """
You are a Research Agent. Your role is to:
1. Search for and gather information from credible sources
2. Synthesize findings into structured reports
3. Cite sources and provide references
4. Avoid speculation - stick to verified information
"""

# Memory configuration
[memory]
backend = "shared" # "shared" | "isolated"
category = "research"

# Reporting configuration
[reporting]
mode = "ipc"
format = "json" # "json" | "markdown" | "both"
timeout_seconds = 300

# Retry configuration
[retry]
max_attempts = 3
backoff_ms = 1000

2. Agent Registry

The AgentRegistry discovers and manages agent definitions:

pub struct AgentRegistry {
 agents_dir: PathBuf,
 agents: HashMap<String, AgentDefinition>,
 security: Arc<SecurityPolicy>,
}

impl AgentRegistry {
 pub fn new(agents_dir: PathBuf, security: Arc<SecurityPolicy>) -> Result<Self>;
 pub fn discover(&mut self) -> Result<()>;
 pub fn get(&self, id: &str) -> Option<&AgentDefinition>;
 pub fn list(&self) -> Vec<String>;
}

3. Inter-Process Communication (IPC)

Task Message (Main → Agent)

pub struct AgentTask {
 pub task_id: String,
 pub from_agent: String,
 pub to_agent: String,
 pub prompt: String,
 pub context: HashMap<String, serde_json::Value>,
 pub input: Option<serde_json::Value>,
 pub timestamp: chrono::DateTime<chrono::Utc>,
 pub deadline: Option<chrono::DateTime<chrono::Utc>>,
}

Result Message (Agent → Main)

pub struct AgentResult {
 pub task_id: String,
 pub agent_id: String,
 pub status: AgentStatus,
 pub data: Option<serde_json::Value>,
 pub output: String,
 pub error: Option<String>,
 pub metrics: AgentMetrics,
 pub artifacts: Vec<Artifact>,
 pub timestamp: chrono::DateTime<chrono::Utc>,
}

4. Security Considerations

Execution Mode	Isolation	Use Case
Subprocess	Process-level	Trusted agents
Docker	Container	Untrusted, file operations
Wasm	Memory-only	High security needs

5. CLI Commands

# List available agents
zeroclaw agent list

# Show agent details
zeroclaw agent show <agent_id>

# Run an agent directly (for testing)
zeroclaw agent run --agent-id researcher --prompt "Research X"

# Create a new agent from template
zeroclaw agent create --id my-agent --name "My Agent"

# Validate agent definition
zeroclaw agent validate <agent_id>

6. Success Criteria

Agent definition files validated on load
Subprocess agents spawn and complete tasks
IPC protocol supports tasks >1GB data
Main agent can invoke worker agents via tool
Failed agents don’t crash main agent
Security policy enforced per-agent
CLI commands for agent management

Korean Version: 한국어 버전

[ZeroClaw] Multi-Agent Protocol Design

Thu, 26 Feb 2026 23:37:59 +0900

ZeroClaw Multi-Agent Communication Protocol Design

Written on February 26, 2026

Overview

This is a communication protocol design for ZeroClaw’s multi-agent system.

1. Design Goals

Standardized Message Format - Consistent envelope-based messaging
Flexible Routing - Direct, broadcast, Pub/Sub patterns
Sync + Async - Support for blocking and non-blocking communication
Event-driven Coordination - React to system events
State Sharing - Safe shared memory and distributed state

2. Message Types (12)

Task, TaskResult, Query, QueryResponse, Stream, Event, Heartbeat, Ack, Error, Control, Sync, SyncResponse

3. Communication Patterns

Direct (1:1)
Broadcast (1:N)
Request-Response
Pub/Sub
Streaming

4. Implementation Roadmap

Phase	Content
1	Core messaging layer
2	State store
3	DelegateTool integration
4	Pub/Sub and streaming
5	Distributed environment support

This document was written through collaboration of the ZeroClaw development team.

Korean Version: 한국어 버전

[ZeroClaw] Codebase Architecture Analysis

Thu, 26 Feb 2026 10:07:29 +0900

ZeroClaw Codebase Architecture Analysis Report

Written on February 26, 2026

Overview

ZeroClaw is a high-performance autonomous agent runtime written in Rust. This report summarizes the analysis of the codebase structure and security architecture.

1. Core Architecture Patterns

ZeroClaw adopts trait-driven extensibility as its core design principle.

1.1 Major Traits (7)

Trait	Location	Role
`Provider`	src/providers/traits.rs	AI model provider interface
`Channel`	src/channels/traits.rs	Communication channel interface
`Tool`	src/tools/traits.rs	Tool execution interface
`Memory`	src/memory/traits.rs	Memory backend interface
`Observer`	src/observability/traits.rs	Observability interface
`RuntimeAdapter`	src/runtime/traits.rs	Runtime adapter interface
`Peripheral`	src/peripherals/traits.rs	Hardware peripheral interface

2. Security Architecture

ZeroClaw implements security through a Defense-in-Depth strategy.

2.1 Security Layers (6)

SecurityPolicy Core - Autonomy level management
Gateway Security - Bearer token authentication
Tool Validation - Injection prevention
Runtime Sandbox - Landlock/Firejail/Docker
Secret Management - ChaCha20-Poly1305
Audit Logging - Event tracking

2.2 Core Security Boundaries

Command allowlist: 15 items
Rate limiting: 20 requests/hour
Environment variables: only 8 allowed

3. Multi-Agent System

Implementation Roadmap

Phase	Duration	Content
1	1 week	Core traits, DelegateTool extension
2	2-3 weeks	Docker/Wasm execution modes
3	4+ weeks	Distributed message bus, consensus algorithm

Conclusion

ZeroClaw has an excellent architecture in terms of extensibility, security, performance, and maintainability.

This report was written based on collaborative analysis by the ZeroClaw development team.

Korean Version: 한국어 버전

[Multi-Agent] Communication Platform Design

Sat, 21 Feb 2026 21:00:00 +0900

Introduction

As AI agent systems evolve, the transition from single-agent to multi-agent systems is accelerating. This article explores how to design a platform architecture for efficient communication between multiple agents.

1. Architecture Overview

A multi-agent platform consists primarily of an Orchestrator, Message Bus, and various specialized agents.

Multi-Agent Architecture

Core Components

Component	Role
Orchestrator	Task coordination, agent scheduling
Message Bus	Inter-agent communication relay
State Store	Shared state management
Task Queue	Priority-based work queue
Agents	Specialized task execution

2. Communication Protocol Design

Inter-agent communication is designed based on asynchronous message passing.

Message Protocol

Communication Flow

Publish: Agent publishes task request to message bus
Route: Bus routes message to appropriate agent
Accept: Target agent accepts task
Acknowledge: Bus sends acceptance confirmation to requester
Execute: Agent performs actual work
Result: Result is published to bus
Deliver: Bus delivers result to requester

3. Message Structure

Design scalable and type-safe message structures.

Message Structure

Message Envelope

{
 "header": {
 "message_id": "uuid-v4",
 "timestamp": "2026-02-21T12:00:00Z",
 "source_agent": "agent-research-01",
 "target_agent": "agent-writer-01",
 "message_type": "TASK_REQUEST"
 },
 "metadata": {
 "priority": "normal",
 "ttl": 3600,
 "correlation_id": "parent-uuid"
 },
 "payload": {
 "content_type": "json",
 "encoding": "utf-8",
 "data": {
 "task": "summarize",
 "content": "..."
 }
 }
}

Message Types

Type	Purpose
`TASK_REQUEST`	Task request
`TASK_RESULT`	Task result
`STATUS_UPDATE`	Status change notification
`HEARTBEAT`	Liveness check
`QUERY`	Information lookup
`RESPONSE`	Query response

4. Agent State Management

Each agent has a clear state machine.

State Management

State Transitions

IDLE → RECEIVING → PROCESSING → EXECUTING → COMPLETED → IDLE
 ↘ ↘ ↘
 ERROR ──────→ retry ──→ IDLE

State Behaviors

State	Behavior
IDLE	Waiting for new task
RECEIVING	Message reception and validation
PROCESSING	Task analysis and preparation
EXECUTING	Actual work execution
COMPLETED	Result transmission and cleanup
ERROR	Error handling and retry

5. Communication Patterns

5.1 Request-Response

Synchronous 1:1 communication pattern.

# Request
response = await bus.request(
 target="agent-code-01",
 message=TaskRequest(task="generate_code", spec={...}),
 timeout=30
)

# Response
return TaskResult(status="success", data=generated_code)

Asynchronous 1:N communication pattern.

# Subscribe
@bus.subscribe("research.completed")
async def handle_research_result(message):
 # Handle research result
 pass

# Publish
await bus.publish(
 topic="research.completed",
 message=ResearchResult(data={...})
)

5.3 Broadcast

Used to send notifications to all agents.

# Broadcast
await bus.broadcast(
 message=SystemAlert(
 level="warning",
 message="High load detected"
 )
)

6. Core Design Principles

6.1 Loose Coupling

Agents should not know each other’s internal implementations. They communicate only through message interfaces.

6.2 Fault Tolerance

class Agent:
 async def execute_with_retry(self, task, max_retries=3):
 for attempt in range(max_retries):
 try:
 return await self.execute(task)
 except Exception as e:
 if attempt == max_retries - 1:
 await self.transition_to(State.ERROR)
 raise
 await asyncio.sleep(2 ** attempt) # Exponential backoff

6.3 Scalability

Horizontal scaling: Add agents with the same role
Load balancing: Automatic distribution by message bus
Sharding: Separate agent groups by task type

6.4 Observability

# Metrics collection
@metrics.track
async def process_message(self, message):
 with metrics.timer("process_duration"):
 result = await self.handle(message)
 metrics.increment("messages_processed")
 return result

7. Implementation Considerations

7.1 Message Serialization

Format	Pros	Cons
JSON	Readability, compatibility	Size, performance
Protocol Buffers	Performance, schema	Complexity
MessagePack	JSON compatible, size	Tool support

7.2 Backpressure

class Agent:
 def __init__(self, max_concurrent=10):
 self.semaphore = asyncio.Semaphore(max_concurrent)

 async def process(self, message):
 async with self.semaphore:
 return await self.handle(message)

7.3 Dead Letter Queue

Failed messages are moved to a separate queue for analysis and reprocessing.

8. Conclusion

Key elements of a multi-agent communication platform include:

Flexible message structure: Support for various communication scenarios
Clear state management: Predictable agent behavior
Diverse communication patterns: Request-response, publish-subscribe, broadcast
Fault-tolerant design: Retry, timeout, error handling

Based on these principles, scalable and reliable multi-agent systems can be built.

References

Korean Version: 한국어 버전

Multi-Agent on Yarang's Tech Lair

ZeroClaw and Ornith-1.0: A Comparative Analysis of Next-Generation Open-Source Agent Architectures

ZeroClaw and Ornith-1.0: A Comparative Analysis of Next-Generation Open-Source Agent Architectures

1. Ornith-1.0: The Approach to Self-Improvement

2. Synergy with ZeroClaw Architecture

3. Concrete Implementation: Feedback Loop Simulation

4. Considerations for Integration with [Discord MCP] and [Cloud Monitor]

5. Conclusion: Towards the Development Direction of H1 2026

References

ZeroClaw Agent Runtime: Implementing a TCP/IP Architecture for High-Performance Multi-Agent Communication

Challenges with Existing Communication and ZeroClaw’s Approach

Asynchronous Server Structure Using Rust Tokio

1. Defining Basic Message Structures

2. Implementing Asynchronous TCP Handlers

Team Agent Communication and Protocol Design

Conclusion: Towards Scalable Agent Systems

Reference Code and Resources

Building a High-Performance Agent Runtime with Rust: An In-depth Analysis of the ZeroClaw Architecture

Building a High-Performance Agent Runtime with Rust: An In-depth Analysis of the ZeroClaw Architecture

1. Why Rust? (Safe Concurrency)

2. Communication Protocol Design: File-Based vs. Memory-Based

2.1. Implementing the Request-Response Pattern

3. Integration with MCP: The Bridge Pattern

4. Roadmap for H1 2026: Directions for Advancement

Conclusion

Designing and Implementing a Communication Protocol for MCP-based Multi-Agent Systems in Rust

1. Problem Definition: Why a Communication Protocol?

2. Protocol Design: Request, Task, Completion

3. Implementing the ZeroClaw Communication Layer in Rust

3.1. Message Definition (Based on JSON-RPC)

3.2. Agent Runtime Structure

4. Conclusion and Next Steps

References

[ZeroClaw] Rust Channel-Based IPC Design for Asynchronous Agent Runtime

[ZeroClaw] Rust Channel-Based IPC Design for Asynchronous Agent Runtime

1. Problems with the Existing Architecture and the Need for Asynchronous Design

2. Event Loop Structure Using Rust’s tokio::sync::mpsc

Core Design Points

3. Practical Code: A Concrete Implementation Example

Step 1: Define the Message Protocol

Step 2: Implement Agent Struct and Runner

Step 3: Main Runtime and Channel Connection

4. ZeroClaw Project Application Effects

Conclusion

Building a Lightweight MCP Server with Rust and ZeroClaw: An Efficient Agent Communication Structure

Building a Lightweight MCP Server with Rust and ZeroClaw: An Efficient Agent Communication Structure

1. Combining ZeroClaw Architecture and MCP

2. Core Structure: Asynchronous Request Routing

2.1. Cargo.toml Configuration

2.2. Defining MCP Message Structure

3. Implementing a Lightweight Request Handler

4. Advanced Optimization: ZeroClaw Integration

5. Conclusion

High-Performance IPC Channel Optimization for ZeroClaw Agents: Rust Zero-Copy Strategy

Bottlenecks in Multi-Agent Systems

Problem Diagnosis: Serialization and Copy Overhead

Solution: Rust-based Zero-Copy IPC Design

1. Buffer Management using Bytes and Arc

2. Shared Memory IPC (IPC Channel) Implementation

Performance Comparison and Measurement

Conclusion: Completing ZeroClaw’s High-Performance Architecture

Building ZeroClaw with Rust: An LLM-Based Multi-Agent Runtime Architecture

1. Why Rust? (Performance & Safety)

2. ZeroClaw’s Core Architecture

2.1. File-Based State Management

2.2. Event-Driven Communication

3. Integration with MCP (Model Context Protocol)

4. Conclusion: Development Directions for H1 2026

Reference Links

MCP (Model Context Protocol) Based Multi-Agent System Design and Implementation Guide

MCP (Model Context Protocol) Based Multi-Agent System Design and Implementation Guide

1. MCP-Based Multi-Agent Architecture Design

Key Design Principles

Architecture Diagram (Conceptual)

2. Implementing MCP Servers: Building Lightweight Agents with Rust

Dependency Setup (Cargo.toml)

MCP Server Code Example

3. Agent Communication and Data Synchronization

File-Based State Sharing Example

4. Conclusion and Future Directions

2. Event Loop Structure Using Rust’s `tokio::sync::mpsc`

1. Buffer Management using `Bytes` and `Arc`

1. State Sharing using `Arc` and `RwLock`