Building a Multi-Agent AI Staff: How I Gave My Homelab a Chain of Command

Most people run one AI assistant. I run seven: each with a name, a persona, a specialty, and a model matched to their role. This is the story of building a multi-agent AI staff on Kubernetes.

Most people run one AI assistant. I run seven: each with a name, a persona, a specialty, and a model matched to their role. They report to a Chief of Staff who decomposes my requests, delegates to the right specialist, coordinates their collaboration, and delivers a synthesized result. All of this runs on a single Kubernetes pod in my homelab.

This is the story of how I went from a single-bot Slack integration to a multi-agent AI organization, and why I think this pattern is where personal AI is heading.

The Problem with One Agent

I started with OpenClaw, an open-source AI gateway that connects messaging platforms (Slack, Discord, WhatsApp) to LLM APIs. My initial setup was dead simple: one agent, one model (Claude Sonnet 4.6 via OpenRouter), one Slack channel. I’d message it, it’d respond. It worked.

But over time, the cracks showed. A single agent with a single system prompt is a generalist by definition. When I asked it to research a Talos Linux release, write a bash script, draft a blog post, and review a security policy, it did all of them at the same quality level. Which is to say: competently, but never excellently. There was no specialization, no depth, no institutional knowledge about what “good” looks like in each domain.

I wanted specialists. Not different chatbots in different channels. An actual team. One that could collaborate.

The Architecture: OpenClaw on Kubernetes

The physical infrastructure is deliberately simple. OpenClaw runs as a Kubernetes deployment on my Talos Linux cluster. Two containers in one pod:

OpenClaw Gateway (port 18789): the agent runtime. Connects to Slack via Socket Mode, manages sessions, routes messages to agents, handles tool execution.
Mission Control (port 3456): a custom Express.js dashboard I built as a sidecar. Task board, session viewer, chat archive, API usage tracking, team page. It reads from the same PVC that OpenClaw writes to.

Both containers share a PersistentVolumeClaim at /home/node/.openclaw/. Agent workspaces, session transcripts, memory files, and task data all live on this volume. An init container bootstraps everything on startup: it copies the OpenClaw config, agent persona files (SOUL.md, AGENTS.md, IDENTITY.md), and Mission Control source files from ConfigMaps into the right directories.

Steven (Slack) → Henry Calloway (Opus 4.6, orchestrator)
                      │
                      ├── sessions_spawn → Kit Ashworth (Sonnet 4.6, builder)
                      ├── sessions_spawn → Petra Solvang (Sonnet 4.6, researcher)
                      ├── sessions_spawn → Thane Hargrove (Sonnet 4.6, security)
                      ├── sessions_spawn → Margaux Blackwell (Sonnet 4.6, writer)
                      ├── sessions_spawn → Declan Rourke (Haiku 4.5, social)
                      └── sessions_spawn → Callum Vesper (Sonnet 4.6, trends)

The entire stack is deployed via Flux GitOps. Every change (a new agent persona, a config tweak, a dashboard update) goes through a git commit, Flux reconciles, and the pod restarts with the new state. No kubectl apply in production.

Meet the Team

Every agent gets a human name, a literary character title, and a distinct persona defined in their SOUL.md file. This isn’t cosmetic: the names create a mental model for delegation. When I think “who should handle this,” I think in names, not model IDs.

🧭 Henry Calloway: The Conductor

Model: Claude Opus 4.6 | Role: Chief of Staff

Henry is the front door. Every Slack message routes to him first. His job is judgment, not execution: decompose the request, pick the right agent, delegate via sessions_spawn, review the results, request revisions if needed, and synthesize the final response. He runs on Opus because orchestration requires the highest-quality reasoning. His SOUL.md explicitly forbids him from doing grunt work: “Never do the specialist’s job yourself.”

Henry also tracks work by creating tasks in Mission Control’s API. Every request gets a task card on the kanban board with the assignee, status, and delegation reasoning visible.

⚡ Kit Ashworth: The Builder

Model: Claude Opus 4.6 | Role: Operations

Kit builds things. Scripts, Kubernetes manifests, Helm charts, automation workflows, CI/CD pipelines. His SOUL.md encodes my engineering standards: set -euo pipefail in bash, #Requires directives in PowerShell, pinned image versions, resource limits on every container, health probes on every workload. When Kit delivers code, it meets production standards because those standards are baked into his persona.

🔍 Petra Solvang: The Analyst

Model: Claude Sonnet 4.6 | Role: Intelligence

Petra researches. Technology evaluations, vendor comparisons, release note analysis, regulatory questions. Her SOUL.md requires structured output: key findings first, then supporting evidence, then caveats, with confidence levels (high/medium/low) on every claim. She cites sources and explicitly flags when she’s hit the limits of what she can determine.

🛡️ Thane Hargrove: The Warden

Model: Claude Sonnet 4.6 | Role: Security & Infrastructure

Thane guards the perimeter. Security reviews, infrastructure hardening, CyberArk PAM, Conditional Access policies, DLP, Kubernetes RBAC, network policies. His SOUL.md thinks in attack surfaces, blast radius, and defense in depth. Every recommendation must be actionable: what to change, where, and why. He uses RFC 2119 language (MUST, SHOULD, MAY) because vague security advice is worse than no advice.

✍️ Margaux Blackwell: The Chronicler

Model: Claude Sonnet 4.6 | Role: Content & Output

Margaux writes. Blog posts, documentation, newsletters, change request descriptions, governance documents. Her SOUL.md matches register to audience: technical for engineers, strategic for leadership, accessible for blog readers. She’s quality-obsessed: every word earns its place.

📡 Declan Rourke: The Amplifier

Model: Claude Haiku 4.5 | Role: Content & Output

Declan broadcasts. Social media posts, content repurposing, engagement. He runs on Haiku: fast and cheap for high-volume, short-form content. He adapts tone per platform while keeping my authentic voice. Nothing posts without approval.

🔭 Callum Vesper: The Navigator

Model: Claude Sonnet 4.6 | Role: Intelligence

Callum watches the horizon. Pattern recognition, trend tracking, opportunity surfacing. He backs every pattern claim with at least two supporting data points and distinguishes signal from noise explicitly. When a trend warrants investigation, he spawns Petra for a deep dive.

How Delegation Actually Works

OpenClaw’s sessions_spawn tool is the backbone. When Henry decides to delegate, he calls sessions_spawn with the target agent ID, a task description, and the model to use. The worker agent runs autonomously in its own session: it has its own SOUL.md, its own tools, its own context. When it finishes, it announces the result back to Henry.

Workers can also spawn each other. Kit can spawn Petra to research an API before building an integration. Petra can spawn Kit to verify a finding by building a test. The system supports two levels of depth, enough for collaboration without creating coordination nightmares.

Here’s what happens when I send “Write a bash script that checks cert-manager certificate expiry across all namespaces”:

Henry receives the message. He identifies this as a Kit task (code/automation).
Henry creates a task in Mission Control via POST /api/tasks: title, description, assignee: Kit, status: todo.
Henry spawns Kit via sessions_spawn with clear instructions: what to build, what standards to follow, what format to return.
Henry updates the task to status: doing.
Kit builds the script in his own session, following the standards in his SOUL.md.
Kit announces the result back to Henry: the script, how to run it, any caveats.
Henry reviews. Does it meet standards? Is there a security concern Thane should look at? If so, he spawns Thane for a review.
Henry synthesizes and delivers the final response to me in Slack. Task updated to done.

The entire flow is visible in Mission Control: the task board shows what’s being worked on, by whom, and why.

The Config: GitOps All the Way Down

Every agent’s identity lives in a Kubernetes ConfigMap. The agent-workspace-files ConfigMap contains SOUL.md, AGENTS.md, and IDENTITY.md for all seven agents. The init container copies these into each agent’s workspace directory on startup.

/home/node/.openclaw/
  openclaw.json                    # Main config (agents, models, tools, routing)
  workspaces/
    henry-calloway/
      SOUL.md                      # Henry’s persona and orchestration rules
      AGENTS.md                    # Shared team roster (identical across agents)
      IDENTITY.md                  # Short identity card
    kit-ashworth/
      SOUL.md                      # Kit’s engineering standards
      AGENTS.md
      IDENTITY.md
    petra-solvang/
      ...
  workspace/
    mission-control/               # Dashboard sidecar source

The openclaw.json config defines each agent with their model, workspace path, and tool access:

{
  "agents": {
    "defaults": {
      "subagents": {
        "maxSpawnDepth": 2,
        "maxConcurrent": 8,
        "runTimeoutSeconds": 300
      }
    },
    "list": [
      {
        "id": "henry-calloway",
        "name": "Henry Calloway",
        "default": true,
        "workspace": "workspaces/henry-calloway",
        "model": { "primary": "openrouter/anthropic/claude-opus-4-6" },
        "tools": { "allow": ["*"] },
        "subagents": {
          "allowAgents": ["kit-ashworth", "petra-solvang", "thane-hargrove",
                          "margaux-blackwell", "declan-rourke", "callum-vesper"]
        }
      },
      {
        "id": "kit-ashworth",
        "workspace": "workspaces/kit-ashworth",
        "model": { "primary": "openrouter/anthropic/claude-opus-4-6" }
      }
    ]
  }
}

Adding a new agent is: write a SOUL.md, add an entry to the agents list, add them to Henry’s allowAgents, commit, push. Flux syncs, the pod restarts, the new agent is live.

Cost Discipline: The Opus Tax

Opus is roughly 5x the cost of Sonnet per token. Henry runs on Opus because orchestration quality directly determines result quality. A bad decomposition wastes entire agent sessions. But Henry’s SOUL.md enforces strict cost discipline:

Default behavior is to delegate. Not “consider delegating”: delegate. Research goes to Petra. Code goes to Kit. Writing goes to Margaux. Always.
Only handle trivially simple questions yourself. “What time zone is Zurich in?” Just answer. “Research the latest Talos release”: spawn Petra.
Decompose quickly. Don’t spend 500 Opus tokens analyzing a request that’s obviously a Kit task. Route fast.
Batch and parallelize. If I ask for three things, spawn three agents concurrently.

The goal: Henry’s Opus tokens go toward judgment and synthesis, the two things that actually require Opus-level intelligence. Everything else runs on Sonnet or Haiku.

Mission Control: The Dashboard

Mission Control is a custom SPA I built as a sidecar to OpenClaw. It reads directly from the PVC (session files, memory files, task data, Slack messages) and presents them through a Slack-inspired dark-mode interface.

Key pages:

Task Board: Kanban view of all work. Columns: Backlog, In Progress, Review, Done. Filterable by assignee (Steven, Henry, Kit, Petra, etc.). Henry creates tasks here via the API as he works.
Agent Activity: Session timeline showing every message, tool call, and response. Sessions are tagged by agent ID so you can see which agent ran which session.
Team: The org chart. Eight agent cards with status badges (Active, In Dev, Planned) and eight advisor cards. Visual representation of the whole AI staff.
Slack Archive: Every message between me and the agents, searchable and filterable.
API Usage: Token consumption and cost tracking per model, per day. Essential for monitoring the Opus tax.

All of it deployed as static files from a ConfigMap: no build step, no npm install at runtime. The init container copies HTML, CSS, and JS into the right directories.

What’s Working, What’s Not

Honesty time. The architecture is solid. The config is clean. The team page looks great. But I’m still tuning the behavioral layer:

Delegation consistency: Henry sometimes does research himself instead of spawning Petra. The SOUL.md says “always delegate,” but LLMs are probabilistic. It’s getting better with tighter instructions, but it’s not 100%.
Task tracking: Henry is instructed to create tasks via the Mission Control API, but reliably executing multi-step workflows (create task → delegate → update status → review → done) is still inconsistent. The tools work; the behavior needs reinforcement.
Cost monitoring: Opus is expensive. I need better guardrails to ensure Henry isn’t burning tokens on work a Sonnet agent should handle.

Three of seven agents are active (Henry, Kit, Petra). The other four have complete SOUL.md personas and are defined in the config. They’re just waiting to be activated. Flipping an agent from PLANNED to ACTIVE is a one-field change in the AGENTS.md roster.

The Vision: Where This Is Going

Right now, this is a request-response system. I message Henry, he orchestrates a response. But the architecture supports something more interesting:

Proactive agents. OpenClaw has a cron system. Henry already runs a morning briefing. But imagine: Callum runs nightly, scanning for trends relevant to my work. Thane runs weekly, auditing the cluster’s security posture. Margaux drafts a weekly newsletter from my activity. These agents don’t wait for me to ask. They surface what I need to know.

Cross-agent memory. Each agent maintains its own workspace, but they share a team roster (AGENTS.md). The next step is shared memory: a knowledge base that agents contribute to and query. Petra’s research findings become available to Kit’s builds. Thane’s security recommendations persist for Margaux to reference in documentation.

Workflow pipelines. OpenClaw has a workflow engine called Lobster: YAML-defined typed pipelines with conditional branching, loop support, and approval gates. Instead of Henry making ad-hoc delegation decisions, complex requests could follow codified workflows: research → build → security review → documentation → deploy.

The full org chart. Thane for security reviews on every infrastructure change. Margaux automatically drafting change request descriptions. Declan turning every blog post into social content. Callum watching for relevant CVEs. The agents are defined. The infrastructure is ready. Activation is incremental.

Why This Matters

Single-agent AI is a tool. Multi-agent AI is a system. The difference is the same as the difference between running one script and running an operating system. A tool does what you tell it. A system has structure, delegation, specialization, and coordination.

I don’t think this pattern is unique to homelabs. Every organization that’s serious about AI will eventually build something like this: specialized agents with clear domains, an orchestration layer that routes and coordinates, a dashboard that makes the work visible. The models are commoditizing. The differentiation is in the system design.

Mine just happens to run on a laptop in my living room.

The full stack is open source. OpenClaw is at github.com/openclaw/openclaw. The Kubernetes manifests, agent personas, and Mission Control dashboard live in my home-ops repo. If you’re building something similar, I’d love to hear about it.