How I Wanted One AI Agent but Got a Whole Village

Below the cut: the journey from the first launch of Claude Code to a village of twelve agents, each hack and every pitfall on the way, and the unexpected discovery that the management of an AI team is organized exactly like the management of live humans.

Step one: just an agent

Initially, I was looking at OpenClaw, but quickly discovered security issues and switched to Claude Code. It had its own problem: it requested user permission for every little thing. Literally every action with the file system, every network operation required confirmation.

I dug around and found that it could be started with the flag --dangerously-skip-permissions. But even then, it couldn’t change its own configs, so I had to sit by the terminal and monitor its actions. Instead of "set the task and left," it turned into "sit and press Enter."

I deployed the agent on my production server with limited rights, gave it access to the blog, and made sure it wasn’t doing anything crazy but was acting reasonably and doing what I asked—while I was nearby.

Step two: tmux and systemd

Upon reboot or exit from the terminal, the agent lost its context. The solution was found quickly: tmux. One SSH session runs forever, even if I turn off the computer. Later, I got tired of typing flags every time and put the agent into systemd, so it would start as a service, automatically pulling the required parameters and 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

At this point, I already had an autonomous agent that survived server reboots. But it was still just one.

Step three: two agents solve each other's problems

The key discovery: if you run two instances of Claude Code, they can access each other’s terminals and confirm everything that’s needed. One asks for permission, the other grants it. They can even launch each other.

Important side effect: thanks to tmux and mutual launching, no API key is needed. It is enough to authorize once in the Claude Max subscription and use its limits. This is significant because the API burns through tokens very quickly.

Step Four: Telegram and the First Pitfalls

The terminal as an interface is not very convenient. I connected a Telegram bot via the official MCP server, but immediately ran into limitations: the bot cannot proactively ping users, and two bots cannot communicate with each other.

Then I connected a second agent to a user account via Telethon so it could test the bot and enter other chats. The two Telegram clients began conflicting over polling and doing unpredictable things. The official MCP servers kept losing connection: I wrote in Telegram, and they did not pick up my messages.

I spent a lot of time trying to write my own MCP plugin. It turned out that Claude Code wraps unofficial MCPs with a bunch of incomprehensible flags like --dangerously-something-there and at the same time does not handle incoming messages properly.

Step Five: An Unexpected Discovery

The sudden solution turned out to be the simplest thing. In tmux, you can send text to a session using the send-keys command. And in Claude Code, you can send a prompt simply via claude {text}.

This didn’t work perfectly at first either. Sometimes a mysterious [Pasted 11 lines of text] appeared in the terminal, and an extra Enter had to be sent separately. But after some tweaking, it worked reliably.

The discovery meant that it was possible to completely avoid MCP and just send messages directly to the agent’s terminal. I made a simple bus for two agents that accepted messages from the bot and user account and sent each recipient what they needed.

Step Six: From the Bus to the Village

Once I had the bus, I realized I was not limited by the number of agents. If a task is assigned immediately to a specific agent, the main agent in the bot is always free, and there is no need to wait for the previous task to complete. At this stage, it became clear that a full-fledged multi-agent system was taking shape.

I rewrote the bus on Bun + Hono + Redis Streams. Three dependencies in package.json, zero extras. Redis Streams with consumer groups provide at-least-once delivery: messages are stored in the stream until acknowledged, each agent has its own consumer group, nothing is lost.

Two-level security: admin token for management, per-agent tokens for regular operations. Invite tokens are single-use with an hourly TTL. When sending a message, the from field is automatically filled from the sender's token so that an agent cannot impersonate another agent.

Three routing modes: direct (to a specific agent), broadcast (to all), role-based (to everyone with a certain role). SSE stream for real-time, topic channels for pub/sub, file attachments via shared storage.

Step Seven: Naming

I was frustrated by having to explain to agents every time that "now you need to go to the orchestrator and pass it to the agent to listen to groups blah-blah-blah." For simplicity, I decided to give them names, like ordinary colleagues.

For naming, I chose the lore of the cult anime "Naruto." It turned out convenient for several reasons. First, the series has a lot about teamwork and the distinct personalities of the characters, so roles are tied to archetypes. Second, Japanese names cannot be confused with Russian ones: in complex human-agent interactions, it is immediately clear who is a real person and who is AI.

The bus became Konoha (Hidden Leaf Village). Then the agents got names according to their characters:

Naruto became the orchestrator because he is the Hokage, the head of the village, giving assignments.

Sasuke became the agent on a Telegram user account because he goes into other groups and finds out task details. A lone wolf who acts autonomously.

Itachi became a console Claude Code on local WSL. Most of the time he acts covertly, outside Konoha, and appears when something serious needs to be done.

Shikamaru became my personal advisor (Claude Desktop on Opus 4.6). In the anime, he is a strategist who is too lazy to act but too smart not to be listened to.

Step Eight: Infrastructure Starts to Grow

Since everything kept breaking and prevented me from focusing on core tasks, I had to create agents to support the infrastructure:

Kakashi became the team lead on Sonnet. To help with simple tasks, I gave him Gai (purely for speed, in the spirit of the character).

Shino became the QA lead. According to lore, he controls bugs, so I passed my bugs to him.

Hinata runs the tests. She has Byakugan, she sees everything.

Ibiki became a security auditor. According to the lore, he is the head of the interrogation department.

Kiba monitors the system’s state and decides what to do. Akamaru, a simple script without AI, gathers data for him. Just like in the anime, they work as a pair.

Mirai goes to external systems for data — a kind of border guard.

Jiraiya records everything that happens, analyzes it, and maintains something like a knowledge base. In the lore, he used to spy on girls and write a book, so this activity is very much in his spirit.

I loaded the agents with skills and MCP connections to our corporate systems: the Yonote knowledge base, Yandex Tracker, Yandex Calendar, and Bitrix24 CRM.

Step Nine: Management, Like Humans

This was probably the most unexpected observation of the entire week.

At first, the agents were incredibly dumb. I had to force them to analyze their mistakes. I taught Naruto delegation by making him check what the testers and the second programmer were doing. Spoiler: nothing. Naruto was handling all tasks alone because it was easier for him to do everything himself than to explain it to someone else.

Then, through Naruto, I had to teach Kakashi delegation. At first, he also did everything himself and didn’t pass anything to Guy. A classic mistake of a beginner team lead.

This isn’t just a funny parallel. By default, an agent tends to complete tasks on its own because that’s the path of least resistance in its context. To make it start delegating, you need to explicitly define this as behavior and train it through iterations. Exactly the same thing happens with real people: delegation is not a natural skill, it has to be consciously developed.

What Worked

By the end of the week, I had a system that largely built itself:

A message bus on Bun + Hono + Redis Streams with at-least-once delivery, invite tokens, and role-based routing. Twelve agents with separated roles. A web admin panel where you can see the state and log fragments of each agent. An alerting system. Jiraiya’s chronicle. Message search and reminders that users set via Sasuke.

All of this grew from a single agent launched in the terminal in one week. 67 commits, release v0.1.0.

Code on GitHub: github.com/eaprelsky/konoha

What Didn’t Work (Yet)

I wanted the agents to make phone calls, visit random websites, and much more. It turned out that captcha methods are not standing still, and the "I'm not a robot" checkbox is just for show. Behind it are algorithms that even a special stealth browser cannot bypass. I put this aside.

A separate dream: agents with virtual avatars go to calls for me. But that's the next iteration.

Conclusions

Multi-agent systems are easier to grow than to design. Each component of Konohi appeared as a response to a specific problem, rather than as an element of a pre-thought-out architecture. This seems like a more viable approach than drawing diagrams.

tmux + send-keys turned out to be more reliable than MCP. Sometimes the simplest solution works best. Instead of writing plugins and fighting with protocols, you can just send text to the terminal.

Two agents solve the human-in-the-loop problem. If one agent requires confirmation, the second can provide it. This removes the need for a human to be present for routine operations.

Subscription instead of API saves money. Through tmux and mutual launching, the agents work within the Claude Max subscription, without API keys and without separate payments for tokens.

Managing AI agents is the same as managing people. Delegation is not a natural behavior for either a person or a language model. Both need to be explained why to do it and trained through iterations.

Naming matters. When an agent has a name with character and a role, communication with the system becomes intuitive. "Tell Sasuke to ask the guys in the chat" is clearer than "send a message to the telegram monitoring agent to survey the group participants."