Building an AI Agent Fleet with OpenClaw

How I built a system of specialized AI agents that work together to handle tasks, write code, and manage my day.

Most people interact with AI through chat interfaces. You ask a question, you get an answer. That’s useful, but it’s limited.

What if instead of chatting with AI, you could delegate to it?

The Vision

I wanted a system where I could queue a task like “Build a dashboard for monitoring agent status” and have it done by the time I wake up. Not by magic — by an orchestrated system of AI agents, each specialized for different work.

The Architecture

Here’s what I built:

                 ┌─────────────────┐
                 │     Higgins     │
                 │  (Orchestrator) │
                 └────────┬────────┘
                          │
        ┌─────────┬───────┼───────┬─────────┐
        ▼         ▼       ▼       ▼         ▼
    ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
    │Builder│ │Content│ │Research│ │Product│ │  QA   │
    └───────┘ └───────┘ └───────┘ └───────┘ └───────┘

Higgins is the orchestrator — my single point of contact. It routes tasks to specialists:

  • Builder — writes code, creates infrastructure, fixes bugs
  • Content — drafts posts, scripts, social content
  • Research — deep dives, market analysis, competitive intel
  • Product — specs, strategy docs, system design
  • QA — validates Builder’s output before it ships

The Task Queue

Tasks flow through a SQLite database:

INSERT INTO tasks (id, agent, title, status)
VALUES ('task-builder-001', 'builder', 'Build dashboard', 'queued');

Persistent daemons poll the database, claim tasks, execute them with timeouts, and mark completion. A watchdog recovers stuck tasks.

What I Learned

  1. Orchestration > single agents — Specialized agents with clear boundaries outperform one generalist agent trying to do everything.

  2. File-based state is fragile — I started with JSON files. They corrupt, they race, they drift. SQLite solved this.

  3. QA gates matter — Without validation, agents ship broken code. The QA agent catches issues before they reach production.

  4. Daemons > poll triggers — launchd polling created race conditions. Persistent daemons with proper signal handling are more reliable.

What’s Next

I’m working on:

  • Task decomposition (breaking large builds into phased work)
  • Cross-agent memory (Cognee knowledge graph)
  • Better observability (structured logging, metrics)

More posts coming as I build. Follow along.