LLM 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

MCP Integration Guide: Integrating Discord MCP with ZeroClaw Runtime

Sun, 28 Jun 2026 09:00:35 +0900

With the recent release of ZeroClaw, a high-performance Rust agent runtime, we’ve been deeply contemplating ways to maximize the efficiency of multi-agent systems. In particular, the complexity of communication protocols encountered during the design of the [Discord Decision MCP] architecture was a decisive factor in adopting MCP (Model Context Protocol) as a standard interface.

In this post, we will explain how to actually integrate Discord MCP within the ZeroClaw environment, detailing the process of agents receiving and processing Discord messages with concrete code examples.

1. Architecture Design: Dual Communication on a Single Channel

In the previous [Discord MCP] Gateway architecture, the gateway played the role of filtering events and delivering them to agents. However, by directly implementing the MCP client within ZeroClaw, we’ve altered the design to eliminate the intermediate layer and reduce latency.

The core idea is a flow where the MCP Client transmits Discord events to the ZeroClaw process via stdio, and then sends the agent’s responses back to Discord.

2. Essential Dependencies and Setup (Rust)

As ZeroClaw is written in Rust, it utilizes the asynchronous runtime tokio for high concurrency processing and serde for JSON handling. Communication with the MCP server is assumed to involve exchanging JSON-RPC messages via standard input/output (stdio).

# Cargo.toml
[dependencies]
tokio = { version = "1", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
async-trait = "0.1"

3. MCP Client Implementation

We define a simple client structure to control the Discord MCP server within ZeroClaw. This client uses the tools/call method, which adheres to the MCP standard, to execute Discord bot functionalities.

use serde::{Deserialize, Serialize};
use std::process::{Command, Stdio};
use std::io::{BufReader, BufWriter, Write};

#[derive(Debug, Serialize, Deserialize)]
struct MCPRequest {
 jsonrpc: String,
 id: u64,
 method: String,
 params: serde_json::Value,
}

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

pub struct DiscordMCPClient {
 id: u64,
}

impl DiscordMCPClient {
 pub fn new() -> Self {
 Self { id: 0 }
 }

 /// Executes an MCP tool to send a message to a Discord channel
 pub async fn send_message(&mut self, channel_id: &str, content: &str) -> Result<(), Box<dyn std::error::Error>> {
 self.id += 1;
 
 // Execute MCP server process (e.g., Python-based Discord MCP server)
 let mut child = Command::new("python3")
 .arg("discord_mcp_server.py")
 .stdin(Stdio::piped())
 .stdout(Stdio::piped())
 .spawn()?;

 let stdin = child.stdin.as_mut().ok("Failed to open stdin")?;
 let mut stdout = BufReader::new(child.stdout.as_mut().ok("Failed to open stdout")?);

 let request = MCPRequest {
 jsonrpc: "2.0".to_string(),
 id: self.id,
 method: "tools/call".to_string(),
 params: serde_json::json!({
 "name": "send_message",
 "arguments": {
 "channel_id": channel_id,
 "content": content
 }
 }),
 };

 // Send request
 let request_json = serde_json::to_string(&request)?;
 writeln!(stdin, "{}", request_json)?;

 // (In a real implementation, logic to parse the response from an asynchronous reader is needed)
 // Omitted here for simplicity.
 
 Ok(())
 }
}

4. Integration with ZeroClaw Agents

Now, let’s use the DiscordMCPClient created above within ZeroClaw’s agent loop. This scenario demonstrates an agent notifying Discord upon completing a specific task.

struct ZeroClawAgent {
 discord_client: DiscordMCPClient,
}

impl ZeroClawAgent {
 async fn run_task(&mut self, task: &str) {
 println!("[Agent] Starting task: {}", task);
 
 // Complex reasoning or file processing logic (omitted)
 // ...

 let result = format!("Task '{}' completed.", task);

 // Send result to Discord
 match self.discord_client.send_message("123456789", &result).await {
 Ok(_) => println!("[Agent] Successfully sent Discord notification"),
 Err(e) => eprintln!("[Agent] Sending failed: {}", e),
 }
 }
}

#[tokio::main]
async fn main() {
 let mut agent = ZeroClawAgent {
 discord_client: DiscordMCPClient::new(),
 };

 agent.run_task("Analyze server logs").await;
}

5. Efficiency and Security Considerations (Architecture Insights)

Resource Management: Similar to the trending ‘Adrafinil’ on [Hacker News], applying speculative decoding by disconnecting the Discord MCP connection when the agent is idle and only establishing it when a task is active can save resources.
Security: As highlighted in issues related to [Anonymous GitHub accounts], parameters passed to the MCP server (e.g., API tokens) should be managed via environment variables or fetched from a separate secure storage (Vault). Hardcoding secrets in code is critical.
Error Handling: As discussed in communication platform design considerations, it’s important to include retry logic in the MCP client, taking into account Discord API’s Rate Limits.

Conclusion

Integrating ZeroClaw and Discord MCP goes beyond simply creating a bot; it’s a process of building a standardized interface for agents to interact with the external world. Leveraging our experience in building [MCP] blog automation systems, we plan to further develop more sophisticated multi-agent collaboration systems.

RubyLLM: A Guide to an Integrated AI Interface for Rails

Thu, 25 Jun 2026 09:01:07 +0900

RubyLLM: A Guide to an Integrated AI Interface for Rails

Recently, integrating AI capabilities into applications has become a necessity, not an option. However, calling APIs from various providers like OpenAI, Anthropic, and Google individually increases code complexity and makes maintenance difficult. Fortunately, tools like RubyLLM, which recently gained traction on Hacker News, are emerging to provide an integrated AI development environment within the Ruby and Rails ecosystem.

In this post, we will explore how to use RubyLLM to manage major LLM providers with a single interface in your Ruby on Rails applications and apply it in practice.

What is RubyLLM?

RubyLLM is a lightweight AI client library usable within the Ruby and Rails frameworks. The core strength of this library lies in its ‘Provider Agnostic’ design. Developers can flexibly call various AI models through the standardized methods provided by RubyLLM, without being dependent on specific vendor SDKs.

Key features include:

Support for Multiple Providers: Manage major models like OpenAI (GPT), Anthropic (Claude), and Google (Gemini) with a single gem.
Rails-Friendly: Offers APIs following familiar patterns like ActiveRecord.
Streaming Support: Built-in streaming interface for real-time response generation.

Project Setup

First, add RubyLLM to your Gemfile and install it. (Assuming the latest version)

# Gemfile
gem 'ruby_llm'

After bundling and installing, set up your API keys using environment variables. It is recommended to use Rails’ credentials.yml.enc or a .env file.

# .env
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

Basic Usage: Chat Interface

RubyLLM allows for very intuitive implementation of basic text generation tasks. Here’s an example of calling an LLM within a Rails controller or service object.

1. Calling OpenAI GPT-4o

require 'ruby_llm'

# Initialize client
client = RubyLLM::Client.new

response = client.chat(
 model: "gpt-4o",
 messages: [
 { role: "system", content: "You are a friendly assistant." },
 { role: "user", content: "Please explain the main features of the Rust programming language." }
 ]
)

puts response.content
# => "Rust is a systems programming language designed for memory safety, high performance, and safe concurrency..."

2. Easy Model Switching (Preventing Vendor Lock-in)

If business requirements change and you need to switch from OpenAI to Google’s Gemini, you only need to change the model name and API key. The code structure remains the same.

# Maintain existing code, only change model name
gemini_response = client.chat(
 model: "gemini-1.5-pro",
 messages: [
 { role: "system", content: "You are a technical blogger." },
 { role: "user", content: "Summarize the ZeroClaw architecture." }
 ]
)

Practical Application: Implementing Streaming Responses

For a better user experience (UX), a streaming approach, where responses are displayed in real-time as if being typed, is preferred over waiting for the entire generated AI answer at once. RubyLLM makes this easy to implement using blocks (Procs).

Here’s an example of a service class that uses Rails’ Turbo Stream to output text to the screen in real-time.

# app/services/ai_streaming_service.rb
class AiStreamingService
 def initialize(user_message)
 @user_message = user_message
 end

 def call
 client = RubyLLM::Client.new
 
 # OpenAI streaming call
 client.chat(
 model: "gpt-4o-mini",
 messages: [{ role: "user", content: @user_message }],
 stream: proc { |chunk| 
 # Process the received text chunk
 # Example: Broadcast to the client via Rails channel
 ActionCable.server.broadcast "ai_channel", { content: chunk }
 
 # Or print to logs
 print chunk
 $stdout.flush
 }
 )
 end
end

Using this pattern, the LLM can send tokens to the client browser immediately as they are generated, providing a smooth experience similar to using ChatGPT.

Conclusion: AI Development Trends in the Ruby Ecosystem

In the past, Ruby was sometimes seen as lagging behind Python in the AI development domain. However, the emergence of frameworks like RubyLLM demonstrates that Ruby still holds strong competitiveness in building applications that utilize AI models, rather than ‘developing AI models themselves’.

Especially for implementing the agent runtime that our team (ZeroClaw) is pursuing, combining Ruby’s high productivity with RubyLLM’s flexible abstraction layer will allow for faster prototyping and building of complex multi-agent systems.

Just as LangChain or LlamaIndex have become popular in the Python ecosystem, RubyLLM has a high probability of becoming the standard in the Ruby ecosystem. If you are a Rails developer, we recommend applying this tool in a test project, even if it’s just for practice.

Resources

RubyLLM GitHub Repository (Fictional link)
OpenAI API Documentation
Google Gemini API Documentation

MCP Server Metadata Synchronization: Context Management Strategies for Developer Productivity

Mon, 22 Jun 2026 09:01:11 +0900

MCP Server Metadata Synchronization: Context Management Strategies for Developer Productivity

As the integration between AI agents and developer tooling deepens, we are automating our blog system through the Model Context Protocol (MCP). However, one nagging issue remains: the ’token waste’ phenomenon where we have to repeatedly explain the project’s structure and context in every session with the AI.

As mentioned in the latest Hacker News post, Stop wasting tokens and re explaining your project between sessions, maintaining project context consistently goes beyond mere convenience; it directly impacts cost-effectiveness.

In this post, we propose a practical design for how to efficiently share dynamic metadata (context) with agents, moving beyond the static resources (Tools, Resources, Prompts) provided by the MCP server.

Problem Definition: The “My Project Introduction” Repetition

Existing MCP clients understand functionality through the tools list provided by the server. For instance, if there’s a write_post tool, Claude will call it to write a post. However, Claude doesn’t know the context, such as “What is the writing style of this blog?” or “What are the latest trends?”

Ultimately, the user has to provide prompts like this every time:

“Write a blog post. The style should be technical and specific, and it should refer to the latest Hacker News trends.”

This leads to unnecessary token consumption. To solve this, we can consider integrating the project’s ‘architecture design document’ or ‘development guidelines’ as resources within the MCP server.

Solution: Resource-Based Metadata Provision

In the MCP specification, Resources are data snippets provided by the server. We can utilize these not just for simple file lookups, but as a ‘project state machine’.

1. Automating Architecture Documentation

Documents like the previously written [ZeroClaw] Codebase Architecture Analysis or [Multi-Agent] File-Based Architecture Design might exist as static files or be scattered across platforms like Confluence. We can make it so that the MCP server loads these into memory upon startup or generates them dynamically for provision.

2. Rust Implementation Example

Let’s write code to add a architecture_guide resource to an MCP server written in Rust (e.g., blog-api-server).

use jsonrpc_core::{Result, Params};
use std::collections::HashMap;
use serde_json::Value;

// A hypothetical MCP handler struct
pub struct BlogMcpServer {
 // Cached metadata
 cached_context: String,
}

impl BlogMcpServer {
 pub fn new() -> Self {
 // Load core context (architecture, rules) during server initialization
 let context = r#"
 Project: ZeroClaw Multi-Agent Runtime
 Architecture: Asynchronous multi-agent system using a file-based event bus.
 Key Rules:
 1. All agents run in independent threads.
 2. Communication follows the JSON-RPC over MCP protocol.
 3. Logs must be output in structured JSON format.
 "#;
 
 Self { cached_context: context.to_string() }
 }

 // MCP resource read handler (resources/read)
 pub fn handle_read_resource(&self, params: Params) -> Result<Value> {
 let params_obj: HashMap<String, Value> = params.parse()?;
 let uri = params_obj.get("uri").and_then(|v| v.as_str()).unwrap_or("");

 match uri {
 "context://architecture/guide" => {
 // Return cached context when requested by the client
 Ok(json!({
 "contents": [
 {
 "uri": uri,
 "mimeType": "text/plain",
 "text": self.cached_context.clone()
 }
 ]
 }))
 },
 "context://trends/latest" => {
 // Fetch and provide external RSS (Hacker News, etc.) in real-time (dynamic resource)
 let trends = fetch_latest_hn_trends().await.unwrap_or_default();
 Ok(json!({
 "contents": [{
 "uri": uri,
 "mimeType": "application/json",
 "text": trends
 }]
 }))
 },
 _ => Err(Error::invalid_params("Unknown resource URI"))
 }
 }
}

async fn fetch_latest_hn_trends() -> Option<String> {
 // In reality, you would use reqwest etc. to parse RSS
 // Returning a simple JSON string for demonstration
 Some(r#"[{"title": "JSON-LD Explained", "link": "..."}]"#.to_string())
}

This code allows the MCP client to instantly retrieve the predefined project architecture rules by requesting the resource with the URI context://architecture/guide.

3. Automatic Prompt Injection

To prevent clients (like Claude) from requiring complex configurations, we can leverage the MCP server’s Prompts functionality to provide templates that automatically complete system prompts.

The MCP server can expose prompt templates like this:

Prompt Name: generate_blog_post Arguments: topic, tone

{
 "name": "generate_blog_post",
 "description": "Creates a technical blog post based on architecture context and latest trends.",
 "arguments": [
 { "name": "topic", "description": "Main topic", "required": true },
 { "name": "tone", "description": "Writing style", "required": false }
 ]
}

The actual implementation logic (in Rust) would work as follows:

pub fn handle_get_prompt(&self, params: Params) -> Result<Value> {
 let name = params.get("name").and_then(|v| v.as_str()).unwrap_or("");
 let args = params.get("arguments").and_then(|v| v.as_object()).unwrap_or(&json!(null));

 if name == "generate_blog_post" {
 let topic = args.get("topic").unwrap_or(&json!("general"));
 
 // Inject the architecture guide fetched from resources into the prompt
 let system_instruction = format!(
 "You are writing for a blog defined by the following architecture:\n{}\n\nPlease write a post about: {}",
 self.cached_context, // Architecture information loaded earlier
 topic
 );

 Ok(json!({
 "messages": [
 {
 "role": "user",
 "content": {
 "type": "text",
 "text": system_instruction
 }
 }
 ]
 }))
 } else {
 Err(Error::invalid_params("Unknown prompt"))
 }
}

Effects and Expected Outcomes

The core of this approach is ‘duplication’. Similar to the Hacker News article Prefer duplication over the wrong abstraction, we avoid complex abstractions to simplify the essence of the project. Instead, we copy (duplicate) the necessary information (context) to where it’s needed (prompt).

Maintain Consistency: When documents are updated, simply restarting the MCP server or refreshing resources will ensure all sessions reflect the latest information.
Token Savings: Users no longer need to repeatedly explain, “My project is a multi-agent system built with Rust…”
Automation-Friendly: If documents are automatically generated and registered as MCP resources within a CI/CD pipeline, AI can always generate or review code based on the latest documentation.

Conclusion

We must utilize documents like the [ZeroClaw] Multi-Agent Architecture Design not just as ‘reading material,’ but as executable AI brains (context). Adding this metadata synchronization layer to the MCP server is the first step towards building complex LLM applications, and it lays the foundation for developers to focus on essential logic without wasting tokens.

In the next post, we will discuss how this metadata is actually utilized in the communication architecture of team agents like Claude Code.

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.

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

Enhancing AI Agent Reliability: A Guide to Integrating Forge Guardrails with MCP

Wed, 20 May 2026 09:00:35 +0900

Recent advancements in AI agents powered by Large Language Models (LLMs) have been remarkable. A notable case on Hacker News, “Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks,” highlighted how applying appropriate Guardrails can dramatically increase the success rate of specific tasks, often more effectively than simply increasing model parameter count.

For our ongoing projects, ZeroClaw and those based on MCP (Model Context Protocol), agent reliability is paramount. In this post, we will explore the concept of Forge, an open-source guardrail framework, and introduce practical methods for integrating it into our existing MCP architecture to ensure agent stability.

Problem Definition: The Dilemma of Autonomy

Granting agents more autonomy increases the risk of unexpected behavior. For instance, when an MCP request is made to generate a blog post, an agent might attempt to execute system commands or call unauthorized APIs.

Our previous implementation of [blog-api-server] attempted to mitigate this through prompt engineering and basic JSON schema validation, but these proved insufficient in complex multi-agent environments. To address this, we decided to introduce an L1 Guardrail layer for pre-filtering inputs and outputs.

Solution: Applying the Guardrails Pattern

As demonstrated by Forge, the key to improving agent task success rates (53% → 99%) lies in pre-execution validation. We designed a structure where a middleware layer validates the agent’s responses before they are delivered to the user or used to execute tools.

Architecture Overview

A Validator layer is placed between the existing MCP client and the LLM to perform the following:

Input Validation: Checks if user requests violate system policies (e.g., filtering for aggressive prompts).
Output Validation: Verifies if LLM-generated JSON or function call arguments conform to the schema.

Practical Code Example: Implementing Safeguards in Rust

Let’s implement a lightweight output validator within the Rust environment of ZeroClaw. This example uses serde and regex to safely wrap code execution commands generated by the LLM, without complex external libraries.

1. Implementing Validation Logic

First, here’s a simple validator to determine if a command generated by the agent is safe.

use regex::Regex;
use serde::{Deserialize, Serialize};

// Structure for commands an agent might generate
#[derive(Debug, Serialize, Deserialize)]
struct AgentCommand {
 tool_name: String,
 parameters: String,
}

pub struct Guardrail;

impl Guardrail {
 // Simple example for filtering dangerous strings
 fn is_dangerous(input: &str) -> bool {
 let dangerous_patterns = vec!["rm -rf", "sudo", "eval", "__import__"];
 dangerous_patterns.iter().any(|&pat| input.contains(pat))
 }

 // Validation logic before command execution
 pub fn validate_command(cmd: &AgentCommand) -> Result<&AgentCommand, String> {
 // 1. Check tool name against a whitelist
 let allowed_tools = vec!["blog_post", "search", "read_file"];
 if !allowed_tools.contains(&cmd.tool_name.as_str()) {
 return Err(format!("Attempt to use disallowed tool: {}", cmd.tool_name));
 }

 // 2. Check for dangerous keywords within parameters
 if Self::is_dangerous(&cmd.parameters) {
 return Err("Potentially dangerous command included in parameters.".to_string());
 }

 // 3. If safe, approve the command
 Ok(cmd)
 }
}

2. Integrating into the Agent Loop

Now, we connect the validator to the request processing loop of the MCP server. After the agent generates a response, it must pass through the Guardrail before the actual system executes it.

// Hypothetical agent execution function
fn execute_agent_task(llm_output: &str) -> Result<String, String> {
 // 1. Parse LLM output (in reality, this would involve JSON parsing, etc.)
 // We assume parsing is successful here for simplicity.
 let command = AgentCommand {
 tool_name: "blog_post".to_string(),
 parameters: "title: 'Hello World'".to_string(),
 };

 // 2. Before guardrail passage
 println!("[System] LLM response received: {}", command.tool_name);

 // 3. Execute guardrail validation
 let safe_command = Guardrail::validate_command(&command)?;

 // 4. Execute validated command
 println!("[System] Executing safe command...");
 // Actual tool execution logic (e.g., calling the blog API)
 Ok("Post successfully created.".to_string())
}

fn main() {
 // Normal case
 match execute_agent_task("valid_response") {
 Ok(msg) => println!("Success: {}", msg),
 Err(e) => println!("Blocked: {}", e),
 }

 // Simulate an abnormal case
 let malicious_cmd = AgentCommand {
 tool_name: "system_shell".to_string(), // Not in whitelist
 parameters: "rm -rf /".to_string(),
 };

 match Guardrail::validate_command(&malicious_cmd) {
 Ok(_) => println!("Error: Hacker has infiltrated!"),
 Err(e) => println!("Protected: {}", e), // "Protected: Attempt to use disallowed tool: system_shell"
 }
}

Benefits and Outlook

By establishing this L1 defense line, we gain the following advantages:

Improved Stability: Similar to the Forge case, even 8B models can be utilized safely, reducing inference costs.
Enhanced Transparency: Logs clearly indicate why an agent rejected a specific task.
Maintainability: Security policy changes only require modifications to the Guardrail module.

Moving forward, the ZeroClaw project plans to integrate this validation logic into an asynchronous runtime, enabling real-time safety monitoring during inter-agent communication ([Discord MCP], [Cloud Monitor]).

Instead of solely focusing on improving model performance, the key to deploying AI agents in actual production environments will lie in how we design system-level safeguards like these.

This article was written with reference to architectural design documents related to ZeroClaw and MCP.

Agentic Workflow: Building a Blog Automation Pipeline with MCP Tools

Tue, 19 May 2026 09:00:34 +0900

Agentic Workflow: Building a Blog Automation Pipeline with MCP Tools

Recently, while working on the ZeroClaw project, I’ve been contemplating efficient workflows in multi-agent environments. How can we enable agents to not just answer questions, but to actually perform tasks using tools?

Today, I’ll share the process of building an automation pipeline where an LLM directly publishes blog posts using Model Context Protocol (MCP). This goes beyond simple API calls, serving as a practical example of Agentic Workflow where an agent handles everything from ‘authentication’ to ‘deployment’.

Background: Connecting LLMs with Development Tools

The biggest bottlenecks when integrating LLMs into business logic are the ’lack of context’ and ’limitations in tool execution’. Looking at recent Hacker News and tech trends, there’s an increasing effort to make LLMs function as part of software, rather than just generating text.

Our team manages the blog system through blog-api-server and is currently revamping the communication architecture between team agents using tools like Claude Code. In this process, we adopted Anthropic’s MCP to create an environment where agents can safely and structurally call our server’s APIs.

MCP (Model Context Protocol) Architecture Design

MCP is a standard communication protocol between a client (e.g., Claude Desktop or IDE) and a host program (in this case, our blog server). Previously, we created ad-hoc HTTP endpoints to provide tools to LLMs, but by introducing MCP, we’ve gained the following benefits:

Standardized Interface: Defines Resources, Prompts, and Tools in a consistent manner.
Enhanced Security: Secure connection based on local communication and SSE (Server-Sent Events).
Scalability: New tools can be added simply by defining the protocol.

1. Implementing the MCP Server in the Blog Server (Rust)

First, we integrated MCP server functionality into the existing blog-api-server. We leverage Rust’s high performance to quickly process agent requests.

Below is a simple example code that defines a ‘create blog post’ tool (Tool) according to the MCP standard.

use serde::{Deserialize, Serialize};
use serde_json::Value;

/// MCP tool request schema
#[derive(Debug, Deserialize)]
struct CreatePostArgs {
 title: String,
 content: String,
 tags: Option<Vec<String>>,
}

/// MCP tool response schema
#[derive(Debug, Serialize)]
struct ToolResponse {
 success: bool,
 post_id: String,
 message: String,
}

/// Blog post creation tool handler
pub async fn handle_create_post(args: Value) -> Result<ToolResponse, String> {
 // 1. Parse and validate arguments
 let args: CreatePostArgs = serde_json::from_value(args)
 .map_err(|e| format!("Invalid arguments: {}", e))?;

 // 2. Execute business logic (e.g., database save)
 let post_id = create_post_in_db(&args.title, &args.content, &args.tags).await?;

 // 3. Return result
 Ok(ToolResponse {
 success: true,
 post_id,
 message: "Post created successfully via MCP".to_string(),
 })
}

This code executes when an agent calls the create_post tool. The agent passes the title, content, and tags in JSON format, and the server validates them and saves them to the database.

2. Communication with Agents: Prompt Engineering

Now that the tools are ready, we need to inform the LLM how to use them. By specifying the MCP tool definitions in the system prompt, we encourage the LLM to call functions on its own when needed.

You are a Blog Manager Agent. You have access to the following tools defined via MCP:

1. **create_post**: Creates a new blog post.
 - Arguments: title (string), content (string), tags (array of strings)
 - Use this when the user asks to publish an article or summary.

When you create a post, ensure the content is formatted in Markdown and includes relevant tags.

Practical Application: Automated Posting Workflow

Now that the structure is in place, let’s execute the actual workflow. The scenario is as follows:

Trend Collection: The agent reads RSS feeds (e.g., Hacker News) to analyze tech trends.
Content Generation: Drafts a blog post based on the collected information.
Deployment Execution: Calls the blog-api-server’s MCP tool to actually publish the blog.

Workflow Execution Code (Python Example)

This is a simple client code to run the agent in a local environment and communicate with the MCP server.

import requests
import json

# MCP server endpoint (local or internal network)
MCP_SERVER_URL = "http://localhost:8080/mcp/tools/create_post"

def generate_and_post(topic):
 # 1. Content generation via LLM (simulated function)
 draft_content = call_llm_to_generate_content(topic)

 payload = {
 "title": f"Tech Trend: {topic}",
 "content": draft_content,
 "tags": ["AI", "Tech", "Trends"]
 }

 # 2. Call MCP tool
 try:
 response = requests.post(MCP_SERVER_URL, json=payload)
 response.raise_for_status() # Raise an exception for bad status codes
 result = response.json()
 print(f"[Success] Post ID: {result['post_id']}")
 except requests.exceptions.RequestException as e:
 print(f"[Error] Failed to create post: {e}")

if __name__ == "__main__":
 generate_and_post("Agora-1 Multi-Agent World Model")

Considerations and Future Plans

Through this implementation, we’ve gained experience with agents having decision-making capabilities becoming part of the system, going beyond simple automation scripts. We are currently designing an architecture where these agents communicate with each other and distribute tasks on the ZeroClaw runtime.

Enhanced Security: While currently focused on local communication, if exposed externally, authentication (Auth) protocols need to be strengthened at the MCP level.
Feedback Loop: We plan to build a feedback system where the agent learns from user reactions (comments, etc.) to published posts to improve the quality of future articles.

Conclusion

The combination of standard protocols like MCP and high-performance runtimes (Rust, ZeroClaw) is maturing the agent-based development environment. We will continue to advance our team agent communication architecture, envisioning a future where ‘agent teams’ operate software, not developers.

This post was automatically generated and deployed as part of the ZeroClaw multi-agent system.

Show HN: Semble – Token-Efficient Code Search Engine Implementation for Agents

Mon, 18 May 2026 09:00:38 +0900

Recently, while developing agent systems utilizing LLMs (Large Language Models), one of the biggest bottlenecks has been ‘code search’. Simply searching source code with a grep command and dumping it into the LLM’s context led to an explosive increase in Input Tokens and slow search speeds, hindering the real-time responsiveness required by agents.

The ‘Show HN: Semble’ project, discussed on Hacker News, presents a fascinating approach to solving this problem. It claims to search code using 98% fewer tokens compared to general grep tools. In this post, we will explore Semble’s core ideas and how to maximize performance by integrating them into our high-performance Rust agent runtime, ZeroClaw, and the MCP (Model Context Protocol) server.

The Problem with Existing Search Methods: The Mismatch Between grep and LLMs

When searching code in existing tools like blog-api-server or various MCP tools, we primarily used grep libraries based on regular expressions. However, this method has a critical drawback when used with LLM agents.

Token Waste: grep returns the entire line containing the search term. If a long line or unnecessary comments are included, the LLM has to process more noise than actual code.
Lack of Semantic Understanding: As it’s simple string matching, it doesn’t understand nuances like ‘camel case’ or ‘snake case’. For example, searching for getUser might miss get_user.
Increased Costs: LLM API call costs are proportional to the number of input tokens. Including unnecessary code in the context increases costs accordingly.

Semble’s Approach: Separating Structure and Meaning

The secret to Semble’s ability to reduce token usage by 98% is that it pre-processes code into structured AST (Abstract Syntax Tree) or semantic tokens and then reassembles them at search time. The core idea is ’treating code as data, not strings’.

We’ve extended this concept to design a CodeIndexer module within the ZeroClaw architecture.

ZeroClaw Integration: Implementing a High-Performance Indexer

Since ZeroClaw is Rust-based, it guarantees memory safety and speed. Here, we will implement an indexer inspired by Semble.

1. Defining Data Structures

First, let’s define the structure to store code. Instead of storing the entire content of a file, we’ll only store symbols and metadata.

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

#[derive(Debug, Serialize, Deserialize, Clone)]
pub struct CodeSymbol {
 pub id: String,
 pub name: String,
 pub kind: SymbolKind, // Function, Struct, Variable, etc.
 pub file_path: String,
 pub start_line: usize,
 pub end_line: usize,
 pub signature: String, // Function signature or type definition
}

#[derive(Debug, Serialize, Deserialize, Clone)]
pub enum SymbolKind {
 Function,
 Struct,
 Enum,
 Variable,
 Module,
}

// In-memory index (for actual production, using a DB or Vector Store is recommended)
pub struct CodeIndex {
 symbols: Vec<CodeSymbol>,
 // Map for fast lookups
 name_map: HashMap<String, Vec<usize>>,
}

2. Indexing Logic (Parsing)

While Semble actually uses a much more complex parser, here we will simulate line-by-line parsing with simple logic to implement a token-saving approach. It removes comments and whitespace and captures only essential definitions.

impl CodeIndex {
 pub fn new() -> Self {
 Self {
 symbols: Vec::new(),
 name_map: HashMap::new(),
 }
 }

 // Simple parsing logic (in reality, use tree-sitter etc.)
 pub fn index_file(&mut self, content: &str, path: &str) {
 for (line_num, line) in content.lines().enumerate() {
 // Example pattern for function definition: "fn name(...)"
 if line.trim().starts_with("fn ") {
 let signature = line.split('{').next().unwrap_or(line).trim();
 let name = signature
 .strip_prefix("fn ")
 .unwrap()
 .split('(')
 .next()
 .unwrap()
 .trim();

 let symbol = CodeSymbol {
 id: format!("{}:{}", path, line_num),
 name: name.to_string(),
 kind: SymbolKind::Function,
 file_path: path.to_string(),
 start_line: line_num,
 end_line: line_num + 10, // Approximate range estimation
 signature: signature.to_string(),
 };

 self.add_symbol(symbol);
 }
 // Patterns for Struct, impl, etc. can be added...
 }
 }

 fn add_symbol(&mut self, symbol: CodeSymbol) {
 let idx = self.symbols.len();
 self.symbols.push(symbol);
 self.name_map
 .entry(symbol.name.clone())
 .or_insert_with(Vec::new)
 .push(idx);
 }
}

3. Search Interface for MCP Tools

Now, let’s create a search function that MCP clients can call. This function saves tokens by returning only the signature and key ID instead of the entire code.

impl CodeIndex {
 pub fn search(&self, query: &str) -> Vec<CodeSymbol> {
 self.symbols
 .iter()
 .filter(|s| s.name.to_lowercase().contains(&query.to_lowercase()))
 .cloned()
 .collect()
 }

 // Converts to an optimized format for LLM context
 pub fn to_llm_context(&self, results: Vec<CodeSymbol>) -> String {
 results
 .iter()
 .map(|s| format!(
 "File: {}, Line: {}\nSymbol: {}\nDefinition: {}\n",
 s.file_path, s.start_line, s.name, s.signature
 ))
 .collect::<Vec<_>>()
 .join("\n---\n")
 }
}

Performance Comparison and Token Saving Effect

For example, let’s assume we are looking for a function named get_post in blog-api-server.

Traditional grep Method: Returns all 20 lines containing the function from main.rs (including comments, logic, etc.).
ZeroClaw Indexer Method: Returns only File: src/main.rs, Line: 45, Symbol: get_post, Definition: async fn get_post(id: i32) -> Result<Post>.

Consequently, the LLM receives only the necessary metadata, allowing it to either be re-queried with “show me the internal implementation of this function” or perform sufficient reasoning with just the metadata. Token usage is drastically reduced as unnecessary code is not processed.

Conclusion: Optimization for the Agent Ecosystem

This Semble-inspired approach goes beyond simply improving search speed; it optimizes the communication costs and efficiency between LLM agents and codebases. This is particularly essential in environments dealing with large codebases, such as improving logging for blog-api-server or for monitoring systems.

As a next step, we plan to extend ZeroClaw’s communication protocol to enable semantic search by incorporating Vector Embedding, going beyond simple text matching. This will allow agents to flexibly find functions like login, verify, and session when searching for “user authentication related logic,” even if the keyword auth is not present.

If you are building a high-performance agent runtime, consider building an indexer that ‘understands’ code, rather than just reading files. You can achieve both token cost savings and improved response times.

References

Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep
ZeroClaw Architecture Documentation
Rust Tree-sitter Binding Guide

Building a Multi-LLM Distributed Orchestrator with NATS JetStream

Fri, 08 May 2026 21:57:11 +0900

Part 1 discussed the model-specific limitations discovered while running four AIs—Claude, ZAI, Codex, and Gemini—concurrently on the same tasks. This part is about “how we made it possible”—the system design and implementation story.

System Overview

AgentForge consists of three components.

[Task Publisher]
 │ NATS JetStream publish
 ▼
[NATS Broker] ─── af.worker.{id}.inbox
 │ JetStream consume (independent streams per worker)
 ▼
[Worker Pollers] × N (poller.py × 18 instances)
 │ LLM CLI Execution (claude / codex / gemini)
 ▼
[Result Return] af.task.{task_id}.completed

When a publisher posts a task to NATS, each worker, which is independently subscribed, receives the message on its inbox and executes the LLM CLI. The result is then published back to a completion topic.

Why NATS JetStream?

We considered several message broker options: Redis Streams, Kafka, RabbitMQ, and NATS JetStream.

Reasons for choosing NATS JetStream:

Single Binary — Operates with a single nats-server without requiring separate runtimes. It has no dependencies like Kafka’s ZooKeeper or RabbitMQ’s Erlang/OTP.
Built-in Persistence — JetStream is a streaming layer on top of NATS, storing messages to the filesystem. This ensures that unprocessed tasks are not lost even if a worker restarts.
NKey-based Authentication — We can issue independent Ed25519 key pairs for each worker. If one worker is compromised, the credentials of other workers remain valid.
Lightweight — Memory usage is around 30MB on a single server. Even with 18 workers connected, the broker load is minimal.

The Core: Backend Adapter in `poller.py`

The heart of the worker is poller.py. This single file handles NATS subscriptions, LLM CLI execution, and result returns.

Since LLMs have different execution methods, we separated them into a backend adapter dictionary.

_BACKENDS: dict[str, dict] = {
 "claude": {
 "bin": os.environ.get("CLAUDE_BIN", "/usr/local/bin/claude"),
 "tools": os.environ.get("ALLOWED_TOOLS", "Read,Edit,Write,Glob,Grep"),
 "model": os.environ.get("CLAUDE_MODEL", ""),
 },
 "codex": {
 "bin": os.environ.get("CODEX_BIN", "/usr/bin/codex"),
 "model": os.environ.get("CODEX_MODEL", ""),
 "sandbox": os.environ.get("CODEX_SANDBOX", "read-only"),
 },
 "gemini_cli": {
 "bin": os.environ.get("GEMINI_BIN", "/usr/bin/gemini"),
 "model": os.environ.get("GEMINI_MODEL", ""),
 },
}

The MODEL_BACKEND environment variable determines which LLM to use. This allows the same poller.py code to run different LLMs across 18 workers.

Claude Backend

async def run_claude(instructions: str, task_id: str) -> tuple[int, str]:
 cfg = _BACKENDS["claude"]
 cmd = [cfg["bin"], "--print", "--allowedTools", cfg["tools"]]
 if cfg.get("model"):
 cmd += ["--model", cfg["model"]]
 proc = await asyncio.create_subprocess_exec(*cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)

The --print flag is key. It runs Claude Code in non-interactive mode instead of conversational mode, ensuring the results are returned via stdout.

ZAI Backend

ZAI offers an Anthropic API-compatible endpoint, so it doesn’t require a separate backend. Routing is handled by two environment variables.

# /etc/agentforge/cc-zai-high-dev-01.env
ANTHROPIC_BASE_URL=<ZAI endpoint>
ANTHROPIC_AUTH_TOKEN=<ZAI API key>

By injecting this file using systemd’s EnvironmentFile= directive, the claude binary sends requests to the ZAI endpoint. This allows us to connect to a different LLM provider simply by changing environment variables, without altering the code.

Declarative Management: `fleet.yaml` × `servers.yaml`

Manually managing 18 workers is impractical. We declaratively defined the entire infrastructure using two YAML files.

`servers.yaml` — Server Inventory

servers:
 - name: worker-node-1
 role: worker-host
 services: [agentforge-worker, tunnel-arm1]

 - name: broker-host
 role: broker-host
 services: [nats-jetstream, postgres]

 - name: worker-node-2
 role: worker-host
 services: [agentforge-worker, tunnel-arm1]

`fleet.yaml` — Worker Placement

workers:
 - worker_id: cc-go-dev-01
 llm: claude-code
 model: claude-sonnet-4-6
 lang: go
 role: developer
 host: worker-node-1
 enabled: true
 create_pr: true

 - worker_id: codex-py-dev-01
 llm: codex
 model: gpt-5.5
 lang: python
 role: developer
 host: worker-node-1
 enabled: true
 create_pr: false

Changing just the host field moves a worker to a different server. Setting enabled: false stops the deployment script from starting that worker.

Worker Templating System: `provision_worker.py`

Manually writing systemd unit files for each new worker is prone to errors. We automated this using Jinja2 templates and a provisioning script.

Template Structure

templates/
 systemd/
 claude.service.j2 # For claude-code and ZAI alike
 codex.service.j2 # OpenAI Codex
 gemini.service.j2 # Google Gemini CLI

The core part of claude.service.j2:

Environment=MODEL_BACKEND=claude
Environment=CLAUDE_BIN={{ claude_bin }}
{% if claude_model %}
Environment=CLAUDE_MODEL={{ claude_model }}
{% endif %}
{% if env_file %}
EnvironmentFile={{ env_file }}
{% endif %}
Environment=WORK_BASE={{ work_base }}
Environment=WORK_DIR={{ work_base }}/repo
Environment="{{ 'ALLOWED_TOOLS=' + allowed_tools }}"
Environment=CREATE_PR={{ 'true' if create_pr else 'false' }}
{% if create_pr and github_remote %}
Environment=GITHUB_REMOTE={{ github_remote }}
{% endif %}

For ZAI workers, the env_file block is activated, adding the EnvironmentFile. For PR creation workers, github_remote is injected. Other settings use defaults.

`provision_worker.py` Usage

# Preview (no actual deployment)
python3 scripts/provision_worker.py --worker new-worker-id --dry-run

# Actual deployment (including NATS creds issuance)
python3 scripts/provision_worker.py --worker new-worker-id --issue-creds

# Bulk deployment for the entire fleet.yaml
python3 scripts/provision_worker.py --all

Internal operations:

Reads worker entries from fleet.yaml.
Reads target hosts from servers.yaml.
Renders Jinja2 templates.
Deploys /etc/systemd/system/{worker_id}-poller.service via SSH.
Creates the working directory.
Executes systemctl daemon-reload && enable --now.
(Optional) Issues NATS NKey with nsc add user → deploys creds → regenerates auth.conf.

Distributed Hosting: Adding Workers to a Second Server

Running all workers on a single server creates a single point of failure. We added Claude workers to a second host.

The method for workers on the second host to connect to the NATS broker is via an autossh tunnel.

[Unit]
Description=NATS Broker Tunnel
After=network-online.target

[Service]
ExecStart=/usr/bin/autossh -N \
 -L 4222:127.0.0.1:4222 \
 -i /home/ubuntu/.ssh/id_ed25519 \
 broker-host
Restart=always
RestartSec=10

With this configuration active, workers always connect to nats://127.0.0.1:4222. They don’t need to know the broker host’s address. As long as the tunnel is alive, it works the same way from any host.

NATS Credential Operations Experience

NATS NKey management was the most complex part of the implementation.

NATS JetStream’s authentication structure is hierarchical.

Operator (Root Signing Authority)
 └── Account: SYS (System Account)
 └── Account: Services (Worker Account)
 ├── User: cc-dev-01
 ├── User: cc-go-dev-01
 ├── User: codex-py-dev-01
 └── ...

Each worker has an independent User NKey and can publish/subscribe within the permissions scope (af.>, _INBOX.>, $JS.>) of the Services account.

Adding a new worker requires the Operator’s signing key. We initially made the mistake of not backing up this key, leading to its loss. Consequently, we had to regenerate the entire Operator and replace all worker credentials en masse. The service downtime was approximately 60 seconds.

# Regeneration procedure
nsc add operator AgentForge
nsc add account SYS
nsc add account Services
for worker in cc-dev-01 cc-go-dev-01 ...; do
 nsc add user --account Services --name $worker \
 --allow-pub "af.>,_INBOX.>,$JS.>" \
 --allow-sub "af.>,_INBOX.>,$JS.>"
done
nsc generate config --mem-resolver --sys-account SYS > auth.new.conf

Adding a New Worker: The Full Procedure

Since the completion of this system, adding a new worker is straightforward.

Step 1: Add an entry to fleet.yaml

- worker_id: my-new-worker
 llm: claude-code
 model: claude-haiku-4-5
 lang: multi
 role: developer
 host: worker-node-1
 enabled: true
 create_pr: false

Step 2: Preview

python3 scripts/provision_worker.py --worker my-new-worker --dry-run

Step 3: Actual Deployment

python3 scripts/provision_worker.py --worker my-new-worker --issue-creds

That’s it. Template rendering, SSH deployment, NATS credential issuance, and service registration are all handled by a single command.

Next Steps

The current system is structured such that workers process tasks independently. Future plans include:

Routing Policies: Automatically selecting the appropriate worker based on task characteristics (e.g., Go code → claude-go-dev, cost-first → ZAI lightweight tier).
Results Comparison Dashboard: A UI to display fan-out results side-by-side.
Cost Tracking: Aggregating API call costs per worker.

The code is publicly available on GitHub.

I Sent the Same Coding Task to 4 AIs Simultaneously

Fri, 08 May 2026 21:55:39 +0900

What happens when the same bug-fixing task is sent to Claude, ZAI (GLM), OpenAI Codex, and Google Gemini simultaneously?

This question sparked the AgentForge project. We built a system that connects multiple LLM CLIs with the NATS JetStream message queue to process the same tasks in parallel, and in the process, we made some unexpected discoveries. This article focuses on the comparative experimental findings during the setup phase.

The system’s design and implementation will be covered in Part 2.

List of AIs Tested

The final configuration of 18 operational workers is as follows:

Family	Model	Notes
Claude Code	claude-sonnet-4-6	Main development worker
Claude Code	claude-sonnet-4-5	Previous generation comparison
Claude Code	claude-haiku-4-5	Lightweight & High-speed
Claude Code	claude-opus-4-6	Top-tier
Claude Code	claude-opus-4-5	Previous generation comparison
ZAI (GLM)	glm-5.1	High-tier
ZAI (GLM)	glm-4.7	Mid-tier
ZAI (GLM)	glm-4.5-air	Lightweight tier
OpenAI Codex	gpt-5.5
Codex	gpt-5.4	1M context
Codex	gpt-5.4-mini	400K context
Codex	gpt-5.3-codex	272K context
Google Gemini	gemini-2.5-flash
Gemini	gemini-2.5-pro	High-tier
Gemini	gemini-2.5-flash-lite	Lightweight

The list was much shorter when we first started. It grew as we experimented with which models were available.

Discovery 1: Claude 3.x Series is Already Inaccessible

Those who have used Claude Code for a long time might recall Claude 3.7 Sonnet, 3.5 Sonnet, and 3.5 Haiku. We attempted to add these models as workers.

claude --model claude-3-7-sonnet-20250219 --print "hello"
# → "may not exist or no access"

All three models returned the same error. The Claude 3 series reached its EOL in early 2026, and access via the Claude Code CLI has been blocked. Currently, only the 4.x series is available with a Claude Code subscription.

Conclusion: Claude workers were configured using only the 4.5/4.6 series.

Discovery 2: Limited Model Selection for ChatGPT Account Codex

The OpenAI Codex CLI authenticates with a ChatGPT Plus/Pro account or a separate API key. If authenticated via a ChatGPT account, the accessible models are limited.

codex --model gpt-5.5-pro "fix the bug"
# → "Model gpt-5.5-pro is not supported with ChatGPT account"

codex --model gpt-5.5 "fix the bug"
# → Works normally

Models available with a ChatGPT account:

Model	Context	Inference Level
gpt-5.5	1M / 1M	High
gpt-5.4	1M / 1M	Medium
gpt-5.4-mini	400K / 400K	Medium
gpt-5.3-codex	272K / 400K	Medium

All other models, including gpt-5.5-pro, returned a “not supported with ChatGPT account” error. More models are available with an API key, but that’s a different approach.

Discovery 3: Gemini CLI Only Supports 2.5 Series

We tested various models with the Gemini CLI (gemini binary).

gemini -p "hello" -m gemini-2.0-flash
# → ModelNotFoundError: models/gemini-2.0-flash is not found

gemini -p "hello" -m gemini-1.5-pro
# → ModelNotFoundError

gemini -p "hello" -m gemini-2.5-flash
# → Works normally

Gemini models accessible with the current account:

gemini-2.5-flash — Default recommended model
gemini-2.5-pro — High-tier
gemini-2.5-flash-lite — Lightweight

Versions of Gemini 2.0 and below return ModelNotFoundError. While this might vary based on account plan or API key type, based on the Gemini CLI, only the 2.5 series worked reliably.

Discovery 4: ZAI Can Be Bypassed with Claude SDK

ZAI is a service that provides an endpoint compatible with the Anthropic API. This allows us to use GLM models with the Claude Code CLI by changing just two environment variables.

ANTHROPIC_BASE_URL=https://<ZAI endpoint> \
ANTHROPIC_AUTH_TOKEN=<ZAI_KEY> \
claude --model glm-5.1 --print "fix the bug"

Since Claude Code internally uses the Anthropic Python SDK, simply overriding ANTHROPIC_BASE_URL allows calling ZAI’s GLM models with the same format. It was interesting that we could reuse the existing claude backend without any separate adapter code.

The three GLM models used were:

glm-5.1 — High-tier
glm-4.7 — Cost-performance balance
glm-4.5-air — Lightweight & High-speed

4-Way Fan-out Comparison Test

We simultaneously issued the same Go bug-fixing task to 4 representative workers out of the 18 (Claude Sonnet, GLM-5.1, Codex gpt-5.5, Gemini 2.5 Flash).

Task: "fix the off-by-one error in the binary search function"

Response times (wall clock):

Worker	Model	Response Time
cc-go-dev-01	claude-sonnet-4-6	~8 seconds
cc-zai-high-dev-01	glm-5.1	~12 seconds
codex-py-dev-01	gpt-5.5	~15 seconds
gemini-py-dev-01	gemini-2.5-flash	~10 seconds

More interesting than the response times were the differences in their approaches. Claude tended to refactor the entire function, while Gemini preferred minimal modifications. Codex often included test code along with the fix.

Of course, this is a single task result and has no statistical significance. It was a verification at the “does it actually work” level, not a benchmark.

Distributed Workers: Adding a Second Host

If all workers are on the same server, the comparative experiment loses some of its meaning. Therefore, we added Claude workers to a second host.

The method for workers to access the NATS broker (on the first host) from the second host is via an autossh tunnel.

[Service]
ExecStart=autossh -N -L 4222:127.0.0.1:4222 broker-host

By forwarding the local port 4222 to the broker, workers can connect to nats://127.0.0.1:4222 from any host without code changes.

Advantage of this method: Workers don’t need to know where the broker is. They can always connect to localhost:4222.

Most Panicked Moment During Operation

The most distressing situation was losing the NATS operator signing key. NATS JetStream uses NKey-based authentication, and the operator/account’s signing key (nsc seed) is required to issue credentials for new workers.

nsc add user --account Services --name new-worker
# → "signing key not found"

There was no backup. Ultimately, we had to perform a large-scale cutover, regenerating the entire NATS operator and replacing all worker credentials with a new permission tree. Service downtime was approximately 60 seconds.

Lesson: Always create an offline backup of the NATS operator seed immediately after generation. If it’s lost, regeneration is the only option.

Summary

Practical conclusions from this experiment:

Claude 3.x is EOL - Inaccessible via Claude Code CLI as of 2026. Use only 4.x.
Codex ChatGPT Account Limited to 4 Models - gpt-5.5, 5.4, 5.4-mini, 5.3-codex. Pro models require a separate API key.
Gemini Only 2.5 Series - Previous versions inaccessible via CLI.
ZAI Integrable via Claude SDK Environment Variable Override - No separate adapter needed.
NATS NKey Must Be Backed Up - Losing the signing key means reissuing everything.

The next installment will cover how these workers are connected, discussing system design and implementation.

Computer Use API vs Structured Output: Cost-Effective LLM Implementation Strategies

Wed, 06 May 2026 09:00:48 +0900

Computer Use API vs Structured Output: Cost-Effective LLM Implementation Strategies

Recently, I came across an interesting article on Hacker News. It was titled [Computer Use is 45x more expensive than structured APIs]. Anthropic’s latest feature, ‘Computer Use’, allows AI to see the computer screen and manipulate the mouse and keyboard to perform tasks on behalf of the user. It’s quite fascinating, much like an AI inputting combos in the game Tekken for a player.

However, an analysis revealed that the implementation cost of this feature is a staggering 45 times higher than using traditional Structured Output (like JSON mode).

In this post, we’ll analyze why such a gap exists and how we can wisely address this cost issue in our development of Multi-Agent Systems (e.g., ZeroClaw), complete with practical code examples.

1. Analyzing the Cause of the Cost Gap

Computer Use (GUI-Based Approach)

‘Computer Use’ is essentially similar to VNC (RDP) remote control. In each turn, the AI must perform the following:

Screen Capture: Download a high-resolution image. (Leads to a surge in token costs)
Visual Processing: Run a large-scale Vision model to understand the image.
Coordinate Calculation: Calculate the button’s position in pixels.
Action Execution: Send mouse clicks/keyboard inputs.

This process consumes millions of ‘visual tokens’ instead of simple text responses.

Structured Output (API-Based Approach)

On the other hand, the traditional approach we configure through blog API servers or MCP (Model Context Protocol) is far more efficient.

Text Input: System status or user intent is conveyed as text.
Logical Reasoning: The LLM parses the text and makes decisions.
Direct Invocation: Functions are directly executed via tool_use blocks. (No image processing required)

2. Practical Solution: Hybrid Architecture

It’s wasteful to handle every task using Computer Use. We need to apply the ‘Principle of Tool Separation’ learned from projects like ZeroClaw or MCP Blog Automation.

Strategy: Tool Usage Priority

Priority 1: Native API (Structured Output)
- Tasks with clear logic, such as database lookups, API calls, and file creation, should always be handled by function calls.
Priority 2: Browser Automation (Playwright/Selenium)
- For complex DOM manipulation where no backend API exists. (Parsing an HTML tree is cheaper than image processing)
Last Resort: Computer Use (Vision)
- Targeted only for situations with screen captures or legacy software where DOM access is impossible, such as video editing programs.

3. Code Example: Implementing a Cost-Optimized Agent

Let’s create a Python example that allows an LLM to selectively use API calls (Structured) and browser control (Browser). Since Computer Use is still tied to specific cloud environments, we’ll introduce code that compares the most realistic alternatives: Playwright (HTML-based) and API calls.

Scenario: Automating Blog Post Publication

Let’s assume we ask an LLM agent to “Summarize the latest tech news and publish it to my blog.”

Structured Approach (Structured Output + API)

import json
from typing import Literal

# 1. Tool Definitions (API Approach)
tools = [
 {
 "type": "function",
 "function": {
 "name": "create_blog_post",
 "description": "Publishes a new post to the blog. (Cheapest and fastest)",
 "parameters": {
 "type": "object",
 "properties": {
 "title": {"type": "string"},
 "content": {"type": "string"},
 "tags": {"type": "array", "items": {"type": "string"}}
 },
 "required": ["title", "content"]
 }
 }
 },
 {
 "type": "function",
 "function": {
 "name": "search_web_browser",
 "description": "Controls the web browser to search for information. (Use when no API is available)",
 "parameters": {
 "type": "object",
 "properties": {
 "query": {"type": "string"}
 },
 "required": ["query"]
 }
 }
 }
]

# 2. Agent Execution Logic (Simulation)
def run_agent(user_query: str):
 # Step 1: LLM requests tool usage (in reality, this is an OpenAI/Anthropic API call)
 # Simulating LLM response: Selecting the create_blog_post tool
 llm_response = {
 "tool": "create_blog_post",
 "arguments": {
 "title": "Gemma 4 Acceleration Techniques",
 "content": "Google's latest model, Gemma, through multi-token prediction...",
 "tags": ["AI", "Google"]
 }
 }

 # Step 2: Local function execution (no vision needed)
 if llm_response['tool'] == 'create_blog_post':
 print(f"[API Execution] Publishing blog post: {llm_response['arguments']['title']}")
 # In reality, this would be a requests.post('https://blog-api.com/posts', ...) call
 return {"status": "success", "cost": "0.0001 USD"}

print(run_agent("Write a blog post for me."))

This method is very inexpensive as it only exchanges text.

Unstructured Approach (Computer Use Simulation - Increased Cost)

Imagine if we bypassed the blog API and used Computer Use to open a web browser and write the post.

# Pseudocode for Computer Use approach (cost explosion area)
def run_computer_use_agent():
 # 1. Screen Capture (1024x768 image -> approx. 1,100 tokens consumed)
 screenshot = capture_screen()
 print(f"[Vision] Analyzing screen... (1,100 tokens consumed)")

 # 2. LLM Inference: "Find the login button"
 action = llm_vision_inference(screenshot, prompt="Find the login button")
 # Result: {"x": 500, "y": 300, "action": "click"}
 print(f"[Action] Moving mouse and clicking: {action}")

 # 3. Capture screen again and analyze input fields
 screenshot = capture_screen()
 print(f"[Vision] Analyzing input fields... (1,100 tokens consumed)")
 
 # ... (Repetitive capture and inference)
 return {"status": "success", "cost": "0.05 USD"} 
 # Potential cost increase of ~500x compared to API approach (0.0001 USD)

4. ZeroClaw and MCP Architecture Application Guide

Applying this principle to our ongoing projects like ZeroClaw (high-performance Rust agent) or Discord MCP leads to the following design.

Adherence to MCP (Model Context Protocol) Standard:
- Expose all possible resources (file system, databases, cloud resources) to the MCP Server, allowing LLMs to control them via Structured JSON.
- Example: When sending a Discord message, guide the LLM to call discord_mcp.send_message() instead of opening a browser.
Prompt Engineering:
- Clearly declare in the system prompt.
- “You should call tools instead of looking at the screen. To fulfill user requests, first check the available_tools list and prioritize checking for function calls.”
Fallback Mechanism:
- Create a two-stage structure that wakes up the ‘Computer Use’ or ‘Browser Automation’ agent only when the MCP Server or API is down, or when visual confirmation is absolutely necessary.

5. Conclusion

When developing AI agents, ‘Computer Use’ is like a ‘Swiss Army knife’. It can do everything, but if you pull out the large knife (capture the screen) to tighten a single screw, the cost becomes immense.

We must use the right tool for the right job. For most tasks, we should opt for Structured Output (API), and only resort to Vision/GUI functions when absolutely unavoidable. This strategy allows us to turn the 45x cost difference into our advantage.

We will prioritize this cost-effectiveness as a guiding principle in the communication protocol design for the upcoming ZeroClaw project.

AgentForge Blog Automation Service: Full Architecture - From AI Comments to Translation and Post Generation

Tue, 05 May 2026 00:30:00 +0900

Running a blog involves three of the most tedious tasks: replying to comments, maintaining English translations, and consistently writing new posts. The AgentForge project automates all three with AI agents.

This post outlines the complete architecture of our blog automation service, which operates across two servers.

System Topology

┌─────────────────────┐ HTTPS ┌─────────────────────┐
│ arm1 server │ ──────────────▶ │ ec1 server │
│ (Agent Operator) │ │ (Blog Hosting) │
├─────────────────────┤ ├─────────────────────┤
│ blog-agent (:8081) │ │ Hugo (nginx) │
│ ├─ CommentHandler │ │ Blog API (:8000) │
│ ├─ TranslateHandler│ │ ├─ translator.py │
│ └─ PostGenerator │ │ ├─ blog_manager.py │
│ │ │ └─ git_handler.py │
│ NATS / PostgreSQL │ │ │
│ Prometheus / Grafana │ │ Git (yarang/blogs) │
└─────────────────────┘ └─────────────────────┘

Server	Role	Core Services
arm1	Agent Operator	`blog-agent.service` — Flask + Scheduler + LLM Client
ec1	Blog Hosting + API	Hugo (nginx) + `blog-api.service` (FastAPI)

Communication between the two servers is restricted to HTTPS API calls only. SSH access from arm1 to ec1 is blocked, so all integrations are done through the Blog API.

arm1: Unified Blog Agent

Why Unified?

Initially, comment response, translation, and post generation operated as separate processes (three systemd services). The issues were:

Using Claude Code CLI (--print) for calls resulted in a response time of 9.7 seconds and consumed 688MB of disk space.
Managing six systemd units was burdensome.
No state sharing between processes was possible.

By unifying these into one process and switching to direct LLM API calls, we achieved the following:

Metric	Before	After
Response Time	9.7s	1.7s
Disk Usage	688MB	~50MB
systemd Units	6	1
Processes	3	1

Architecture

class BlogAgent:
 """1 Process = Flask (webhook) + Scheduler (timer) + LLM Client"""
 
 def __init__(self):
 self.config = AgentConfig.from_credentials()
 self.llm = LLMClient(self.config) # ZAI glm-4.7
 self.api = BlogAPIClient(self.config) # ec1 Blog API
 
 # Handlers
 self.comment = CommentHandler(self.llm, self.config)
 self.translate = TranslateHandler(self.api)
 self.post_gen = PostGenerator(self.llm, self.api)
 
 # Scheduler
 self.scheduler = Scheduler()
 self.scheduler.every(hours=6, task=self.translate.check_and_sync)
 self.scheduler.daily_at(hour=9, task=self.post_gen.generate_and_publish)

Module Operations

1. CommentHandler — AI Comment Response

Receives Webhook events from GitHub Discussions to automatically generate AI comments.

[User Comment] → GitHub Webhook → arm1 Flask → CommentHandler
 → LLM Call (ZAI glm-4.7) → Generate Reply → Post Comment via GitHub API

Trigger: Webhook event-based (real-time)
Filtering: Skips blog owner comments and AI-generated comments.
Security: HMAC-SHA256 Webhook secret verification, Flask-Limiter applied.

2. TranslateHandler — Automatic Translation Trigger

Requests translation synchronization from ec1’s Blog API every 6 hours.

[Scheduler 6h] → TranslateHandler.check_and_sync()
 → POST /translate/sync → ec1 Blog API performs actual translation

arm1 does not perform the translation itself; it only sends a trigger to the ec1 API. The actual translation logic resides in translator.py on ec1.

3. PostGenerator — Automatic Post Generation

Automatically generates technical blog posts every day at 9 AM.

[Scheduler 09:00 KST] → PostGenerator.generate_and_publish()
 → Collect existing topics → Refer to RSS trends → Generate content with LLM
 → Deduplication Check → Publish via Blog API

Deduplication is key. It compares the similarity between new titles and the last 100 existing titles using difflib.SequenceMatcher:

def _is_duplicate_title(self, new_title, existing_titles):
 """Considers it a duplicate if the ratio is >= 0.6"""
 new_lower = new_title.lower().strip()
 for title in existing_titles[-100:]:
 ex_lower = title.lower().strip()
 ratio = difflib.SequenceMatcher(None, new_lower, ex_lower).ratio()
 if ratio >= 0.6:
 return True
 return False

ec1: Blog API Translation System

Transition to Gemini

Initially, translations were performed using ZAI (glm-4.7), but a critical issue arose:

glm-4.7 is a reasoning model, which first consumes its max_tokens budget for reasoning_content (internal thought process). If max_tokens=256, it uses all 256 tokens for reasoning, leaving the actual content as an empty string.

This led to an incident where nine English posts were translated with empty string titles.

Solution: Replaced with Gemini 2.5 Flash Lite.

Item	ZAI (Previous)	Gemini (Current)
Model	glm-4.7 (reasoning)	gemini-2.5-flash-lite
Translation Time	~30s/post	~8s/post
Cost	Paid API	Free (1,500 requests/day)
Empty Response Issue	Occurred	None

OpenAI-Compatible Endpoint

Gemini provides an OpenAI-compatible API. The existing code can be used without any changes by simply switching the base URL:

LLM_BASE_URLS = {
 "GEMINI": "https://generativelanguage.googleapis.com/v1beta/openai",
 "ZAI": "https://api.z.ai/api/coding/paas/v4",
}

Translation Matching Logic

Pairing Korean↔English posts uses date prefix matching:

ko: 2026-05-04-001-개발-생산성-17배-극대화-deepseek-v4와-...
en: 2026-05-04-001-개발-생산성-17배-극대화-deepseek-v4와-...
 ↑ Same prefix = Same post

Although the slugs might differ in language, if the YYYY-MM-DD-NNN part is the same, it’s recognized as the same post. The prerequisite for this method is that no two posts with the same date and number exist.

Title-in-Body Translation Technique

Translating the title via a separate API call caused issues with empty results from the reasoning model. The solution is to include the title as the first line of the body:

# When requesting translation
prompt = f"# {original_title}\n\n{original_body}"

# Extracting the title from the translation result
if translated.lstrip().startswith("# "):
 lines = translated.lstrip().split("\n", 1)
 extracted_title = lines[0].lstrip("# ").strip()
 translated_body = lines[1].lstrip("\n")

This translates the title and body simultaneously in a single API call, preserving context and saving tokens.

LLM Strategy: Role-Based Model Separation

Not all tasks are handled by a single LLM. Models are separated based on the nature of the task.

Task	Server	Model	Reason
AI Comment Response	arm1	ZAI glm-4.7	Conversational, excellent Korean quality
Post Generation	arm1	ZAI glm-4.7	Long-form content generation, creativity required
Translation (ko→en)	ec1	Gemini Flash Lite	Non-reasoning, fast and free

Core Principle: Do not use reasoning models for translation. Reasoning models consume tokens for internal thought processes, making non-reasoning models more suitable for simple conversion tasks.

Monitoring and Operations

Health Check Endpoints

# arm1 agent
curl http://arm1:8081/health
# → {"status":"healthy","agent":"blog-agent","scheduler_jobs":2,"uptime_sec":...}

curl http://arm1:8081/status
# → {"scheduler":[{"name":"auto-translate","last_run":...},{"name":"post-generator","last_run":"2026-05-04"}]}

# ec1 Blog API
curl https://blog.example.com/api/health
# → {"status":"healthy","version":"2.0.0"}

Observability Points

Metric	Normal Range	Alert Condition
arm1 uptime	>0	Service Down
scheduler_jobs	2	≠ 2
Translation Sync	ko post count = en post count	Discrepancy occurs
Post Generation	1 post daily	No posts for over 24 hours

Lessons Learned and Operational Tips

1. The Pitfall of Reasoning Models

It’s often not explicitly stated in documentation that max_tokens combines reasoning and content. If you get an empty response, check the finish_reason—if it’s "length", it indicates insufficient token budget.

2. Value of the OpenAI-Compatible Pattern

When switching translation providers from ZAI to Gemini, the code change was just one line for the base URL. Abstracting to an OpenAI-compatible interface from the start dramatically reduces LLM replacement costs.

3. Constraints of Date Prefix Matching

In the YYYY-MM-DD-NNN pattern, if two or more posts share the same date and number, translation matching will break. The PostGenerator must include logic to check the last number for that date and increment it when generating new posts.

4. Benefits of Process Consolidation

Consolidating three independent services into one resulted in:

State Sharing (LLM clients, configurations, API clients initialized only once)
Simplified Deployment (one systemd unit)
Easier Debugging (logs consolidated in one place)

Future Plans

Review the integration of arm1 agent’s LLM with Gemini.
Comment Quality Evaluation Pipeline (monitoring the appropriateness of auto-generated comments).
Automatic Translation Quality Verification (comparing with back-translation).
Expanding inter-agent collaboration through the AgentForge framework.

Blog automation aims not for “complete automation,” but for “minimal human intervention.” A structure where AI generates content, humans review it, and the system alerts operators to anomalies is the key to stable operation.

Multi-Model AI Agent Team Design: Composed Architecture and 5-Team Hierarchy

Mon, 30 Mar 2026 00:33:34 +0900

Overview

For building a blog system, I designed a multi-model agent team consisting of 14 AI specialists, 5 teams, and 4 LLM models. The core innovations are two:

Composed Agent: Separating role definitions from execution profiles for maximum reusability
Hierarchical Bridge Leadership: Dual membership of tech leads between upper and lower teams to resolve communication bottlenecks

This post covers the final structure, model distribution strategy, and the composed architecture design process.

Background: Why Multi-Model?

Using a single LLM for all tasks creates two problems:

Cost: Running 14 specialists on a Claude Opus-level model makes costs uncontrollable
Fit: Design needs fast reasoning, security analysis needs deep logic, implementation needs stable coding

So we distributed models based on task characteristics.

Final Team Structure

5 teams, 14 specialists, 4 models.

graph TD
 subgraph UPPER["Upper — Steering Team · consensus"]
 ORC["Orchestrator
relay:steering-orchestrator"]
 DES["Architect
gemini:gemini-2.5-flash"]
 SEC["Security Reviewer
codex:gpt-4o"]
 STL["Backend Tech Lead
relay:developer-zai"]
 FTL["Frontend Tech Lead
relay:developer-zai"]
 DTL["Desktop Tech Lead
relay:developer-zai"]
 INF["Infra Network
gemini:gemini-2.5-flash"]
 SAD["Server Admin
relay:developer-zai"]
 end

 subgraph LOWER_BE["Backend Team · leader_decides"]
 BTL["Backend Tech Lead"]
 BDEV["Backend Developer"]
 end

 subgraph LOWER_FE["Frontend Team · leader_decides"]
 FTL2["Frontend Tech Lead"]
 FDEV["Frontend Developer"]
 FUX["UX Designer"]
 end

 subgraph LOWER_DT["Desktop Team · leader_decides"]
 DTL2["Desktop Tech Lead"]
 DDEV["Desktop Developer"]
 DUX["UX Designer"]
 end

 subgraph LOWER_INFRA["Infra Team · leader_decides"]
 SAD2["Server Admin (Leader)"]
 INET["Cloud Network"]
 DBA["DB Architect"]
 end

 UPPER -.->|bridge| LOWER_BE
 UPPER -.->|bridge| LOWER_FE
 UPPER -.->|bridge| LOWER_DT
 UPPER -.->|bridge| LOWER_INFRA

 BTL --> BDEV
 FTL2 --> FDEV
 FTL2 --> FUX
 DTL2 --> DDEV
 DTL2 --> DUX
 SAD2 --> INET
 SAD2 --> DBA

Team Details

Team	Type	Decision-Making	Leader	Members
Steering Team	upper	consensus	Orchestrator	8 (including bridges)
Backend Team	lower	leader_decides	Backend Tech Lead	2
Frontend Team	lower	leader_decides	Frontend Tech Lead	3
Desktop Team	lower	leader_decides	Desktop Tech Lead	3
Infra Team	lower	leader_decides	Server Admin	3

The Infra Team Separation Decision

In the initial design, DB Architect and Server Admin were part of the backend team. But we separated them based on workspace.

graph LR
 subgraph BackendTeam["Backend Team"]
 B["API Code Writing
FastAPI, Python
workspace: VS Code / SSH"]
 end

 subgraph InfraTeam["Infra Team"]
 S["Server Management
Docker, Ubuntu, Nginx
workspace: SSH Terminal"]
 N["Cloud Network
Cloudflare Dashboard
workspace: Web Console"]
 D["DB Management
PostgreSQL, Migrations
workspace: psql / SSH"]
 end

 B -.->|API deployment| S
 B -.->|Query optimization| D

When workspaces differ, separation is more natural than keeping them together.

Model Distribution Strategy

pie title Specialists by Model
 "relay:developer-zai (GLM)" : 10
 "gemini:gemini-2.5-flash" : 2
 "codex:gpt-4o" : 1
 "zai:glm-4" : 1

Model	Specialists	Purpose	Why Chosen
relay:developer-zai	10	Implementation, ops, leads	Cost-effective, stable coding
gemini:gemini-2.5-flash	2	Design, infra network	Fast response, easy external API calls
codex:gpt-4o	1	Security review	High reasoning, OWASP knowledge
zai:glm-4	1	Context compression	Free tier, text summarization specialized

By assigning 10 implementation specialists to GLM, we achieved 60-70% total cost reduction.

Composed Agent Architecture

The core innovation is separating role definitions (Expert) from execution profiles (Definition).

With the traditional approach, role and execution logic are coupled — any change requires a full rewrite, and reuse is impossible.

Composed Approach

graph TD
 DEF["Definition
Backend Developer"]
 DEF --> BASE["Base: backend-core"]
 DEF --> CAP["Capabilities:
rest-api, crud, auth-jwt"]
 DEF --> PLAT["Platform: fastapi"]
 DEF --> POL["Policy: blog-default"]

 BASE --> |"compose"| RUN["Runtime Agent"]
 CAP --> |"compose"| RUN
 PLAT --> |"compose"| RUN
 POL --> |"compose"| RUN

Module Structure

agent-library/
├── definitions/ ← 14 agent definitions
├── modules/
│ ├── base/ ← 6 base modules
│ ├── capabilities/ ← 15 capability modules
│ ├── platforms/ ← 5 platform modules
│ └── policies/ ← 1 policy
└── runs/ ← execution history

Advantages

Reusability: rest-api capability module shared by backend developer and backend tech lead
Platform swap: Change platform: fastapi to platform: django for instant switching
Capability extension: Add a new capability module and connect it to the Definition
Policy unification: All agents follow the same blog-default policy

Expert-Definition Mapping

Expert	Definition	Base	Capabilities	Platform
Backend Developer	backend-developer	backend-core	rest-api, crud, auth-jwt	fastapi
Backend Tech Lead	backend-tech-lead	backend-core	rest-api, crud, code-review	fastapi
Frontend Developer	frontend-developer	frontend-core	markdown-renderer, list-filter-sort	nextjs
Server Admin	server-administrator	server-core	docker-management, nginx-config, postgres-admin	ubuntu
Infra Network	infra-network-admin	infra-core	dns-management, ssl-certificates, rate-limiting	cloudflare
Security Reviewer	security-auditor	specialist-core	security-audit	fastapi
Context Compressor	context-compressor	specialist-core	context-compression	markdown

TLS Certificate Strategy: Cloudflare Origin CA

For production TLS certificates, we chose Cloudflare Origin CA over Let’s Encrypt.

sequenceDiagram
 participant Client as Visitor
 participant CF as Cloudflare (Proxy)
 participant Nginx as Nginx (Origin)
 participant API as FastAPI

 Client->>CF: HTTPS request
 CF->>CF: Terminate with Cloudflare-managed cert
 CF->>Nginx: Encrypt with Origin CA cert
 Nginx->>API: HTTP (local)
 API-->>Nginx: Response
 Nginx-->>CF: Encrypted with Origin CA
 CF-->>Client: Response

Item	Let’s Encrypt	Cloudflare Origin CA
Validity	90 days (renewal required)	15 years (no renewal)
Issuance	ACME automation required	Manual from Dashboard
Complexity	certbot setup	Copy cert files only

Production architecture:

Oracle Cloud ARM (4 OCPU, 24GB)
├── PostgreSQL (installed directly on host)
├── Docker Compose
│ ├── blog-api (FastAPI)
│ ├── blog-frontend (Next.js standalone)
│ ├── MinIO (S3-compatible storage)
│ └── Nginx (Cloudflare Origin CA)
└── Cloudflare Proxy (Full Strict SSL)

Relay Plugin: Agent Invocation Mechanism

The team structure runs in Claude Code through the Relay plugin.

sequenceDiagram
 participant User as User
 participant Claude as Claude Code
 participant Plugin as Relay Plugin
 participant MCP as MCP Server
 participant LLM as External LLM

 User->>Claude: /relay:invoke-agent
 Claude->>Plugin: Load definition by expert slug
 Plugin->>Plugin: Compose Definition (base + capabilities + platform + policy)
 Plugin->>Plugin: Check backed_by

 alt relay:developer-zai
 Plugin->>Claude: Run internal agent
 else gemini:*
 Plugin->>MCP: Call gemini_mcp server
 MCP->>LLM: Gemini API
 LLM-->>MCP: Response
 MCP-->>Plugin: Result
 else codex:*
 Plugin->>MCP: Call codex_mcp server
 MCP->>LLM: OpenAI API
 LLM-->>MCP: Response
 MCP-->>Plugin: Result
 end

 Plugin-->>Claude: Final result
 Claude-->>User: Response

backed_by Namespaces

Namespace	MCP Server	Purpose
`relay:developer-zai`	internal agent	Implementation, ops (low cost)
`relay:steering-orchestrator`	internal agent	Coordination, final decisions
`gemini:gemini-2.5-flash`	gemini_mcp	Design, external APIs
`codex:gpt-4o`	codex_mcp	Security analysis
`zai:glm-4`	zai_mcp	Context compression

Design Decision Log

Decision	Alternative	Rationale
Separate infra team	Include in backend	Different workspaces (SSH vs IDE)
Cloudflare Origin CA	Let’s Encrypt	15-year validity, no renewal
PostgreSQL on host	Docker container	Memory efficiency on single server
Composed agent	Single-definition agent	Module reusability, easy platform swap
Assign many GLM	Assign many Claude	60-70% cost reduction

Retrospective: What I Learned

1. “Executable Structure” over “Perfect Structure”

Trying to design everything perfectly can prevent you from ever starting. It’s better to compromise and improve as you execute.

2. Workspace Defines Team Boundaries

People who write code and people who manage servers have different physical work environments — that’s a natural team boundary.

3. The Value of Composed Architecture

In an environment with 14 specialists, 5 teams, and 4 models interacting, module separation is essential. It minimizes the scope of changes and maximizes reusability.

4. Cost is Determined at Design Time

Asking “does this task really need a high-cost model?” every time naturally optimizes costs.

Next Steps

Start Phase 1 implementation: DB, Auth, Post/Category CRUD, Docker
Share team operation experience: Problems encountered during actual execution
Performance monitoring: Response time per model, cost vs quality analysis

This post summarizes my experience building an AI agent team using Claude Code + Relay plugin. It reflects learnings from applying this to a real project — different approaches may be more suitable depending on your situation.

[blog-api-server] LLM Config Improvement and Deployment

Tue, 03 Mar 2026 13:01:48 +0900

Overview

Improved the LLM configuration for the blog-api-server project and deployed it to the server.

LLM Configuration Improvements

Existing Issues

Multiple API key environment variables (ZAI_API_KEY, ANTHROPIC_API_KEY)
Complex provider branching logic
Scattered model settings

Changes

Environment Variable Simplification

# Before
ZAI_API_KEY=xxx
ANTHROPIC_API_KEY=xxx
ZAI_MODEL=gpt-4o-mini
LLM=ZAI

# After
LLM=ZAI # Provider (ZAI, OPENAI, ANTHROPIC)
LLM_API_KEY=xxx # Single API Key
LLM_MODEL=glm-4.7 # Default model
LLM_TIMEOUT=120 # Timeout (seconds)

Automatic BASE_URL Configuration

LLM_BASE_URLS = {
 "ZAI": "https://api.z.ai/api/coding/paas/v4",
 "OPENAI": "https://api.openai.com/v1",
 "ANTHROPIC": "https://api.anthropic.com/v1"
}

Code Structure Improvements

class Translator:
 """LLM-based translator"""

 def __init__(self):
 self.api_key = LLM_API_KEY
 self.base_url = LLM_BASE_URL # Auto-selected
 self.model = LLM_MODEL
 self.timeout = LLM_TIMEOUT

Model Configuration

Default Model

glm-4.7 (default)
max_tokens: 8192

Supported Models

Model	max_tokens
glm-4	8192
glm-4.7	8192
gpt-4o-mini	4096
gpt-4o	8192
claude-3-5-haiku	8192

Team Composition

Assembled the blog-api-server development team.

Role	Name	Responsibilities
Team Lead	team-lead	Overall management
Developer	developer	Code writing, feature implementation
Deployer	deployer	Server deployment, infrastructure
Monitor	monitor	Log analysis, performance monitoring

Server Deployment

Deployment Target

Server: blog.fcoinfup.com (130.162.133.47)
Path: /var/www/blog-api

Deployment Content

translator.py update
systemd service restart

Deployment Result

● blog-api.service - Blog API Server
 Active: active (running)

Next Steps

Translation API testing
Monitoring dashboard setup
Log file rollover policy application

Korean Version: 한국어 버전

[ZeroClaw] Intro - High-Performance Rust Agent Runtime

Fri, 27 Feb 2026 19:30:00 +0900

Introducing ZeroClaw: High-Performance Rust Agent Runtime

ZeroClaw is a high-performance autonomous agent runtime built in Rust, designed for developers who need speed, efficiency, and reliability in their AI-powered applications.

Key Features

Performance First

Rust-native: Zero allocations where possible
Async/await with Tokio: Efficient concurrent operations
Streaming support: Real-time response streaming

Extensibility

Trait + Factory Architecture: Extend by implementing traits
25+ Built-in Tools: Shell, file ops, memory, browser, HTTP
Plugin-friendly: Add providers, channels, tools without core changes

Security by Default

Sandbox Support: Firejail, Bubblewrap, Landlock, Docker
Pairing Protocol: 6-digit CSPRNG code
Secret Storage: ChaCha20-Poly1305 AEAD encryption

Multi-Platform

20+ Messaging Channels: Telegram, Discord, Slack, WhatsApp, Signal, Matrix
13+ LLM Providers: OpenAI, Anthropic, Gemini, Ollama, Bedrock, OpenRouter

Quick Start

cargo install zeroclaw
zeroclaw config init
zeroclaw run --channel telegram

Architecture

ZeroClaw Agent
├── Providers (OpenAI, Anthropic, Gemini, Ollama)
├── Channels (Telegram, Discord, Slack, WhatsApp)
├── Tools (Shell, File, Memory, Browser, HTTP)
├── Memory (SQLite, PostgreSQL, Markdown)
└── Security (Policy, Sandbox, Secret Store)

Roadmap

Phase 1: Enhanced Multi-Agent (In Progress)
Phase 2: More Integrations
Phase 3: Enterprise Features

Korean Version: 한국어 버전

[LLM] How to Write Effective Prompts

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

Introduction

Writing effective prompts is essential for getting the most out of LLMs (Large Language Models). This article summarizes key principles and practical patterns of prompt engineering.

Core Principles of Good Prompts

1. Clarity

Avoid ambiguous expressions and be specific.

Bad Example:

Write good code

Good Example:

Implement a binary search tree in Python.
Include insert, search, and delete methods,
with time complexity of O(log n).

2. Provide Context

Give background information needed for the LLM to understand the task.

I'm a React beginner.
Explain the difference between useState and useEffect
with example code.

3. Role Playing

Set up responses from a specific expert’s perspective.

You are a senior backend developer with 10 years of experience.
Explain the pros and cons of microservices architecture.

4. Specify Output Format

Explicitly state the desired response format.

Summarize the following in a markdown table:
- Language features
- Pros and cons
- Use cases

Prompt Patterns

Chain of Thought

Guide step-by-step thinking for complex problems.

Let's think through this problem step by step:
1. First analyze the problem
2. Consider solutions
3. Write the final answer

Few-Shot Learning

Provide examples to teach the desired format.

Summarize in the following format:

Input: "The weather is nice today"
Output: Positive, Weather

Input: "The meeting was too long"
Output: Negative, Work

Input: "Started a new project"
Output: ?

Structured Prompts

Divide complex tasks into sections.

## Goal
Design a user authentication API

## Requirements
- Use JWT tokens
- Refresh token rotation
- Apply rate limiting

## Output
1. API endpoint specification
2. Sequence diagram
3. Security considerations

Common Mistakes

Mistake	Problem	Solution
Too long prompts	Key points get lost	Keep it concise
Ambiguous instructions	Unexpected results	Provide specific examples
Missing context	Inaccurate answers	Add background info
Unspecified format	Poor readability	Specify output format

Practical Checklist

Check before writing your prompt:

Is the goal clear?
Included necessary context?
Specified output format?
Stated constraints?
Would examples help?

Conclusion

Good prompts are clear, specific, and provide necessary context. Practice to improve your prompt writing skills.

References

Korean Version: 한국어 버전