I Managed 16 AI Agents for 30 Days. I Became the Bottleneck.

A study of my 30 days @claudeai code @AnthropicAI .jsonl and @herdrdev logs by @cancelik

Except sleeping, eating, working out in the gym, i kept myself connected via mobile apps like Moshi by @odd_joel to engage with agents in herdr.

NOTE:

• I don't count sub agents spawned.
• When I say it seriously, I mean give solid input, check, review and verify, not just keep saying yes or like in yolo mode!
• It is all serious software application projects not toy apps for vibe coding demo, which means each ran thru full lifecycle development QA, verify, UAT, push back, correction etc.

So, eventually, I didn’t run out of tokens. I ran out of myself.

My Setup

• I use Herdr as the runtime: multiple coding agents, each alive in its own terminal pane, with visible working, blocked, and idle states.
• I use @Larksuite (a Slack counterpart on steroids) as the agent operation layer. Context, plans, research, decisions, and artifacts all flow back into one place.
• And I built a personal baby Xirp (by @SpotifyEng available on Spotify Backstage which is an agents management apps) which I can see sessions, worktrees status via a terminal tunnel, so that, whether my agents doing the projects on my personal laptop, or on my server, i have one place to chat and monitoring the status, and all agents sharing the same context, session memory, and with skills that agents will automatically create a Lark channel like @SlackHQ code channel and update status in Lark's bitable like @airtable with Kanban views like @jira

My original theory was about token throughput

For a fixed model and service, several variables are relatively stable:

• time to first token
• tokens per second
• model capability
• API pricing and rate limits

A day is still 24 hours. My attention span is finite.

That leaves one powerful variable I can change: concurrency 🤔

If one agent can generate a certain amount of useful work in a day, then running several agents should multiply my output. And if agents can delegate to other agents, perhaps that capacity can grow even faster.

At first, this felt true.

While one agent was coding, another could research.

A third could inspect a bug.

A fourth could prepare documentation.

Herdr made it easy to see which agent was moving and which one needed me.

Not my herdr workspace, but similar

I was consuming more tokens, but more importantly, I was directing more work.

Then the fleet got fast enough to expose the next constraint.

The first wall was attention

Peter Steinberger, the creator of OpenClaw, reportedly put it perfectly:

“Six months ago, my bottleneck was tokens. Then I joined OpenAI. Now my bottleneck is attention.”

I felt this almost immediately.

Starting another agent is cheap. Giving it a task is cheap. Letting it run is cheap.

But every agent creates a future claim on my attention.

At some point,

• it will need clarification.
• It will make a decision I did not anticipate.
• It will finish and ask for review.

Or worse, it will confidently declare success when the work is only superficially complete.

I can drink another Red Bull. I can sleep less. I can jump between more terminal panes.

As you can see, in the last 30 days agents were still waiting on me around 40% of the time — I tend to fire off as many sessions as I can before bed, but still most of time, agents are waiting for my input.

More agents do not remove the attention ceiling. They reach it faster.

The deeper wall was verification

Then Jason Wei’s blog, Asymmetry of Verification and Verifier’s Rule, started making much more sense to me.

Jason, now at Meta Superintelligence Labs, describes how some problems are much easier to verify than to solve. A Sudoku puzzle may take a long time to complete, but checking the finished answer is relatively easy.

That asymmetry is enormously valuable for AI. If a solution can be evaluated quickly and objectively, the system can generate and test many candidates.

But not all product work has that property.

Sometimes verifying an agent’s output takes almost as long as producing it manually. Sometimes it takes longer.

An agent can implement a feature in minutes. I still need to open the product, understand what changed, test the primary flow, try the edge cases, compare the result with my original intent, and decide whether it actually feels right.

That last part matters.

A test can tell me whether the button works. It cannot always tell me whether the product became better.

This is where I hit my real limit: UAT.

The agents were no longer waiting for compute. They were waiting for me to decide whether their work was acceptable.

The faster the fleet moved, the longer my verification queue became.

Completion is not acceptance

This forced me to separate several things I had unconsciously treated as one:

• generated output
• technically valid output
• accepted output
• shipped value

Agents are already extremely good at increasing the first number.

With automated tests, they can improve the second.

But the third and fourth still depend heavily on human judgment, especially in product work involving ambiguous requirements, UX, taste, priorities, and trade-offs.

So measuring token consumption alone tells me very little.

A fleet can burn millions of tokens and create an impressive pile of work. If I cannot verify, integrate, and ship it, that pile has almost no value.

My current model is:

AI effective capacity = min(compute from tokens, acceptance, attention)

Increasing compute only helps until one of the other two terms becomes smaller.

And right now, acceptance is becoming my shortest stave.

I may need to study “Acceptance Engineering”

I’m using this as a working term, not an established discipline.

Acceptance Engineering means designing the work so that correctness and usefulness become cheaper to verify.

That starts before an agent writes any code.

What does “done” mean? What evidence must the agent return? Which tests should pass? What screenshots, logs, or before-and-after comparisons should exist? Which decisions can a verifier agent make, and which decisions still require my judgment?

The goal is not to eliminate human review. It is to reserve human attention for the places where it has the highest value.

• Herdr can tell me which agent is blocked.
• Lark can hold the plan, acceptance criteria, decisions, and evidence.
• Automated tests can reject obvious failures.
• Verifier agents can independently challenge the implementation.

Risk tiers can decide whether a task needs a quick check, a full UAT pass, or my direct involvement from the beginning.

That is a much more interesting problem than simply opening more agents.

Managing agents became a mirror

I started this experiment to discover how many agents I could run.

Instead, I discovered the limits of my own agent fleet management system.

The fleet amplified my ability, but it also amplified every weakness in how I think and manage.

That may be the deepest lesson.

Originally published as an X Article on September 13, 2026. Read on X ↗