← All Notes

Related: this is the cultural version of an argument made structurally in The AI Cone — most people get 20% faster, a few get multiplied — and practically in If You're Measuring AI in Percent, You're Not There Yet.

Rani Molla wrote a piece for Business Insider about a new status game, and I want to be careful here, because the easy read of it is wrong.

The game is called agentmaxxing. Anxious about being displaced by AI, some professionals have started building their own AI agents — and then posting the count. Mason Scurry, a recent Brown graduate running an AI consulting firm, says he has more than thirty AI "employees," each with a name, a job title, a backstory, and a profile picture, working around the clock for less than a penny an hour. Derrick Hicks, a veteran marketer, built sixteen specialized agents and then built a seventeenth, called Conductor, to manage the other sixteen. Robbie Allen runs about twenty-five. Maayan Sarig, a communications manager at Meta, manages a team of six, only one of whom is human.

The easy read is that these people are ridiculous. That's not my read. My read is that they have the right instinct and the wrong scoreboard.

The Best Argument Against Agentmaxxing Is Inside the Article

Here is what makes Molla's piece good rather than just viral: almost everyone she quotes disputes the premise she's reporting on.

Hicks, who built the sixteen: "Who the hell cares how many agents you have?" Maayan Sarig, the Meta manager: the metric isn't the count, it's output quality and time saved. Melissa Hilbert, a vice president analyst at Gartner: "You could have 200 agents, but if they deliver thousands of pieces of content and nobody uses them, then they're useless. You could have two agents that decrease the pipeline cycle time by 50%. That's an actual sales outcome that provides value." Allen, at twenty-five, asks the question that actually punctures it — can you even think of a thousand things you'd want an agent to do?

And Scurry, the guy whose thirty agents are the headline, says the quiet part himself: a lot of the posts are just "I have agents," with no clients and no finished work behind them.

So the people doing this already know. The count is a shipping manifest someone mistook for the cargo.

Agent count is an input. Nobody walks a buyer through a factory and brags about how many robots are bolted to the floor. They show you what comes off the line.

The instinct underneath it is correct, and I don't want that lost in the dunking. The instinct is: don't wait to be automated, automate. That is the right move. It's the same move I'd tell anyone to make. The mistake is measuring it by headcount, because headcount is the one number in this entire discipline that takes no skill to increase.

Most of These "Agents" Are Cron Jobs

Robbie Allen is the most useful person in the piece, and he's the one who gets quoted least on the part that matters.

Allen has founded three AI companies. He runs about twenty-five agents. And he says plainly that the number sounds more impressive than the underlying reality: most of them are scheduled jobs that wake up periodically, call a model or an outside service, and perform one narrow task. Not every step even uses a language model. Some just move data from one place to another. They are not twenty-five entities continuously thinking and deciding. They're a crontab.

"I have 25 of these not because I spent a month working on each one of them, but because I could create them quickly," he says.

I have been writing that program since the nineties. So has every sysadmin alive. A scheduled job that wakes up, hits an endpoint, transforms the result, and writes it somewhere is the single most common piece of software in the working world, and nobody has ever called one an employee or given it a headshot. What's genuinely new is that one of the steps in the middle can now handle ambiguity. That is a real and significant upgrade to the actuator. It is not a new species.

And then Allen says the thing that gave me a jolt of recognition, because it's the exact lesson everyone learns at the same point on this curve: he has another agent whose only job is to check whether the other agents are working and text him when one fails. Something on the list breaks most days.

That's a monitor. He built a drift detector. He arrived at it the same way I did — by having enough things running unattended that "did it actually run?" became its own job. That's not an AI insight, it's an operations insight, and it's the moment you stop counting agents and start caring about reliability, because reliability is the actual product.

The bill for skipping that step is measurable. A report from Glean's Work AI Institute found office workers spend upward of six hours a week "botsitting" — feeding context, checking output, correcting mistakes. Agents don't only save work. Built carelessly, they manufacture it, and the invoice arrives every week.

A Count With No Unit

There's a more basic problem with the number, and Molla names it: there is no agreed definition of an agent. The two labs whose models everyone is running don't use the same one.

OpenAI's guide is broad and flat: "Agents are systems that independently accomplish tasks on your behalf." Anthropic draws the line somewhere much narrower — a workflow is a system where models and tools are "orchestrated through predefined code paths," and only a system where the model "dynamically direct[s] [its] own processes and tool usage, maintaining control over how [it] accomplish[es] tasks" earns the word agent.

Sit with that for a second, because it's not a pedantic distinction. By Anthropic's definition, a scheduled job that wakes up, calls a model, and writes the result somewhere is not an agent at all. It's a workflow with an LLM in the middle of it. Which is, by his own description, most of what Allen is counting — and almost certainly most of what everyone else is counting too.

So in practice the word stretches across a system that finds a lead, researches them, writes a personalized pitch and books the meeting — and a bot that reads your calendar each morning and texts you the list. Those are not the same unit. One is a business process with judgment in the loop. The other is a shell script with a nicer haircut.

So when someone says "I run forty agents," the sentence has no information in it. Not because they're lying — because the noun is undefined. You can't compare two counts when neither person will tell you what they're counting, and the incentive runs entirely toward counting the cheap kind.

Personas Are the Fluff

I should confess something before I get sanctimonious: I do the persona thing too.

My agents have codenames. There's a master agent that owns the box, a content agent that owns every article across the network, a PM agent, a research agent. They have scoped identities and standing instructions and a defined sense of what is theirs to touch. I find it genuinely useful. When I'm holding five threads at once, "ask content" is a faster thought than "open the session rooted in the directory that owns the markdown."

But I want to be precise about what that buys me, because it is easy to mistake it for the work. Personas are ergonomics. They're a naming convention for humans. They help me keep my place. They do not make the system work, and they are not evidence that it does.

The clearest illustration in Molla's article is Scurry's agent Penny, the "token auditor." I understand the appeal completely — I care about token spend, I've written about the meter running. But a persona named Penny who audits tokens is a prompt. What I have instead is a table. Every inference call across every project on my server routes through one abstraction layer, and that layer writes a row: model, tokens, cost, which project, which call. It is not a character. It cannot forget, embellish, or be talked out of a number. If I want to know what August cost me, that's a query, not a conversation.

That's the whole difference, and it isn't about agents at all. One of those is a costume. The other is an instrumented process.

To be fair to Scurry, he's honest about why he does it: "It's more fun. They feel like real employees." His agents have their own Slack channels and publish their own newspaper, The Scurryville Nightly, tagline "while he slept," in which they complain and brag about their work. I think that's genuinely delightful and I'd read it. I just wouldn't confuse it with the org chart.

I've Been Automating Since Dial-Up

I have been designing automated processes since modems screamed.

Batch files. Shell scripts. Cron. Makefiles. Scheduled jobs, message queues, ETL that had to survive a link going down mid-transfer, build pipelines, CI, deployment automation, orchestration layers. Thirty-odd years of the same underlying job: take something a person does by hand, understand it well enough to describe it exactly, then build a structure that performs it reliably when nobody is watching.

That discipline has a name. It's process engineering, and it predates all of this by a century — it comes out of factories, not computers. The hard parts have never been the actuator. The hard parts are: where does the work enter, who owns each step, what happens when a step fails, how do you know it failed, what's the state when you resume, and who is accountable for the output.

AI is a new actuator. A staggeringly good one — the first one I've ever had that can handle ambiguity, which is genuinely new and I don't want to undersell it. But it's an actuator. It attaches to a process. If you don't have a process, an LLM doesn't give you one. It gives you thirty enthusiastic strangers with no org chart.

An engineer at a workbench machining a precision tool by hand, while in the background a row of robotic arms wait with open grippers to receive it

A Prompt and a Prayer

Here's the parallel that makes this concrete, because we've already lived through it once.

Software engineering went through exactly this. The tools got good enough that anyone could build something. Visual Basic, then Access, then WordPress, then no-code, and now an agent that writes the whole thing. And every single time, the same thing was true: the floor for building a small working app dropped through the basement, and the ceiling for building enterprise-grade software did not move at all.

With an agentic AI, anyone can build a small app. That is real, it's not a slight, and it's a genuinely wonderful development. Go do it.

Now try to build something that ten thousand people depend on. Something with authentication boundaries and per-tenant data isolation. Something where a schema migration has to run against live data and be reversible. Something observable enough that you find out it's broken from a monitor and not from a customer. Something idempotent, because the job will run twice. Something with a rollback path, a blast radius you've actually calculated, and a supervised process manager so the worker doesn't die silently at 3 a.m. and take a week of deliveries with it.

You do not get there with a prompt and a prayer. You get there the same way you always did: someone who understands the system designs it, and then uses whatever tools are available to build it faster than they could have before. The tool changed. The prerequisite didn't.

Four Questions That Actually Separate People

So if the count is noise, what's signal? Four questions. None of them is "how many."

Question 1

Are you a leader? Delegation is a skill, and most people are bad at it in exactly the same way with agents as they are with people. You either define an outcome, scope the authority, and verify the result — or you hand over something vague and then either micromanage it or get surprised by it. Running thirty agents badly is just being a bad manager thirty times concurrently.

Question 2

Are you a process engineer? Can you take a thing you do by hand and decompose it into steps with owners, inputs, failure modes, and a defined state at every boundary? Because that's the artifact. The agent executes the process; it does not invent it. If you can't draw it, you can't delegate it — you can only describe it and hope.

Question 3

Do you understand the security trade-offs? Every capability you grant an agent is an expansion of your attack surface, and most people granting them have not thought about it for thirty seconds. What credentials can it reach? What can it write to? Is it reading untrusted input, and if so, do you understand that untrusted input is now partly in control of it? What's the worst single action it can take, and can it take that action twice?

Question 4

Do you build tools for your agents to use? This is the one that actually sorts people, and almost nobody is doing it. Keep reading.

Build Tools for Your Agents

The fourth question is the dividing line, and it's the least discussed thing in the entire agentic discourse.

Almost everyone treats an agent as something you talk to. You write a better prompt, you stuff more context in, you give it a personality, and you hope the quality of your instruction carries the day. That's the middle floor — I've made this argument before about which layer the AI-tips discourse lives on.

The move nobody makes is to stop writing better instructions and start building infrastructure the agent can query and execute, so it doesn't need the instruction.

A worked example from my own setup. I run more than twenty projects on one server, and each has its own agent. Early on I kept re-explaining the same things: where does this project live, what's the URL for that service, who owns this, what's already been decided. Endless context, re-pasted, going stale the moment anything moved.

So I stopped explaining and built things instead:

Notice what none of those are. None of them is a persona. None is a prompt. None makes the model smarter. Every one of them converts something I used to explain into something that is simply true of the environment — which means it can't be forgotten, misremembered, or dropped when a context window fills up.

When you find yourself writing the same instruction for the third time, you have found a missing tool. Stop writing the instruction. Build the tool.

A single figure at a terminal inside a glass containment cell, the boundary of its reach marked by a bright line on a wet floor, the rest of the dark facility stretching away beyond it

This is also, not coincidentally, how you answer question three. My agents mostly can't reach credentials, because credentials sit behind an abstraction that hands out scoped, revocable tokens instead. That's not restraint on the agent's part. It's a wall. The security posture is a property of the system, not a promise in a prompt.

The Enterprises Already Priced This In

If this sounds like one guy being sour on LinkedIn, note who else has already moved.

The firms that spent the last year deploying agents at scale are quietly changing what they report. PwC says it now cares less about how many agents it has deployed than how many people actually use them. EY and Boston Consulting Group track productivity, cost, and time saved. Meanwhile the count itself keeps inflating — agents were mentioned in 2,175 public company earnings transcripts last quarter, double a year earlier, and Salesforce says more than 25,000 companies have built something on Agentforce.

That's the shape of every metric that gets adopted because it's easy to produce. It goes vertical, it saturates, and the serious operators quietly stop reporting it and start reporting outcomes instead. The count has about a year of life left in it as a signal. Adoption is not usage, and usage is not value.

So What Is the Number

If you want a metric, here's the one I use, and it isn't a count of anything.

How many things are running right now that you are not thinking about?

Not agents. Processes. Things that were once work you did, that now happen without you, correctly, and that you'd find out about if they stopped. That number is the only one that tracks multiplication, because it's the only one that can't be inflated by adding another costume.

Thirty agents that need you watching them is one job with extra steps — and six hours a week of botsitting is the bill for the difference. Six processes you genuinely forgot about because they've been right for four months — that's leverage. The count of agents involved is an implementation detail, and honestly, if you've built it well, you'll have to go look it up.

Which is exactly why nobody who's really doing this posts the number. They don't know it off the top of their head.

1:1 With JP

The gap between running agents and engineering a process is the whole ballgame, and it's faster to close with someone who's built the second one a few times. $100/hr on Zoom, $250 for three hours. On-site in NYC, Jersey City, or Hoboken adds a flat $50 travel fee.

→ Book a session

— J.P. Howlett

Related:

Sources