Attention is the bottleneck

My opinion

In a team that builds with agents, the scarce thing is a person’s attention. That’s the claim of this page. It’s a short sentence from a design document, and I found it worth arguing with. As models need less step-by-step help, what limits the work moves off the model and onto the people who have to follow it.

This is another piece on the theme I keep coming back to: a company should focus on the core of its business. Attention is the thing a company has least of. Spending it on the core is the point.

This page is my opinion, with no hiring statistics on it. Every point is one I’ve already made on another page of the site, in my words from that page, with a link to it. The one outside source is a design document from the DeepSeek Harness account on X. I put it in my finds.

A vendor’s design document, machine translated

The source is an X Article, Exploring Super-agent Design: Towards a More Autonomous Agent System, posted on 2026-11-01 by the DeepSeek Harness account [DeepSeek Harness (vendor)]. It’s a machine translation of a Chinese original, and it’s a design document from a vendor of an agent harness, not research. Whether the account speaks for the company DeepSeek, I don’t know. I don’t claim it does.

The account argues that as models need less continuous monitoring on a single task, doing several tasks at once is limited by human attention, and it says a person can usually follow only three to five active sessions [DeepSeek Harness (vendor)]. In its words the bottleneck to further productivity gains is shifting to “human attention” [DeepSeek Harness (vendor)].

Its design has five parts. A long-lived Router session is the only thing that talks to people, and it hands out tasks to Workers, each running one task with its own context. Events from chat, email and code review arrive as triggers, filtered first by cheap code and then by a model, and replies are tuned to the channel so people are interrupted only for a decision or sign-off. Compute, state and environments are kept apart, and a separate Watchdog session sits outside the system and watches it [DeepSeek Harness (vendor)].

Its tests compare the Router design with a single session that has a subagent tool. The Router design finished simulated tasks in about 12.4 minutes at the median and 15.7 at the 95th percentile, against up to 29.5 minutes for a single session with a neutral prompt, and removing the pass-through of follow-up events to workers raised cache-read tokens by about 37 percent [DeepSeek Harness (vendor)]. These are the vendor’s own figures, from synthetic workloads and simulated coding work. The account itself calls them indicative only [DeepSeek Harness (vendor)].

The first idea is that one place talks to people and the work happens somewhere else. I’ve drawn something close to that already. A lead splits the work, workers run in parallel, and code checks the pieces before anything combines them.

The router’s work, the account says, is often simpler than expected. A lighter model can do it [DeepSeek Harness (vendor)]. It’s the same shape as the second quote. The expensive model is for the hard work.

The account filters events in two stages. Code drops the noise first, on fixed conditions such as the source and allowlists. Only the candidates reach a model [DeepSeek Harness (vendor)]. I make the same point about routing.

The same page says the tests in a loop should be a gate the run has to pass, not the model’s opinion. The Jev chapters take the same cost view of when to let a model decide.

The account’s rule for chat is to notify people only when a decision or sign-off is needed [DeepSeek Harness (vendor)]. I treat the same thing as a cost that has to be counted. And I put a person at the step that can’t be undone.

The account lets its router recall earlier work by following references from one object to the next, and it names long-term memory as the main bottleneck once the system has run for months [DeepSeek Harness (vendor)]. My second-brain series is about the same problem from the other side: what the next reader, person or agent, can find.

I haven’t tested any vault over months, so I have nothing to add on the account’s open problem. Except that it’s the part I’d trust least.

The account runs a Watchdog session outside the main system, checking whether workers are making progress. Maintainers can ask it in natural language why something failed [DeepSeek Harness (vendor)]. From a failed run, I want a record. One I can read myself.

The account says an always-on design takes in untrusted input, that a prompt injection could take over every device connected to the agent, and that an agent needs a way to use credentials without seeing them [DeepSeek Harness (vendor)]. It lists these as open problems. I’d solve them first.

The evidence against

There are three places where my own pages disagree with the design, or ask for more. That’s my reading. And a design document isn’t a finished system.

First, proactive. The account wants an agent that acts on events without being asked, and stays quiet otherwise [DeepSeek Harness (vendor)]. My rule: a script decides what a script can. A person decides anything that can’t be undone.

Second, the watchdog. A model judging whether a worker is making progress is a model grading a run. I don’t trust that.

Third, a watchdog you question in chat isn’t a receipt. What I want is a record that a named check passed on this content. Not an answer from a session.

The account says its tests are indicative only. I read them that way too. They don’t tell me a router beats a single session on real work.

An always-on agent with a router, workers, triggers, a separate state store and a watchdog is a lot of system to own. For most businesses, that’s a build. And I’ve said when not to build.

I’d put a person’s attention on the core of the business, and on deciding whether a system like this is core.

My opinion

The account and I agree on the end of the argument. As the models improve, people move up to decisions and sign-off, and every interruption of a person costs something. A team that builds with agents should spend that attention on the core of its business and on gates and records it can read, and let the rest run without asking.

• Designing an agent graphRouters, workers, gates and budgets.
• Jev: a model that decidesThresholds, and what an interruption costs.
• Traces, checkpoints and receiptsThe records you can read.
• Security in the age of AIThe agent as a system to defend.
• Who to hire nowThe engineer worth having on a team has changed because of LLMs, agent graphs and second brains: my points from other Lab pages, gathered and linked.
• What gets cheap, and what doesn’tWhen execution gets cheap, where the margin moves: a model’s answer taken apart with my own Lab pages, and my claim about guarantees and service contracts.

• DeepSeek Harness (vendor) · DeepSeek Harness (@DeepSeekHarness), X Article "Exploring Super-agent Design: Towards a More Autonomous Agent System", posted 2026-11-01; a vendor design document, a machine translation of a Chinese original, with self-reported figures from synthetic workloads (read 2026-11-02)