Multi-agent system on Claude Code: deployment

From a Single AI Agent to a Multi-Agent System: Real-World Deployment

The developer started with Claude Code to automate tasks on a production server. The challenge? Constant permission requests for file and network operations. The --dangerously-skip-permissions flag helped, but the agent couldn’t edit configurations autonomously.

Autonomy was achieved using tmux to preserve sessions and systemd for automatic startup. A systemd service file ensured restarts after failures and loaded context from files:

[Unit]
Description=Claude Code Agent
After=network.target

[Service]
Type=simple
User=ubuntu
ExecStart=/usr/local/bin/claude --dangerously-skip-permissions ...
Restart=always
RestartSec=5

The agent with limited permissions handled blog tasks but remained isolated.

Agent Collaboration to Bypass Limitations

Two instances of Claude Code solved the confirmation bottleneck: one requested actions, the second confirmed them via tmux. This eliminated reliance on human-in-the-loop approval and API keys. The Claude Max subscription covers usage limits without consuming tokens on API calls.

Integration with Telegram revealed conflicts: the official MCP server didn’t support proactive messages, and Telethon caused polling issues. The solution? A tmux-based bus using send-keys and direct claude {text} commands for prompt delivery.

Message Bus as the Foundation for Scaling

A message bus built on Bun + Hono + Redis Streams enabled at-least-once delivery through consumer groups. Each agent has its own group, and messages are retained until acknowledged.

Security:

• Admin tokens for management.
• Per-agent tokens for operations.
• Invite tokens with 1-hour TTL, single-use.

Routing:

• Direct — to a specific agent.
• Broadcast — to all agents.
• Role-based — by role.

Supports SSE for real-time updates, pub/sub over topic channels, and attachments via shared storage. The from field is auto-populated from the token.

Role Assignment Using Naruto Archetypes

Agents were named after characters from the Naruto lore to clarify roles and distinguish them from human operators:

• Naruto: Orchestrator, assigns tasks.
• Sasuke: Telegram user account, monitors groups.
• Itachi: Console-based Claude Code on WSL for complex tasks.
• Shikamaru: Strategic advisor on Claude Desktop Opus.

Infrastructure agents:

• Kakashi (Sonnet): Team lead.
• Gai: Handles quick tasks.
• Shino: QA lead.
• Hinata: Tests.
• Ibiki: Security audits.
• Kiba + Akamaru: Monitoring.
• Mira: Access to external systems.
• Jiraiya: Logs and knowledge base.

Integrations: Yonote, Yandex Tracker, Yandex Calendar, Bitrix24.

Training Delegation in a Multi-Agent Environment

Initially, agents performed tasks independently, ignoring delegation. Iterative prompt engineering developed delegation skills:

• Naruto checks team readiness before assigning tasks.
• Kakashi delegates simple jobs to Gai.

Behavior mirrors human management: delegation requires explicit training, as self-execution is the path of least resistance for LLMs.

Final Architecture and Limitations

System: 12 agents, web admin panel with logs, alerts, message search, reminders. Self-built in one week, 67 commits.

Not implemented: phone calls, bypassing captchas, avatars for video calls.

Key Takeaways:

• Multi-agent systems grow organically from solving real problems.
• tmux + send-keys outperforms MCP protocols.
• Mutual agent confirmation removes human-in-the-loop dependency.
• Claude Max subscription reduces API costs.
• Delegation needs iterative training—just like humans.

— Editorial Team