Agent on Yarang's Tech Lair

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

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

Mon, 04 May 2026 09:01:31 +0900

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

Recently, an interesting project called DeepClaude was introduced on Hacker News. It is a hybrid architecture that combines DeepSeek V4 Pro with Claude Code’s Agent Loop feature to deliver the same performance at a 17 times lower cost compared to existing solutions.

This article will not merely deliver interesting news but will specifically cover how to build a cost-effective AI coding assistant by integrating Claude Code with DeepSeek V4 in a real development environment. In particular, it provides a comprehensive guide, including how to control GitHub and the file system using MCP (Model Context Protocol).

1. Why DeepSeek V4 and Claude Code?

Claude Code provides a powerful ‘Agent Loop’ feature. This is an automated process where the AI writes code, executes it, fixes errors, and repeats until the goal is achieved. However, the cost burden of continuously using the high-quality Sonnet model is significant.

This is where DeepSeek V4 Pro comes in. DeepSeek V4 is one of the most notable models in the open-source community recently, showing excellent performance not only in complex reasoning capabilities but also in code generation. Above all, its cost-effectiveness is overwhelming.

Core Strategy of the DeepClaude Approach:

Planner: Use the existing Claude model for analyzing tasks and establishing a plan (one-time use).
Worker: Use DeepSeek V4 for the actual code writing and modification loop (Run Loop) (high volume use).

Through this structure, it is possible to reduce the total cost to 1/17th while maintaining the task completion rate.

2. Prerequisites: Configuring the MCP Server Environment

To implement this architecture, the AI must be able to read and write files in the local environment. To do this, we will apply the MCP Server concept covered in the previous post for setup.

2.1. Configuring the MCP Settings File (`mcp_config.json`)

Configure the settings so the AI agent can access the project folder. Create a local mcp_config.json file and write the following content.

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/Projects/DeepAgent"],
 "env": {
 "ALLOWED_DIRECTORIES": "/Users/yourname/Projects/DeepAgent"
 }
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"]
 }
 }
}

filesystem: Specifies the path where the agent will generate and modify code.
github: (Optional) Token environment variables may be required to create GitHub issues or PRs.

3. Implementing the Integration of DeepSeek V4 and Claude Code

Now, let’s implement a Python script that performs tasks by switching between the two models by writing actual code. This script is the core logic of the ‘Hybrid Agent’.

3.1. Installing Dependencies

pip install openai anthropic

3.2. Implementing the Hybrid Agent Code (`hybrid_agent.py`)

This code uses a mix of the Anthropic API and the OpenAI-compatible API (DeepSeek).

import os
import json
from openai import OpenAI
from anthropic import Anthropic

# Configuration: Manage API keys via environment variables
DEEPSEEK_API_KEY = os.getenv("DEEPSEEK_API_KEY")
ANTHROPIC_API_KEY = os.getenv("ANTHROPIC_API_KEY")

def create_hybrid_agent(task_description: str, max_iterations: int = 5):
 """
 Hybrid agent function combining DeepSeek V4 (Worker) and Claude (Planner)
 """
 
 # 1. Initialize Model Clients
 # DeepSeek V4 is accessed via OpenAI SDK (example)
 worker_client = OpenAI(
 api_key=DEEPSEEK_API_KEY,
 base_url="https://api.deepseek.com/v1" # Verify actual endpoint needed
 )
 planner_client = Anthropic(api_key=ANTHROPIC_API_KEY)

 print(f"[System] Task start: {task_description}")
 
 # 2. Request initial plan from Claude (Planner)
 planning_prompt = f"""
 You are a software architect. Please establish a concrete step-by-step plan to perform the following task.
 Task: {task_description}
 
 Please respond only with a step list in JSON format.
 Example: {{"steps": ["Create file", "Implement logic", "Run test"]}}
 """
 
 try:
 message = planner_client.messages.create(
 model="claude-3-5-sonnet-20241022",
 max_tokens=1024,
 messages=[{"role": "user", "content": planning_prompt}]
 )
 plan_text = message.content[0].text
 print(f"[Planner] Plan established: {plan_text}")
 except Exception as e:
 print(f"[Error] Failed to establish plan: {e}")
 return

 # 3. Execute DeepSeek V4 (Worker) Loop
 current_context = f"Task Goal: {task_description}\nPlan: {plan_text}"
 
 for i in range(max_iterations):
 print(f"\n--- Loop {i+1}/{max_iterations} (Worker: DeepSeek V4) ---")
 
 try:
 response = worker_client.chat.completions.create(
 model="deepseek-chat", # DeepSeek V4 model name
 messages=[
 {"role": "system", "content": "You are a professional developer who writes and modifies code according to the plan."},
 {"role": "user", "content": current_context}
 ],
 temperature=0.3
 )
 
 worker_output = response.choices[0].message.content
 print(f"[Worker] Execution Result:\n{worker_output[:500]}...\n") # Summarize output
 
 # (In actual implementation, call MCP tools here to write files or execute commands)
 # file_system_tool.write_file(path="main.py", content=worker_output)
 
 # Check termination condition (e.g., "TASK_COMPLETE" keyword)
 if "Done" in worker_output or "TASK_COMPLETE" in worker_output:
 print("[System] Task completed successfully.")
 break
 
 # Update context for feedback loop
 current_context += f"\n\nPrevious Attempt Result:\n{worker_output}\n\nPlease continue or fix errors."
 
 except Exception as e:
 print(f"[Error] Error occurred during Worker execution: {e}")
 break

# Execution Example
if __name__ == "__main__":
 create_hybrid_agent(
 task_description="Create a Next.js API handler to generate a /hello endpoint, and include TypeScript type validation."
 )

3.3. Code Explanation

Planner (Claude): Uses the anthropic library to analyze user requirements and define the order of tasks. Since this process occurs only once, using a high-cost model has little impact on the total cost.
Worker (DeepSeek V4): Calls the DeepSeek API via the openai library. It loops max_iterations times to generate code and repeatedly modifies it based on virtual feedback (or actual execution results). This is the part that consumes the most tokens.

4. Troubleshooting and Tips

1. DeepSeek API Compatibility: DeepSeek V4 Pro is currently often provided in a way compatible with the OpenAI SDK, but you may need to configure the Base URL (e.g., https://api.deepseek.com). Please check the official documentation.

2. Context Window: DeepSeek models usually support a long context window of 128k or more. This is very advantageous for analyzing long codebases or maintaining conversation history. Even if the context lengthens as the loop runs, there is little performance degradation.

3. MCP Integration: The Python code above is a simple example. In reality, you must communicate with the server defined in mcp_config.json to access the file system. To do this, you need to implement client logic that communicates with the MCP server via stdio inside hybrid_agent.py to enable full automation.

5. Conclusion: Balancing Cost and Performance

For developers, AI is becoming not just a simple chat window but an ‘Acting Agent’. However, indiscriminately using GPT-4o or Claude Sonnet without regard for cost is not realistic.

The hybrid strategy of placing a high-performance open-source model like DeepSeek V4 as the ‘Worker’ and utilizing a high-cost model as the ‘Planner’ is likely to become the standard pattern for future AI agent development.

Test the code above right now and add 17x efficiency to your development workflow.

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.

[Claude Code] Team Agent Communication Architecture

Sat, 28 Feb 2026 14:07:38 +0900

Claude Code Team Agent Communication Architecture Design

Overview

When multiple AI agents collaborate in Claude Code, an efficient communication method is needed. This article shares the communication architecture designed while building a Discord-integrated server monitoring team.

Problem Definition

Claude Code has two types of agents:

Python Processes (Daemon)
- Discord Gateway, user_comm_daemon, etc.
- Always running, filesystem access available
LLM Agents (Created as Tasks)
- gcp-monitor, oci-monitor, alert-manager, etc.
- Use SendMessage tool, Claude Code native communication

Communication between these two types was needed.

Considered Approaches

1. File-based Message Queue (Existing)

Pros: Simple implementation, no dependencies
Cons: Latency (~1s), file management required

2. WebSocket

Pros: Real-time bidirectional communication
Cons: Server/client implementation required

3. gRPC

Pros: Strong type checking, streaming
Cons: proto file management, high complexity

4. SQLite Message Hub (Adopted)

Pros: Fast (~10ms), transactions, no additional dependencies
Cons: Works only on a single machine

Final Architecture

┌─────────────────────────────────────────────────────────────────┐
│ SQLite Message Hub (messages.db) │
│ ~/.claude/teams/{team}/messages.db │
└───────────────────────────┬─────────────────────────────────────┘
 │
 ┌───────────────────┼───────────────────┐
 ↓ ↓ ↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Discord │ │ Python │ │ LLM │
│ Gateway │ │ Daemon │ │ Agent │
│ (Direct Access)│ │ (Direct Access)│ │ (MCP Tool) │
└──────────────┘ └──────────────┘ └──────────────┘

SQLite Message Hub Structure

Messages Table

CREATE TABLE messages (
 id INTEGER PRIMARY KEY AUTOINCREMENT,
 message_id TEXT UNIQUE NOT NULL,
 sender TEXT NOT NULL,
 recipient TEXT, -- NULL = broadcast
 message_type TEXT DEFAULT 'message',
 content TEXT NOT NULL,
 priority TEXT DEFAULT 'normal',
 metadata TEXT DEFAULT '{}',
 status TEXT DEFAULT 'pending',
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
 processed_at TIMESTAMP,
 expires_at TIMESTAMP
);

Agent Status Table

CREATE TABLE agent_status (
 agent_name TEXT PRIMARY KEY,
 status TEXT DEFAULT 'offline',
 last_heartbeat TIMESTAMP,
 metadata TEXT DEFAULT '{}'
);

Communication Methods

LLM Agent ↔ LLM Agent

Use SendMessage (Claude Code native)
Auto-managed, idle notification provided

Python ↔ LLM Agent

SQLite Hub + MCP Tool
Python accesses SQLite directly
LLM Agent accesses via MCP Tool

MCP Server Implementation

MCP tools for LLM Agents:

@server.list_tools()
async def list_tools():
 return [
 Tool(name="team_send_message", ...),
 Tool(name="team_read_messages", ...),
 Tool(name="team_broadcast", ...),
 Tool(name="team_get_status", ...),
 Tool(name="team_update_status", ...),
 ]

Message Flow Example

1. Discord user: "Hello"
 ↓
2. Discord Gateway → SQLite: INSERT message
 ↓
3. user_comm Daemon → SQLite: SELECT pending
 ↓
4. user_comm → SQLite: INSERT response
 ↓
5. Discord Gateway → SQLite: SELECT response
 ↓
6. Discord channel: "Hi there! 👋"

Performance Comparison

Method	Latency	Stability	Complexity
File-based	~1000ms	Medium	Low
WebSocket	~5ms	High	Medium
SQLite	~10ms	High	Low

Conclusion

The SQLite Message Hub + MCP Server combination was most suitable for Claude Code team agent communication:

Low Latency: 100x faster than file-based
Stability: Data integrity guaranteed through transactions
Simplicity: Uses Python’s built-in sqlite3 without additional dependencies
Flexibility: Both Python and LLM Agents use the same data source

Code

Core components:

message_hub.py: SQLite Message Hub
team_comm_mcp_server.py: MCP Server
discord_gateway.py: Discord integration gateway
user_comm_daemon.py: Message processing daemon

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: 한국어 버전

[Multi-Agent] Communication Platform Design

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

Introduction

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

1. Architecture Overview

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

Multi-Agent Architecture

Core Components

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

2. Communication Protocol Design

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

Message Protocol

Communication Flow

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

3. Message Structure

Design scalable and type-safe message structures.

Message Structure

Message Envelope

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

Message Types

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

4. Agent State Management

Each agent has a clear state machine.

State Management

State Transitions

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

State Behaviors

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

5. Communication Patterns

5.1 Request-Response

Synchronous 1:1 communication pattern.

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

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

Asynchronous 1:N communication pattern.

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

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

5.3 Broadcast

Used to send notifications to all agents.

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

6. Core Design Principles

6.1 Loose Coupling

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

6.2 Fault Tolerance

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

6.3 Scalability

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

6.4 Observability

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

7. Implementation Considerations

7.1 Message Serialization

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

7.2 Backpressure

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

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

7.3 Dead Letter Queue

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

8. Conclusion

Key elements of a multi-agent communication platform include:

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

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

References

Korean Version: 한국어 버전

Agent on Yarang's Tech Lair

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

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

Semble’s Approach: Separating Structure and Meaning

ZeroClaw Integration: Implementing a High-Performance Indexer

1. Defining Data Structures

2. Indexing Logic (Parsing)

3. Search Interface for MCP Tools

Performance Comparison and Token Saving Effect

Conclusion: Optimization for the Agent Ecosystem

References

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

Maximizing Development Productivity by 17x: Building a Low-Cost AI Agent Loop with DeepSeek V4 and Claude Code

1. Why DeepSeek V4 and Claude Code?

2. Prerequisites: Configuring the MCP Server Environment

2.1. Configuring the MCP Settings File (mcp_config.json)

3. Implementing the Integration of DeepSeek V4 and Claude Code

3.1. Installing Dependencies

3.2. Implementing the Hybrid Agent Code (hybrid_agent.py)

3.3. Code Explanation

4. Troubleshooting and Tips

5. Conclusion: Balancing Cost and Performance

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

Overview

Background: Why Multi-Model?

Final Team Structure

Team Details

The Infra Team Separation Decision

Model Distribution Strategy

Composed Agent Architecture

Composed Approach

Module Structure

Advantages

Expert-Definition Mapping

TLS Certificate Strategy: Cloudflare Origin CA

Relay Plugin: Agent Invocation Mechanism

backed_by Namespaces

Design Decision Log

Retrospective: What I Learned

1. “Executable Structure” over “Perfect Structure”

2. Workspace Defines Team Boundaries

3. The Value of Composed Architecture

4. Cost is Determined at Design Time

Next Steps

[Claude Code] Team Agent Communication Architecture

Claude Code Team Agent Communication Architecture Design

Overview

Problem Definition

Considered Approaches

1. File-based Message Queue (Existing)

2. WebSocket

3. gRPC

4. SQLite Message Hub (Adopted)

Final Architecture

SQLite Message Hub Structure

Messages Table

Agent Status Table

Communication Methods

LLM Agent ↔ LLM Agent

Python ↔ LLM Agent

MCP Server Implementation

Message Flow Example

Performance Comparison

Conclusion

Code

[ZeroClaw] Intro - High-Performance Rust Agent Runtime

Introducing ZeroClaw: High-Performance Rust Agent Runtime

Key Features

Performance First

Extensibility

Security by Default

Multi-Platform

Quick Start

Architecture

Roadmap

[Multi-Agent] Communication Platform Design

Introduction

1. Architecture Overview

Core Components

2. Communication Protocol Design

2.1. Configuring the MCP Settings File (`mcp_config.json`)

3.2. Implementing the Hybrid Agent Code (`hybrid_agent.py`)