Three Months of Learning: 10 Perspectives on Enterprise AI, Digital Workplace & Governance

Over the past three months, I've been writing about developments across enterprise technology, from Digital Workplace and Microsoft 365 to AI adoption, service management, security, and governance.

Looking back, what started as individual learning notes has gradually become a collection of connected perspectives.

Some articles focus on emerging technologies, while others explore the practical side of running enterprise IT services: testing, observability, operational ownership, financial governance, and the challenges that come with AI adoption.

As we begin November, I thought it would be a good time to bring together ten articles from August through October 2026.

This isn't a ranking or an exhaustive list. It's a collection of topics I've enjoyed exploring, organized to help readers discover something relevant to their interests.

Watch: Three Months of Learning in 60 Seconds

The visuals in this video are AI-generated and represent a conceptual scenario, not an actual implementation or prediction.

Digital Workplace & Enterprise AI

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

The Digital Workplace is evolving into an AI-enabled environment, but the foundations remain important. This article explores how employee experience, endpoints, collaboration, identity, security, and service governance continue to shape the modern workplace.

2. Enterprise AI Is Evolving Fast: Are We Ready for a Multi-AI Workplace?

With Microsoft Copilot, ChatGPT, Claude, Gemini, and other AI platforms becoming part of the enterprise conversation, organizations have more choices than ever. I explore what this means for adoption, integration, and governance.

Service Operations, Testing & Observability

3. AI-Enabled Service Management: Automating Work, Evolving People's Roles

AI and automation are changing how IT services are delivered. This article looks at the opportunities to improve service operations while maintaining clear ownership, accountability, and human judgment.

4. Is Your Organization Investing Enough in Testing Before Production?

Technology is evolving quickly, but are our testing environments and validation practices keeping pace? I share why testing, change governance, phased deployments, and operational readiness deserve continued investment.

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

As enterprise environments become more interconnected, understanding service health and employee experience is increasingly important. This article explores observability, AI-assisted investigation, automated remediation, and why operational ownership still matters.

AI Economics & Agent Governance

6. FinOps for AI: Understanding Tokens, Copilot Credits and the Real Cost of AI

AI adoption brings new consumption models and financial considerations. From tokens to Copilot credits, I explore how organizations can better understand usage, manage costs, and connect AI investments to business value.

7. Building an Agentic Center of Excellence: Do We Really Need Another CoE?

As organizations introduce AI agents, governance structures are evolving too. Rather than immediately creating another CoE, this article explores how existing enterprise capabilities might be extended to support agentic AI.

8. Who Owns an AI Agent After It Goes Live? Building the Enterprise Agent Operating Model

Deploying an AI agent is only the beginning. Who owns it when something goes wrong? This article explores operational accountability, agent identities, access controls, monitoring, and lifecycle management.

Security, Regulation & Responsible AI

9. The EU AI Act Enters Enforcement: What It Really Means for Microsoft 365 Copilot

August 2026 marked an important milestone for the EU AI Act, with new transparency obligations and enforcement powers for applicable provisions. This article explores what those developments mean for enterprise AI adoption, why Copilot use cases need to be assessed individually, and how organizations can prepare for requirements taking effect in later phases.

Looking Ahead: The Enterprise of 2035

10. The Enterprise of 2035: Who Will Lead the AI Workforce?

I wanted to close this collection with a different perspective, one that looks beyond today's technology announcements.

What might the enterprise look like in 2035, when people and AI agents could be working alongside each other at a much greater scale?

This article explores ten possibilities for the future workplace, including AI agent identities, evolving responsibilities, human leadership, and the importance of developing judgment and experience in an AI-enabled world.

Looking Forward to November

October brought plenty of interesting developments, and November looks promising too.

Microsoft Ignite 2026, scheduled for November 17–20, is just around the corner. I'm particularly interested in what Microsoft shares across Copilot, AI agents, security, governance, and the evolving Digital Workplace.

There will be more to explore, but as always, I prefer to look beyond the announcements and understand what they mean for enterprise adoption and day-to-day operations.

I'll be following the developments and sharing my learning notes and perspectives here on Exchange Anywhere.

Explore More with AI Atlas

If you're exploring some of the terminology and technologies discussed in these articles, you can also visit my AI Atlas.

It brings together AI vocabulary, technology landscapes, enterprise adoption frameworks, governance concepts, and other learning resources in one place.

Closing Thoughts

Looking back at these three months, one thing stands out to me.

The technologies may be changing rapidly, but the fundamentals of enterprise IT haven't disappeared. Reliable services, secure environments, good governance, responsible investment, and clear accountability remain just as important.

AI is adding a new dimension to all of this, and there's still plenty for us to learn.

Thanks for following along, and here's to more learning and conversations in November.

Stay tuned to Exchange Anywhere for more updates.

Discover, Govern and Contain AI Agents: Microsoft's Expanding Enterprise Security Approach

Discover, Govern and Contain AI Agents: Microsoft's Expanding Enterprise Security Approach

As AI agents become part of enterprise operations, an important question emerges: How do organizations discover agents, govern their access, and respond when they behave unexpectedly?

These agents may be developed through Microsoft Copilot Studio, hosted on third-party platforms, or installed directly on employee workstations.

Microsoft's October 29 announcement on the general availability of local AI agent discovery through Defender for Endpoint marks another important step toward enterprise-wide AI visibility.

1. Discover: Where are our AI agents?

Microsoft provides different discovery mechanisms depending on where an agent operates.

• Microsoft 365 agents: The Microsoft 365 Agent Registry provides visibility into supported Microsoft, partner, organizational, and user-shared agents.
• Third-party cloud agents: Microsoft Agent 365 supports connected-platform synchronization from Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, Databricks Genie, Anthropic Claude Managed Agents, Oracle Generative AI Agents, and Snowflake Cortex.
• Local AI agents: Microsoft Defender for Endpoint discovers supported agents such as Claude Code and Cursor on managed Windows and macOS devices, including their configured Model Context Protocol (MCP) servers.

For local agents, administrators can navigate to Microsoft Defender portal → Assets → AI agents → Local agents.

Discovery begins after Defender observes supported agent activity on an onboarded device. An installed but inactive agent may not appear immediately.

Microsoft's October 29 announcement describes coverage for more than 50 supported agents and MCP servers. However, no discovery mechanism guarantees visibility into every custom or unsupported agent.

2. Govern: Where does Agent 365 fit?

Microsoft Agent 365 provides a centralized governance approach, while the Microsoft 365 Agent Registry offers inventory, ownership, and administrative visibility.

Microsoft Defender contributes security discovery and investigation. Microsoft Entra and Purview provide complementary identity, access, and data security capabilities.

For connected third-party platforms, an important distinction applies:

Connections are read-only by design. Agent 365 does not invoke, execute, or modify agents in the source platform through these connections.

The exception is an administrator's explicit action to remove a synchronized agent, which requires a separate, optional deletion permission.

Organizations can withhold that permission unless there is a clear operational requirement.

Ownership matters beyond initial onboarding

Connected-platform governance also introduces operational responsibilities:

• Synchronization: Registry synchronization is manual. Changes or deletions in the source platform may not automatically appear in the registry, making periodic reconciliation important.
• Credentials: Supported connections require key-based credentials. Credential rotation, secure storage, and expiry monitoring need clear ownership.
• Administrative responsibilities: The Agent 365 AI administrator manages connection setup, validation, and synchronized-agent verification, while the source-platform administrator provisions credentials and grants permissions.

The Microsoft 365 Agent Registry also highlights agents without owners, including situations where a shared agent's creator has left the organization. This reinforces an important governance principle: agent ownership must be reviewed throughout its lifecycle, not just assigned during deployment.

These are practical examples of why AI agent governance requires shared accountability between platform, identity, and security teams.

3. Contain: When an agent behaves unexpectedly

Consider an employee running an AI coding assistant on a managed corporate laptop, configured with an MCP connection to an internal development service.

Defender discovers the supported agent, its associated device and account, and the configured MCP server.

Security teams can investigate its configuration, including whether the agent automatically approves its own actions, and assess the associated identities and potential exposure.

Depending on the deployment, typical incident-response steps may include:

• Microsoft 365 agents: Use supported administrative controls to block or remove the agent.
• Local endpoint agents: Restrict the application, investigate the endpoint, or isolate the device when warranted.
• Third-party cloud agents: Use source-platform controls to disable the agent or revoke affected credentials and integrations. Where supported and explicitly authorized, Agent 365 may provide a synchronized-agent removal action.

These are general incident-response approaches, not a single automated containment capability delivered by Defender discovery.

Discovering an agent does not automatically provide a universal kill switch.

4. Licensing, availability and limitations

Microsoft's October 29 announcement describes local AI agent discovery on Windows and macOS as generally available.

An earlier Microsoft Learn implementation page still labels macOS discovery as preview. Because these sources differ, organizations should confirm current platform-specific availability before deployment.

Other considerations include:

• Licensing: Defender for Endpoint Plan 2 supports discovery and advanced hunting. Agent risk levels, risk indicators, and security recommendations require Microsoft 365 E7, or Microsoft Agent 365 together with Defender for Endpoint Plan 2.
• Cloud availability: Local agent discovery requires Microsoft's commercial cloud; sovereign and national clouds are not supported.
• Runtime protection: Windows runtime prompt-injection protection remains in preview and is separate from discovery.
• Observability: Connected-platform observability data collection is a separate capability associated with the Frontier preview program; agent synchronization should not be confused with full runtime monitoring.

My perspective

Enterprise AI governance must extend beyond centrally managed agents.

Digital Workplace, EUC, identity, and security teams increasingly need visibility into local AI tools, third-party agents, their permissions, and the enterprise systems they can access.

But visibility alone is not enough. Organizations also need clear responsibility for agent ownership, registry synchronization, credential lifecycle, access reviews, and incident response.

Three questions should guide the operating model:

Can we discover the agent? Who governs it? How can we contain it?

This complements my earlier article, Who Owns an AI Agent After It Goes Live?, which explored ownership and operational accountability.

The next step is translating those principles into practical security operations.

Official Microsoft references

• Microsoft Defender — Local AI agent discovery announcement
• Microsoft Learn — Discover local AI agents with Defender for Endpoint
• Microsoft Learn — Connected platforms in Microsoft Agent 365
• Microsoft Learn — Agent Registry overview

Microsoft's Becoming Frontier: 8 Practical Guides for AI Adoption Across Business Functions

Microsoft has released a collection of eight practical e-books under its Becoming Frontier initiative, focused on how Microsoft 365 Copilot and AI agents can support different business functions.

What makes this collection useful is its role-based approach. Rather than presenting AI as a single technology deployment, the guides explore how different teams can apply AI to their everyday work, decisions, and business processes.

What's included?

The collection covers eight business functions:

• Leadership: Decision-making, work redesign, and scaling AI adoption.
• Marketing: Customer insights, campaign planning, and workflow improvement.
• Finance: Financial insights, controls, and accountability.
• HR: Workforce processes and preparing employees for AI-enabled work.
• IT: Modernizing operations and establishing a secure AI foundation.
• Legal: Improving legal workflows while maintaining trust and governance.
• Sales: Customer engagement, pipeline visibility, and sales decisions.
• Customer Service: Case resolution, SLA risk, escalation management, and customer outcomes.

My perspective

One of the challenges with enterprise AI adoption is moving beyond technology availability to meaningful business use cases.

An AI agent supporting IT operations will have different data, permissions, success measures, and operational responsibilities from an agent supporting Finance or Customer Service.

That's why a role-based approach matters.

Organizations need to understand where AI can create value, how employees will work alongside it, and who will maintain accountability once these capabilities become part of everyday operations.

This also connects with my earlier article, What It Takes for an Organization to Become a Frontier Firm, where I explored the broader organizational transformation needed to move beyond AI experimentation. Microsoft's role-based guides complement that perspective by providing practical starting points for applying AI across different business functions.

These guides provide a useful starting point for organizations looking to translate AI strategy into everyday work and measurable business outcomes.

Explore the guides

Microsoft has made the collection available through its official resource page:

Becoming Frontier — Microsoft 365 Copilot and Agents e-book collection

These are Microsoft learning resources. Individual guides may require registration.

Final thought: The opportunity with enterprise AI isn't simply to introduce more agents. It's to identify where they can improve work, establish the right controls, and deliver measurable business outcomes.

Copilot Cowork Skills for Leaders: A Practical Guide and a Governance Perspective

I came across a 97-slide guide, The Big Book of Cowork Prompts & Skills for Leaders & Executives, shared by Abigail Bohrer of Microsoft on LinkedIn.

It offers practical examples of how leaders can move beyond individual prompts and use reusable skills to simplify everyday work.

The guide's original publisher has not been independently verified.

What's Inside?

The guide covers:

• 8 practical prompts for calendar planning, open actions and escalation management.
• 20 reusable skills for meeting preparation, decision-making, vendor negotiations and leadership activities.
• 8 multi-skill workflows, including a weekly briefing that combines 12 skills.
• Guidance on sharing skills, managing credits and measuring productivity improvements.

What Caught My Attention?

Beyond personal productivity, reusable skills introduce some familiar enterprise considerations.

Ownership: When skills are shared across teams, who maintains, reviews and retires them?

Governance: What information can skills access, and how should sensitive employee or business data be handled?

Cost: How do organizations monitor Copilot credit consumption and ensure it delivers measurable value?

Adoption: Can improvements in meeting time, decision turnaround and follow-up activities demonstrate real productivity gains?

These questions connect with my earlier discussions on AI agent ownership and AI FinOps.

My Perspective

The interesting shift isn't simply having more prompts. It's turning useful instructions into reusable skills that support repeatable business workflows.

For enterprises, that opportunity also brings responsibility for ownership, access, lifecycle management and cost.

Productivity tools scale faster than the habits that govern them. Reusable skills are no exception.

References

• Abigail Bohrer's LinkedIn post sharing the guide
• Microsoft Adoption — Copilot Prompt Gallery

From GitHub Copilot Harness to Microsoft Copilot Harness: What's Changed?

Microsoft Copilot Harness — A Shared Execution Foundation Across Copilot Studio and Microsoft Foundry.

Back in August, I wrote about the different harnesses available in Microsoft Copilot Studio: Standard, Copilot Chat and GitHub Copilot. I also shared Microsoft's Agent Academy learning paths for getting hands-on with them.

Microsoft's October 28 announcement brings an interesting update to that earlier discussion.

The GitHub Copilot harness in Copilot Studio is now called the Microsoft Copilot harness.

But there is more to this announcement than a name change.

What Has Changed?

Microsoft is extending a shared harness foundation across its Copilot experiences, including Microsoft Foundry.

In Copilot Studio, the change is primarily about naming. Existing agents continue working without changes to their capabilities or billing, and the updated terminology will appear over the coming weeks.

In Microsoft Foundry, however, Microsoft has introduced the Copilot harness in Foundry Agent Service in public preview.

It provides a managed execution environment for more complex agents, bringing together reusable skills, connected tools, file and code execution, subagent delegation and working-context management. Developers can also manage agent definitions alongside their application code.

Separately, Microsoft announced the general availability of long-running resilience for hosted agents, helping workflows recover from interruptions. Applications still need to manage their own checkpoints and avoid duplicate actions when restarting.

Understanding the Harness Evolution: Renaming in Copilot Studio, Shared Capabilities, and Expansion into Microsoft Foundry.

Why I Find This Interesting

When I first explored harnesses, the discussion was mainly about choosing the right approach for building an agent.

The Standard harness was useful for more structured, predictable workflows, while the GitHub Copilot harness supported more flexible, reasoning-intensive tasks.

Now Microsoft is extending that execution foundation beyond Copilot Studio into Foundry.

Microsoft also shared some interesting results from its internal evaluations:

• Changing harnesses made a greater difference to task pass rates than changing models in the scenarios Microsoft evaluated. Compared with the Standard harness, Microsoft reported improvements of 10.8 percentage points with an OpenAI model and 22.1 percentage points with an Anthropic model.
• After a failed tool call, agents using the Microsoft Copilot harness continued attempting the task in 84–91% of evaluated cases, compared with fewer than 7% using the Standard harness.

These are Microsoft's internal evaluation and telemetry results, not independent benchmarks. The results may vary by model, configuration and scenario, and continued attempts do not necessarily mean the overall task was completed successfully.

Still, they reinforce an important learning: a more capable AI model alone doesn't guarantee a more reliable agent. The execution system around it matters too.

A Note on Preview Availability and Cost

The Microsoft Copilot harness in Foundry Agent Service is currently in public preview.

During this preview, the harness must be selected when creating an agent. Existing agents remain unchanged, and switching the harness after creation is not yet supported.

Harness runtime usage is free until December 1, 2026, after which consumption-based runtime billing begins. However, model inference, separately billed tools and connected services may still incur charges during the free-runtime period.

This is separate from Copilot Studio's existing billing arrangements, which Microsoft says are unaffected by the rename.

Connecting This to Agent Ownership

Microsoft's Copilot Studio announcement also points to persistent, proactive agents using capabilities such as agent accounts, business process memory and triggers.

As agents take on ongoing business responsibilities, their execution capabilities must be accompanied by clear accountability.

This connects to another topic I explored recently: Who Owns an AI Agent After It Goes Live? Building the Enterprise Agent Operating Model.

An agent that can continue working, retain context and execute actions still needs a named owner, appropriate permissions, monitoring and a way to intervene when something goes wrong.

My Perspective

For me, this announcement connects the learning from August with where Microsoft's agent platforms are heading.

We started by understanding different harness types and how to build agents with them. Now we're seeing Microsoft extend a shared execution foundation across its broader AI ecosystem.

For organizations adopting agents, the starting point should remain the business scenario, required controls, complexity and cost—not simply which harness is newest.

The model provides intelligence. The harness helps turn that intelligence into controlled execution..

Related Reading — Exchange Anywhere

• Copilot Studio Harness Explained: Types, Examples, and What Each One Costs in Copilot Credits
• Copilot Studio Harnesses in Practice: Microsoft's Free Agent Academy
• Who Owns an AI Agent After It Goes Live? Building the Enterprise Agent Operating Model

References — Official Microsoft Sources

• The GitHub Copilot harness in Copilot Studio is now the Microsoft Copilot harness
• Microsoft Foundry Blog — Microsoft Copilot Harness in Foundry

Microsoft Teams in 2026: From Collaboration Platform to AI-Powered Workplace

Microsoft Teams has come a long way from chat, meetings, and calling. Looking at Microsoft's announcements from September and October 2026, it's clear that Teams is evolving into something bigger, bringing AI, intelligent communications, and stronger governance into everyday collaboration.

Here are some innovations worth watching, particularly for organizations managing Teams at enterprise scale.

Meetings are becoming organizational knowledge

One significant development is AI archives for Teams meetings. Copilot and Facilitator can use AI-generated meeting memories to answer questions about earlier discussions. These archives are stored in Teams-owned SharePoint Embedded containers without storing raw transcripts.

Deleting or expiring a transcript doesn't automatically delete its AI archive. Depending on expiration settings and Microsoft Purview retention policies, these memories may remain accessible to AI beyond the transcript's retention period. The default archive expiration is five years.

This raises an interesting question: How long should AI remember organizational conversations?

AI archives are in preview for organizations participating in the Teams Technology Adoption Program (TAP). They aren't created for certain encrypted or content-restricted meetings and don't yet support information barriers.

Other improvements include AI-generated video recaps, translated intelligent recaps, and Interpreter support for eligible Teams Rooms on Android, helping employees revisit meetings and collaborate across languages.

Copilot is moving closer to everyday work

Copilot can be opened directly from Teams messages or selected conversation text, carrying relevant context into the interaction. Teams search also helps employees discover agents and apps.

These improvements bring AI assistance closer to where employees already work.

Teams Phone is getting smarter

The Teams Phone Agent, now generally available, introduces an AI-powered receptionist that handles routine questions and routes callers with contextual summaries.

Microsoft is also expanding Intelligent Call Delegation, an AI-powered personal call assistant that can answer incoming Teams calls, gather caller context, and schedule follow-up appointments through Microsoft Bookings. Already available through the Frontier early-access program, it is planned for broader public preview in November 2026 and general availability in January 2027, subject to licensing and administrator configuration.

The Queues app is also evolving with intelligent call recaps, Copilot-assisted insights, and automatic recording and transcription.

The recording capability deserves particular attention. Recordings and transcripts are stored in SharePoint, with access governed through recording templates and the Queues app.

An important governance consideration: Explicit recording consent must be turned off for automatic call queue recording to work. Callers instead hear a recording announcement. Organizations should review applicable legal, privacy, and compliance requirements before enabling it.

Deployment requires conference mode, group- or channel-based call answering, and Shared Call History. Recording access settings and the SharePoint destination are fixed when the template is created. Changes to SharePoint structures or permissions can also cause recording failures.

Security and management are evolving too

Teams provides external bot detection and lobby controls, requiring organizer approval before detected external meeting bots can join.

The Security Detection Report in the Teams admin center provides visibility into messaging threats such as impersonation, malicious URLs, and potentially dangerous files.

Microsoft is also improving cross-tenant meeting audit visibility and app and agent installation management across Teams, Outlook, and Microsoft 365 Copilot.

My perspective

What interests me most is how Teams is becoming a place where organizational knowledge is created, remembered, and acted upon.

That creates opportunities, but also responsibilities around information protection, retention, licensing, consent, and service ownership.

These developments connect to the broader questions in The Enterprise of 2035, particularly how AI changes organizational knowledge, decision-making, and human accountability. For the practical side, Who Owns an AI Agent After It Goes Live? makes the case that ownership, access controls, and governance need to be settled before AI becomes part of everyday operations.

The real value isn't enabling every AI feature. It's making collaboration simpler while maintaining governance and accountability.

Feature availability and licensing vary. Microsoft's What's New in Teams roundup now follows a quarterly schedule, with the next edition expected in December 2026.

Official Microsoft References

• What's New in Microsoft Teams — August–September 2026
• Help customers get answers and reach the right support with Teams Phone Agent
• AI Archives for Microsoft Teams Meetings
• Manage External Bots in Teams
• Automatic Recording for Teams Call Queues
• Intelligent Recap for Teams Calls and Meetings
• Microsoft Teams Release Notes
• Microsoft — Focus on the Teams Phone calls that matter most with intelligent call delegation

Microsoft Copilot Acceleration Team (CAT): Practical Resources for Enterprise AI and Agent Adoption

Building an AI agent is only the beginning. The harder work is knowing whether it performs reliably, whether its architecture will hold up at scale, and who keeps it running once it's live. Microsoft's Copilot Acceleration Team (CAT) brings together practical resources aimed at these challenges.

CAT is part of Microsoft's Copilot engineering organization. Its mission is to accelerate the adoption and success of Microsoft 365 Copilot and Copilot Studio, drawing on real-world customer experience. CAT is a resource hub, not a new Microsoft product.

Microsoft Copilot Acceleration Team (CAT) — Enterprise AI and Agent Adoption Resources.

Start with evaluation

The Copilot Agent Kit helps teams develop and test custom agents, validate AI-generated responses, optimize prompts, and track key performance indicators.

Its GitHub repository also documents capabilities such as Agent Inventory, Compliance Hub, Agent Review Tool, and performance analysis, extending its usefulness into agent governance and operational oversight.

For organizations preparing to deploy agents, evaluation should be considered early, alongside requirements, architecture, and security.

Design for operation, not just launch

CAT's guidance addresses the questions that come after a successful demonstration.

The Architect Agent Solutions guidance covers fit for purpose, operability, trust, search and tool use, and multi-agent architecture patterns.

The broader Agent Resources collection brings together resources for building, deploying, managing, and adopting agents across Microsoft's AI platforms.

For enterprise teams, these resources provide useful starting points for defining architecture standards, operational responsibilities, and governance practices before scaling deployments.

Learn by building

For hands-on learning, Microsoft's Copilot Studio Samples provide examples and reusable components that developers can explore and adapt.

The Skills for Copilot Studio GitHub repository provides tools for authoring, testing, and troubleshooting Copilot Studio agents through YAML files using compatible AI coding tools.

This repository is an experimental project rather than a formally supported Microsoft product, so generated configurations should be reviewed and validated before deployment.

CAT also offers learning opportunities, including Agent In A Day, monthly Agent Build-A-Thons, AI webinars, and a three-day Architecture Bootcamp for architects.

These programs help teams move from understanding agent concepts to building and evaluating practical solutions.

Keep up with the thinking

The Custom Engine blog shares insights, architecture patterns, and implementation practices from the CAT team on building custom engine agents and extending Microsoft Copilot.

It's a useful resource for following how Microsoft's practical guidance continues to evolve.

An enterprise leadership perspective

CAT's emphasis on evaluation, architecture, and operability connects with a broader question I've explored in The Enterprise of 2035: as AI agents become part of everyday enterprise operations, who remains accountable for their decisions, permissions, performance, and outcomes?

Technical capabilities alone cannot answer that question. Organizations need clear ownership, governance, operational accountability, and measurable outcomes throughout the agent lifecycle.

Resources such as CAT can help translate these principles into practical implementation approaches.

Where to start

If your organization is beginning its agent journey, explore the architecture and adoption resources alongside the evaluation tools. Use the samples and learning programs to develop practical experience.

For organizations already deploying agents, the testing, governance, performance-monitoring, and operational guidance may be particularly valuable.

Building agents is only the beginning. Evaluation, secure architecture, operational governance, and measurable business outcomes are what make enterprise AI adoption sustainable.

CAT provides a useful collection of resources to support that journey.

Official Resources

• Microsoft Copilot Acceleration Team (CAT)
• Copilot Agent Kit — GitHub
• Agent Resources
• Architect Agent Solutions — Microsoft Learn
• Skills for Copilot Studio — GitHub
• The Custom Engine — CAT Technical Blog
• CAT Learning Programs

The Enterprise of 2035: Who Will Lead the AI Workforce?

My perspective on how AI agents, human leadership, and emerging AI capabilities could reshape the future enterprise.

AI is evolving beyond traditional assistants. Agentic AI is beginning to execute tasks, coordinate workflows, and support business decisions across IT, finance, HR, sales, marketing, and operations.

Looking at today's developments, I envision a future where human employees and AI agents could operate as two interconnected workforces, with distinct identities, responsibilities, permissions, and governance boundaries.

Microsoft's 2026 Work Trend Index highlights an emerging shift in which AI agents take on more execution while people increasingly direct work, evaluate results, and remain accountable for outcomes. This reinforces some of the trends shaping my perspective on the enterprise of 2035.

But this raises a fundamental question:

If AI agents increasingly perform the work through which today's professionals developed their expertise, how will the next generation gain the experience and judgment needed to lead enterprises?

The potential evolution toward Artificial General Intelligence (AGI) adds another dimension. Its timeline, maturity, capabilities, and enterprise implications remain uncertain. More capable AI systems could reshape this operating model in ways we cannot yet anticipate.

Watch: The Enterprise of 2035 in 60 Seconds

The visuals are AI-generated and represent a conceptual scenario, not a prediction of how enterprises will operate in 2035.

What might an enterprise look like when humans and AI agents increasingly work alongside each other?

This short AI-generated video illustrates one possible future, highlighting human–AI collaboration, evolving workforce structures, and the continued importance of human leadership.

The following illustration explores ten possibilities for how the enterprise workforce might evolve by 2035.

The Future Enterprise: Humans and AI Agents — An illustrative vision of a human-led, agent-enabled organization.

Ten Possibilities for the Future Enterprise

1. Two workforces, one organization: Humans and AI agents may work together with distinct roles and responsibilities.

2. Outcome-driven work: Organizations could increasingly organize work around outcomes rather than traditional job structures.

3. Digital agent identities: AI agents may require identities, access permissions, ownership, and audit histories.

4. Human leadership: People remain responsible for strategic direction, judgment, ethics, and accountability.

5. Agent-to-agent collaboration: Specialized agents could coordinate activities across business functions.

6. Changing workforce structures: Greater automation may reshape staffing needs and productivity expectations.

7. New career pathways: Structured learning, mentoring, and supervised experience may become essential for developing future leaders.

8. Evidence-driven performance: AI-generated insights may inform evaluations, but employees must retain transparency and opportunities to challenge decisions.

9. Governance and resilience: Enterprises will need clear policies, oversight, and the ability to intervene when autonomous systems fail.

10. An uncertain future: More capable AI, potentially including AGI, could reshape these possibilities in ways we cannot yet predict.

Who Will Lead the AI Workforce?

My view is that future enterprise leaders will need to combine human judgment, business understanding, and the ability to direct and challenge intelligent systems.

Leadership cannot be reduced to supervising AI-generated dashboards. It requires understanding how work gets done, making decisions under uncertainty, developing people, and taking responsibility for outcomes.

As AI takes on more execution, enterprises must deliberately preserve opportunities for employees to develop foundational expertise, critical thinking, and independent judgment rather than assuming those capabilities will emerge through AI supervision alone. 

That also raises an unresolved accountability question: when an AI agent makes a harmful decision or takes an incorrect action, who owns the consequences?

I explored the operational ownership dimension in my earlier article, Who Owns an AI Agent After It Goes Live?.

What Should Enterprises Consider Today?

For enterprise leaders considering this transition, three priorities stand out today:

• Establish agent accountability: Identify deployed agents, their owners, permissions, and governance boundaries.

• Preserve career development: Ensure early-career professionals continue gaining practical experience through supervised work and mentoring.

• Design for human oversight: Build transparency, intervention mechanisms, and operational resilience into agent-enabled processes.

These foundations matter regardless of how quickly AI capabilities advance.

The real challenge may not be how much work AI can automate, but whether we can continue developing leaders capable of understanding, challenging, and governing increasingly autonomous enterprises.

References and Further Reading

• Microsoft — 2026 Work Trend Index: Agents, Human Agency, and the Opportunity for Every Organization — Research on how AI agents are reshaping work, human leadership, organizational structures, and accountability.
• Microsoft — Three New Patterns of Work — How AI is changing organizational workflows.
• Anthropic — Economic Index — Research into AI use across economic activities.
• NIST — AI Risk Management Framework — Identifying and managing AI-related risks.
• European Commission — AI Act — Regulatory requirements and risk-based AI governance.

Beyond the Commercial Cloud: Understanding Microsoft's Sovereign Cloud Ecosystem

Exploring Microsoft's cloud ecosystem beyond commercial Microsoft 365 and Azure.

When we talk about Microsoft 365, Azure or the Digital Workplace, most of us naturally think about the commercial cloud: Exchange Online, Teams, SharePoint, OneDrive, Azure services and the familiar Microsoft 365 tenant.

That has been my primary area of experience too.

But while reading Microsoft's latest announcement about digital sovereignty, I came across another part of the Microsoft Cloud ecosystem that I wanted to understand better.

Government clouds, sovereign cloud options, Azure Local and Microsoft 365 Local.

These aren't necessarily new technologies, but they are areas we may not encounter regularly when working with commercial Microsoft 365 environments.

I thought it would be useful to share what I've learned.

What Is Digital Sovereignty?

One thing that stood out to me is that sovereignty isn't just about where data is stored.

It's also about who can access systems, who operates the infrastructure, how sensitive information is protected and whether critical applications can continue working during disruptions.

In simple terms, digital sovereignty is about control, not just data location.

Different organizations have different requirements. A commercial business, government agency or highly regulated organization may not be able to use exactly the same cloud operating model.

Microsoft 365 Government: GCC, GCC High and DoD

Microsoft provides specialized Microsoft 365 environments for eligible US government organizations and contractors.

Environment	What it means
GCC	Government Community Cloud, designed for eligible US government organizations and qualifying contractors
GCC High	An environment for eligible organizations with more demanding security and compliance requirements, including certain defense-related workloads
DoD	A dedicated environment exclusively for the US Department of Defense, supporting DoD Impact Level 5 requirements

These environments have specific eligibility requirements and compliance commitments.

They also differ in service availability from commercial Microsoft 365. We shouldn't assume every feature or Copilot capability is available everywhere at the same time.

Microsoft Sovereign Cloud: Another Part of the Picture

Microsoft Sovereign Cloud is broader than the US government environments.

Microsoft describes three areas:

• Sovereign Public Cloud: Public-cloud services with additional options for data residency, security, encryption and operational control.

• Sovereign Private Cloud: Cloud capabilities running in customer-operated environments, including supported disconnected scenarios.

• Sovereign Partner Ecosystem: Independently operated national cloud environments and specialized partners addressing local requirements.

What interested me is that sovereignty isn't presented as one fixed destination.

The level of control can depend on the workload.

An organization might use public-cloud services for everyday collaboration while keeping certain sensitive systems or AI workloads within infrastructure it operates.

Azure Local: Bringing Azure Capabilities Closer

Another product worth understanding is Azure Local, previously known as Azure Stack HCI.

It allows organizations to run supported Azure workloads on infrastructure they manage, including within their own datacenters and other locations.

This can be useful when applications require local processing, operational resilience, regulatory controls or limited dependence on internet connectivity.

Azure Local also supports disconnected operations, subject to specific eligibility, infrastructure and technical requirements.

It isn't simply a replacement for Azure's public cloud. It offers another way to operate selected workloads.

Microsoft 365 Local: Not the Same as Microsoft 365 Online

This was particularly interesting from a Digital Workplace perspective.

Microsoft 365 Local enables organizations to run Exchange Server, SharePoint Server and Skype for Business Server on customer-owned and managed Azure Local infrastructure.

It is different from running the complete Microsoft 365 commercial-cloud experience locally. It does not mean an organization gets Exchange Online, SharePoint Online, Teams and every Copilot capability inside its own datacenter.

It packages the existing Subscription Edition server workloads within a Microsoft-validated Azure Local architecture, deployed through certified partners. Microsoft positions it for sovereignty, operational consistency, disconnected operation and business continuity. Whether it’s worth it depends on whether an organization has one of those requirements that its current environment doesn’t meet.

Microsoft confirms that Microsoft 365 Local is generally available.

Unlike enabling a service in an existing tenant, deploying Microsoft 365 Local requires a Microsoft-certified solution partner and validated Azure Local Premier Solution hardware.

For organizations still operating on-premises collaboration platforms, another important point is Microsoft's commitment to support the Subscription Editions of Exchange Server, SharePoint Server and Skype for Business through at least 2035.

In its October 20 announcement, Microsoft also described Foundry Local's integration with Microsoft 365 Local, currently in preview for approved customers. This extends local AI inference and agentic retrieval to locally operated SharePoint and Exchange servers.

The distinction is important: the integration is in preview, while Microsoft 365 Local itself is generally available.

Where Does Foundry Local Fit?

Microsoft is also expanding Foundry Local, enabling supported AI models and workloads to operate in customer-controlled environments.

According to Microsoft's October 20 announcement, Foundry Local is scheduled to become generally available for connected and disconnected operations on Azure Local at Microsoft Ignite 2026.

This introduces another consideration for enterprise AI adoption.

Not every organization will want sensitive data, model inference or AI workloads to depend entirely on public-cloud infrastructure.

For some, the ability to operate AI locally may be an important architectural requirement.

Microsoft's earlier Sovereign AI announcement (October 5, 2026) provides additional context around control, choice, flexibility and resilience in enterprise AI deployment.

It reinforces an important consideration: AI sovereignty isn't only about where data resides. It also involves how organizations select and operate models, control access to sensitive information, choose deployment environments and maintain operational continuity.

This complements the sovereign cloud and local AI capabilities discussed above, without suggesting that every organization needs to run AI workloads locally.

My Learning and Perspective

What I take away from this is that the Microsoft Cloud ecosystem is broader than the environments many of us work with every day.

We often discuss Digital Workplace transformation through Microsoft 365, collaboration, security, Copilot and AI adoption.

But there are other dimensions worth knowing about: government environments, sovereign infrastructure, local workloads, operational independence and AI deployment choices.

This doesn't mean every organization needs a sovereign cloud or that commercial Microsoft 365 is insufficient.

It simply means the right architecture depends on the organization's requirements.

For me, this was a useful learning exercise. I wanted to share it because understanding the wider ecosystem helps us ask better questions, even when we aren't directly working with these environments.

The Digital Workplace isn't limited to the commercial tenant, and the Microsoft Cloud ecosystem isn't limited to the public cloud.

Sometimes learning starts by discovering what exists beyond the platforms we're most familiar with.

Stay tuned for more learning notes and updates.

References

1. Microsoft — Advancing Digital Sovereignty with Greater Control and Choice (October 20, 2026)

2. Microsoft — Sovereign Cloud

3. Microsoft Learn — Office 365 US Government

4. Microsoft Learn — GCC High and DoD

5. Microsoft Learn — Azure Local Overview

6. Microsoft Learn — Microsoft 365 Local Overview

7. Microsoft Learn — Disconnected Operations for Azure Local

8. Microsoft — Sovereign AI: Accelerate Innovation with Control and Choice (October 5, 2026)

Is Your Organization Investing Enough in Testing Before Production?

Why investing in testing, change governance and observability is essential for operational stability, better employee experience and continuous innovation.

Listen to a short audio summary (6 min)

Prefer reading? The full article continues below.

Organizations continue to invest in cloud transformation, automation, AI and modern technology platforms. Product vendors are accelerating their roadmaps, while Agile, DevOps, CI/CD and Touchless Change Management are enabling faster technology delivery.

However, an important question deserves attention:

Are organizations investing sufficiently in testing environments and operational readiness to keep pace with these changes?

Based on my experience in enterprise IT service ownership, I continue to observe gaps in how some organizations invest in and prioritize their development, UAT and pre-production environments. While investments are being made, there is still room to strengthen testing capabilities, particularly as technology changes accelerate and delivery timelines become increasingly demanding.

Investing in testing, monitoring and operational readiness is not simply an additional IT expense. It helps organizations maintain stable services while creating more opportunities to focus on innovation.

Testing Environments Are an Essential Investment

Development, integration, UAT and pre-production environments play an important role in validating changes before they reach production.

These environments should adequately represent critical production configurations, dependencies, security controls and business workflows. They do not necessarily need to replicate every production component, but they should help identify risks relevant to the services being changed.

Testing should also cover appropriate failure scenarios, not just successful outcomes.

Testing environments should also use appropriately protected test data, with production credentials and sensitive information kept out of non-production environments wherever possible.

A change that works in isolation may behave differently when introduced into a complex enterprise environment.

Investing in suitable environments, test automation and skilled resources can help organizations strengthen validation practices and reduce avoidable disruptions.

Align Your Testing Roadmap with Technology Roadmaps

Technology vendors continuously introduce new features, security updates, platform changes and capabilities. Organizations may have limited control over these external release schedules, but they can establish their own approach to testing and deployment.

An organization's testing roadmap should evolve alongside the product and technology roadmaps it depends on.

This involves understanding upcoming changes, assessing dependencies, planning validation activities and allowing sufficient time for testing before broader deployment.

Not every change can be deferred, particularly when urgent security remediation is required. However, appropriate risk-based validation and deployment safeguards should remain part of the process.

Just because a new capability becomes available does not necessarily mean it needs to reach the entire organization immediately.

Pilot groups, phased deployments and clearly defined acceptance criteria can help teams evaluate changes before introducing them to larger user populations.

Change Management Is Evolving, but Validation Remains Essential

Traditional change management practices often relied on documented testing results, risk assessments, implementation plans and approvals before production deployment.

With DevOps, CI/CD and touchless change management, many of these activities can now be integrated into automated delivery pipelines.

Testing evidence, security checks, deployment results and approvals can be captured automatically, helping reduce manual effort while maintaining traceability.

Touchless change management should not mean testing-free change management.

Whether changes are deployed manually or automatically, organizations should maintain appropriate validation, risk-based controls and documented evidence.

The delivery approach may evolve, but the responsibility to protect production services remains.

Connecting Testing, Deployment and Observability

A reliable operating model should connect testing with deployment, monitoring and continuous improvement.

Stage	Key Considerations
Development and UAT	Validate functionality, integrations, security, business workflows and relevant failure scenarios using representative environments and appropriately protected test data.
Roadmap and change governance	Align testing with upcoming releases, assess risks, automate quality gates and retain validation evidence.
Production deployment	Use pilot groups, phased rollouts, health checks and appropriate rollback or recovery procedures.
Monitoring and observability	Monitor service health, performance, dependencies and unexpected behavior through relevant telemetry and alerts.
Remediation and improvement	Maintain response procedures, document findings and use production lessons to strengthen future testing.

These practices become increasingly relevant as organizations introduce AI agents and automation into enterprise workflows.

Beyond functional testing, teams should consider agent permissions, access to enterprise data, connected tools, unexpected actions and mechanisms for human intervention.

These considerations also connect with my earlier article, Who Owns an AI Agent After It Goes Live?

Testing Does Not End at Production Deployment

Even well-designed testing environments cannot reproduce every production condition.

This is where continuous monitoring and observability become essential.

Organizations need appropriate visibility into application and infrastructure health, integrations, performance and unexpected behavior through relevant logs, metrics, traces and alerts.

Equally important are clearly defined service ownership, incident response procedures and remediation capabilities.

Testing results, deployment records, approvals and operational documentation should also be retained to support troubleshooting, audit readiness and continuous improvement.

Production observations should feed back into testing strategies, helping teams address previously unidentified risks and strengthen future validation.

This complements the perspective shared in Observability Is Taking Center Stage

Three enterprise scenarios illustrating how testing, phased rollouts and continuous monitoring help reduce operational and security risks.

Update — 18 October 2026: When Trusted Applications Become a Security Risk

Illustration by the author, based on reporting from Huntress and ConnectWise.

The recent ConnectWise Cloud Backup (formerly SkyKick) incident highlights an important risk in Microsoft 365 environments: compromised vendor application credentials can provide access to customer tenants without compromising user passwords or triggering user MFA.

Huntress reported unauthorized application sign-ins across 162 tenants as of 16 October 2026. In one investigated tenant, a related application reportedly gained Global Administrator privileges and added credentials to other applications.

The lesson: Third-party application consent is not a one-time approval. Application identities, permissions and credentials require continuous governance, validation and monitoring.

Organizations should review:

• Application access: Identify affected applications by Application ID and follow vendor guidance on disabling them.
• Sign-in activity: Examine service principal sign-in logs, not just user sign-ins.
• Privilege changes: Investigate unexpected credentials, certificates and directory role assignments.
• Log retention: Preserve relevant logs promptly, especially where retention is limited.

This reinforces why testing, change governance and observability must work together, including for vendor-managed integrations and automated services.

References: Huntress Investigation | ConnectWise Trust Advisories

Final Thoughts

As enterprise technology continues to evolve, organizations should periodically reassess whether their investments in testing environments, validation processes and operational readiness remain aligned with their technology ambitions.

Where gaps exist, now is an appropriate time to revisit testing and operational strategies.

Testing roadmaps should evolve alongside product roadmaps, with teams having suitable environments, resources and time to validate changes before introducing them to larger user populations.

While strengthening these capabilities may require additional investment, it can help reduce avoidable production issues, minimize end-user disruption and improve service stability.

A stable IT environment with fewer recurring issues gives teams more time to focus on innovation, improve digital employee experiences and deliver greater business value.

Modernizing technology delivery should not mean rushing changes into production. It should mean enabling innovation with the testing, governance, observability and operational safeguards needed to support it.

Additional Resources — Microsoft Guidance

The perspectives shared in this article are based on my experience in enterprise IT service ownership, change governance and operational readiness. The following Microsoft Azure Well-Architected resources provide additional guidance for cloud workloads, with principles that are also relevant to Microsoft 365, endpoint management and broader enterprise IT operations.

1. Operational Excellence Design Principles — DevOps practices, operational excellence and reliable delivery.

2. Architecture Strategies for Testing — Testing strategies, validation and quality assurance.

3. Architecture Strategies for Designing a Monitoring System — Observability, telemetry and monitoring practices.

Windows Autopatch Adds Policy-Driven Update Approvals

Managing Windows updates across an enterprise requires balancing security, stability and employee experience.

Microsoft has introduced policy-driven update approvals in Windows Autopatch, allowing IT teams to choose which updates are approved automatically and which require manual review.

Microsoft targeted October 15, 2026, for rollout completion. Administrators can check their Microsoft Intune admin center for availability.

Scope clarification: These Windows Autopatch capabilities apply to eligible Windows client devices managed through Microsoft Intune. Windows Server operating systems are not supported by these Intune-based Autopatch policies and require separate server patch management solutions, such as Azure Update Manager or Microsoft Configuration Manager.

Figure: Microsoft 365 Message Center announcement MC1478956, published September 24, 2026, highlighting Windows Autopatch update approval enhancements. Illustrative recreation based on the announcement.

What's New in Windows Autopatch?

Capability	What It Means
Update approvals	Automatic or manual approval for monthly security, non-security preview and out-of-band updates
Flexible policies	Combine automatic and manual approval methods within one policy, including supported .NET Framework updates
Default behavior	Security updates default to automatic approval, other categories default to manual
Deferral periods	Delay automatically approved updates by 0–30 days
Pause controls	Pause individual update releases when issues arise
Quick machine recovery	Configure approval and deferral behavior for recovery updates that help repair Windows devices unable to boot after critical large-scale failures
Device reporting	Monitor update status, device readiness, assigned policies and deployment alerts. Report data refreshes approximately every four hours

These controls give endpoint teams more flexibility to automate routine security updates while retaining oversight of releases that need additional validation.

Three Important Things to Know

1. Pausing doesn't mean rolling back.

Pausing an update prevents further deployment but doesn't remove it from devices where installation has already completed. Microsoft notes that a pause can take up to eight hours to reach devices.

2. Hotpatch requires careful planning.

When hotpatch is enabled, devices won't receive approved non-security updates because installing them would interrupt the hotpatch servicing path. Administrators must disable hotpatch in the quality update policy to deploy those updates.

3. Approval methods cannot be changed after policy creation.

Switching between automatic and manual approval requires creating a new policy. This makes the initial policy design important.

What Does This Mean for Digital Workplace Teams?

The bigger change is not simply automation. It's how endpoint teams manage updates.

From manual approvals to policy governance: Teams can focus on defining approval rules, deployment rings, deferral periods and exceptions instead of repeatedly reviewing routine releases.

From reporting to action: Device-level visibility helps identify endpoints that require attention and supports targeted remediation. This aligns with the operational principles discussed in Observability Is Taking Center Stage.

Supporting AI-ready endpoints: As Windows evolves to support AI agents and intelligent workflows, maintaining secure, updated endpoints becomes increasingly important. I explored this broader direction in Windows Is Becoming a Platform for AI Agents.

Before You Enable It

Review Microsoft's prerequisites, device eligibility and update policies before enabling broader automation.

For example, .NET Framework update policy control applies to Windows 11, while Windows 10 devices enrolled in Extended Security Updates continue using client-side settings.

Organizations should also maintain pilot validation, deployment monitoring and clear ownership of failed updates or exceptions.

Final Thoughts

Windows Autopatch's latest enhancements offer a practical way to reduce repetitive update administration while improving deployment control and visibility.

Automating approvals removes repetitive work. It doesn't remove the need for someone to own what happens when an update goes wrong.

Resources

• Microsoft Learn — Windows Quality Updates and .NET Framework Updates
• Microsoft Learn — Quality Update Status Report
• Microsoft Learn — Quick Machine Recovery Updates
• Microsoft 365 Message Center — MC1478956: Windows Autopatch Enhancements (September 24, 2026) (Microsoft 365 admin sign-in required)

Stay tuned for more updates...