I used to say it. "I run BMD HODL with 11 AI agents." It sounds impressive. It means almost nothing.
A friend pushed back on this. He said if he told you he had 11 spreadsheets, or 11 browser tabs open, you would not be impressed. You would ask what they do. Agent count is the same. The number is vanity. It tells you about volume, not value.
I went back and looked at my own fleet after that. Some of those agents did real work every single day. One scanned email and dropped article links into a queue. One reviewed blog drafts and either passed them or sent them back with reasons. One checked, every night, whether the things that should have happened that day actually happened.
And some of them were noise. They ran on a schedule, wrote a file nobody read, and exited zero. Green check, no outcome. If I had retired three of them, my "count" would have dropped from 11 to 8 and the business would have run exactly the same.
The count hides the only question that matters
The real question is not how many agents you have. It is: what does each one do, on what input, how often, and can you tell when it lied?
I started describing the fleet with three things instead of a number. A verb, a queue, and a cadence. "Reviews blog drafts in the Outbox folder every morning at 8:30." That sentence tells you more than "11 agents" ever did. It says what work happens, what it operates on, and when. If I cannot fill in that sentence for an agent, the agent should not exist.
Try it on your own setup. Write the verb-queue-cadence line for every agent you run. The ones where you stall on the verb are the ones doing nothing. Kill them.
Counting also hides cost
Here is the part that actually cost me money. When you think in counts, you do not think in spend. Eleven agents felt like a fixed thing, a headcount. But each one makes model calls, and a few of them retried on failure without a ceiling.
One agent hit a retry loop and burned through tokens for an hour before I noticed. The count did not change. It was still "11 agents." The bill changed. That is the problem with the headcount frame. It draws your eye to the wrong number.
What I actually need to watch is per-agent spend, token rate, and call volume. Not how many agents exist, but what each one consumes and whether any single one is running away. That is a different dashboard than "agent count: 11."
What to track instead
Drop the count from how you describe the system, internally and publicly. Replace it with these:
For each agent: the verb-queue-cadence line, so you know what it does. Did it produce its declared output today, not just exit zero. And what it spent, with a hard ceiling so a runaway loop trips a limit instead of your credit card.
The first one is free. You write it once. The second one is the difference between "my monitoring is green" and "the work actually happened," which are not the same thing and I learned that the hard way. The third one is why I built AgentGuard.
The honest version
So when someone asks how many agents I run now, I try not to answer with a number. I tell them what the fleet does. It scans, it digests, it reviews, it publishes, it audits its own runs at night. The count is whatever it happens to be that week, and I do not optimize for it going up.
If you are building an agent setup, resist the urge to brag about the count. Nobody hiring you, reading you, or buying from you cares that the number is high. They care that the work gets done, that you know when it does not, and that it does not quietly cost you a fortune. Describe it that way and you will also build it better, because the vanity number stops being the thing you chase.
The agents that survive that filter are the ones worth running. The rest were always just tabs you forgot to close.
If runaway token cost is the part that scares you, that is the right instinct. AgentGuard puts a hard budget, token, and rate limit around any agent so one bad loop trips a ceiling instead of your bill. It is open source, pip install agentguard. See it at https://bmdpat.com/tools/agentguard.
Top comments (0)