Throughput, Not Activity

AI can make individual tasks faster without making an organisation complete more useful work. The difference becomes measurable once you follow the whole path from first draft to finished result.

By Stefano Zoia · 5 October 2026 · 6 min

TL;DR

What the evidence supports: AI can accelerate individual tasks while review, testing and decision processes limit how much useful work gets completed. Adoption and activity alone do not establish productivity gains.
What remains uncertain: The research discussed here does not establish that most organisations have become less productive, or that people are the sole constraint. Faster tasks, better decisions and greater autonomy are different outcomes.
What businesses can do: Track completed work, elapsed time, quality and total effort. Identify where work waits or returns for correction, then address that constraint before expanding generation.

Imagine a team that once prepared five proposals a week and can now draft fifteen. The people responsible for checking feasibility, pricing and contractual terms can still approve only five.

The drafting team is faster. The organisation may still send the same number of proposals, with a larger queue waiting for review.

This is an illustrative example, not a research finding. It captures a question that AI adoption dashboards rarely answer: has the organisation improved the work it completes, or simply increased the work it starts?

Research published in September 2026 gives that question practical weight. It describes limits in review capacity, decision ownership, governance and organisational readiness. It does not establish that AI has failed to improve productivity across most businesses.

The distinction matters. The management problem is to find out where faster individual tasks produce better results—and where the benefit is absorbed elsewhere.

Three measures that should not be confused

Activity, throughput and productivity describe different things.

Activity measures what people and systems do: drafts generated, analyses run, code written or recommendations produced.

Throughput, as used here, measures useful work completed within a given period: proposals delivered, contracts finalised or customer cases resolved.

Productivity relates useful output to the resources required to produce it.

An organisation can improve productivity without increasing throughput. Completing the same work with fewer hours and unchanged quality is a real gain. It can also increase throughput without improving productivity, if the extra output requires disproportionately more effort.

That is why counting completed work is necessary but insufficient. Quality, cost and rework belong alongside it.

In the proposal example, faster drafting might free time for customer conversations even if the number of proposals stays constant. Alternatively, it might create additional checking and correction that consumes the time saved. The adoption dashboard would look similar in both cases. The economics would not.

Faster generation can expose slower stages

McKinsey’s Technology Trends Outlook 2026 describes a growing imbalance in software development: AI can produce code faster than organisations can review, test and deploy it securely. It identifies a related issue in scientific research, where generating candidates does not remove the work required to validate them. [1]

This supports a specific operational concern. Accelerating one stage does not automatically accelerate the whole process.

It does not mean that generated work is wasted, that review is unnecessary or that humans should be removed. Review may be the step that makes an output usable at all.

The question is whether the workflow can absorb the additional volume without accumulating delays, defects or unfinished work.

For a business applying AI, this suggests examining the path after generation. Who checks the result? What information do they need? Which errors send it back? How long does it wait between people or systems?

The answers may point to training or clearer authority. They may also point to poor source data, missing integrations, unreliable outputs or an unnecessarily complicated approval process.

The constraint needs to be observed, not assumed.

Autonomy is a separate question

A Gartner forecast published on 24 September expects that, by 2030, only 5% of organisations implementing supply chain planning automation will make at least 10% of planning decisions autonomously. Its accompanying survey found substantial investment in automation among large organisations. [2]

That juxtaposition can sound like evidence of disappointing returns. It is not enough to establish that.

A planner might make a better decision, with less preparation, while retaining final responsibility. An organisation might deliberately preserve human approval for decisions with significant consequences. Both can be sensible outcomes.

Gartner’s more useful recommendation is to begin with the decision and decide whether AI should support, augment or automate it. Its guidance also calls for measuring improvements in decision effectiveness rather than technology deployment. [2]

This gives managers a more demanding test than an autonomy target: what improved because the capability was introduced?

Organisational conditions matter, but “people” is not a diagnosis

Gartner’s September research on data governance provides another relevant signal. In a survey of 223 data and analytics leaders, cultural resistance was cited more often than funding constraints as the primary reason governance initiatives fail: 60% versus 40%. [3]

That is evidence about governance programmes, not a direct measurement of AI productivity. It nevertheless highlights why installing a capability and making it work inside an organisation are different tasks.

Calling the problem “people” is too vague to help.

An employee may lack the skill to assess an AI-generated recommendation. They may also lack access to the evidence behind it, permission to act on it or a clear definition of an acceptable result. More training addresses only the first of those problems.

The practical task is to distinguish capability, information, authority and process. Each requires a different response.

These studies concern different settings and measures. They should not be combined into a single estimate of AI’s business impact. Their value here is to identify questions an organisation can investigate in its own work.

Measure the whole path to completion

Start with one recurring workflow that has a recognisable result.

Define what “complete” means before measuring speed. A proposal may be complete when it reaches the customer with approved terms. A service case may require a confirmed resolution, rather than a closed ticket. A software change may need to be deployed and working, rather than merged.

Then track four things:

Completed work: how many comparable items reach that agreed endpoint.
Elapsed time: how long they take from request to completion, including waiting.
Quality: errors, rejected outputs, reopened cases and other signs that completion did not hold.
Total effort and cost: generation, checking, correction and relevant tool costs.

Use comparable work and record changes in complexity, staffing and demand. A quieter month or a shift towards simpler requests can otherwise look like an improvement caused by AI.

Alongside those measures, inspect the queue. Where does work accumulate? How old are the waiting items? Which steps repeatedly return work for correction?

This turns a general discussion about adoption into a specific operational decision. The response might be to improve inputs, simplify an approval, strengthen testing or give a qualified team clearer decision rights.

It might also be to generate fewer items.

Fix the constraint you can see

If review is overloaded, increasing generation can enlarge the backlog. If drafts are consistently inaccurate, adding reviewers may treat the symptom while leaving the cause intact. If approved work waits for a decision nobody owns, faster drafting is unlikely to resolve the delay.

The appropriate change depends on the observed constraint. After making it, measure again: removing one source of delay may reveal another.

This is why “redesign the last human step” is too narrow a prescription. The relevant constraint can sit anywhere in the workflow, and it may be technical, organisational or a combination of both.

AI usage remains worth tracking. It can show whether a capability is reaching its intended users. But usage cannot tell you whether the organisation is completing better work, sooner, with less effort.

Before expanding an AI programme, ask the team to show what happens between the first generated output and the finished result. That is where the productivity claim becomes testable.

— Stefano

Sources

McKinsey & Company, Technology Trends Outlook 2026, September 2026. See the discussion of generation outpacing review, testing and validation.
Gartner, “Gartner Predicts Only 5% of Organizations Will Make at Least 10% of Supply Chain Planning Decisions Autonomously by 2030”, 24 September 2026. The accompanying survey covered 243 senior leaders at organisations with annual revenue of at least $500 million.
Gartner, “Gartner Predicts 60% of Organizations That Ignore Data Governance Culture Challenges Will Fail to Govern AI Successfully by 2027”, 21 September 2026. The cultural-resistance and funding figures come from its March 2026 survey of 223 data and analytics leaders.