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

- URL: https://os.klynwuu.xyz/posts/i-managed-16-ai-agents
- Author: Hong (克林) — https://os.klynwuu.xyz/readme
- Published: 2026-09-13
- Language: English
- Tags: ai, work

> Thirty days of Claude Code and Herdr logs with up to 16 AI agents in flight showed that tokens were never the limit — my attention and my ability to verify the work were.

![Cover: Klyn at a desk in a blue-lit room, shown in a green-and-blue thermal-camera look, chin resting on one hand, under the red words “I'm the Bottleneck”.](https://os.klynwuu.xyz/images/x-article-bottleneck.jpg)

A study of my 30 days [@claudeai](https://x.com/claudeai) code [@AnthropicAI](https://x.com/AnthropicAI) `.jsonl` and [@herdrdev](https://x.com/herdrdev) logs by [@cancelik](https://x.com/cancelik)

Except sleeping, eating, working out in the gym, i kept myself connected via mobile apps like Moshi by [@odd_joel](https://x.com/odd_joel) to engage with agents in herdr.

![The Moshi app on an iPhone in dark mode: two live tmux sessions, my-opc-ai-infra and .hermes-ops, each with a Claude Code resume command; a connection marked “Needs attention: 1”; and shortcuts to tmux sessions, Herdr workspaces and Jump to.](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/01-moshi-sessions.webp)

### 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.**

![Terminal chart “fleet experiment week · multiplier vs baseline”: agents in session 16×, output tokens per day 3.95× (1.11M → 4.40M), commits per day 9.3× (10.2 → 95.2), three or more agents concurrent 99.8% of the week. Bottom line in red: 16 agents ≠ 16× output.](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/02-fleet-week-multiplier.webp)

### 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](https://x.com/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](https://x.com/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](https://x.com/SlackHQ) code channel and update status in Lark's bitable like [@airtable](https://x.com/airtable) with Kanban views like [@jira](https://x.com/jira)**

![A macOS menu bar dropdown for the agent fleet: 1 running · 8 workers · 2 worktrees, Bus: 3 listeners up; the hub session at about 378k context tokens over 58 turns; seven stopped project workers, one with two feature worktrees; and New Project Worker, Resume All, Stop All, Keep Mac Awake (caffeinate) and Quit (workers keep running).](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/03-menu-bar-workers.webp)

![A Lark sidebar titled “CCT Projects” listing twelve project group chats, each named “CCT·” followed by a blurred project name, one with an unread badge.](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/04-lark-cct-projects.webp)

### 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.

![A Herdr workspace in a phone terminal, a similar setup rather than mine: spaces and grouped Codex agents on the left; on the right an agent reports 1,082 unit tests, 8 emulator checks, lint and a debug build passed after working 12 minutes 45 seconds, but it could not confirm the app on the locked device.](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/05-herdr-mobile-workspace.webp)

> 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._**

![Terminal chart “concurrency · normal weeks (fleet week excluded)” from agent session logs: zero agents in session 43.2% of the time; only one agent during 61.9% of active time; four or more agents concurrent during 6.2%. Header: “the compute is ready. the queue is empty.”](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/06-concurrency-normal-weeks.webp)

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_](https://www.jasonwei.net/blog/asymmetry-of-verification-and-verifiers-law), 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**.

![Terminal chart “throughput · one operator”: 100 generated, 12 verified and accepted, and attention can hold 2–4, marked as the min(); an unverified backlog of 88 — unread messages, half-builds, rework. Effective capacity = 12, not 100.](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/07-throughput-one-operator.webp)

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)**

![Terminal dashboard “herdr – fleet monitor · 30 days”: 30 days, $20k+ tokens, 21 repos, a peak of 16 agent panes, managed from one phone. Center: effective capacity = min(generate, verify, attention), with generate 100/day, verify 12/day and attention 2–4 threads highlighted. Footer: macOS, iOS, web, backend; commits per day 10.2 → 95.2.](https://os.klynwuu.xyz/images/i-managed-16-ai-agents/08-effective-capacity.webp)

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 ↗](https://x.com/klynwuu/status/2099243491239063730)