As More AI Agents Are Deployed, Humans Become the Slowest Link

Should parallel tasks be handed to a coordinator to track progress while the human only watches the main conversation? Or should the human open each thread separately to track progress? In his tweet, Baoyu pushed this debate one step forward: neither is good enough.

With only a main session, subtasks are opaque to the human. It is like a boss handing work to a department director: you cannot see execution details, and if you want to add context or make adjustments, you have to go past the director and enter the task directly. With just a pile of sessions, the management cost falls back on the human. You have to remember what each session is doing, which amounts to being your own project manager for every project.

Baoyu's ideal state is a combination of the two. The human only watches the main conversation; each time a message is sent into the conversation, the coordinator decides whether it is ordinary chat or belongs to a certain task. Specific tasks can be opened and intervened in. It is analogous to a boss and department heads: the boss only deals with the heads, and the heads assign work, but the boss must be able to go past the heads to see task details and give direct instructions. One commenter put it more bluntly: the coordinator watches the threads, I watch the coordinator, and in the end I am still working overtime.

This reply hits the key issue. Once the coordinator becomes a new single point, the human has merely gone from watching a pile of sessions to watching one coordinator. If the triage decision is wrong, there is no obvious signal. When an instruction goes into the wrong task, or a task instruction is treated as chit-chat, it often becomes visible only after the task has gone off track. One commenter asked: if triage is wrong, who discovers it?

Halcight's article offers an actionable process. He pushes eight projects forward at the same time, with up to 17 agents running at peak, managed with Herdr. The tool solves visibility; the real bottleneck is attention: switching pane by pane means rebuilding project context every time, and the more agents there are, the more likely the human is to become the slowest link in the system. His approach is a two-layer structure plus a dedicated orchestration agent for patrols. The main agent is responsible for one project's context, plan, and PRs; sub-agents only do tasks with clear boundaries and do not spawn further sub-agents. The orchestration agent is not responsible for any project; every five minutes it reads the latest output from all agents and reports only things that need human handling.

Patrols have two steps. First, check for overlap: whether two agents are modifying or making decisions in the same area - a module, a document, an API contract, a PR, a deployment. If overlap is found, notify both parties and have them align before making further changes. Then check pending items: whether an agent is stuck on an approval or question dialog, whether the last reply requires a human decision, whether it reports an unfixable failure, and whether the host is abnormal. The report structure is fixed: first overlap, then things that need humans, and finally one line each for working, waiting, and idle. The point of this process is attention allocation: direction and trade-offs are set by the human; who is waiting for someone and who is conflicting with whom can be clearly defined and handed to the orchestration agent for periodic checks.

One commenter's approach is more decentralized. pcat is split into several bots, with each bot handling only one thing: X drafts, data, and website news each have their own conversation, and to intervene you go directly into that bot to add context. Bots rarely pass messages to each other; they mainly read and write the same shared set of Markdown files, so it is possible to look up who did what. This idea makes the task entry point the bot boundary, at the cost of the human having to remember which bot to check.

Another commenter divides the process into three stages. In the first stage, one bot and one chat window run all tasks 24/7; the problem is not knowing each task's progress and results. In the second stage, projects are split by task, then bots are split by work node, with a central brain retained to arrange the bots below and set rules and standards. The problem is still not knowing the specific progress of each task. In the third stage, a visual workbench is added to see each task's progress and project details, and to correct problems in time. The sketch shows tasks, nodes, and alerting logic.

Ham.DeepQueue's approach is to first lay down codex-style sessions and parallel agents at the underlying layer, then introduce the bot concept, with a coordinator coordinating sessions and parallel agents. Xuanyuan added in a reply: first lay the sessions and parallel agents down at the bottom, otherwise the coordinator has nothing to coordinate; if something breaks, you still have to click into that thread and look yourself.

Kyaver uses Paseo's custom layout to turn the harness into a chief-of-staff plus N owned bots, with each owned bot managing a group of outsourced bots. Outsourced bots are shut down after use, while every move of the owned bots can be seen. This structure is close to Baoyu's three layers of boss, department head, and task details, except the department head is replaced by a persistent bot.

On the product side, Claude Duet is considered relatively close to this idea, with a Tasks view and an artifacts view, so tasks and results from the main conversation can accumulate. The Grokbot form is friendlier to ordinary users, who do not need to see task details. Herdr's tabs can also open main agents and subagents, and a subagent's session can be viewed and directly intervened in. T3 Code's Orchestra mode likewise supports clicking in to intervene.

Putting these replies together, the debate centers on two things: visibility and intervention cost. Watching only the main conversation gives poor visibility; tasks and results easily get buried in chat logs, like looking for a file in a WeChat group. Watching threads one by one has a high intervention cost, and the human becomes a relay and project manager. A more reasonable form is: the main conversation assigns work, the coordinator handles triage and patrols, and every task keeps a click-through entry point. Tasks and results need independent views and cannot remain only in the main session's chat stream. The coordinator's triage errors need somewhere to be exposed, such as a task view, status files, and patrol reports. Otherwise the human merely goes from watching many sessions to watching a busier coordinator.

Tools can change, processes can be simplified, but there is only one attention. The more agents there are, the more we need to turn 'who is waiting for me' and 'who is conflicting with whom' into checkable processes, while leaving decisions to humans. The commenter's line - 'the coordinator watches the threads, I watch the coordinator, and in the end I am still working overtime' - is a reminder: the coordinator is only an intermediate layer, and the click-through entry points and task views cannot be omitted.

References:

• Baoyu tweet: https://x.com/dotey/status/2121434782433190063
• Xuanyuan tweet: https://x.com/4xy/status/2121420969252139452
• Halcight article: https://halcight.dev/zh/posts/managing-a-dozen-agents/
• Kyaver tweet: https://x.com/kyaver_real/status/2120742060454195389