Your Agents Spend 80% of Their Time Waiting for You: Human Attention Is the New Engineering Bottleneck
Anthropic's own employment data shows agent hours running at six times human hours, with Claude sessions spending around 80% of their time idle, waiting for a person. The constraint on AI-assisted delivery is no longer generation. It is how fast humans can decide.
What Anthropic's Own Numbers Actually Say
Most claims about AI productivity come from vendors describing their customers. This one is unusual because the vendor measured itself. Anthropic's report, written by Nathan Wilmers and Regina Catipon, draws on internal hiring records, output metrics, employee surveys, Slack and calendar data, and 17 employee interviews. Its headline finding is that combined autonomous and interactive agent work hours first overtook total human work hours in March 2026, and by August were running at roughly six times human hours.
The output numbers moved too. According to the report, commits per engineer are about five times their level six months earlier, and the vast bulk of tokens flowing through the company's agents is spent producing software code. If you only read that far, the story is the one every board deck wants to tell: machines doing most of the work, engineers multiplied.
Read further and the picture becomes more interesting. The report states that Claude sessions amount to around 80% idly waiting for human input, and that the vast majority of agents' session time is not spent working at all, but spent waiting. The share of an average employee's interactive sessions devoted to meta-work, managing and monitoring agents rather than doing the task itself, rose from 10% in autumn 2025 to 22% in spring 2026. Coverage of the report adds that median meeting time is up about 20% year on year, and 16% even among technical individual contributors.
The report's own one-line summary is the sentence engineering leaders should pin above their desks: this acceleration makes human attention the bottleneck for agent output. One employee quoted in the coverage described working with an army of Claudes, with every one asking for my attention. That is not a complaint about the tools. It is a description of a production system whose constraint has moved.
Six to One Is a Runtime Number, Not an Output Number
Before drawing conclusions, it is worth being precise about what the ratio measures, because the headline has already been misread in both directions. Six to one compares elapsed agent session time with estimated human working hours. It does not say agents produce six times as much value as people, and the authors are explicit that the session clock keeps running while an agent sits waiting for someone to reply.
The report is also careful about causality. Tool adoption inside the company was not random, early adopters were already on a steeper output trajectory, and the link between agent use and changes in junior hiring is presented as descriptive rather than causal. Anthropic is also not a typical employer: its headcount roughly tripled in a year, its engineers build the models they use, and they have unlimited access to the most capable versions. Treat the numbers as a view of where a very aggressive adopter has arrived, not a forecast for your company next quarter.
Even with those caveats, the 80% figure is the most transferable finding in the report, because it describes a structural property rather than a Silicon Valley quirk. An agent that can generate a plausible change in minutes but needs a human to clarify a requirement, approve a migration or review a diff will spend most of its wall-clock life blocked. The faster the agent gets, the larger the share of its time spent waiting. Improvements in model speed now mostly increase idle time.
That inverts a long-standing assumption in software delivery. For decades the scarce resource was the engineer's ability to produce code, and processes were designed to keep developers busy: queues of tickets, sprint commitments, utilisation targets. When production becomes cheap, the scarce resource becomes the human's ability to decide, and every process designed to maximise developer utilisation starts working against you.
Key Takeaways
- Agent hours passed human hours in March 2026 and reached about six times human hours by August
- Around 80% of Claude session time was idle, waiting for human input
- Meta-work rose from 10% to 22% of interactive sessions in roughly six months
- The ratio measures elapsed runtime, not output; the report presents its hiring findings as descriptive, not causal
Where the Waiting Shows Up in Your Pipeline
You do not need access to Anthropic's internal telemetry to see the same effect in your own delivery data. The most concrete public evidence comes from LinearB's 2026 Software Engineering Benchmarks, built on more than 8.1 million pull requests from 4,800 teams. At the 75th percentile, agent-authored pull requests waited 17.6 hours before anyone picked them up, compared with 3.4 hours for unassisted work. Once picked up, review took 6.4 hours against 4.2 hours for unassisted changes. And AI pull requests merged within 30 days only 32.7% of the time, versus 84.4% for unassisted ones.
LinearB attributes part of the wait to two organisational causes rather than technical ones: unclear ownership of agent-created work, and agentic flows being pointed at low-priority backlog items that nobody is in a hurry to review. Both are attention problems. The code exists; nobody has been assigned to care about it.
Faros AI's Acceleration Whiplash study points the same way. As summarised in this write-up, telemetry from 22,000 developers across more than 4,000 teams showed median time in pull request review rising 441.5% between organisations' low and high AI-adoption periods, 31.3% more pull requests merging with no review at all, and incidents per pull request rising 242.7%. The authors stress these are correlations, but the shape is consistent: more output, longer queues, and a growing share of work that slips through without the human attention it was supposed to receive.
That last point matters most. When attention is scarce, it does not fail loudly. It degrades silently into rubber-stamp approvals, skipped reviews and decisions made by default because the agent kept going while the human was in a meeting. We have written before about the verification gap and about merge queues for agent fleets; the attention problem sits upstream of both. Before a change can be verified or merged, someone has to notice it, understand what it is asking, and decide.
Attention Is a Budget. Most Teams Have Never Written One Down.
Engineering organisations budget compute, cloud spend and headcount with care. Almost none budget decision-maker attention, even though it is now the input that determines throughput. A practical starting point is to treat every request an agent makes of a human as a unit of demand, and every hour a qualified reviewer or product owner has available as a unit of supply.
Measured that way, many teams discover they have quietly scaled demand by an order of magnitude without adding a single unit of supply. Ten engineers each running several agents can generate hundreds of clarifying questions, approval requests and review requests a day. The same product owner, the same tech lead and the same two senior reviewers are expected to absorb all of it, in between the extra meetings that coordinating the agents created.
Anthropic's report gives a sense of scale from the non-technical side: by its estimate, reading everything their agents produce would take non-technical employees roughly half their working week. For engineers, the equivalent is review load. When the volume of reviewable output exceeds the hours available to review it, something gives, and in practice it is depth of review, not volume of output.
Writing the budget down changes the conversation. Instead of asking how many agents each engineer can run, leaders ask how many decisions per day each reviewer can make well, which decisions genuinely need a human, and which could be pre-authorised by policy. It also exposes the people who have become single points of failure: the architect whose approval every schema change needs, or the product manager who is the only person able to say what a feature should do.
Key Takeaways
- Count agent requests to humans as demand and qualified reviewer hours as supply
- Most teams have multiplied demand without adding supply; review depth is what quietly gives way
- Identify single-person approval chokepoints before adding more agents
- Ask how many good decisions a reviewer can make per day, not how many agents an engineer can run
Design Agents to Ask Fewer, Better Questions
The cheapest attention is the attention you never have to spend. A large share of agent interruptions are avoidable, because they ask a human for information that already exists somewhere the agent could not see, or for approval of a decision that falls well within limits nobody bothered to write down.
Three design changes cut interruption volume substantially. First, front-load context: a clear specification, acceptance criteria and links to the relevant architecture decisions before the run starts eliminate most clarifying questions. Second, pre-authorise by policy: if any dependency patch release that passes the test suite is acceptable, say so in configuration, and stop asking a human to click approve. Third, tier escalations: separate decisions that genuinely require judgement, such as data model changes, external-facing behaviour or anything touching money or personal data, from routine confirmations that can be logged and reviewed in aggregate.
The second lever is batching. An agent that interrupts a reviewer twelve times across a day costs far more attention than one that collects its twelve questions into a single, well-structured request at a predictable time. Each context switch carries a recovery cost for the human, and a reviewer who is pinged continually cannot do the deep review work that actually protects quality. Scheduled decision windows, for example two fixed review blocks per day per reviewer, turn an unbounded stream into a manageable queue.
The third lever is the format of the question itself. Agents that present a recommendation, the alternatives considered, the evidence and the consequence of each option let a human decide in a minute. Agents that dump a long transcript and ask what to do next make the human redo the agent's reasoning. Requiring a structured decision summary for every escalation is one of the highest-return changes a team can make, and it is pure engineering work on the harness, not a model upgrade.
Key Takeaways
- Front-load specs and architecture context so agents stop asking for information that already exists
- Pre-authorise routine decisions in policy and reserve human escalation for judgement calls
- Batch agent questions into scheduled decision windows instead of continuous interruptions
- Require a structured decision summary: recommendation, alternatives, evidence, consequences
Decision Latency Has a Time Zone
Once human decisions are the constraint, where your decision-makers sit becomes an engineering parameter. An agent that raises a question at 4 p.m. and gets an answer at 9 a.m. the next morning has lost seventeen hours, and if its work is a dependency for three other agents, they lose it too. In a world where generation takes minutes, overnight round-trips dominate cycle time.
Research on human teams already showed how expensive temporal distance is. A study of more than 12,000 employees at a Fortune 100 multinational, published in Organization Science and summarised by Rice University, found that each additional hour of time difference cut overlapping business hours by 19% and synchronous communication by 11%. The researchers also found that people compensate by working outside normal hours, and that this time shifting has a real cost. Co-author Tommy Pan Fang suggested that projects depending on synchronous collaboration may benefit from deliberately aligning workers on a shared time zone.
Agents sharpen that finding. In a classic offshore model with eight to twelve hours between the client and the delivery team, the follow-the-sun pitch was that work continued while the client slept. With agents, the work does continue, right up to the first question that needs a client-side decision, and then it waits for the next morning. The more autonomous the agents become, the more of the delivery timeline is made of these waits, and the less the overnight handoff is worth.
This is one of the reasons nearshore delivery has become more valuable in the agent era, not less. A team in Serbia, like Stepto's engineers in Belgrade, works in Central European Time: fully overlapping with clients across the EU and the UK, and sharing several working hours each day with the US East Coast. Questions raised by agents, by Stepto's developers or by the client's product owner get answered the same day, and the decisions that unblock agents happen while everyone involved is at their desk.
Key Takeaways
- Each extra hour of time difference cut overlapping business hours by 19% and synchronous communication by 11% in an Organization Science study
- Agents work until the first decision they cannot make, then wait for a human
- Overnight round-trips now dominate cycle time in agent-heavy delivery
- Same-day decision loops matter more than round-the-clock coding
Who Should Be Holding the Attention
The staffing implication is uncomfortable but clear. If the bottleneck is decisions, then the people you need more of are the ones who can make good decisions about code quickly: experienced engineers who know the domain, understand the architecture and can read a diff and know whether it is right. Anthropic's report shows the company moving in exactly that direction, with the junior share of technical hires falling from 27% to 9% and hiring scorecards giving far more weight to candidates' ability to work with AI tools.
That does not mean most companies should stop hiring junior engineers. We have argued elsewhere that a pipeline with no juniors becomes a seniority crisis a few years later, and the same report is careful to call the hiring link descriptive. It does mean that the composition of a team needs to match the new constraint. A team of six where one senior engineer reviews the output of five people and their agents will be blocked on that one person, however fast everyone else becomes.
It also changes what a good outsourcing engagement looks like. Many vendors are still selling capacity to produce code: more developers, more hours, more agents. The client's problem is increasingly the opposite. They need more qualified attention: engineers who can own a part of the system, make routine technical decisions without escalating, review agent output with real context, and only bring the client the decisions that genuinely belong to the business.
That is how Stepto structures dedicated development teams. Our engineers work as long-term members of the client's team rather than as interchangeable hours, so they build the context required to decide rather than ask. Senior engineers own review and technical decisions within agreed boundaries, product questions are batched and brought to the client's owner in shared working hours, and the agent harness is configured so routine decisions are pre-authorised and only judgement calls reach a human. The client gets the throughput gains of agents without becoming the single point every agent is waiting on.
A 30-Day Plan to Measure and Cut Agent Wait Time
Week one is measurement. Instrument your agent workflows to record when an agent first blocks on a human, who it is waiting for, and how long the wait lasts. Add pickup time and review time for agent-authored pull requests to your existing delivery dashboards, separately from human-authored work. Most teams find that a handful of people account for most of the waiting.
Week two is triage of the demand side. Go through a sample of agent escalations and classify each one: information the agent should have had, a routine decision that could be pre-authorised, or a genuine judgement call. Fix the first category with better specifications and context files, and the second with explicit policy in the harness. Only the third category should survive as human interruptions.
Week three is the supply side. Name an owner for every stream of agent-generated work so nothing lands in an unowned queue, introduce scheduled decision windows for reviewers, and spread approval rights so no single architect or product owner gates every change. Check where your decision-makers sit relative to the people and agents waiting on them, and move ownership closer where overnight round-trips are common.
Week four is verification. Compare blocked time, pickup time and review depth against the baseline. Watch the leading indicator of silent attention failure, the share of changes merged with no meaningful review, and treat any increase as a regression rather than a productivity gain. Then decide how many agents your team can actually supervise, and set that as the limit until supply catches up.
Key Takeaways
- Measure blocked time per agent, per human reviewer, and pickup time for agent-authored PRs
- Classify escalations: missing context, pre-authorisable, or genuine judgement
- Assign an owner to every agent work stream and schedule reviewer decision windows
- Treat a rise in unreviewed merges as a regression, not a win
Throughput Now Depends on How Fast People Can Decide
Anthropic's report is one company's data, with honest caveats, but its central observation travels well: when agents can generate faster than people can respond, human attention becomes the constraint, and most of an agent's life is spent waiting. Industry pull request data shows the same queues forming everywhere. The fix is not more agents or faster models. It is treating decision-maker attention as a budget, designing agents to ask fewer and better questions, giving every stream of agent work a named owner, and keeping the people who decide in the same working day as the work that waits on them. If your agents are fast but your delivery is not, Stepto's dedicated nearshore teams in Serbia can add the senior, context-rich engineering attention that turns agent output into shipped software, in hours that overlap with yours.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversation