Microsoft 365 Copilot experiences for organizing work, collaborating, and using AI assistance.
Microsoft Copilot is evolving beyond a conversational assistant into a broader environment for organizing work, collaborating with teams, and using specialized AI capabilities.
With Microsoft's recent evolution of Copilot Notebooks into Workspaces and the introduction of Projects, I've been looking more closely at how these experiences fit together. While the capabilities are interesting individually, the more practical question is which one an everyday employee should use, and when.
Understanding the Differences
Copilot offers several complementary experiences, each designed for a different way of working. The following visual summarizes their primary purposes and where they fit into everyday productivity.
Microsoft 365 Copilot experiences at a glance — complementary capabilities, not a required sequence.
What Happened to Copilot Notebooks?
Microsoft is evolving Copilot Notebooks into Copilot Workspaces, bringing a stronger focus on shared context and team collaboration.
Existing notebook content and sharing arrangements carry forward. Importantly, a private notebook does not automatically become accessible to everyone.
The rollout is phased, beginning in late October 2026, so availability may vary across organizations.
Copilot Projects remains a separate experience, primarily intended for organizing individual work.
A Simple Workplace Example
Consider an employee preparing a quarterly service review.
They might use Copilot Chat to summarize information, Projects to organize personal analysis and working notes, Pages to refine the report, and Workspaces to share review materials and collaborate with colleagues.
If preparing these reviews becomes a recurring organizational requirement, a Copilot Agent could provide standardized assistance using approved knowledge and instructions.
This doesn't mean Projects automatically become Agents or that every task requires an Agent.
One Governance Consideration
As employees increasingly use AI to organize and perform work, organizations should consider what happens to the information and capabilities they create.
Who maintains an important Workspace when its creator changes roles? Where should business-critical outputs be retained? Who owns and reviews an Agent used by multiple employees?
The answers depend on the experience, its storage and sharing model, and organizational policies.
AI agents may outlive their creators. Ownership, knowledge, and accountability must endure.
Listen to a short audio summary (6 min)
Prefer reading? The full article continues below.
What happens when the person who built an AI agent is no longer available to support it?
Imagine an organization deploying an AI agent to automate SharePoint permission attestations.
The agent coordinates access reviews, follows up on pending approvals, and generates compliance reports. Everything works as expected, and over time, the organization starts depending on it.
Then the engineer who developed it leaves. Perhaps the engineer is an employee, or perhaps they work for a supplier whose contract is ending.
The agent continues to exist. But who understands its architecture, integrations, business rules, and recovery procedures?
Can another engineer take over without depending on the original developer?
This is where AI agent ownership becomes a digital succession challenge.
Here, I want to look at something closely related but different: how organizations retain the knowledge and operational control behind the AI assets they create.
The offboarding risk we may be overlooking
Employee offboarding is familiar territory for most IT organizations. Accounts are disabled, access is revoked, and responsibilities are transferred.
But AI agents introduce dependencies that may not be immediately visible.
An agent could rely on Power Automate workflows, APIs, connectors, knowledge sources, service identities, and configuration decisions made by one engineer.
Microsoft already documents how Copilot Studio agents can become orphaned when owners leave, and how Power Automate flows may fail when they depend on connections associated with departed employees.
Microsoft's agent registry can help identify agents without owners, while Agent Builder supports multiple owners to reduce reliance on a single individual.
These are useful capabilities. But identifying an orphaned agent or assigning a new owner is only part of the process.
Transferring ownership does not automatically transfer operational knowledge.
There are security considerations too. Depending on assigned privileges, a new owner may gain access to existing agent transcripts. That makes permissions and data-access reviews an important part of succession.
The AI Asset Passport: Keeping knowledge within the organization
I believe every production AI agent should have a simple, maintained record of what it does, how it works, and who can support it.
I would call this an AI Asset Passport.
Document the agent. Preserve the knowledge. Protect continuity.
It is a proposed governance practice, not an official Microsoft framework.
Area
What should be captured
Identity
Purpose, environment, business criticality
Ownership
Business owner, technical custodian, backup owner, supplier contacts
Dependencies
Workflows, APIs, connectors, knowledge sources
Security
Identities, permissions, data sensitivity
Operations
Monitoring, troubleshooting, recovery procedures
Knowledge
Architecture, source repositories, runbooks, change history
Succession
Successor details, handover evidence, validation date
The passport doesn't need to become another lengthy document.
It could be a lightweight record linking to existing CMDB entries, SharePoint repositories, source-control systems, and operational documentation.
What matters is that these records remain accessible to authorized teams, version-controlled where appropriate, and regularly updated.
Knowledge retention cannot be a one-time activity performed during deployment or offboarding.
Six practical controls for digital succession
I would build succession into existing enterprise service management and AI governance practices through six controls:
Accountable ownership: Assign a business owner, technical custodian, and successor.
AI Asset Passport: Maintain an inventory of purpose, dependencies, ownership, and operational references.
Knowledge continuity: Preserve architecture, configurations, runbooks, and change history in enterprise-controlled repositories.
Supplier succession: Establish backup resources, knowledge-transfer obligations, and exit procedures.
Operational validation: Verify that another authorized engineer can troubleshoot, modify, and recover the agent.
These controls are not intended to introduce bureaucracy. They are practical measures to prevent operational knowledge from disappearing when people change.
This approach also aligns with NIST's AI Risk Management Framework, which addresses AI system inventories (Govern 1.6), defined roles and responsibilities (Govern 2.1), safe decommissioning (Govern 1.7), and third-party risk management (Govern 6).
A practical example: SharePoint access attestation
Consider an organization that engages a supplier to develop an AI-assisted SharePoint permission attestation solution.
The solution uses an agent to coordinate reviews, Power Automate to orchestrate workflows, and approved Microsoft Graph integrations to retrieve relevant information.
A supplier engineer develops and supports the solution.
A few months later, that engineer is reassigned to another project.
The organization may have the agent, workflows, and necessary licenses, but the detailed knowledge of exception handling, approval logic, or technical dependencies may sit primarily with that engineer.
This does not mean the agent automatically stops working. The risk is that troubleshooting, maintenance, or future changes become difficult.
With a succession plan, the transition looks different.
The replacement engineer can access the AI Asset Passport, review current architecture and runbooks, validate workflow connections, and execute a controlled attestation test.
The service owner confirms that approvals, exceptions, reporting, and monitoring work before accepting the handover.
The organization has not simply reassigned ownership. It has demonstrated continuity.
Supplier dependency: The challenge deserves more attention
This is where I see a broader operational concern.
Across enterprise IT, knowledge transfer has always been a challenge, particularly in supplier-managed environments.
From my experience in enterprise service ownership and supplier management, I've seen how resource transitions, knowledge gaps, and unclear accountability can introduce operational risks, even when the underlying technology is working well. As AI agents become part of business operations, these challenges deserve attention from the outset.
People move between projects, contracts change, critical resources resign, and sometimes supplier teams are reorganized with very little notice. Often, the gaps become visible only when an incident occurs or a replacement engineer needs to make a change.
AI agents could make this challenge more significant.
A supplier may develop multiple agents across HR, Finance, Procurement, and IT. Each agent may contain business rules, prompts, workflows, integrations, and configuration decisions that are not obvious from the user interface.
If that knowledge stays with a few supplier engineers, the organization becomes dependent on individuals rather than on a sustainable operating model.
Suppliers may change. Enterprise knowledge and control must remain.
I believe supplier AI exit readiness should become part of vendor governance from the beginning of an engagement.
That means establishing a few expectations:
Enterprise-controlled knowledge:Architecture, configuration references, runbooks, test evidence, and change records should be maintained in approved central repositories, accessible to authorized customer teams.
Continuous knowledge transfer:Suppliers should update documentation as solutions evolve, with periodic walkthroughs and reviews rather than a last-minute handover.
Resource succession:Critical agents should have identified primary and backup support resources, alongside an accountable internal custodian.
Transition readiness:Changes in supplier personnel should trigger dependency checks, knowledge validation, and formal service-owner acceptance.
Contractual clarity:Deliverables, intellectual-property rights, transition assistance, and access revocation should be addressed in supplier agreements.
For proprietary solutions, organizations may not always receive source code or full control over the underlying technology. In those cases, data portability, configuration exports, and documented transition procedures become important.
The goal is not to eliminate suppliers or reduce their contribution.
It is to ensure that the knowledge needed to operate enterprise AI assets remains available to the organization, regardless of who delivers the service.
Measuring whether succession really works
I would keep the measurements simple.
Are production agents assigned accountable owners and successors? Is their documentation current? Have supplier-managed agents completed knowledge-transfer reviews?
And perhaps most importantly, how long would it take an authorized replacement engineer to take over and demonstrate that the agent can be operated safely?
For business-critical agents, I would introduce a periodic succession test:
Can someone other than the original creator support this agent using the knowledge, permissions, and tools the organization has retained?
True ownership is proven when the next person can operate independently.
If not, the handover is not complete, regardless of how many documents have been signed off.
From Governance Principles to Practical Action
Understanding digital succession is only the beginning. Organizations also need repeatable processes to manage ownership, access, knowledge transfer, operational continuity, and lifecycle changes.
To help translate these principles into practice, I've developed the Digital Workplace & AI Lifecycle Toolkit—an interactive resource covering AI agent governance, employee onboarding and off-boarding, Microsoft 365 services, supplier transitions, device lifecycle, and continuous improvement.
Digital succession should become part of existing offboarding, IAM, change management, service ownership, and supplier governance processes.
As organizations deploy more agents, they will inevitably face employee exits, supplier transitions, platform changes, and changing business requirements.
We should be thinking about these situations while designing and deploying agents, not after losing the people who understand them.
The number of agents deployed may demonstrate the pace of AI adoption.
But the ability to maintain those agents independently, securely, and consistently will demonstrate operational maturity.
An AI agent should never become an operational mystery simply because the person who built it has moved on.
Author's note: The AI Asset Passport and six digital succession controls are proposed enterprise governance practices, not official Microsoft or NIST frameworks. The SharePoint attestation example is illustrative and does not represent a specific organization.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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?
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:
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.
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.
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.
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..
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.
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.
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 in this video are AI-generated and represent a conceptual scenario, not an actual implementation or prediction.
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 visuals are AI-generated and represent a conceptual scenario, not a prediction of how enterprises will operate in 2035.
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
Two workforces, one organization: Humans and AI agents may work together with distinct roles and responsibilities.
Outcome-driven work: Organizations could increasingly organize work around outcomes rather than traditional job structures.
Digital agent identities: AI agents may require identities, access permissions, ownership, and audit histories.
Human leadership: People remain responsible for strategic direction, judgment, ethics, and accountability.
Agent-to-agent collaboration: Specialized agents could coordinate activities across business functions.
Changing workforce structures: Greater automation may reshape staffing needs and productivity expectations.
New career pathways: Structured learning, mentoring, and supervised experience may become essential for developing future leaders.
Evidence-driven performance: AI-generated insights may inform evaluations, but employees must retain transparency and opportunities to challenge decisions.
Governance and resilience: Enterprises will need clear policies, oversight, and the ability to intervene when autonomous systems fail.
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?
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.
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.
.png)
