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.
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.
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.
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.
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.
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.
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.
Microsoft recently introduced its evolving Copilot experience around Home, Code and Autopilot, with Chat and Copilot Cowork coming together within Home. OpenAI's DevDay introduced Dots, alongside further developments across ChatGPT and Codex. Anthropic continues to evolve Claude, Claude Code and Managed Agents, and is now bringing its Chat and Cowork experiences together into a unified Claude experience.
These aren't the only platforms and models enterprises are evaluating. Google Gemini is another significant part of the enterprise AI landscape, while Microsoft is expanding its own MAI model family alongside its partnerships with other model providers. Meta continues to develop its AI ecosystem, and xAI's Grok is expanding its business and enterprise presence. Platforms such as AWS Bedrock and IBM watsonx also play important roles in building, deploying and governing enterprise AI.
For this article, I'm focusing specifically on Microsoft Copilot, OpenAI and Anthropic, and how their increasingly overlapping capabilities could shape the multi-AI workplace.
Looking across these developments, one thing stands out to me:
AI is rapidly moving beyond chat.
We started by asking AI questions. Then we started using it to create content and complete tasks. Now we are moving toward AI that can take on larger pieces of work — and increasingly, continue working toward an objective.
For organizations investing across multiple AI platforms, this creates both opportunity and complexity.
Three Platforms, Increasingly Overlapping Capabilities
Microsoft Copilot, OpenAI and Anthropic have different strengths and starting points, but their capabilities are increasingly overlapping.
Here is a simplified view:
Enterprise capability
Microsoft
OpenAI
Anthropic
AI assistant
Microsoft 365 Copilot
ChatGPT
Claude
Delegated knowledge work
Copilot Cowork
ChatGPT work/agent capabilities
Claude / Cowork capabilities
Persistent / asynchronous work
Autopilot (private preview)
Dots (rolling out)
Managed Agents (beta)
Developer AI
GitHub Copilot
Codex
Claude Code
Building/customizing agents
Copilot Studio
OpenAI agent development tools
Claude Agent SDK
Enterprise context & connectivity
Microsoft 365 context, Work IQ and connectors
Apps, plugins and connected enterprise data
MCP, connectors and integrations
Enterprise strength
Deep M365, identity and governance integration
General-purpose AI, cross-platform work and agents
Knowledge work, coding and flexible agent development
These are not exact product equivalents, and they shouldn't be treated as such.
Microsoft's Autopilot, previously known as Scout, is being positioned as a persistent, proactive digital teammate with its own identity, memory, computer and workspace. That is particularly interesting from an enterprise perspective because persistent agents introduce new questions around identity, permissions, governance and accountability.
OpenAI's Dots similarly moves beyond a traditional chat session. A Dot can be given a goal, connected to the applications it needs and continue making progress between conversations using its own cloud computer.
Anthropic's Managed Agents, currently in beta, provides managed infrastructure for long-running and asynchronous agent workloads with persistent sessions.
There is also an interesting relationship between the two Cowork experiences.
Microsoft's Copilot Cowork and Anthropic's Claude Cowork share more than a name. Microsoft says it worked closely with Anthropic to bring the technology powering Claude Cowork into Microsoft 365 Copilot. They remain separate products, delivered and governed through their respective platforms.
Anthropic is now also bringing its Chat and Cowork experiences together into one Claude experience, beginning with Pro and Max users.
Microsoft's Code is another capability worth watching separately. It is aimed at knowledge workers rather than traditional developers, enabling people to create apps, dashboards, widgets and automations using natural language. That makes it different from GitHub Copilot and is why I haven't grouped the two together as developer AI.
Multi-AI May Become Normal
Many organizations are already invested in Microsoft 365 and Copilot while also evaluating ChatGPT Enterprise, Claude and other AI platforms for different business requirements.
That doesn't necessarily mean choosing one and removing the others.
But the growing overlap does make capability and licence optimization increasingly important.
Copilot itself can incorporate technology and models from other AI providers. Copilot Cowork's relationship with Anthropic is a good example. An organization separately licensing multiple AI platforms should therefore look beyond vendor names and understand which capabilities, models and business outcomes it is actually paying for.
That doesn't automatically make overlapping platforms unnecessary. Different products can provide very different enterprise context, user experiences, governance, security and integration even when some underlying AI technology overlaps.
The question is whether that overlap creates additional business value.
Use the Governance Structure You Already Have
This connects with something I wrote about earlier on building an Agentic CoE.
Every new AI platform doesn't require another Center of Excellence.
If your organization already has a dedicated AI or Agentic CoE managing AI workloads, align these evaluations with that team.
If AI governance already sits across Digital Workplace, Architecture, Cloud, Data, Security, Automation or Innovation teams, build on that existing model.
And if that capability doesn't exist today, establishing an appropriate AI governance and evaluation structure becomes increasingly important.
The name of the team matters less than having the right people around the table.
Bring the Capabilities to the Table First
Before taking every new capability to thousands of users, bring it to the table first.
Let the AI CoE or existing governance structure work with platform teams, security, architecture and the champions community. Give selected capabilities to representative business users and test them against real business use cases.
Understand:
What business problem are we solving?
Which platform is best positioned for that workload?
Where do capabilities overlap?
What enterprise data does it require?
What are the identity, security and compliance implications?
What does it cost?
What measurable value does it produce?
Who actually needs access?
Instead of asking:
"Which AI platform is better?"
perhaps the better question is:
"Which AI capability is right for this business use case?"
Some employees may need Copilot. Others may benefit more from ChatGPT or Claude. Developers may require a different combination, while power users and AI champions may genuinely benefit from access to multiple platforms.
Not everyone needs everything.
Governance May Also Cross Platform Boundaries
Another interesting development is that these ecosystems don't necessarily have to remain completely isolated.
OpenAI has indicated that specialist Dots are planned to integrate with Microsoft Agent 365, bringing another dimension to cross-platform agent governance.
It is still early and worth watching rather than drawing conclusions from today.
But as enterprises adopt agents from multiple vendors, the ability to discover, govern, secure and monitor them through common enterprise controls could become increasingly important.
A multi-AI workplace may eventually involve multiple AI providers while maintaining common governance around them.
ROI Needs to Follow the Use Case
Adoption alone isn't ROI.
Knowing that employees activated an AI tool tells us something about adoption, but not necessarily whether the investment is delivering business value.
I would look at something closer to:
Use Case → Platform → Cost → Adoption → Time Saved → Quality → Business Outcome
If AI materially reduces effort while maintaining or improving quality, there is a value story.
If the same employee has three AI licences but consistently uses only one, there may be an optimization opportunity.
And as persistent agents consume resources while performing asynchronous work, AI FinOps and observability become increasingly important.
The objective shouldn't be to give every AI product to every employee.
It should be to put the right capability in the hands of the people and processes where it creates measurable value.
A Note on Availability
Many of these capabilities are still evolving.
Microsoft Copilot Cowork is already generally available, while the newer Home, Code and Autopilot experiences are still progressing through their respective rollout stages. Microsoft says Home will begin reaching its Frontier program in the coming weeks, with Code following at the end of the month and wider access afterward. Autopilot is currently in private preview.
OpenAI Dots is rolling out gradually to eligible users, while Anthropic Managed Agents remains in beta. Anthropic is also progressively bringing Chat and Cowork together, starting with Pro and Max plans. For Enterprise customers, Anthropic says admins will hear from it at least 30 days before anything changes for their organization.
Features, licensing and availability will continue to change, so organizations should validate current vendor guidance before making platform or rollout decisions.
What This Means for Enterprises
Microsoft Copilot, ChatGPT and Claude are all evolving beyond conversational AI toward delegated work, agents, coding, application integration and increasingly persistent execution.
For enterprises, that doesn't mean deploying everything.
If you already have an AI CoE, use it. If you have an established governance model, build on it. Bring your champions and representative business users into the evaluation, test real use cases and understand the overlap before scaling.
The technology will keep changing, and today's differentiator may become tomorrow's standard feature.
So perhaps the question is no longer:
"Which AI should we buy?"
but:
"Which AI capability creates the most value for this work?"
Three Practical Takeaways
If I had to reduce this to three things for enterprise teams:
Map capabilities, not just vendors. Understand where the platforms overlap and where each genuinely adds value.
Use the governance you already have. Extend your existing AI CoE or governance model rather than creating another structure for every new platform.
Pilot before you scale. Test real business use cases with representative users, measure the value and understand the governance implications before expanding access.
From AI Cost to AI Capacity
Microsoft's Jared Spataro recently added another interesting dimension to the FinOps for AI discussion: as agentic AI becomes increasingly consumption-based, the question isn't only how much AI costs, but which business priorities should receive that capacity in the first place.
This shifts the conversation from simply managing AI consumption toward allocating AI capacity based on business value.
Central teams can provide governance, visibility and common controls, while business leaders closer to the work can help determine where that capacity should be invested. The important part is connecting the investment to an expected outcome, measuring whether it delivered, and then scaling what creates value and retiring what doesn't.
For me, this reinforces a simple principle:
AI FinOps shouldn't stop at measuring consumption. It needs to connect consumption to business outcomes.
Not everything announced at DevDay is available to everyone immediately. OpenAI is rolling out GPT-6.1 Sol in ChatGPT Work and Codex, starting with Pro and expanding to Plus, Business, Enterprise and Edu. Dots are initially rolling out to eligible Pro and Business Premium users, with an Enterprise beta, and OpenAI says access may take several days even for eligible accounts.
Other capabilities announced at DevDay are also being introduced progressively, so availability will depend on the feature, plan and region.
For the latest rollout details, check the OpenAI ChatGPT Release Notes alongside the official DevDay recap.
Connecting This to My Earlier Posts
One thing is becoming increasingly clear from these announcements: AI is moving beyond simply answering prompts.
Earlier, I wrote about the evolution of Copilot, autonomous agents, AI governance and FinOps for AI. DevDay adds another piece to that journey — AI systems that can increasingly take actions, use tools and continue working asynchronously.
The individual products will continue to evolve, but the broader direction is worth watching.
We are moving from AI that assists with work toward AI that can participate in the work itself.
I'll explore some of these announcements individually as they mature and as their enterprise implications become clearer.
If you're exploring the GitHub Copilot app and agentic development, Microsoft has released a useful free, open-source hands-on course worth checking out.
The course goes beyond basic code generation and introduces how developers can work with AI coding agents through the GitHub Copilot desktop app.
It covers areas including Interactive, Plan and Autopilot modes, sessions and Git worktrees, custom agents, MCP servers, plugins, canvases and automations.
One part I particularly like is the emphasis on validation.
As coding agents take on longer and more autonomous tasks, it becomes increasingly important to review the changes, run the tests and validate the outcome rather than simply accepting that an agent has completed the task correctly.
You don't need previous experience with agentic development to get started, although some familiarity with GitHub, Git and npm will help.
If you're trying to understand how GitHub Copilot is evolving from a coding assistant towards a more agentic development experience, this looks like a good practical place to start.
Microsoft has announced that Azure Communication Services (ACS) will retire as a standalone offering on September 30, 2028.
I initially looked at this from an ACS Email perspective, but this is much broader.
Several ACS services are being retired, including Email, SMS, Advanced Messaging with WhatsApp, Chat, Rooms, Direct Routing, Job Router, Number Management (Direct Offer) and the Web and Mobile UI Library SDKs.
Not everything is going away. Microsoft says capabilities including Voice and Video Calling, Call Automation, Call Recording, Call Diagnostics, Audio Streaming and Closed Captions will continue, although customers should expect breaking changes and migration requirements.
One detail sharpens that timeline: beginning October 23, 2026, new customers can no longer sign up for the retiring ACS services. Existing resources created before that date can continue during the transition period.
That makes the message for organizations considering ACS today fairly simple: don't start new workloads on a service that is already on a retirement path.
Why ACS Email Caught My Attention
ACS Email has been one of the options for organizations looking to modernize application email and move away from traditional SMTP relay approaches.
So, for organizations that have already adopted ACS Email, this announcement naturally raises the question: what comes next?
Right now, I wouldn't rush into another technology decision.
The retirement date is still two years away, and Microsoft may provide additional migration options, alternatives or more detailed guidance as we get closer to 2028.
But I also wouldn't wait until the last minute.
This is a good time to understand where ACS is being used, which applications depend on it, what services they consume and how critical those integrations are.
For ACS Email, that means identifying application-generated email, notifications and transactional workloads. The same exercise applies to SMS, Chat, WhatsApp and the other affected services.
Be Aware and Start Preparing
There is no need to panic or start migrating everything tomorrow.
Understand your ACS footprint, document the dependencies and keep watching Microsoft's migration guidance.
Cloud services evolve, architectures change and sometimes services retire. Good platform lifecycle management is really about being prepared for those changes rather than reacting when the deadline gets close.
September 2028 gives organizations time.
The important thing now is to know what you have, understand what is impacted and be ready for what comes next.
Microsoft has introduced a new Copilot experience built around Home, Code and Autopilot.
There have been plenty of Copilot updates over the last few years, but this one caught my attention because it shows how quickly Copilot is moving beyond simply answering questions, summarizing information or creating content.
Home brings Copilot Chat and Cowork together, with Word, Excel and PowerPoint creation also becoming part of the experience. It gives users a more unified place to work with Copilot rather than moving between different AI experiences.
Code is another interesting addition. Users can describe what they want to build in natural language and Copilot can help turn that idea into an application. It doesn't replace traditional development, but it certainly makes building applications more accessible to people who understand the business problem but may not be developers themselves.
For me, Autopilot is probably the most interesting part.
Formerly known as Scout, it is designed for ongoing work that can continue in the background instead of waiting for us to provide the next prompt. This is where the shift from AI assistants to agents becomes much more visible. We are not just asking AI for help anymore; we are gradually starting to delegate work to it.
Microsoft is also introducing Microsoft IQ, providing the enterprise context that Copilot and agents need to better understand the people, relationships and information around the work they are performing.
There is another part of this announcement that shouldn't be overlooked: FinOps for AI.
As Copilot moves towards more agentic and usage-based workloads, understanding AI consumption and cost becomes increasingly important. Microsoft is introducing new FinOps capabilities to provide better visibility and control over AI spending.
This announcement also follows Microsoft's recent discussion around building the system for AI at work, and the direction is becoming clearer.
Copilot is gradually becoming much more than an AI assistant sitting alongside our Microsoft 365 applications. It is becoming a place where we can work with AI, build with AI and increasingly delegate work to AI.
We are still early in this journey, and enterprises will need to get security, identity, governance, cost and human oversight right as these capabilities mature.
But Home, Code and Autopilot give us a good indication of where Microsoft believes the next phase of Copilot is heading.
Update (September 25, 2026): Microsoft Copilot Managed Runtime
The same day as the Home, Code and Autopilot announcement, Microsoft also introduced Copilot Managed Runtime into public preview — the enterprise hosting layer underneath apps built in Copilot Cowork, Copilot Code and Copilot Studio.
Functioning code was never the hard part. Provisioning, identity, policy and deployment were — and every app-building tool meant a separate governance stack. Managed Runtime fixes that with one shared foundation: Microsoft Entra identity, governed data access, and a single app inventory in the Microsoft 365 admin center, regardless of where the app was built.
Microsoft is also opening this to third-party tools via an SDK, so the goal looks less like "make Copilot Code production-ready" and more like "one governance model no matter where the app comes from."
If you want a more structured, hands-on way to build these skills, Microsoft launched an AI at Work playlist in AI Skills Navigator on September 28, covering three practical areas: navigating when to use Chat, Cowork, Code and Autopilot for different outcomes; understanding AI FinOps concepts for balancing usage, cost and value; and building familiarity with Copilot Studio and agent harnesses as agents take on more connected, multi-step work.
It's a useful next step once you've read through the announcements above and want to translate the "what" into "how I actually use this in my role." On the FinOps piece specifically, I've covered the token/credit cost-management side in more depth in my earlier post on FinOps for AI— worth a read if usage-based billing is new territory for your org.
