I Built an AI Company with OpenClaw. Now It's Hiring.

A few weeks ago I wrote an article about how I used 6 AI agents to run a company. That article hit 1.2M views. A lot of people liked it.

The most common question in the replies was: "What happened next?"

What happened next is they learned something new: how to hire.

I typed one sentence into my command center: "I'm thinking about quitting my job to start a company. Analyze this from every angle."

30 seconds later, a team of specialists assembled itself:

📊 Market Researcher – analyzing industry size, growth rate, and competitive landscape
💰 Financial Advisor – calculating startup costs, runway length, and break-even point
⚠️ Risk Assessor – listing the top 5 risks with mitigation strategies
🧠 Career Consultant – evaluating skills and experience against market demand
📈 Data Analyst – pulling success rates, funding data, and industry trends for similar founders
✍️ Report Writer – synthesizing everything into one actionable decision report

Six roles, all working in parallel. The final output wasn't six scattered opinions. It was one consolidated decision report with conclusions, evidence, risks, and recommendations.

I didn't assign them one by one. The AI decided who was needed, how many, and what each one should do.

First, What Is an Agent Swarm?

If you already know this concept, skip ahead.

One-line explanation: a group of AI agents working together like a swarm of bees to complete a task. The word "swarm" literally means a colony of bees. One bee is tiny. A swarm of bees can build incredible things.

Traditional AI works like this: you have one ChatGPT or Claude, you ask it a question, it answers. One to one.

Then it evolved: you have an AI agent that doesn't just answer questions but can use tools. Search, write code, send emails. But it's still one agent doing everything alone.

Swarm is the next step: instead of one agent doing everything, a group of agents divides the work. Each agent focuses on its own domain, they execute in parallel, and the results get consolidated. Just like a real company. A CEO doesn't write code, do accounting, and run logistics alone. They build a team.

Why is a Swarm better than a single agent? Four reasons:

Parallel execution → faster, no waiting in line
Specialization → each agent only sees its own domain's context, stays focused, hallucinates less
Fault tolerance → one agent failing doesn't crash the whole pipeline
Cross-validation → multiple perspectives reduce single-point bias

A lot of platforms already offer this. OpenAI has the Swarm framework (experimental). Kimi K2.5 built Agent Swarm into the model layer. Manus has Wide Research. But most of these are packaged products where you're just a user pressing a button.

This article is different. I built this with OpenClaw from scratch. OpenClaw already supports parallel sub-agent spawning, coordinating up to hundreds of subtasks. I built my own orchestration layer on top of it. How roles get assigned, how teams get assembled, how failures get retried, how results get consolidated. All my own code.

Why build it yourself? Because when you build your own swarm, you control every detail: which roles participate, what information they see, how they collaborate, how they recover from errors. This isn't using someone else's black box. This is using OpenClaw to build your own tool.

From "Everyone Does Their Own Thing" to "They Build Their Own Teams"

Let me start with where things were.

I had 6 AI agents, each with their own job: one makes decisions, one analyzes strategy, one gathers intel, one writes content, one manages social media, one does quality checks. (If you're curious about the details, the first article covers the full build process.)

They could each do their jobs. But there was a problem: all collaboration required me to orchestrate manually.

Imagine having 6 employees who are all competent, but every cross-department project requires you to personally create the group chat, assign tasks, chase progress, and compile results. You become the bottleneck. The team's ceiling is your energy.

I kept thinking: what if they could assemble their own teams?

Not me telling them "go find those three people and have a meeting." Instead, I just say "solve this problem" and they decide what kind of experts they need, recruit them, divide the work, and hand me one answer.

Now they can.

The 6 core agents went from executors to commanders. Each commander can summon specialist teams on demand. Procurement strategist, logistics coordinator, financial analyst, risk assessor, marketing specialist, legal counsel...

A set of preset role templates as a reference base (keyword-matched candidates plus detailed role prompts), three assignment modes, and theoretically any combination of teams.

How the "Hiring" Works

The entire pipeline starts with one sentence:

Mission Brief (your instruction)
    ↓
Plan – AI reads your instruction, decides how many people and what roles
    ↓
Spawn – generates N specialists, writes them to the task database
    ↓
Worker Claims – dispatcher on VPS scans every 5 seconds, claims new tasks
    ↓
Parallel Execution – each specialist completes their part independently
    ↓
Consolidated Report – everyone turns in their work, unified conclusion auto-generated

The most critical step is Plan.

How many people? The AI decides.

You don't have to pick a number. When fanout is set to Auto, the AI reads your task description and decides how many specialists are needed (2 to 12). If the judgment fails, it falls back to 5:

// fanout=0: model auto-decides (2..12), falls back to 5
if (normalizedInput.fanout === 0) {
  try {
    normalizedInput.fanout = await determineFanout({
      objective: normalizedInput.objective,
      task: normalizedInput.task,
      model: llmModel,
    });
  } catch {
    normalizedInput.fanout = 5;
  }
}

What kind of people? Three modes:

Rule-based: your instruction mentions "finance," it matches to finance_analyst. Mentions "logistics," it matches logistics_coordinator. Preset roles, keyword-triggered.
Hybrid mode (default): rules create the base, then Claude Sonnet refines each person's specific task description. Templates decide "who to hire," AI decides "what exactly they should do."
Fully autonomous mode: AI creates roles from scratch. It doesn't pick from templates. Instead it invents entirely new specialists based on your task. For example, it once generated a role called "Oxygen System Engineer." That's not in any preset.

The three modes have an automatic fallback chain: fully autonomous fails, downgrades to hybrid. Hybrid fails, downgrades to rule-based. The system never gets stuck because of a wrong mode choice.

const basePlan = buildRuleSpawnPlan(normalizedInput);

if (mode === 'dynamic') {
  try {
    const dynamicRoles = await generateDynamicRoles({ ... });
    return buildDynamicSpawnPlan(normalizedInput, dynamicRoles);
  } catch {
    // dynamic failed → auto-downgrade to hybrid
    return await refinePlanWithLlm({ basePlan, model: policy.llm_model });
  }
}
// hybrid: rules as base + LLM refinement
return await refinePlanWithLlm({ basePlan, model: policy.llm_model });

Every specialist that gets "hired" isn't just a name. They have a full identity:

// The real data structure for dynamic roles
interface SwarmSpawnDynamicRole {
  title: string;            // role name
  mandate: string;          // scope of responsibility
  antiScope: string;        // "don't do this"
  outputContract: string[]; // deliverable format
  riskBoundaries: string;   // risk boundaries
  crossLinks: string[];     // which other roles they collaborate with
}

Role name, scope, boundaries, deliverable specs, even cross-role collaboration links. Same as hiring in the real world. You wouldn't bring someone on without telling them what to do.

When the Team Hits Problems

Once the system was running, I found two pitfalls that are easy to trip over.

Pitfall 1: The Meeting Room Is Full

OpenClaw has a concurrency ceiling on how many sub-agents can run simultaneously. One time I gave it a complex task and the spawn count hit the platform limit. The last specialist got blocked and marked as failed.

But here's the interesting part: only that one failed. The others kept working.

This is the natural advantage of swarm architecture. With a traditional single agent, one error blocks the entire chain. Swarm is different. Local failure doesn't affect the whole. One person calls in sick, the project keeps moving.

In the fix, I made the system smarter: when concurrency is full, don't give a death sentence. Send it back to the queue and try again. Traffic jam? Take a detour. Don't cancel the trip.

// Concurrency full? Don't burn retry count. Requeue after 15 seconds.
if (isConcurrencyLimitResponse(resultPayload)) {
  await updateJob(job.id, {
    status: 'queued',
    next_poll_at: nextPollAt(15_000),
    attempt: Math.max(0, Number(job.attempt ?? 1) - 1), // key: don't consume retry
  });
  return { outcome: 'queued' };
}

Pitfall 2: Everyone Turned In Their Paper, But Nobody Wrote the Summary

Six specialists all completed their individual reports. System shows "6/6 succeeded."

I opened it up and there was no final recommendation. Everyone was talking past each other: finance says you have 8 months of runway, risk assessor says the industry is contracting, career consultant says your skill match is strong... six independent reports, nobody pulling it together. So should you start the company or not? No answer.

Swarm ≠ "everyone finished." Swarm = "everyone finished, and someone synthesized it into one answer."

The fix was adding an orchestration consolidation layer. Whether the final result is all success or partial failure, the system auto-generates a consolidated report. It takes all the specialist reports, assembles them into one Final Report using a structured consolidation function, then syncs the status across the entire mission chain.

// Derive group terminal state: all done or some failed
const next = deriveGroupState(counts);
const terminal = next.status === 'succeeded' || next.status === 'failed';

if (terminal && counts.total > 0) {
  const finalReport = buildFinalConsolidatedReport({
    objective: groupRow.objective,
    status: next.status,
    counts,
    jobs: rows,
  });
  meta.final_report_markdown = finalReport;
  meta.final_report_generated_at = nowIso();

  await sb.from('ops_spawn_groups').update({
    status: next.status,
    summary: `${next.summary} · consolidated report ready`,
    meta,
  }).eq('id', jobGroupId);

  // Sync mission step and mission status
  await syncMissionStepAndMission({ groupRow, next, counts, jobs: rows, finalReport });
}

Now when you open any historical mission, you see both the individual specialist reports and the final consolidated conclusion.

Watch It Work

Talking about it only goes so far. Just look.

Open voxyz.space/swarm and you'll see:

Command Center – six core agents in a honeycomb layout, each with their own color and avatar. Real-time status: who's busy, who's on standby.

Spawn Launcher (admin only) – type a task description, pick a model and thinking depth, hit "Launch Mission." The AI decides the team composition automatically. The public page shows data. Launching missions requires admin access.

Mission Control – kanban view. Queued, Running, Done in three columns. Each task card shows a row of pixel avatars so you can see at a glance who was assigned.

Mission Details – click any completed mission to see each role's execution results and the final consolidated report.

This page shows real data, including all test runs from the development and debugging process. You'll see some failed missions. Those are the traces of me fixing bugs during the build. Every failure was logged, diagnosed, and improved, eventually becoming the stable system running now. That's building in public. What you're seeing isn't cherry-picked success stories. It's the full evolution.

The Same $8/Month Server

The $8/month VPS from the first article. Still the same one.

But now it's running 10 workers, each with their own job:

Content production / memory maintenance / publishing / auto-posting
Relay dispatch / swarm commander / crawling / roundtable discussions / data analysis
Plus 2 anonymous workers quietly doing their thing

The swarm commander (spawn-relay-worker) is the core. It scans the task queue every 5 seconds by default (configurable via policy), claims new tasks, dispatches them to AI agents for execution, monitors progress, auto-retries on failure (exponential backoff, 3-second base interval, max 6 attempts), and generates consolidated reports when a terminal state is reached.

// Worker main loop: poll → execute → refresh status → sleep → repeat
while (true) {
  const sleepMs = await tick(); // claim → process → refreshGroupStatus
  await sleep(sleepMs);         // default 5000ms, hot-updatable via policy
}

Some people run agent swarms on a $599 Mac Mini.

I run mine for the price of a coffee per month.

Not saying hardware doesn't matter. Just saying the barrier is lower than you think.

What This Changes

The first article was about getting AI agents to run things on their own. This one is about something different: getting AI to scale itself.

When your agents can assemble their own teams, you stop being the bottleneck. You describe the problem. They figure out who's needed, how many, and what each person should do. Then they do it.

That's the difference between managing six employees and managing six department heads who can recruit on demand. Your capacity doesn't grow linearly with your effort anymore. It multiplies.

Is it perfect? No. Every specialist is still a temp worker — they show up, do the job, and disappear. The system doesn't remember that last week's Financial Advisor was brilliant. Next time, it hires a new one from scratch. Real teams keep their best people. That's the next problem to solve.

But the system runs. Real tasks go in, real reports come out. Every failure gets logged, diagnosed, and fed back into the next iteration. It's getting better every day.

If you're building agent systems with OpenClaw, I'd love to compare notes. Nobody has all the answers yet. But every conversation saves you from at least one pitfall you haven't hit yet.

What's Next

This article covered the "why" and "what it looks like."

A year ago, I was one person with a laptop. Now I have a team that scales itself. The models will keep getting smarter. The tools will keep getting cheaper. But the system you start building today is the one that compounds.

Next article: the build tutorial. Full architecture from concept to implementation.