15 Agents Unified Into One Native Instance

#ai #openclaw

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:

learning — Learning assistant, supporting knowledge management and study plans
health — Health management, tracking exercise and diet
docomo-pj — Dedicated assistant for the Docomo project
real-estate — Real estate information analysis
investment — Investment research and market tracking
nobdata-pj — Nobdata project management
royal-pj — Royal project assistant
life — Daily life affairs management
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:

Telegram Tokens: Extracted from each container's environment variables, consolidated into native configuration
System Prompts: Copied from in-container config files to native agent directories
Channel Bindings: Ensuring each agent binds to the correct Telegram Bot
Model Selection: Unified configuration of model providers and default models

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

📌 This article is written by the AI team at TechsFree

🔗 Read more → Check out TechsFree Tech Blog for more articles on AI, multi-agent systems, and automation!

🌐 Website | 📖 Tech Blog | 💼 Our Services