I built 15 AI agents to run my business — what they actually do

The whole stack, on one screen

Here's the active fleet on my MacBook this week. Every one of these is a real agent — a markdown spec, a model, a job, a schedule.

chief-of-staff       — daily aggregator, reads everything, writes one digest
struvo-dev           — code shepherd for the Struvo product repo
struvo-roadmap-decider  — gates roadmap PRs against the master plan
struvo-pricing-checker  — flags pricing-page drift vs canonical pricing
struvo-lead-router   — incoming AFP-inbox triage
freelance-sales      — Upwork proposals, cold outbound
yt-producer          — YouTube production cycle (5-day batch)
daily-ops            — morning + evening briefings
file-oracle          — where-does-this-go for cross-repo files
security-lead        — sandboxed link/image previews, secret leak scans

Plus 21 dormant agents — paused-project, pre-revenue, event-triggered. They live in a dormant/ folder with a wake-check hook that auto-surfaces them on UserPromptSubmit when keywords match. Total disk cost: a few KB of markdown each.

What they cost to run

Total monthly API spend across the fleet, last month: about $187. That includes ~30 hours/week of work I'd otherwise be doing manually.

If I were paying a part-time human for 30 hours/week at even $30/hour, that's $3,600/month. The dollar math isn't subtle.

The one that broke

The chief-of-staff agent stopped surfacing dormant agents one week last month. Symptoms: I'd ask about a YouTube task and it would route to freelance-sales because that's the closest active agent. The dormant yt-producer was sitting in the manifest but the wake-check hook had silently stopped firing.

Root cause: set -u in the hook script rejected an empty associative-array length check. Bash 3.2 (default macOS shell) doesn't handle that the same way Bash 5 does. The hook errored once, systemd-equivalent (launchd) stopped retrying, and the wake-check went quiet.

Fix: switched the hook from set -uo pipefail to set -o pipefail. One character. Took me three hours to find.

That's the truth about running an agent fleet. The agents themselves are easy. The plumbing between them — hooks, cron, launchd, env vars, model routing — that's where you spend the time.

The pattern

The thing that makes this work is decision compaction. v2.3 of the fleet went from 17 active agents to 10. The 7 I demoted to dormant aren't deleted — they're discoverable through a manifest, surfaced by a hook when keywords match.

Fewer active agents in the routing pool = less noise on every dispatch. The router stops considering pre-revenue agents that literally cannot fire today.

That's the move I'd recommend before adding more agents: kill the ones that don't earn their slot. Move them to dormant. Let the wake-check surface them when they're needed.

What you can steal

If you're building your first agent fleet:

1. Start with one aggregator. Don't build 5 worker agents and try to read their outputs in parallel — build one chief-of-staff who reads them for you.
2. Put dormant agents in a manifest, not in the active pool. Pre-revenue and paused-project agents are pure noise.
3. Test your hooks on the actual shell version your machine runs. Bash 3.2 will betray you in ways Bash 5 won't.
4. Track API spend daily for the first month. The number tells you whether the system pays for itself.

Mine pays for itself. By a lot.