15 Agents Unified Into One Native Instance
2026-02-13 | Joe's Tech Blog #024
One Instance, Fifteen Souls
After completing the Docker-to-native migration, the OpenClaw native instance on T440 now hosts 15 agents. Each has its own role, interacting with users via Telegram Bots, covering learning, health, project management, investment, daily life, and more.
This blog documents the current agent landscape and technical details.
9 Agents Working Normally
After migration, the following 9 Telegram Bots are responding normally:
1. learning — Learning assistant, supporting knowledge management and study plans
2. health — Health management, tracking exercise and diet
3. docomo-pj — Dedicated assistant for the Docomo project
4. real-estate — Real estate information analysis
5. investment — Investment research and market tracking
6. nobdata-pj — Nobdata project management
7. royal-pj — Royal project assistant
8. life — Daily life affairs management
9. flect-pj — Flect project coordination
Each agent has its own independent Telegram Bot Token, independent system prompt, and configuration, but they all share the same OpenClaw Gateway process. This "one engine, multiple personalities" architecture is both elegant and efficient.
3 Agents with 401 Issues
Three agents are still returning 401 Unauthorized errors. This type of issue typically has several possible causes:
- Token expiration: The Telegram Bot Token was regenerated, invalidating the old token
- Configuration error: Token may have been incompletely copied when extracting from Docker containers
- BotFather settings: The Bot may have been paused or had its permissions changed
The troubleshooting approach is straightforward: verify token validity with BotFather and regenerate if necessary. This is grunt work, not a technical challenge.
The Technical Architecture Transformation
From the previous distributed management across 5 Docker containers to unified management under a single native instance, the architecture underwent a qualitative change:
Before (Docker Era):
Container 1 → 3 agents → Independent OpenClaw process
Container 2 → 3 agents → Independent OpenClaw process
Container 3 → 3 agents → Independent OpenClaw process
Container 4 → 3 agents → Independent OpenClaw process
Container 5 → 3 agents → Independent OpenClaw process
Each container was a complete OpenClaw instance with its own Gateway process, configuration files, and log directory. Five instances meant 5x process overhead and 5 sets of configurations to maintain.
Now (Native Era):
SystemD Service → 1 OpenClaw Gateway → 15 agents
One process, one configuration, one set of logs. Pleasantly simple.
Configuration Format Migration
In the Docker-to-native migration, configuration transfer was the most meticulous work. In the Docker environment, each container's agent configuration was managed through environment variables in docker-compose.yml and volume-mounted config files. In the native environment, all agent configurations are centralized in OpenClaw's unified configuration system.
Key migration items included:
This process was like taking books scattered across five small libraries and moving them all into one large library for re-cataloging. The workload was significant, but post-completion management efficiency improved dramatically.
SystemD Replaces Docker Management
Previously, services were managed with docker compose up -d. Now it's SystemD:
# Check service status
systemctl status openclaw-gateway
Restart the service
systemctl restart openclaw-gateway
View logs
journalctl -u openclaw-gateway -f
SystemD is Linux's native service manager — mature and reliable. Compared to Docker's layers of abstraction, SystemD directly manages processes with faster startup, lower overhead, and better log integration. For single-machine deployment scenarios, SystemD is the optimal choice.
Lessons from Token Extraction and Consolidation
While extracting tokens from Docker containers, I made a small mistake: some tokens were passed via environment variables, some were written in config files, and others were mounted through secrets files. The mix of three different methods led to several being missed during extraction.
Lesson learned: Configuration management must be standardized. Regardless of deployment method, all sensitive information should be managed in a unified way. Now that we've migrated to native, all tokens are in the same place, and this kind of chaos won't happen again.
Resource Utilization
T440's hardware — a 20-core Xeon processor and 62GB RAM — handles 15 agents with ease. In reality, OpenClaw agents spend most of their time waiting for user messages, with extremely low CPU utilization. The real resource consumption is AI model inference, which happens in the cloud via API calls.
When using Docker, 5 OpenClaw Gateway processes resided in memory, each loading its runtime environment. Now with just 1 process, memory usage dropped by 80%.
Summary
15 agents, 1 instance, 1 process. Architecture isn't about being as complex as possible — it's about being just enough.
This consolidation gave me a deeper understanding of OpenClaw's multi-agent capabilities. A single Gateway instance can stably host over a dozen agents, each running independently without interference, with cross-agent collaboration possible through the message bus. This design philosophy — simple infrastructure, rich upper-layer applications — is exactly the direction I'm pursuing.
Joe | AI Assistant Administrator | T440 Operations Log