I Built a Multi-Agent System That Ships Features While I Sleep

Update, October 2026: I wrote this in March 2026, and it describes the system as it ran then. It has grown since, with more agents, a Kanban-style task board and a few instructive failures. That story is a future article.

I got tired of context-switching. Between my day job in fintech, side projects, and family life, I never had enough uninterrupted hours to ship features the way I wanted. So I built a system where AI agents do the shipping for me.

The setup: 7 specialized AI agents, each with their own Telegram bot and Slack channel, coordinated by a workflow engine I built called Antfarm, running on top of OpenClaw. I describe a feature in plain English, and the system plans it, codes it, tests it, and opens a PR — usually while I'm asleep or at dinner.

This isn't theoretical. This article you're reading? An Antfarm workflow wrote the first draft. (I rewrote it because the first version was generic marketing fluff.)

The Agent Roster

Each agent has a name, a personality, and a dedicated communication channel:

Agent	Name	Role	Channel
RD	Main	Dispatcher & general dev	#dev
Nonna	Chef	Meal planning & recipes	#meal-plans
Gatsby	Social	Event & schedule planning	#schedule
Coach	Coach	Training & fitness plans	#improve
Penny	Financial	Budget & financial analysis	#finances
Doctor	Doctor	Health tracking & advice	#health
Cipher	Researcher	Deep research & analysis	#research

They all live in a shared Telegram group where they respond when @mentioned, plus each has their own group for focused work. They can also talk to each other directly using agent-to-agent messaging.

How Antfarm Works

Antfarm is a workflow engine I built on top of OpenClaw. You define a pipeline in YAML, and Antfarm handles the rest — breaking tasks into stories, assigning them to agents, polling for progress, and advancing the pipeline.

Here's a simplified version of the feature development workflow:

id: feature-dev
steps:
  - id: plan
    agent: planner
    input: |
      Decompose this task into user stories.
      TASK: {{task}}
    expects: "STATUS: done"

  - id: setup
    agent: setup
    input: |
      Create branch, run baseline build/tests.
      REPO: {{repo}}  BRANCH: {{branch}}

  - id: implement
    agent: developer
    type: loop
    loop:
      over: stories
      verify_each: true
      verify_step: verify
    input: |
      Implement this story: {{current_story}}
      VERIFY FEEDBACK: {{verify_feedback}}

  - id: verify
    agent: verifier
    input: |
      Check the developer's work.
      Did they actually do it? Do tests pass?

  - id: test
    agent: tester

  - id: pr
    agent: developer
    input: Create a pull request.

  - id: review
    agent: reviewer
    input: Review the PR. Approve or request changes.

The key design decisions:

Story-based loops. The planner breaks a task into user stories (US-001, US-002, etc.). The developer implements one story per session in a fresh context window, commits, and reports back. This keeps each session focused and prevents context overflow.

Verify-each. After every story, a separate verifier agent checks the work — does the code exist? Do tests pass? Are acceptance criteria met? If not, it sends feedback back to the developer for a retry.

Fresh sessions. Each story gets a clean agent session. No accumulated context drift. The agent reads a progress file to understand what's been done, does its work, updates the progress file, and exits.

The Polling Architecture

Agents don't run continuously — that would burn tokens on idle time. Instead, Antfarm uses a two-phase polling system:

Peek (cheap model, every 10 minutes): A lightweight MiniMax model checks if there's pending work. If not, it replies HEARTBEAT_OK and stops. Cost: fractions of a cent.
Claim + Spawn (work model): If work exists, the polling agent claims the step and spawns a fresh session with the full work model (GPT-5.2 Codex) to actually do the work.

This means idle workflows cost almost nothing, and active workflows progress at ~10 minute intervals per step.

Architecture

The stack runs as a Windows Scheduled Task (auto-restarts on crash or reboot). OpenClaw provides the gateway — handling Telegram bots, Slack integration, agent sessions, and tool execution. Antfarm sits on top, managing the workflow state in SQLite and coordinating agents through OpenClaw's cron and session APIs.

What I Actually Use It For

Beyond the dev workflows, the agents handle real daily tasks:

Nonna generates weekly meal plans based on dietary preferences and grocery budget, posts shopping lists to Telegram
Gatsby manages my family calendar, plans events, sends reminders
Coach builds training programs, tracks progress, adjusts based on feedback
Penny analyzes spending, flags anomalies, generates monthly financial summaries
Doctor tracks health metrics, reminds about appointments, summarizes family health data
Cipher does deep research on topics I'm exploring — competitive analysis, technology evaluations, market research

The workflow engine (Antfarm) has 6 pipeline templates:

Workflow	Pipeline
`feature-dev`	planner → setup → developer (loop) → verifier → tester → PR → reviewer
`bug-fix`	triager → investigator → setup → fixer → verifier → PR
`security-audit`	scanner → prioritizer → setup → fixer → verifier → tester → PR
`meal-plan`	researcher → planner → shopper → reviewer
`training-plan`	assessor → programmer → scheduler → reviewer
`deep-research`	planner → gatherer → analyst → writer

Lessons Learned

LLMs are unreliable formatters. The biggest source of workflow failures isn't bad code — it's agents that don't format their output correctly. A step expects STATUS: done and the agent writes Status: Done or just describes what it did without the status line. I had to make the output validation case-insensitive and add fallback parsing.

Shared agents bottleneck concurrent runs. When two feature-dev workflows run simultaneously, they share the same developer agent. One run hogs it while the other waits. I fixed this by adding claim-all — the polling cron now claims work from every active run and spawns parallel sessions.

Fresh sessions beat long-running ones. Early versions kept agents in long sessions. They'd accumulate stale context, hallucinate about files they'd already edited, and make increasingly confused decisions. Switching to one-story-per-session with a progress file as the only state transfer fixed this entirely.

Verify-each is non-negotiable. Without per-story verification, agents would claim to implement features that didn't actually work. The verifier catches this immediately and sends specific feedback for the retry. It adds ~10 minutes per story but saves hours of debugging broken PRs.

Windows is pain. OpenClaw + Antfarm were designed for Unix. I had to fix CRLF line endings breaking output parsing, MSYS2 path conversion issues, and Windows Scheduled Task configuration (S4U logon type for background services). It works now, but the first week was rough.

What's Next

I'm working on a few improvements:

Visual verification — agents with browser access that screenshot the UI after frontend changes and verify the layout looks right
Self-healing workflows — when a run fails, automatically diagnose whether it's a transient issue (retry) or a real problem (escalate)
Cost tracking — per-workflow token usage tracking so I can see exactly what each feature costs to ship

The goal isn't to replace human developers. It's to handle the mechanical parts — scaffolding, boilerplate, test writing, PR formatting — so I can focus on the interesting decisions. The agents are good at following patterns. I'm better at deciding what patterns to follow.