Agent count is not a production metric
SaaStr says it runs on 3 humans and 21+ AI agents. The useful part of the disclosure is the job map, not the ratio — and the scorecard your agent program needs has five columns, none of which is headcount.
On June 2, SaaStr published the operating setup behind the headline it has been running for months: 3 humans, 21+ AI agents. Not a thought experiment — a named list, agent by agent, with marketing agents, customer-success agents, each assigned an actual job. Caveat up front: the operating and revenue figures are first-party claims with no audit trail, so treat the numbers as directional.
The headline ratio is what everyone will repost. Three humans! Twenty-one agents! It reads like a productivity miracle, and every automation programme in every enterprise will now get asked some version of "how many agents do we have?"
That question is a trap, and I want to name it before it lands in your quarterly review.
The job map is the disclosure; the ratio is the marketing
The genuinely useful part of SaaStr's post is not the count. It is that every agent has a name, an owned workflow, and a specific job. An agent that owns "reply to sponsor enquiries end to end" is an operational fact you can inspect. "We have 21 agents" is an inventory line — and inventory is what you count when you don't yet know what the assets produce.
We have been here before. Nobody serious reports "number of microservices" as an engineering KPI, because a service count tells you nothing about uptime, latency, or cost. It took the industry years to stop bragging about cluster sizes and start reporting SLOs. Agent programmes are speed-running the same mistake with a shinier noun.
My rule: an agent only counts when you can answer five questions about it. What workflow does it own? How many completions did it deliver this month? How often did a human have to step in? What did its worst error cost? And what would make you retire it? That last one is the tell — a programme that cannot name retirement criteria is collecting agents, not running them.
The dashboard I keep seeing
At work I reviewed a client dashboard this quarter that celebrated "agents deployed" as the headline metric — a big, confident number, trending up and to the right. Nowhere on the page: accepted outcomes, escalation load, or rework. When we pulled the escalation queue, one "deployed" agent had been silently routing 40% of its tasks to a human for weeks. It was being counted as automation while functioning as a form with extra steps.
We rebuilt the dashboard around the five columns above. Two agents got retired the same week — not because they were broken, but because nobody could say what they owned. The deployed count went down. The programme got healthier. Those two sentences should be allowed to coexist in more board decks than they currently are.
That is also the honest way to read SaaStr's own disclosure. The impressive part is not that they have 21 agents; it is that they can apparently name what each one does. Most enterprises publishing agent counts cannot — and the count is doing the work the job map should be doing.
Steal this before your next review
Take your agent inventory and add five columns: owned workflow, completions, interventions, worst-error cost, retirement criteria. Fill it in before Friday. Any row you cannot complete is not an agent in production — it is a demo with a budget line. Report the rows you completed, and only those, as your programme.
The count will be smaller. It will also, for the first time, be a production metric.
Agents are headcount only in the sense that headcount was never the point — measure owned work, not owned bots.
