A person absorbs ambiguity and carries context forward; an agent consumes attention and returns none. Put one in a headcount ratio with the other and both sides of the plan come out wrong.
By JP LeBlanc
Agent capacity doesn't belong on a headcount spreadsheet, and it doesn't belong in a headcount ratio either, the "one agent equals half an engineer" math a lot of capacity plans are starting to run. The reason isn't philosophical. A person absorbs ambiguity, carries context from one week into the next, and gets more valuable to a plan the longer they're in it. An agent consumes attention to produce output and returns none of that back into the plan. Model one as a fraction of the other and you've mispriced both sides of the plan at once, in opposite directions.
Building a headcount plan from outcomes, backward, in the CFO's own language already means modelling capacity as a function of ramp time, attrition, recruiting overhead, and manager bandwidth, none of which have an agent equivalent. An agent doesn't ramp for three months. It doesn't leave and take institutional knowledge with it. Nobody manages it the way a manager grows a report.
Which sounds like a reason agent capacity is cheaper, and for the specific work it's good at, it is. The mistake is folding that cheap capacity into the same spreadsheet cell as a person's, because the two numbers measure different things, and adding them produces a total that describes neither.
A Series B team went from forty pull requests a week to two hundred, with the same eight engineers. On a headcount spreadsheet that reads like the team quintupled. It didn't. Deployments slowed, because generation got five times cheaper and the pipeline built to review forty PRs a week was still built to review forty. The constraint didn't disappear. It moved to the part of the plan nobody had resized.
That's the sharper version of the headcount error. An org counting agent output as added capacity, without asking what else in the pipeline has to grow alongside it, produces a plan that's wrong in both directions at once. It overstates what the team can actually deliver, because review didn't scale with generation, and it understates what the plan really costs, because someone still has to read, judge, and stand behind every one of those two hundred diffs. Where agents genuinely earn their keep is the well-specified, checkable slice of work, and even there the output still has to pass through a human's judgment before it counts as delivered, which is exactly the step a headcount ratio leaves out.
The tempting fix is better tooling: a smarter dashboard showing agent output next to a capacity number, so the plan is at least legible. Wrong problem. The dashboard only makes the mispriced math easier to look at.
The actual issue is that most capacity planning quietly assumed output was the scarce thing, when the real constraint was always attention: how much judgment an organization's people can hold and exercise in a given week. Loading a team to full utilization doesn't produce more throughput, it produces a queue, because the thing that was actually scarce was never raw hours available. It was the capacity to absorb variance and still make good calls.
Agents don't touch that constraint. They can't absorb the ambiguity in a half-specified ticket, and they can't carry a judgment call about whether a change is safe forward into next quarter. What they can do is produce a lot more raw material for a person to apply judgment to, which is useful right up until the volume outpaces the number of people available to judge it, and then it's a liability with a faster front end.
I made a smaller version of this mistake myself, at Ada. I blocked a colleague by accident. I didn't have all the details, so I didn't trust them to move forward until I had wrapped my head around the situation myself, and the work sat there waiting for my understanding to catch up. My attention was the scarce resource in that chain, and I had made it a required stop. The rule I took from it: I cannot be the bottleneck of thinking. Trust and verify. The judgment belongs with the person who owns the consequence, and my job is to check it, not to queue it behind my own.
The alternative to a headcount ratio is boring, on purpose. Attach agent capacity to the specific outcome it's producing progress on, the same way a contractor's hours get budgeted against a project rather than folded into a permanent seat count. This migration gets an agent doing the mechanical rewrite and a named engineer reviewing it. This support queue gets an agent doing first-pass triage and a person deciding the ambiguous cases. The capacity is real, it's counted, and it's counted against the thing it's actually contributing to, instead of against a permanent slot on an org chart that implies it ramps, grows, and eventually needs a manager.
That framing also answers the review question honestly, because it forces the plan to name who's accountable for judging the output every time, rather than letting "the agent handled it" quietly stand in for "nobody has to."
Put an agent in the org chart as a fraction of a person and the plan comes out optimistic about capacity and blind about cost, in a way that only shows up once the pipeline downstream of the agent starts backing up. By then it looks like a hiring problem, or a review-quality problem, and the org spends a quarter fixing the wrong thing before somebody traces it back to a spreadsheet that counted the wrong resource as scarce.
The resource was never headcount. It was attention. Agents don't add any of it. They just make it more urgent to know where yours is going.