For Microsoft 365 administrators, developers and IT leaders, the useful takeaway is not a spending target. It is a way to connect workflow design, permissions, workforce skills and measurable outcomes before expanding an AI deployment.
What the research actually establishes
IDC defines “Frontier Firms” as the top 10% on its AI maturity scale, with “slow adopters” representing the bottom 30%. Microsoft’s summary highlights these comparisons:
| Reported measure | Frontier Firms | Slow adopters |
|---|---|---|
| Average AI return | 4x | 2.7x |
| Average agent return | 3.8x | 3.0x |
| Agent governance process | 87% | 51% |
| Organization-wide AI skills strategy | 80% | 3% |
These are leader-reported findings, not audited investment results. The maturity scale also includes outcomes, skills and risk-management confidence, so the groups are not independent experimental comparisons. Microsoft’s summary does not explain the return calculation or time horizon and says a fuller InfoBrief will follow. Treat the numbers as benchmarks, not forecasts for your deployment.
The distinction matters: a survey can identify practices worth investigating without proving that buying more AI—or copying a high-performing organization—will reproduce its results.
Four disciplines, translated into IT decisions
Microsoft frames its recommendations around model choice, workflow redesign, governance and measurement. The following is a practical interpretation for deployment planning, rather than a set of interventions proven by the survey.
1. Choose models against a task, not a leaderboard
Before comparing models, define what a successful result looks like.
For an internal support workflow, that might mean a correct answer grounded in approved documentation. For a development workflow, it might mean a change that passes review and testing—not merely code that compiles.
A useful evaluation plan should specify:
- Representative tasks and difficult edge cases.
- Acceptable error rates and required human review.
- Which data the workflow may access.
- Total operating costs, including review and rework.
- Conditions under which the system should decline or escalate.
The recommendation is simple: judge the complete process. A cheaper response is not cheaper if someone must spend ten minutes repairing it.
2. Redesign the handoff, not just the prompt
Bristol Myers Squibb offers a concrete example of workflow-specific automation. Microsoft’s customer account describes RABIT, a Copilot Studio agent that analyzes meeting transcripts, identifies risks and action items, and delivers insights within Microsoft 365 workflows. The company estimates that project managers using it save up to 20% of their time. That is a scoped customer claim, not a workforce-wide productivity measurement.
The practical question is what happens after an agent produces its answer. Who confirms an action item? Who owns a surfaced risk? When should the agent notify a person rather than proceed?
For a pilot, map those handoffs explicitly. Distinguish generating a recommendation from authorizing a business action. Then measure the finished workflow, including corrections and escalations.
That makes the pilot a test of operational improvement rather than a particularly impressive demonstration.
3. Make governance enforceable
Here is where the management language meets actual administrator controls.
Microsoft Learn documents that Copilot Studio data policies can govern authentication, knowledge sources, actions, connectors, HTTP requests, publishing channels and triggers. Its security overview also identifies maker audit logs in Microsoft Purview and tools that can run using the user’s credentials. These are specific controls administrators can evaluate—not simply a promise that an agent is “governed.”
For each proposed agent, the recommended review questions are:
- Ownership: Who is responsible for its behavior and lifecycle?
- Access: Which identities, data sources and connections does it use?
- Authority: Can it only retrieve information, or can it change business records?
- Oversight: Which actions require human authorization?
- Evidence: What records will support investigation and review?
Conagra’s experience illustrates the organizational counterpart. In Microsoft’s customer story, the company describes establishing a steering committee to review risk, access and identity management alongside observability and responsible-AI practices. It also reports role-appropriate training and a network of AI champions. These are customer-reported practices, not independent proof of security effectiveness.
The lesson is to pair accountable people with configured controls. A committee cannot enforce connector restrictions; a connector restriction cannot decide whether a proposed business use is appropriate.
4. Measure outcomes separately from adoption
KOHLER’s customer account supplies an especially useful distinction: it reports more than 3,000 agents created, but hundreds active daily. Those figures describe different things. An inventory count is not a usage measure, and neither establishes financial return.
For an internal scorecard, keep separate measures for:
- Reach: Who has access?
- Usage: Who uses the workflow consistently?
- Quality: How often is the result accepted without correction?
- Outcome: Does the complete process improve?
- Cost: What does that improvement cost to deliver and maintain?
This is an analytical recommendation, not IDC’s published measurement formula. Its purpose is to prevent a busy adoption dashboard from standing in for a business case.
Skills should include process judgment
The customer examples add practical detail beyond an instruction to “train employees.”
Bristol Myers Squibb says employees must complete advanced training before receiving a Copilot Studio license. KOHLER describes training that extends beyond tool operation into breaking business processes down and converting them into AI workflows. Both accounts are published by Microsoft and should be read as attributed customer experiences.
For deployment planning, consider separate learning paths for users, makers, administrators and business owners. Teach not only how to obtain an answer, but how to recognize an unsuitable task, validate an output and escalate a problem.
The useful benchmark is accountability
Microsoft says IDC analyst Shari Lava will discuss the research at Microsoft Ignite on November 18, 2026.
The actionable takeaway need not wait for a conference session: before expanding an agent, ask whether its owner, permissions, approval boundaries, quality threshold and business outcome are all explicit.
That is a more demanding test than “does the demo work?” It is also a much better foundation for deciding whether the next deployment deserves to scale.