Do AI Agents Actually Improve Productivity? What Microsoft's 2026 Field Study Suggests

A research preprint published July 1 studied tens of thousands of Microsoft engineers using Claude Code and GitHub Copilot CLI. Over a four-month window, the researchers estimated that adopters merged approximately 24% more pull requests than they otherwise would have. They also found that initial adoption spread mainly through workplace social networks, while continued usage correlated more closely with existing coding activity.

The authors are careful about what this does and does not show. Merged pull requests are a productivity proxy, not a measure of software quality or business value. The paper is a preprint, not final peer-reviewed evidence. Both caveats deserve to travel with the number.

Why the caveats are the interesting part

A 24% figure will be quoted in a lot of business cases this quarter, usually without its footnotes. That is a mistake, because the footnotes contain the transferable lesson.

Merged pull requests measure throughput of a particular artifact. They do not tell you whether the merged code was necessary, maintainable, or connected to something a customer wanted. Any organization that has watched a velocity metric get optimized understands what happens when a proxy becomes a target.

The same trap exists in service management, where it is arguably more entrenched. Tickets closed, conversations handled, first-response time, chatbot sessions initiated, all are proxies. All can improve while the employee experience stays flat or degrades. A bot that answers quickly and unhelpfully will post excellent response-time numbers.

Adoption spreads socially, not by mandate

The finding about social networks matches what deployment teams observe. People adopt a new tool because a colleague they respect is visibly getting value from it, not because a memo instructed them to.

This has direct implications for how AI is rolled out in IT and HR service functions. Three practical consequences:

Meet people where they work. Adoption requires zero friction at the point of need. This is why we built Sidekick into Teams, Slack, email and voice rather than behind a separate portal: a tool that requires a context switch competes with the habit of messaging a colleague, and loses.

Seed visible wins. Early adopters in high-visibility roles do more for adoption than a launch announcement. Give them the use cases most likely to succeed first.

Make success observable. If nobody sees the tool working, the social transmission mechanism the study identified never engages.

The corollary is that a mandate produces compliance, not usage. Licenses purchased is the least predictive number in any AI business case.

Measure completion, not activity

The better metric in service management is the one that maps to work actually finished. That means tracking:

1. Requests resolved without a ticket ever being created
2. Time from question to completed action, not to first response
3. Repeat-contact rate on the same underlying issue
4. Share of resolutions completed autonomously versus escalated
5. Which categories of recurring work remain unautomated

That last one is a leading indicator rather than a lagging one, and it is the hardest to produce manually. DeskIQ exists for this reason. It clusters ticket history into ranked automation opportunities with projected impact, so the next automation decision is based on your own volume patterns rather than on a vendor's suggestion.

What good looks like in the field

The outcomes worth benchmarking against are operational, not theoretical. Black Angus Steakhouse cut after-hours IT dependency from 90% to 10%: a change in where work happens and who absorbs it, not a throughput statistic. MyEyeDr resolves issues in roughly 10 minutes, with about 30% of issues never becoming a ticket. TotalEnergies Denmark's HR chatbot, Robin, answers in about 30 seconds, around the clock, in a function where the previous alternative was waiting for business hours.

Across deployments, roughly 70% of requests are resolved before they become tickets. That number is useful precisely because the denominator is total employee demand rather than tickets created, measuring only what enters the queue systematically hides the work the system prevented.

The honest conclusion

The Microsoft study is a real contribution to a discourse that has been running on vendor anecdotes. It suggests AI agents can produce measurable output gains at enterprise scale, under specific conditions, on one proxy metric, in a preprint that has not yet completed peer review.

That is a more useful claim than most of what is published on this topic, and it should be represented that way. The operational takeaway is not the percentage. It is that value came from adoption patterns and sustained usage: which means enablement, visible peer success and continuous measurement are the variables leaders actually control.

To see what your own ticket history says about automation potential, book a demo or explore DeskIQ.