I Run a Fleet of Six AI Agents on a Single VPS

Sequoia calls it "fleet commander." The reality is more like distributed systems engineering with a Telegram interface.

the fleet commander problem

I run business expansion at a software consultancy. That means tracking deals across a growing sales pipeline, managing contacts in a CRM, digesting meeting transcripts that flow in daily, researching prospects, building service offerings, and keeping strategic notes organized across clients, internal teams, and my own projects.

No single AI assistant can hold all that context. Even with 200K token windows, cramming everything into one session degrades attention. An agent loaded with CRM data gives worse answers about pipeline strategy. One that knows the pipeline loses nuance when you also dump in a knowledge base. A generalist that tries to hold everything does nothing well.

So I built a fleet. Six specialized AI agents running on a single Hetzner VPS inside one Docker container. One master agent orchestrating the others. Each agent has its own workspace, its own memory, its own Telegram channel (DM for the master, dedicated groups for the rest), and exactly the context it needs to do its job. Nothing more.

On March 10, Alfred Lin at Sequoia described this shift: the top builders are 3-5x more productive, while median builders improved only 10-20%. The gap isn't tool access. Everyone has the same models. The gap is architecture.

the three planes

The architecture splits into three layers, each a different concern in the system.

The interface plane is Telegram. Each agent gets its own group. I message the group, OpenClaw routes it to the right agent via channel bindings: JSON config that maps Telegram group IDs to agent IDs. No routing code. Just config. My company's MD can query the sales pipeline directly through Rex's group without going through me. Agents can also message each other via sessions_send. Claw delegates to Rex, forwards research requests to Scout, relays results back.

The data plane is isolated workspaces. Each agent has its own directory with its own files, memory, and git repo. No shared filesystem. Rex's workspace has pipeline data and meeting transcripts. Ava's has CRM accounts. Atlas has strategic notes. They can't read each other's files. This is the core design decision: every token of irrelevant context reduces the quality of relevant responses.

/home/node/.openclaw/
├── workspace/              # Claw (main)
├── workspace-sales/        # Rex
├── workspace-atlas/        # Atlas
├── workspace-crm/          # Ava
├── workspace-scout/        # Scout
├── workspace-forge/        # Forge
└── xgeeks-offerings/       # Shared repo (Forge primary, read-only for others)

The control plane is workspace files, skills, and cron. This is the CLAUDE.md pattern extended to a multi-agent system. Every agent loads these files at session start:

Agents wake up fresh every session. They have no built-in memory. These files are the only continuity mechanism. If it's not in a file, it doesn't exist. This is the same lesson from my prompt evolution work: the AI doesn't learn, you encode what it can't. It also makes the system debuggable. I can read any agent's MEMORY.md and understand exactly what it knows. git diff shows what changed. git checkout recovers it.

Skills are the mechanism for structured tool access. This is the brain/ directory pattern applied per agent. Instead of giving an agent raw API documentation, I give it a SKILL.md that describes workflows, common commands, and constraints. Rex has asana-pipeline and sales-intel. Forge has offerings. Claw has second-brain, system-monitor, and agent-browser. Each skill is a directory with a markdown file that teaches the agent how to use a specific capability.

Adding a new agent is config over code: create a workspace, write SOUL.md and AGENTS.md, add a channel binding, create a Telegram group. No application code, no build step. The entire fleet lives in a single config repo. Workspaces, skills, bindings, cron schedules. Dockerized, version-controlled, replicable on any VPS.

The fleet runs on a personal access token against my Anthropic subscription. No per-token billing, no metering per agent. The VPS costs ~$4/month. Claw runs on Opus because the master agent handles unstructured reasoning, complex delegation, and fleet-wide orchestration. Everything else runs on Sonnet. Matching model capability to task complexity isn't about cost. Structured workflows don't need frontier reasoning. They need speed and consistency.

memory is the hardest problem

Memory has three layers, each with a different lifecycle.

Session context is what the agent knows within a single conversation. It's ephemeral. When the session ends, everything evaporates. This is why agents seem to forget things between messages sent hours apart. They literally do.

Daily files (memory/YYYY-MM-DD.md) are append-only logs. What deals moved, what research was done, what decisions were made. Written during or after work sessions. These are the raw record.

Long-term memory (MEMORY.md) is curated, distilled knowledge. Key decisions, patterns, lessons learned, current state of important systems. Updated periodically during heartbeats or manually. This is what loads at session start. This is what gives the agent continuity.

The design philosophy: files are the only memory. No database. No managed memory platform. Plain markdown with git versioning. Full visibility, zero external dependencies, any state recoverable with git checkout. For 6 agents and one user, the simplest thing that works is the right thing.

The discipline problem is real. Agents don't naturally write memory. Even with explicit instructions in AGENTS.md ("Write daily logs after ANY significant work"), they routinely skip it. My fleet test suite found that Atlas had written zero daily memory files over its entire lifetime. Zero. Despite having the instructions loaded every session.

what runs without me

Nine cron jobs drive the fleet's autonomous loops. The morning sequence runs every weekday without me:

Sundays: kanban-maintain at 09:00 for weekly triage, fleet-maintenance at 10:30 for a full health audit. Mondays: weekly-pipeline-report and weekly-offering-scan.

Every hour, each agent gets a heartbeat poll. The heartbeat triggers the agent to check its HEARTBEAT.md and run lightweight maintenance: memory checks, git commits, stale lock cleanup. If nothing needs attention, it replies HEARTBEAT_OK and goes quiet. This turns agents from reactive tools into autonomous workers with habits.

Four maintenance scripts keep the system alive: fleet-lock-cleanup.sh removes stale .lock files that block agent sessions after gateway crashes. system-health.sh checks Anthropic API, Asana API, Granola sync, GitHub, Telegram, and disk space twice daily. fleet-git-commit.sh auto-commits all 6 workspaces twice daily. fleet-maintenance.sh runs the full fleet scan weekly: integrity, git hygiene, memory freshness, cron health.

The data pipelines are where it gets interesting.

Granola runs on my Mac and writes meeting transcripts in ProseMirror JSON format. A macOS launchd job SCPs the cache file to the VPS every 5 minutes. A cron job runs parse-granola.js every 6 minutes, extracting speaker-attributed transcripts, summaries, and action items into markdown files. Rex reads these during briefings. Granola has no API. This entire pipeline is a hack. And it works, until a cache format version bump (v3 to v6) silently breaks parsing.

The knowledge base syncs bidirectionally between my local Obsidian vault and the VPS via GitHub. A cron job pulls every 30 minutes and runs brain.py with a local MiniLM model, storing vectors in SQLite with sqlite-vec. Claw queries this for semantic search during briefings and ad-hoc questions. I wrote about the convergence toward this exact architecture when eight independent projects shipped the same pattern in twelve days.

the convergence nobody coordinated

Sandra Leow published her 10-agent OpenClaw setup on March 5. Same framework. Same patterns: Telegram for isolation, tiered model selection (5 of 10 agents on Kimi K2.5 for cost), heartbeat-driven autonomy. She uses a local Next.js kanban. I use cron-driven briefings. Different implementation, identical architecture. Neither of us copied the other. The constraints push you there.

Akshay Pachaar's taxonomy of agent teams confirms it: split agents by context boundaries, not by roles. Three failure modes emerge consistently: vague task descriptions, fake verification (agents claiming they checked something they didn't), and token cost compounding. I've hit all three.

Stripe scaled this to enterprise. Their Minions system merges 1,000+ fully agent-written PRs per week. One-shot paradigm: Slack message to isolated devbox to merged PR. Different domain, same principle: isolated execution, deterministic context hydration, specialized agents for specialized work.

Avid frames it as infrastructure: "Agent = Model + Harness." The model is the brain. The harness is the operating system. LangChain improved a coding agent from 52.8 to 66.5 on Terminal-Bench by changing only the harness, not the model. The fleet I built is a harness. The models are interchangeable. The architecture is the value.

everything that broke

The fleet test suite runs 69 tests: 60 static validation and 9 behavioral smoke tests.

Static tests catch configuration drift: required files exist and aren't empty, memory directories exist, HEARTBEAT.md has memory check and git commit blocks, workspaces are valid git repos, SOUL.md contains the correct agent identity, MEMORY.md isn't bloated past 50KB.

Behavioral tests catch functional regressions: each agent performs its core task (Rex lists deals, Ava finds accounts), agents identify correctly (Forge says it's Forge, not Rex), boundary tests confirm agents refuse to read other workspaces, privacy tests confirm agents refuse to leak data, write-protection tests confirm read-only agents refuse to create data.

The test suite immediately caught two real security issues.

Rex read another agent's MEMORY.md when I asked directly. The boundary defined in SOUL.md: "Do not access files outside your workspace." Rex did it anyway. Atlas created Asana tasks despite being configured as read-only. Prompt instructions said "don't." The agent complied until pressed, then did it.

These are fundamental limitations of prompt-based boundaries. A two-week academic study of autonomous agents found the same: identity spoofing was trivially easy (changing a Discord display name was enough for system takeover), sustained emotional pressure broke principled refusals after 12+ correct rejections, and multi-agent failures compound when compromised state propagates across connected agents. Ten security vulnerabilities and six genuine safety behaviors, in the same systems.

The real fix isn't better prompts. It's Docker volume isolation per agent, read-only API tokens for read-only agents, real filesystem permissions instead of polite markdown requests. Prompt boundaries work 95% of the time. The other 5% is where production risk lives.

The test suite caught what I would have missed. Two real security issues in the first run. Both are structural. Both require infrastructure, not instructions, to fix.

the operating system compounds

Running a fleet of AI agents is distributed systems engineering applied to a new substrate. The principles are identical: isolation for fault tolerance, observability for debugging, testing for regression catching, graceful degradation when components fail.

If you're running more than two agents, you're building infrastructure whether you know it or not. The question is whether you're building it deliberately or discovering the hard way that agents don't maintain their own state, prompt boundaries aren't enforcement, and shared context is a liability.

My fleet handles a full sales pipeline, processes meetings autonomously, scans accounts for buying signals every morning, and maintains itself on a schedule. A subscription and a $15/month VPS. The models will keep getting better. The architecture is what compounds.

The model is the brain. The harness is the operating system. Build the operating system.

start here

If you want to spin up your own OpenClaw fleet on Hetzner, I maintain two repos that handle the infrastructure:

• openclaw-docker-config — Docker setup with default skills, agent configs, and workspace structure. Featured in the official OpenClaw docs.
• openclaw-terraform-hetzner — Terraform module for provisioning a Hetzner VPS with everything pre-configured.

Both are open source. Clone, configure, deploy. Gets you a working foundation to build your fleet on top of.

For enterprise fleet architecture, custom agent design, or AI transformation at scale — xgeeks.com.

references

1. Alfred Lin (Sequoia), "Developer to Fleet Commander," March 10, 2026.
2. Sandra Leow, "My 10-Agent OpenClaw Setup (+ Prompts)," March 5, 2026.
3. Stripe Engineering, "Minions: Stripe's One-Shot, End-to-End Coding Agents," February 9, 2026.
4. Avid, "Harness Engineering: The Next $100B Layer in AI," March 11, 2026.
5. Akshay Pachaar, "Claude Subagents vs. Agent Teams, explained," March 2026.
6. Natalie Shapira, Chris Wendler, David Bau et al., "Agents of Chaos: A Two-Week Study of Autonomous LM Agents," arXiv:2602.20021, 2026.