Microsoft-Decision-1: Why AI Agents Need Decision Models, Not Just LLMs

As AI agents become part of enterprise workflows, an interesting question is emerging.

Do we really need a large language model for every decision an AI agent makes?

Not necessarily.

Microsoft recently introduced Microsoft-Decision-1, a specialized AI model designed to make structured decisions quickly and at a lower cost.

It's an interesting development, particularly as organizations explore how to make AI agents more efficient, reliable and economical.

What Makes Microsoft-Decision-1 Different?

Traditional large language models are designed for a broad range of tasks, including understanding language, generating content and reasoning.

Microsoft-Decision-1 focuses on something more specific: evaluating choices and returning probability scores.

Think about everyday enterprise scenarios:

• Should an IT incident be escalated?

• Which support team should receive a request?

• Does an AI-generated response meet defined quality criteria?

• Should an automated workflow proceed or request human review?

These are examples of where specialized decision models could be useful.

Microsoft developed Microsoft-Decision-1 by post-training the open-weight Qwen3.5-9B model. Microsoft also plans to rebase the model on other foundations, including its own MAI models and OpenAI models.

This highlights an important point: the right AI model depends on the task, not necessarily its size.

What About Performance and Cost?

Microsoft reports that Microsoft-Decision-1 achieved the highest accuracy in its comparison across 36 benchmarks covering nearly 150,000 questions.

It also reported:

• Approximately 35 times faster median latency than GPT-6 Sol in its evaluation.

• 4.5 times faster than the next-fastest specialized decision model.

• In an Xbox Research use case, over 14 times faster and 200 times less expensive, with competitive quality.

Microsoft lists pricing at $0.042 per million input tokens, with output tokens free.

These are Microsoft-reported results, and actual performance will depend on the workload.

It's also worth remembering that comparing a small decision model with a large general-purpose LLM isn't necessarily a like-for-like comparison.

Where Does This Fit in Enterprise AI?

Consider an IT service management scenario.

An AI-enabled workflow receives an incident. A decision model could help classify the issue, recommend the appropriate support team or identify whether escalation is needed.

This connects with my recent article on observability and AI-driven remediation, where better operational intelligence can support faster investigation and recovery.

But there's an important distinction.

A model recommending an action doesn't automatically mean it should be allowed to execute it.

Microsoft emphasizes confidence-based decisions, where applications can act, defer or request review. It also reports robustness testing in which decisions changed on approximately 1.3% of tested input variations.

Organizations still need to validate accuracy, confidence thresholds and risks against their own business requirements.

What Should Enterprises Take Away?

Microsoft-Decision-1 doesn't mean every AI agent needs another model.

Some workflows may work perfectly well with existing business rules, automation or general-purpose LLMs.

But as enterprise AI evolves, we may increasingly see different capabilities working together:

• LLMs for language understanding and reasoning.

• Decision models for evaluating structured choices.

• Workflow engines for executing approved processes.

• Governance and monitoring for maintaining accountability.

The opportunity is to choose the right approach for the problem, rather than introducing AI everywhere.

Closing Thoughts

Microsoft-Decision-1 is another example of how the AI landscape is becoming more specialized.

For enterprises, the real opportunity isn't simply faster or cheaper models. It's designing AI workflows that are reliable, cost-effective and appropriately governed.

Not every task needs a large model. Not every decision needs AI. And not every AI recommendation should become an automated action.

Stay tuned for more updates...

References

• Microsoft — Introducing Microsoft Decision-1
• Microsoft Foundry — Microsoft Decision-1
• Related Reading — Observability Is Taking Center Stage

Observability Is Taking Center Stage: What AI-Driven Remediation Changes, and What It Doesn't

Digital services now span endpoints, networks, cloud platforms, applications and, increasingly, AI agents. When something slows down, users don't care which layer failed. They just know they can't work.

That's why observability deserves renewed attention. Organizations need to understand problems faster, identify emerging issues earlier and, where appropriate, explore automated recovery.

But does that mean investing in more monitoring tools? Not necessarily.

Many Tools, One Question

Most large organizations don't rely on a single monitoring tool.

Different tools provide visibility into different layers: the network, the employee's device, applications, cloud services and the infrastructure underneath.

Each answers part of the question.

The harder question is what is actually happening to the employee, and why?

A service might appear healthy from an infrastructure perspective while employees continue to experience slow applications, connectivity issues or interruptions.

This is where Digital Employee Experience (DEX) and workplace observability intersect.

DEX focuses on understanding and improving employees' technology experience, while observability provides the underlying technical signals needed to investigate performance and reliability issues.

Together, they help organizations move beyond infrastructure availability toward understanding the experience employees actually receive.

That's why connecting signals across systems can be more valuable than simply collecting additional telemetry.

The objective isn't more dashboards. It's a clearer understanding of service health and its impact on users.

Observability as a Service: Worth Considering?

Another concept receiving attention is Observability as a Service (OaaS).

Rather than every team managing its own monitoring capabilities independently, organizations can consider delivering observability as a shared service, supported by common standards, centralized visibility and clearly defined ownership.

This could involve existing enterprise platforms, cloud-delivered services, managed providers or a combination of approaches.

The potential value lies in reducing fragmentation, improving consistency and making operational insights more accessible across teams.

Grafana Labs' 2026 Observability Survey reported that 77% of respondents had saved time or money through centralized observability. As a vendor-run survey, this is a useful indication of practitioner experience rather than proof of industry-wide outcomes.

However, shared observability also brings considerations around integration, data ownership, security and the cost of collecting, processing and retaining telemetry.

The question isn't whether every organization needs OaaS. It's whether its existing capabilities provide the visibility and coordination required to manage increasingly interconnected services.

From Detecting Problems to Fixing Them

Monitoring and scripted automation aren't new.

For years, organizations have used telemetry, alerts, scripts and workflows to detect and respond to operational issues.

What AI introduces is the potential to connect these capabilities more intelligently.

AI-assisted tools can help correlate signals across systems, identify patterns, support investigations and recommend corrective actions.

In some scenarios, they can also initiate approved remediation workflows.

Consider an employee experiencing repeated application failures.

Signals might exist across endpoint monitoring, application telemetry and service management systems. Individually, they may appear unrelated. Together, they could indicate a broader issue affecting multiple employees.

Better correlation can help teams investigate faster, while controlled automation may reduce repetitive troubleshooting and accelerate recovery.

But these capabilities have limitations. AI-generated findings may be inaccurate, integrations may be incomplete and automated actions can introduce additional risks.

Not every issue requires an AI agent, and not every remediation should happen without human approval.

The opportunity is worth exploring, but the outcomes must be validated.

Two More Areas Worth Understanding: AIOps and AI Observability

As observability evolves, two related concepts are also worth exploring.

AIOps (Artificial Intelligence for IT Operations) uses AI and analytics to help IT teams identify anomalies, correlate events, investigate incidents and support operational remediation.

AI Observability, on the other hand, focuses on understanding how AI applications and agents themselves perform.

Are they responding reliably? Are their outputs accurate and relevant? Are their actions succeeding? What are the latency and consumption costs?

The distinction is useful: AIOps applies AI to improve IT operations, while AI observability helps organizations monitor and evaluate their AI systems.

Both deserve consideration as enterprises introduce more AI into their technology environments. Neither removes the need for governance, validation or clear ownership.

What Changes, and What Doesn't

What changes:

• Detection: Moving beyond isolated alerts toward identifying patterns, anomalies and potential service degradation earlier.
• Investigation: Using AI-assisted analysis to connect operational signals and reduce repetitive manual triage.
• Remediation: Linking insights to approved workflows, established runbooks and, where appropriate, automated corrective actions.

What doesn't change: Ownership.

Someone still needs to determine which actions can be automated, define the boundaries, assess the risks and confirm that recovery has actually happened.

An automated response might restart a service, execute a script or initiate a recovery workflow.

But what happens if the action fails? What if the problem returns? What if the remediation creates another issue?

Service ownership, change management, operational governance and human oversight remain essential.

An automated fix isn't a resolved problem until recovery is validated. And it isn't governed until someone owns the outcome.

Questions Worth Asking

For organizations exploring observability and AI-driven remediation, a few questions are worth considering:

• Visibility: Do our existing monitoring capabilities provide an end-to-end understanding of service health and employee experience?
• Integration: Where are the gaps between tools, teams and operational data?
• Ownership: Who is accountable for correlating insights and coordinating service recovery?
• Automation: Which operational issues can be safely automated, and which require human approval?
• Validation: How will we confirm that automated remediation actually resolved the issue?
• Cost and value: What will telemetry collection, retention and automation cost, and how will we measure the benefits?

These questions matter just as much as selecting the technology.

Bottom Line

As enterprise environments become more interconnected, observability deserves greater attention.

Whether delivered through existing monitoring platforms, a shared observability service or a combination of capabilities, the objective should remain the same: better visibility into service health, earlier identification of issues and more informed operational decisions.

AI-assisted investigation and automated remediation introduce new possibilities, but they are not substitutes for sound service management, engineering practices or governance.

Organizations don't necessarily need more tools. They need to understand whether their existing capabilities provide the visibility, intelligence and response mechanisms their services require.

The opportunity is worth exploring. The outcomes still need to be demonstrated.

The way we address problems is changing. Accountability isn't.

Stay tuned for more updates...

Further Reading

• Grafana Labs — Observability Survey 2026
• OpenTelemetry — Documentation
• Microsoft Learn — Automation in Microsoft Sentinel
• Microsoft Learn — AIOps and Agentic Operations
• OpenTelemetry — Generative AI Observability
• Dynatrace — Observability
• Datadog — Observability
• Riverbed — Digital Experience Management
• Nexthink — What Is Digital Employee Experience (DEX)?
• Microsoft Learn — Endpoint Analytics Overview

Windows Is Becoming a Platform for AI Agents: What It Means for the Digital Workplace

Microsoft's October 7 announcement positions Windows as a platform for hybrid intelligence, where AI agents can run locally when appropriate, access cloud intelligence when needed, and operate within enterprise security and management controls.

For Digital Workplace teams, the important shift isn't simply the introduction of AI agents. It's that agents are becoming something the endpoint must contain, identify and manage.

What's New?

1. Microsoft Execution Containers (MXC)

Now generally available on Windows 11, MXC introduces policy-driven containment for AI agents. Organizations can define which files and networks agents can access, with those restrictions enforced at runtime.

In simple terms: MXC provides a controlled execution environment for AI agents, restricting their access to endpoint resources based on policies enforced outside the agent's control.

This helps establish security boundaries rather than allowing unrestricted access to files, networks and other resources.

2. Hybrid Intelligence: Local and Cloud AI

Microsoft is bringing together local AI models, cloud intelligence and intelligent routing to determine where supported workloads should execute.

Beyond performance, this approach has financial implications. Running appropriate workloads locally could help organizations optimize cloud AI consumption and manage token-related costs.

What is GitHub HydraFusion?

GitHub HydraFusion is an intelligent model-routing capability designed to select an appropriate AI model for a task. Microsoft is extending this approach to support routing between local models running on Windows PCs and cloud-based models.

For example, a supported coding task could use a local AI model instead of consuming cloud AI tokens, while more demanding tasks could continue using cloud intelligence.

This hybrid capability is expected to enter experimental preview later in October 2026 across the GitHub Copilot app, GitHub Copilot CLI and Visual Studio Code.

3. More Context-Aware Copilot Experiences

Microsoft also outlined upcoming Copilot capabilities for Copilot+ PCs, including access to relevant PC context with user permission, supported device actions and local AI models.

What are Copilot+ PCs?

Copilot+ PCs are Windows devices equipped with dedicated AI processing capabilities, including a Neural Processing Unit (NPU), enabling supported AI workloads to run locally rather than relying entirely on cloud services.

Microsoft expects these new Copilot experiences to begin rolling out over the coming months. They should not be considered generally available today.

Why This Matters for Enterprises

Microsoft describes three important foundations for securing and managing agents on Windows:

• Containment: Defining and enforcing boundaries around agent access to files, networks and resources.

• Identity: Distinguishing agent actions from human activity to support security, auditing and accountability.

• Manageability: Extending enterprise policies, monitoring and governance to agent workloads, including integration with management capabilities such as Intune and Agent 365. Microsoft notes that governance at scale may require additional services.

For Digital Workplace teams, this also introduces new service management considerations: agent ownership, monitoring, incident handling and operational support.

A practical question organizations should begin asking is:

Who approves what an AI agent on an employee's laptop can access, and who owns that policy?

My Perspective

In my earlier article, The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven't Changed, I discussed why identity, security, governance and service reliability remain essential as AI adoption grows.

Microsoft's latest announcement reinforces that direction.

The future Digital Workplace will increasingly involve people, applications and AI agents working together across endpoints and cloud services.

The technology to contain and manage agents is evolving, but accountability must still come from the organization.

As Windows becomes more agent-aware, Digital Workplace leadership will need to extend existing endpoint, security and service governance practices to this new operating model.

Reference

Microsoft — Building Windows for Hybrid Intelligence (October 7, 2026)

Before You Deploy Copilot: Is Your Microsoft 365 Data Ready for AI?

AI may not create oversharing — but it can make existing exposure easier to discover.

Listen to a short audio summary (5 min)

Prefer reading? The full article continues below.

Imagine an employee asks Copilot a legitimate business question and the response includes information from an old SharePoint site they didn't even know existed.

The document may be sensitive, but the employee already had access through a broad group or sharing setting that nobody had reviewed recently.

Copilot didn't necessarily bypass security. It surfaced information the employee was already permitted to access.

Before asking what Copilot can do, understand what information Copilot could surface based on existing user access.

1. Understand the Existing Exposure

Large Microsoft 365 environments accumulate content and permissions over many years: SharePoint sites, Teams-connected content, OneDrive files, broad groups, external users and old sharing links.

Something being technically accessible doesn't always mean it should still be accessible. That is why Copilot readiness needs to include information and access governance, not just licensing and deployment.

2. Discover Before You Deploy

Start by understanding the information estate.

Where is sensitive information stored? Which sites have large audiences or organization-wide access? Where are Anyone links being used? Which workspaces are inactive, externally shared or no longer have meaningful ownership?

Capabilities such as SharePoint Advanced Management and Data Access Governance can help identify permission patterns, broad sharing and sites that need attention.

The objective isn't to inspect every document manually. It is to identify where the highest risks are.

3. Classify and Protect What Matters

Permissions are only part of the picture. Organizations also need to understand what the information actually is.

Microsoft Purview capabilities such as sensitivity labels and Data Loss Prevention (DLP) can help classify and protect sensitive information. Copilot and agents operate within applicable Microsoft 365 access and protection controls.

But labels alone aren't an information-governance strategy. Someone still needs to understand what information needs protection, who owns it and how it should be handled.

4. Correct Access and Contain Risk

When oversharing is discovered, fix the underlying access wherever possible: remove unnecessary users and groups, revoke old sharing links, validate external access and correct permissions that no longer reflect the business need.

For sites undergoing remediation, Restricted Content Discovery (RCD) can temporarily reduce their visibility in organization-wide search and Copilot experiences without changing the underlying permissions.

Where stronger enforcement is required, Restricted Access Control (RAC) can restrict access to users in specified Microsoft 365 or Microsoft Entra groups. Users outside those groups can't access the site or its content even if they previously had permissions or a shared link.

Restricted discovery can buy time. It doesn't repair an incorrect access model.

5. Validate — Don't Assume

Finding the risk isn't the same as fixing it.

Site Access Reviews can involve site owners in reviewing Data Access Governance findings, validating whether broad access is still required and taking corrective action.

In my experience with large enterprise environments, this is where governance can easily stall. Reports and tooling can identify exposure, but remediation depends on having an owner who understands the information, can make the access decision and is accountable for closing it.

Another practical challenge is ownership itself. Sites can outlive projects, teams change, and the person listed as an owner may no longer understand why particular access was granted. An access review without an engaged information owner can easily become another unresolved task rather than a security improvement.

Consider an organization where external guests still have access to a project site long after the work has finished. The important question isn't whether Copilot is secure. It's whether those identities should still have access at all.

A dashboard showing 5,000 oversharing risks isn't governance. Governance begins when someone owns each risk and closes it.

6. Don't Try to Clean Millions of Files

In an enterprise with thousands of sites and potentially millions of files accumulated over many years, manually reviewing everything before enabling AI isn't realistic.

If I were prioritizing such an environment, I would start where multiple risk signals come together: sensitive or business-critical information, unusually broad audiences, organization-wide sharing, external access, complex permissions and stale or ownerless workspaces.

Then progressively improve the wider information estate.

At enterprise scale, the objective isn't perfect permissions overnight. It is continuously reducing the highest-risk exposure.

7. Make It an Operating Model

Copilot readiness shouldn't become a one-time cleanup exercise.

Content changes. New sites appear. Employees change roles. External partners join and leave. New agents connect to additional information sources.

The operating model therefore needs to be continuous:

Discover → Classify → Assess → Assign Ownership → Remediate → Validate → Monitor

Platform, security and governance teams can identify exposure, but site and information owners need to validate the business requirement and participate in remediation.

User behaviour matters too. Instead of choosing the broadest sharing option because it is convenient, the question should increasingly be:

Who actually needs access to this information?

Oversharing Is Also a Service Management Risk

A significant information exposure doesn't remain only a permissions problem.

It can become a security incident requiring investigation, remediation, compliance or legal involvement, stakeholder escalation and potentially reputational management.

That creates disruption across the IT service and the wider organization.

Preventing oversharing is therefore not only about securing Copilot. It is part of operating a secure and reliable Digital Workplace.

Closing Thoughts

AI doesn't necessarily create the oversharing problem. It can make weaknesses in existing access and information governance easier to discover — and potentially much more consequential.

Before scaling Copilot and agents, organizations should understand their information estate, classify what matters, correct excessive access, establish ownership and continuously monitor what changes.

Better AI starts with better-governed information.

Before asking what Copilot can do, make sure you understand what information it could surface based on the access your users already have.

Note: Availability and licensing for SharePoint Advanced Management capabilities vary. Organizations should validate current Microsoft licensing and prerequisites for the specific controls they plan to use.

References

• Microsoft Learn — Get ready for Microsoft Copilot and agents with SharePoint Advanced Management
• Microsoft Learn — What is SharePoint Advanced Management?
• Microsoft Learn — Copilot controls security and governance
• Microsoft Learn — Restrict discovery of SharePoint sites and content
• Microsoft Learn — Restrict SharePoint site access with Microsoft 365 groups and Microsoft Entra security groups
• Microsoft Learn — Initiate site access reviews for data access governance reports

Microsoft Ignite 2026 Is Coming. Have You Registered Yet?

Microsoft Ignite returns November 17–20, 2026 at the Moscone Center in San Francisco, with both in-person and digital options.

If you work with Microsoft technologies, this is one to keep on your calendar.

What to Expect

This year's Ignite covers Microsoft's latest direction across AI and agents, Microsoft 365, Copilot, Azure, security, data and the wider enterprise ecosystem.

I'm especially watching:

• Copilot and agents: where the platform is heading
• Microsoft 365 and the Digital Workplace: what changes for everyday work
• Security and governance: how enterprises keep AI under control
• Microsoft IQ and enterprise AI: how the different pieces are coming together

Can't Travel?

Microsoft offers a free Digital Pass with online access to keynotes, sessions and a wide range of technical content.

The session catalog is already live, so this is a good time to explore what's available and start building your list.

Event Snapshot

📅 Dates: November 17–20, 2026

📍 Location: San Francisco + Online

💻 Digital Pass: Free

Get Ready for Ignite

Whether you're attending in San Francisco or joining online, Ignite is a good opportunity to hear directly from Microsoft, explore what's changing across the technology landscape and identify what matters for your organization.

Register, explore the session catalog and start building your agenda.

I'll be following Ignite and sharing the updates that matter to the enterprise workplace and AI community here.

Read Here to Know More

• Microsoft Ignite 2026 — Registration and event details
• Microsoft Ignite 2026 — Session Catalog
• Microsoft Events

Stay tuned for more updates...

Understanding Microsoft IQ: Work IQ, Fabric IQ, Foundry IQ and Web IQ

As Copilot and AI agents become more connected to enterprise work, context becomes just as important as the AI model itself.

A capable model that doesn't understand how people work, how the business operates, what the organization knows or what is happening outside it will still give generic answers. The more we expect agents to act, the more that context matters.

Microsoft's answer to this is Microsoft IQ, an intelligence layer designed to ground Copilot and agent interactions in a shared understanding of the organization.

This article explains how its four capabilities fit together and what they mean for the people responsible for the workplace.

One Layer, Four Types of Context

Microsoft IQ is the umbrella. Underneath it, four capabilities each provide a different kind of context.

Work IQ provides a live understanding of how employees work, with context on people, collaboration and workflows across Microsoft 365, such as meetings, emails, files and conversations.

Fabric IQ provides the live state of the business. It helps agents understand business entities and their relationships, properties, actions and rules, so enterprise data carries business meaning instead of being a set of disconnected tables.

Foundry IQ provides curated institutional knowledge: policies, authoritative documents and reusable knowledge bases that agents can draw on.

Web IQ provides fresh, real-world information from across the web, so agents aren't limited to what exists inside the organization.

A Simple Way to Remember Them

Each one answers a different question:

Work IQ → How do we work?

Fabric IQ → How does the business operate?

Foundry IQ → What does the organization know?

Web IQ → What's happening outside the organization?

The value comes from bringing these different types of context together.

An Illustrative Example

This example is hypothetical and simplified. It shows why the four capabilities complement each other and doesn't describe a specific product configuration.

Imagine an account manager asking an agent to help prepare for a customer meeting.

Work IQ can bring in recent meetings, email threads and shared documents involving that customer.

Fabric IQ can add the business picture: orders, performance and account status.

Foundry IQ can supply contract terms, pricing policies and approved guidance.

Web IQ can add recent news about the customer's company or industry.

No single source is enough. The agent needs the work context, business state, organizational knowledge and outside view to prepare something genuinely useful.

Why This Matters for Digital Workplace Leaders

The value of Copilot and agents won't depend only on how capable the underlying models become. It will also depend on how well they understand the people, business, knowledge and external context around the work.

For anyone responsible for the workplace, that has a practical consequence.

Each context source has its own owners, permissions and quality considerations. Work context depends on how information is shared and organized. Business context depends on data quality and common definitions. Institutional knowledge depends on whether policies and documents are current and trusted.

In other words, the foundations I wrote about in my earlier articles matter even more. Identity, permissions, information architecture, data quality and knowledge management will influence how useful this intelligence layer becomes.

Better context also raises governance questions. Which sources should an agent use? Who owns their quality? How do we verify what an agent relied on?

A Note on Availability

Microsoft IQ is an umbrella, and its components and individual capabilities don't necessarily share the same availability, licensing or maturity.

Before planning around a specific capability, check Microsoft's current documentation for availability, pricing and requirements.

Closing Thoughts

AI agents are moving from answering questions to taking part in work. That makes context increasingly important.

Microsoft IQ is one indication of where enterprise AI is heading: toward systems that understand the people, the business, organizational knowledge and the world around the work.

Better context won't replace good foundations. It will depend on them.

That's why Microsoft IQ is worth watching—and why the groundwork inside the enterprise matters as much as the next model release.

References

• Microsoft Learn — Microsoft IQ documentation

• Microsoft Learn — Work IQ overview

• Microsoft Learn — What is Fabric IQ?

• Microsoft Learn — Foundry IQ FAQ

• Microsoft — Microsoft IQ: Unified Enterprise Intelligence for AI

Related Reading

• The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven't Changed
• From AI Adoption to Business Value: What Should Digital Workplace Leaders Measure?AI 
• Atlas: AI Ecosystem Guide

From AI Adoption to Business Value: What Should Digital Workplace Leaders Measure?

Making deliberate AI investments, matching capabilities to people’s needs, and validating the business value they deliver.

Listen to a short audio summary (5 min)

Prefer reading? The full article continues below.

In my recent articles, I explored what changes as the Digital Workplace becomes an AI Workplace, and how work and people’s roles evolve in AI-enabled service management.

Both lead to a practical question:

How do we make sound AI investments, and know whether they are delivering value?

Adoption figures are a useful starting point. But they are only the beginning.

Licences assigned show access. Prompts submitted show activity. Sustained use shows adoption. Better work outcomes show improvement. Business value requires evidence—and someone accountable for validating it.

This article reflects my perspective as a Digital Workplace and service management leader. It offers a practical approach to investment and measurement; outcomes will depend on the organization, its workflows and how the capabilities are implemented.

Business Value Starts Before the Investment

Value is usually discussed after a rollout. It starts earlier.

Before buying or enabling an AI capability, we need to ask:

• What business problem are we trying to solve?
• Which users and workflows need support?
• Can existing capabilities already meet the requirement?
• What improvement do we expect?
• Who owns the outcome, and how will it be verified?

New AI features arrive constantly. Each should trigger an evaluation, not an automatic investment.

A capability can be impressive without addressing a priority business need. It may also overlap with something the organization already has.

The governance approach I discussed in Building an Agentic Center of Excellence applies here: involve the existing governance structure and relevant owners, assess the requirement, and make a deliberate decision.

The investment should follow the need.

The Right Capability and License for the Right User

Licensing should follow the work.

Someone handling complex, frequent workflows may need different capabilities from a person who uses AI occasionally. Role, task frequency, required features, existing entitlements and approved data access all matter.

Paid AI licences do not necessarily need to go to the entire organization.

Start with users and workflows where there is a clear requirement and a credible opportunity to improve outcomes. Choose the capability and licensing option that meet that need.

A targeted pilot can establish who benefits, what support they need, and whether wider investment is justified.

The approval should connect the user, the capability and the expected outcome.

Move Up the Measurement Ladder

Activity is often the easiest starting point. The harder question is how far up the ladder the evidence actually reaches.

Stage	What it tells us	Example evidence
Activity	People have access and are trying AI	Licences assigned, active users, interactions
Adoption	AI is becoming part of relevant work	Sustained use in defined workflows
Work outcome	The work is improving	Quality, handling time, effort, rework
Business value	The improvement supports organizational goals	Capacity used, service improvement, validated savings or risk reduction

Each stage answers a different question.

An assigned licence shows access. Repeated use suggests adoption. Neither establishes whether the work is better.

High usage may reflect useful support. It may also reflect experimentation, repeated attempts or outputs that require correction.

To connect adoption with value, establish a baseline: how the work performed before the change, and what improvement would justify the investment.

Tools Help Build the Evidence

In my earlier Analytics Hub article, I explored resources for understanding Copilot adoption, licence utilization and potential impact. That discussion also included Copilot Analytics Labs and Microsoft365 Analytics Insights – Copilot Adoption.

These resources can help teams investigate usage patterns, identify adoption gaps and inform licence reviews.

Microsoft’s Copilot Dashboard in Viva Insights provides readiness, adoption, impact and sentiment insights. The measurement ladder in this article is my framework for connecting those signals with workflow outcomes and business value.

Microsoft’s own documentation describes Copilot assisted hours as a general estimate, using activity data and research-based assumptions. Its current methodology applies six-minute assistance factors to search or summary actions and creation actions; meeting-related assistance is calculated differently.

These are broad approximations, not direct measurements of the time each employee saved. Microsoft also notes that seasonality, role shifts and organizational changes can influence metric changes.

The important step is connecting telemetry with actual work.

Combine tool-generated insights with workflow measures, employee feedback and validated costs. Check metric definitions and known data issues before relying on a baseline.

Tools help assemble the evidence. Accountable owners determine whether it supports the investment decision.

Who Owns the Evidence?

An AI business case needs a clear answer to this question.

Someone must establish the baseline, validate the results and decide whether to scale. Several groups contribute:

Contributor	Responsibility
Business or process owner	Defines the expected outcome and confirms its relevance
Service or platform owner	Coordinates measurement, adoption and ongoing optimization
Employees	Validate the practical benefit and review effort
Finance	Validates financial benefit claims where applicable
AI CoE, security and governance teams	Support evaluation and appropriate controls

Several teams contribute evidence, but a named business or service owner should remain accountable for the outcome and the decision to scale.

One distinction matters: time saved does not automatically become financial savings.

It may create capacity, reduce employee effort or improve service responsiveness. Each is a potential benefit, but it should be measured and described accurately.

If capacity is redirected into resolving recurring problems or improving knowledge, show that connection. If the benefit is reduced workload, evaluate it directly rather than converting every saved minute into a cash-saving claim.

An Illustrative Example: AI-Assisted Service Desk Work

This example is hypothetical. The directional changes illustrate how to assess a pilot; they do not represent measured or expected results.

Consider a common category of collaboration tickets where AI could help analysts retrieve knowledge and prepare responses.

1. Establish the baseline. Record active handling time, end-to-end resolution time, reopen rates, quality and analyst effort. Compare tickets of similar categories and complexity.

2. Select the right users and capability. Choose analysts who regularly handle the workflow and identify the capability they need.

3. Run a limited pilot. Define its scope, duration, review requirements and success criteria.

4. Measure more than speed. Track quality, rework, analyst effort and the experience of people receiving support.

5. Validate the benefit. Include relevant costs and the time spent checking and correcting AI output.

6. Decide. Expand, adjust or stop based on the evidence.

The pilot might produce a mixed result:

Measure	Before	During pilot
Active handling time, including review	Established baseline	Lower
Reopened tickets	Established baseline	Slightly higher
AI-output review effort	No AI-specific review	Additional effort within handling time
Analyst experience	Established baseline	Mixed feedback

Faster handling is promising, but additional reopened tickets could reduce the overall benefit. Review effort should be included in handling time and tracked separately for understanding, without counting it twice.

The next step may be to improve knowledge sources, training or the review process before expanding access. Other changes during the pilot—such as staffing or ticket complexity—should also be considered before attributing the result to AI.

A pilot is useful when it improves the decision, including a decision to adjust the approach.

Review, Optimize and Scale

Licence optimization starts at approval and continues throughout the service lifecycle.

As needs evolve, review whether licences remain assigned to the right people and whether outcomes justify renewal or expansion.

Do users need training? Has the workflow changed? Would another approved capability meet the requirement more effectively?

When usage is low, investigate before reassigning licences. The cause may be missing skills, access barriers, an unclear use case or a workflow that gains little from AI.

Frequent usage should also be assessed against outcomes before expanding investment.

Licence and consumption costs belong in the evaluation, alongside implementation, support and human review. My AI FinOps article explores cost management in more detail.

Here, the focus is whether those costs are justified by verified benefits. Where financial ROI is claimed, use validated financial benefits and relevant costs over a defined period. Report service quality, employee experience and risk benefits separately unless there is a defensible basis for monetizing them.

Closing Thoughts

Digital Workplace leaders need to connect AI investment with user needs, service outcomes and organizational priorities.

That means looking beyond deployment and usage to understand whether the capability improves work—and whether that improvement justifies continued investment.

Before asking how many people are using AI, ask which people need which capabilities, what outcome the investment should improve, and who will verify that it did.

Define the need. Approve deliberately. Validate the benefit. Use the evidence to optimize or scale.

Related Reading

• The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven’t Changed
• AI-Enabled Service Management: Automating Work, Evolving People’s Roles
• Building an Agentic Center of Excellence: Do We Really Need Another CoE?
• Analytics Hub: Microsoft’s Free Toolkit to Measure Copilot Adoption, Impact & ROI
• FinOps for AI: Understanding Tokens, Copilot Credits and the Real Cost of AI

Reference

• Microsoft Learn: Microsoft Copilot Dashboard in Viva Insights — Official documentation covering dashboard metrics, assisted-hours methodology, interpretation limitations and known data issues.

AI-Enabled Service Management: Automating Work, Evolving People’s Roles

How AI-enabled service management can improve operations, build people’s skills, strengthen accountability and support responsible workforce change.

Listen to a short audio summary (4 min)

Prefer reading? The full article continues below.

Recently, I wrote that AI can make service management more intelligent, but it doesn’t make it unnecessary.

That raises a practical question:

When AI takes on more of the execution, how do we help people contribute more value?

Organizations have hired and developed people to support services, resolve incidents, manage changes and keep operations running. As AI becomes part of that work, some activities will require less manual effort. Others may be automated entirely.

The opportunity to optimize is real. So is the concern among people whose work is changing.

Both deserve attention in the same conversation.

This article reflects my perspective on how AI and people can work together in service management. Many of these considerations are common across organizations, but the right approach will vary with the service, its risks and the people involved. Other approaches may deliver even greater value—the aim is to open a practical conversation and learn from each other.

A Familiar Scenario

A recurring issue affects a collaboration service.

Tickets arrive. Several describe the same symptom differently. Some reach the wrong team. An incident is raised, engineers review logs, someone prepares stakeholder updates, and a change is proposed.

Much of the effort goes into gathering information, documenting it and passing it between teams.

AI is already supporting these activities. ServiceNow’s current ITSM documentation lists incident summaries, resolution-note generation, change-request summaries and change-risk explanations among its generative AI capabilities.

But a summary alone does not tell us whether a critical business process is interrupted, whether the proposed fix addresses the cause, or whether releasing it now is sensible.

Those questions require technical knowledge, business context and judgment.

As execution becomes more automated, organizations need to develop that capability alongside it.

Where the Work Can Evolve

Here is a practical way to think about the balance.

Area	AI and automation can help with	People can focus more on
Ticket management	Classification, routing, summaries and execution of approved fixes	Complex diagnosis, exceptions and employee impact
Incident and problem management	Gathering evidence, suggesting investigative steps and preparing timelines	Coordinating recovery, validating causes and preventing recurrence
Change and CI/CD	Preparing records, supporting test creation and executing controlled workflows	Defining release criteria, assessing business risk and managing exceptions
Continual improvement	Identifying recurring patterns and repetitive manual work	Choosing improvements and measuring their effect
Agent-driven operations	Executing actions within defined permissions	Setting boundaries, monitoring performance and intervening when needed

The balance will depend on the service and its risks. It should evolve as the organization gains evidence that the automation works reliably.

Optimization Should Include People Development

Organizations will naturally look at AI through cost and productivity.

If work can be completed reliably with less effort, preserving the manual process simply because it is familiar makes little sense.

But there is usually more useful work waiting.

Recurring incidents need investigation. Knowledge articles need updating. Monitoring gaps remain unresolved. Recovery procedures need testing. Service improvements stay in the backlog because daily operations consume the team’s time.

Automation can create room to address some of these weaknesses.

The question is what the organization will do with that capacity—and whether people are equipped to use it.

This makes learning and development part of the transformation roadmap.

A service desk analyst needs to know how to check an AI-generated summary and recognize an unsuitable recommendation. An engineer needs to validate generated code and tests. A service owner needs to understand how agent permissions, escalation paths and failures affect the service.

NIST’s AI Risk Management Framework explicitly addresses AI risk-management training, leadership responsibility and defined roles for human oversight.

Training should connect to actual responsibilities, with protected time to practise and opportunities to apply new skills.

Employees should also participate in automation design. They know the exceptions, workarounds and operational details that process documentation often misses.

For me, this is a stronger value proposition: use AI to improve execution while developing people to investigate, improve and govern the service.

Employees have a part to play in developing their skills. Organizations have a part to play in making that development achievable.

Touchless Change Still Needs Ownership

Change management is a useful example.

Continuous integration and continuous delivery or deployment—CI/CD—already support automated testing and deployment workflows. Azure Pipelines provides approvals and checks that control whether deployment stages proceed. AI can assist with surrounding activities, but the pipeline controls themselves are established automation.

For a repeatable, lower-risk deployment, a workflow could proceed when defined tests and policy checks pass, with exceptions routed for review.

Someone still needs to decide which changes qualify, what evidence is required, when execution must stop and how recovery will work.

ITIL guidance supports AI-enabled service management while emphasizing oversight, accountability and risk management.

Touchless doesn’t mean ownerless.

Reducing manual intervention should go together with clear service ownership and tested controls.

An Honest Conversation About Jobs

People are understandably concerned when activities they were hired to perform become easier to automate.

I do not think we can promise that AI will never replace anyone.

Some tasks will disappear. Roles may change significantly. Some organizations may reduce staffing.

The ILO’s 2025 occupational-exposure index identified job transformation as the most likely impact of generative AI. Its June 2026 evidence review finds that large-scale job displacement remains limited in the evidence reviewed, while highlighting uneven productivity gains and risks to employment opportunities and job quality. Neither finding guarantees security for an individual role.

What leaders can offer is a responsible transition: explain what is changing, involve the people affected, provide relevant learning and identify realistic opportunities in revised roles.

“Move into higher-value work” is only useful advice when people have somewhere to move and the support to get there.

Measure What Actually Improves

Time saved matters, but the service should tell us whether the investment is working.

Are repeat incidents decreasing? Is recovery faster? Are releases more reliable? Are employees receiving better support?

Incorrect routing, unsuccessful automated fixes, rework and unnecessary rollbacks also need attention. Faster execution has little value if it creates more problems downstream.

For the workforce, course completion is an early indicator. The stronger measure is whether people can apply what they have learned, assess AI outputs and manage the revised workflows confidently.

That gives leaders a fuller picture of optimization.

Closing Thoughts

AI creates an opportunity to rethink how service work gets done.

Organizations can reduce repetitive effort and improve operations while developing the people who understand their services.

That requires deliberate choices about investment, roles, learning and accountability.

The automation roadmap and the people-development roadmap should move together.

That is where I would start. Role design, learning pathways and the operating model for agents deserve a deeper discussion in a future post.

References

• ServiceNow — Using ITSM Generative AI Skills — Official documentation, updated 10 September 2026.

• Microsoft Learn — Azure Pipelines Approvals and Checks — Official deployment-control documentation.

• PeopleCert — Official ITIL Frequently Asked Questions — Current guidance on ITIL, AI-enabled environments and governance.

• NIST — AI Risk Management Framework Core — Foundational guidance from AI RMF 1.0 (2023); GOVERN sections 2.2, 2.3 and 3.2 cover training, leadership responsibility and human oversight.

• ILO — Generative AI and Jobs: A Refined Global Index of Occupational Exposure — Published 20 May 2025.

• ILO — The Impact of GenAI on Jobs, Productivity and Work Organization: A Review of the Empirical Evidence — Published 1 June 2026.

Related Reading

AnywhereExchange —The Digital Workplace Is Becoming an AI Workplace

The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven't Changed

The digital workplace is evolving as people, copilots and agents work together. AI adds new possibilities, while identity, security, governance and employee experience remain essential foundations.

Listen to a short audio summary (4 min)

Prefer reading? The full article continues below.

For years, the Digital Workplace has been built around a simple goal: give employees a secure, reliable and productive experience wherever they work.

What sits behind that experience has changed a lot.

Devices moved from domain-joined desktops to cloud-managed endpoints. Applications moved from data centers to SaaS. Identity became the control plane, with SSO, MFA, Conditional Access and Zero Trust. Microsoft 365 brought messaging, meetings, chat and content together. Digital Employee Experience brought greater focus to device health, application performance and proactive support. Security and compliance became part of workplace design rather than controls added afterwards.

The Digital Workplace became the combination of devices, applications, identity, connectivity, collaboration, data, security, employee experience and the services supporting all of them.

Now another layer is being added.

Artificial Intelligence (AI).

Copilots are becoming part of everyday applications. Agents are beginning to go further, interacting with enterprise data, applications and tools to complete work.

But that doesn't make everything we built before less important. I think it's the opposite.

From Digital Workplace to AI Workplace

The journey hasn't happened in one step.

Each stage built on the one before it.

Moving to the cloud didn't remove endpoint security. SaaS didn't remove access management. Microsoft 365 didn't remove information governance. Better DEX didn't remove service management.

Adding AI doesn't remove any of them either. Instead, AI depends on all of them working together.

Having worked through most of these stages over the years, one pattern keeps repeating: every new layer exposes how well the previous one was built.

One Agent, Five Foundations

Here's a simple scenario.

A manager asks an agent to summarize the status of a project and draft an update.

To do that, the agent needs:

An identity. Who is this agent, and who owns it?

Permissions. What is it allowed to access, and on whose behalf?

Trusted data. If the project site has outdated documents and over-shared folders, the summary could be wrong or expose something it shouldn't.

Security and audit. Can we see what it accessed and what it produced?

Operational ownership. If it fails, returns a bad result or can't reach a dependent service, who responds?

That one request touches identity, data, security, service management and governance.

None of these are new disciplines.

What's new is that a single AI interaction depends on all of them at once.

Identity Matters Even More

We already think about authentication, least privilege and lifecycle management for employees.

Now imagine hundreds or thousands of agents interacting with enterprise systems.

Who is the agent? What can it access? Who owns it? What happens when it's no longer needed?

These are familiar IAM questions applied to a new type of identity.

Microsoft is already moving in this direction with Microsoft Entra Agent ID, extending identity, access and lifecycle governance to AI agents.

The technology may be new. The principle isn't.

Give an identity only the access it needs, for only as long as it needs it.

AI Is Only as Useful as the Information Around It

An AI assistant can be extremely capable, but it still needs the right enterprise context.

If SharePoint is full of outdated documents, permissions are poorly managed, knowledge is scattered or important information lives only in people's heads, AI doesn't magically fix that.

It surfaces it faster.

This is why information architecture, Microsoft Graph, SharePoint, OneDrive, data quality and knowledge management become more important, not less.

Microsoft's Work IQ direction is interesting here because it connects Copilot and agents with organizational knowledge and work context.

We spent years building the Digital Workplace.

AI is now trying to understand it.

Security, Compliance and Governance Have to Work Together

AI doesn't create a separate security universe.

The same questions remain.

What can this user or agent see?

Is sensitive information protected?

Can we audit what happened?

Do retention and compliance requirements still apply?

As agents gain more autonomy, identity governance, Zero Trust, data protection, DLP and auditing matter even more.

And governance has to connect all of it.

Devices have policies. Applications have owners. Identities have access controls. Data has classification and retention requirements. AI adds models, copilots and agents.

But employees experience all of this as one workplace, so governance can't become a separate conversation for each technology.

The challenge isn't simply deploying more AI.

It's introducing AI without losing control of the environment around it.

That doesn't mean nothing is new. AI brings new cost models, new identities and new regulatory considerations. But these are extensions of the foundations we already have, not replacements for them.

Employee Experience and Service Management Still Matter

Digital Employee Experience now has another dimension:

How effectively can an employee work with AI?

Making Copilot available doesn't mean people know when or how to use it.

Deploying agents doesn't mean employees will trust them.

Adoption, training, change management and feedback still decide the outcome.

AI will also change how services are operated.

Incidents can be summarized faster. Recurring problems can be spotted earlier. Knowledge can surface inside the workflow. Routine requests can increasingly be fulfilled through automation and agents.

But someone still needs to own the service.

Someone still needs to understand the business impact when something fails.

We still need incident, problem and change management, service levels and clear accountability.

AI can make service management more intelligent. It doesn't make it unnecessary.

And when agents become part of business processes, an agent failure becomes an operational issue like any other.

The service model needs to evolve with the technology.

The Technology Changes. The Fundamentals Remain.

We are moving from employees interacting primarily with applications to a workplace where people, copilots and agents increasingly work together.

That's a significant change.

But underneath it, the same foundations remain:

Devices and applications.

Identity and access.

Security and compliance.

Trusted data and knowledge.

Connectivity and collaboration.

Employee experience.

Service management.

Governance and lifecycle management.

And most importantly, people and accountability.

The organizations that move best with AI may not be the ones with the most models, copilots or agents.

They may simply be the ones with strong foundations and the ability to extend them into this new way of working.

The Digital Workplace is becoming an AI Workplace.

We don't need to rebuild everything from scratch. We need to make sure the foundations are ready for what comes next.

Update (October 10, 2026): Satya Nadella's Infinite SaaS Factory

Satya Nadella has outlined Microsoft's vision of an Infinite SaaS Factory, where Copilot and AI agents help organizations create adaptive business workflows across enterprise applications.

Rather than replacing CRM, ERP and other systems of record, AI could provide a more intelligent way to interact with them.

My Perspective

The Digital Workplace is evolving into an AI Workplace, but the foundations remain unchanged: security, governance, enterprise architecture and accountability.

AI may transform how employees interact with software, but organizations must retain control over data, decisions and business processes.

References

• Microsoft Learn: Work IQ overview

• Microsoft Learn: Microsoft Entra Agent ID

• Satya Nadella — Infinite SaaS Factory

EWS Deprecation Is Here — Is Your Exchange Online Environment Ready?

After years of discussion and preparation, Exchange Web Services (EWS) in Exchange Online is entering its final phase.

Microsoft has started the phased disablement of EWS from October 2026, with EWS scheduled to be fully disabled in Exchange Online in April 2027.

For many organizations, this isn't new. Those that started preparing early have already been identifying applications using EWS to access Exchange Online, working with application and business owners, engaging vendors and moving supported workloads towards Microsoft Graph.

But there may still be work to do.

Finding the Remaining Dependencies

From my experience with large enterprise messaging environments, knowing that a technology is being retired is the easy part.

EWS has been part of the Exchange ecosystem since Exchange Server 2007, and many applications have used it over the years.

For this retirement, the focus is specifically on applications using EWS to access Exchange Online.

Some of those applications may already have moved to Microsoft Graph. Others may still be in transition, waiting for application changes or vendor support, particularly where there isn't a straightforward Graph equivalent.

That's why identifying the remaining Exchange Online EWS dependencies is important. Application owners, business stakeholders, messaging teams and vendors may all need to work together to complete the migration.

The Next Few Months Matter

The EWS disablement isn't happening across every tenant at exactly the same time. Microsoft is rolling out the change tenant by tenant, starting with Worldwide (WW) tenants, with other environments following their respective rollout timelines.

If your organization has already started the migration, now is a good time to revisit the landscape.

A few things worth checking:

• Review the EWS Usage Report — identify applications still making EWS calls to Exchange Online.

• Check the Graph migration status — confirm what's already moved and what's still in progress.

• Revisit vendor-blocked applications — check whether vendors now have a migration path or updated support.

• Look for anything missed — older integrations and less-visible applications can easily remain in the environment.

Microsoft also provides migration guidance and tools to help developers assess existing EWS applications and potential Graph migration paths.

If you haven't started yet, start with discovery. Identify the applications, understand why they're using EWS, find the owners and build a migration plan.

The phased rollout through April 2027 provides some time to work through the remaining dependencies, but I wouldn't treat that as time to wait.

I'd treat it as time to finish the job.

One Important Distinction

This retirement applies to EWS in Exchange Online.

EWS isn't being retired from on-premises Exchange Server as part of this change.

Hybrid organizations should therefore look specifically at applications and scenarios interacting with Exchange Online mailboxes, including any relevant hybrid or cross-organization dependencies.

Final Thoughts

EWS has served the Exchange ecosystem for almost two decades.

Its retirement is another reminder that legacy dependencies can remain long after the technology landscape around them has changed.

Having worked through these kinds of enterprise messaging transitions, one thing continues to stand out for me:

The technology change is often the easier part. Finding the dependencies, getting the right people involved and moving every application safely is where the real work happens.

If you're already on the EWS migration journey, now is the time to close the remaining gaps.

If you haven't started, now is the time to understand your landscape.

References

Microsoft Exchange Team — EWS Deprecation Is Here – What This Means To You

Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online

Microsoft Learn — Exchange Web Services (EWS) Usage Report

Microsoft Graph — Migrate Exchange Web Services (EWS) apps to Microsoft Graph

Microsoft Exchange Team — Impact of Exchange Online EWS Deprecation on Hybrid Rich Coexistence and Cross-org Sharing