November 2026 · 5 min read
AI pays inside functions and stalls at the seam
Key Definitions
Seam The boundary between two functions where one unit output becomes another unit input. It usually has no report and no named owner, so the loss it causes is counted by neither side.
Age of the oldest item How long the longest-waiting item in a queue has waited. It reflects real impact better than average wait time, which flattens the tail.
Rework rate The share of items a downstream step sends back. It measures whether upstream output is usable, not merely fast. Returns clustered in one reason mean the acceptance standard was never aligned.
At two in the morning the social publishing job wakes up, opens its queue, and finds the oldest item is an article published twelve days ago. The article itself took two days to write, shipped in Chinese and English, passed every check, and returns 200 on all four URLs. It is waiting to be turned into copy for a few platforms, and that work does not belong to the person who wrote it.
The handoff itself is normal. Work gets handed on. What is not normal is that twelve days went by without anyone reporting the gap. The writing unit looks at its own delivery, on time and on target. The social unit looks at its own output, daily volume, also on target. Both weekly reports are green, the twelve days belong to no department metric, and so they do not appear anywhere.
An article in Harvard Business Review last week moved this from intuition to evidence. Its conclusion is that most companies use AI well inside individual functions and never cross the boundaries between them, which is why enterprise productivity data shows no movement. That claim deserves attention from anyone calculating an AI return, because if it holds, the problem is not model capability and the money is in the wrong place.
Three studies, one direction
Hastings, Syverson and Zimmerman assembled three published surveys in their October 21 piece. The first, from early 2026, asked nearly 6,000 senior executives. Sixty-nine percent said their company actively uses AI, more than two-thirds use it themselves, and about nine in ten reported no measurable effect on productivity or employment. The underlying work is NBER working paper w34836.
The second is McKinsey in 2025: 88 percent of organizations use AI regularly, and only 39 percent report any enterprise-level EBIT impact. The third is narrower still. In a 2025 business AI survey, only 5 percent of pilots had produced a measurable bottom-line impact.
The samples and methods differ, and the conclusion repeats: high usage, thin results. Consistent findings across independent studies usually point to a structural cause rather than insufficient effort at the execution layer. The explanation HBR offers is that tools optimise work inside a function, while value requires crossing the boundary between functions.
Label this evidence for what it is. All three are self-reported corporate surveys, not audited financials, and the third comes from a commercial publisher with weaker sample coverage than the first two. They work as direction indicators, not as precise benchmarks.
Why faster inside makes the whole slower
An old result explains the paradox. Amdahl law says that speeding up one part of a system caps the overall gain at the parts you did not speed up. A ten-step process with one step cut from ten hours to one minute barely changes in total, because the other nine steps still take nine hours.
Organisational processes have that shape, and the handoffs are the parts nobody accelerated. AI makes output inside a function cheap: writing code, drafting, translating, cleaning data, assembling reports. The handoff does not get cheaper with it, because handoff cost is not generation cost. It is waiting cost and accountability cost. Waiting needs someone watching the queue, and accountability needs a signature.
So the relative cost shifts. Generation used to take eighty percent of the clock and handoff twenty. Generation drops to thirty, the handoff stays at twenty, and its share rises to forty percent. The end-to-end chain does not get three or four times faster, which is why departmental efficiency figures look strong while enterprise productivity stays flat.
There is a counterintuitive second effect. Once an upstream step speeds up, it produces more items per hour for the same downstream capacity, and the queue grows. Longer waiting eats all the time saved upstream and can eat more, because items in a queue have a shelf life, and expired items get redone.
Three quantities worth measuring at the seam
Handoff is easy to discuss as a concept, so it needs numbers. At the seam there are only three worth watching.
The first is waiting time: how long between an item leaving one step and the next step picking it up. Any system with a queue already holds this value, and no new platform is required.
The second is the rework rate: the share of items sent back by the downstream step. This number says more than waiting time, because it measures whether the upstream output was usable. If the reasons cluster in one category, the acceptance standard was never aligned, which is not an execution failure.
The third is ownership: whose name is on the record when something goes wrong after the handoff. That one is not a number, but it decides whether the first two ever improve. It is also the most often missing, because organisations naturally prefer a seam with no owner.
All three share a difficulty. They sit in the middle of a boundary rather than at the exit of any report. Each department instruments its own exit, and once the data is exported it belongs to someone else. So either a person assembles the chain across systems, or nobody looks.
Assembling that chain is cheap. In the article-to-social case, the start timestamp lives in the content system and the end timestamp lives in the publishing queue. Joining them takes ten minutes. The reason it does not happen is not technical. Nobody is measured on the middle segment.
Our own measured numbers
Using ourselves as the sample is more convincing than citing a survey, and also harder. Our chain runs like this: an article goes live, enters a derivation queue, another unit rewrites it for each platform, a person publishes. The queue holds 52 records: 43 derived, 5 pending, 4 skipped, and the oldest pending item has waited twelve days.
Forty-three against five is not an ugly ratio, and an eighty percent processing rate would pass in most teams. The twelve days exposes the mechanism: how fast the queue drains depends on the workload of a different unit, and that unit is not asked to report the age of its oldest item.
There is a finer cause underneath. An article has a two-day writing cycle and goes live the same day, while social copy has a shelf life of hours. The two cycles differ by an order of magnitude, and the handoff sits exactly at that interface. Upstream plans by the week, downstream operates by the hour, and the gap does not close on its own. It accumulates.
State our limits. Fifty-two records cannot support a statistical conclusion, and twelve days may be an outlier rather than the norm. Its value is as a checkable example: one organisation, two units, both sets of metrics healthy, and the segment between them broken for twelve days. That is not a technology problem. It is an organisation that never treated the segment as work.
We have not fully fixed it either. What we do now is put the age of the oldest item into a daily check and escalate past three days. That is an alert, not a repair. A repair requires the downstream unit to treat the queue as its own inventory rather than as orders arriving from someone else.
Three repairs, and how to tell they worked
The first repair moves acceptance onto the seam. When upstream delivers, it delivers something downstream can use without asking: not a task description, but the criteria. An article ships with its core claim in one sentence, the data points allowed for citation, and the boundary of permitted rewriting. Downstream takes all three and stops needing to ask, and waiting time drops.
The test is whether downstream can finish without a conversation. If it must ask three questions before starting, upstream delivered an incomplete package, and half the waiting time is upstream fault.
The second repair turns queue depth into an alert. Do not measure average waiting time. Measure the age of the oldest item. Averages hide the tail: one item stuck for thirty days and thirty items stuck for one day average out the same, but the business consequence differs entirely. The test is whether the alert has ever been acted on. An alert nobody responded to does not exist.
The third repair puts the rework rate into the upstream scorecard. When output is sent back, the rate lands on the producer rather than on the unit doing the checking. This is the hardest to push because it changes appraisal, and it is the only one that makes upstream improve delivery on its own. The test is whether return reasons get categorised. If everything is filed as a quality problem, the metric is dead.
These have an order. Do the second first, because it is cheapest and produces a number within a week. Then the first, which requires two units to sit down and align. Then the third, because it touches appraisal. Done in reverse, the sequence usually stalls.
Not every seam is worth repairing
Treating cross-function optimisation as a universal principle wastes money. Some handoffs should not be instrumented.
Low-frequency handoffs, for one. Something that happens once a quarter at a three-day wait costs nothing worth measuring, and building a monitor for it is negative value. Low-value handoffs are the same case: if the output on both sides is worth little, optimising it saves zero.
Another class is delay that belongs in the design. A handoff across a regulatory boundary needs human review, and waiting is the compliance requirement. Driving it to zero releases the risk. The right move there is to write down an acceptable wait ceiling rather than to eliminate the wait.
A simpler test: if the waiting this seam causes in a year were converted to money, would it cover the cost of measuring it. If the number cannot be computed, leave it alone. If it computes and it is large, the seam has earned a dedicated conversation.
Our judgment
The difference in enterprise AI returns is moving from model capability to process interface. Whoever treats the handoff as a piece of work with an owner converts in-function efficiency into enterprise results. Whoever treats it as a natural blank has efficiency gains that stop at the edge of a report.
That judgment has a testable implication. If a company reports AI gains concentrated in internal department metrics while enterprise-level cycle time, inventory turns and customer waiting time do not move, its AI spending has most likely stopped on the left side of the seam.
Three moves for this week
First, pick one cross-department chain you know well, join the start and end timestamps, and compute the age of the oldest item. That is a day of work and needs no approval.
Second, ask the downstream team one question: how many times do you go back to upstream before you can start. Three or more means the problem is in the shape of the delivery, not in downstream capability.
Third, write a waiting ceiling for that chain into one job description and into that job weekly report. A seam without an owner rots quietly, and nobody reports it.
A question for whoever owns the budget: how much of this year AI return was proven inside a single department metric, and how much was proven in the time gap between two departments. The first number usually looks better. The second number is usually the one a customer feels.
References
External figures come from the pages below. Internal figures come from our derivation queue records.
NBER Working Paper w34836 (the survey of nearly 6,000 executives, cited by the HBR piece)
FAQ
Why does in-function speed not become enterprise productivity+
A single accelerated step is capped by the parts left unaccelerated. Handoff cost is waiting plus accountability, and AI does not reduce it. Faster upstream output lengthens the queue and eats the saved time.
Do the three surveys agree+
They agree in direction but not in kind. The executive survey finds 69 percent active use and about nine in ten reporting no productivity change. McKinsey 2025 finds 88 percent regular use and 39 percent reporting enterprise EBIT impact. A third report finds 5 percent of pilots with measurable bottom-line impact. All are self-reported, so direction is credible and precision is limited.
Which quantity matters most at the seam+
The age of the oldest item. It is cheapest to get, produces a number within a week, and exposes impact better than an average that hides a thirty-day outlier.
In what order should the repairs run+
Queue-age alert first, delivery criteria second, rework rate in the upstream scorecard last. Reversed, the first step already touches appraisal and usually stalls.
Which seams should not be instrumented+
Low-frequency, low-value handoffs, and handoffs where delay is part of the design, such as human review across a regulatory boundary. The test is whether a year of waiting, converted to money, covers the cost of measuring it.
Have you fixed your own seam+
Not fully. The age of the oldest item now sits in a daily check with escalation past three days. That is an alert, not a repair. A repair means downstream treats the queue as its own inventory.
Run the same check on your own execution log
Send a redacted 30-day agent execution log and get an eight-row table in 48 hours: one row per technical item, each cell carrying its numerator, denominator and criterion, gaps sorted by whether a schema change is needed. First three engagements are $1,200.
Related Articles
30% more code, no more closed issues
Across 700+ firms, coding agents lifted commits 20% and code 30% while issue resolution stayed flat. The metric that decides AI payback is closure.
70% of FDE agents abandoned: the handover gap
Gartner puts 70 percent of agent projects built by vendor engineers on the abandonment path. The vendor leaves with the standard for a correct judgment.
We Are Our Own First Customer: How OOMeta Runs on AI
We are our own first customer: one human and 7 AI amoeba units run a real company daily. How signals become action, and the measured results.
The pilot reviewer was your eval set
78% of enterprises run an agent pilot, 14% scaled one. The gap is not the model: the pilot human reviewer was the eval set, and scale deletes it.