With an environment comprising 100,000 network devices (including access points) and over 900 buildings (including data centers), which supports 350,000 users and over 1 million connected devices generating 300,000 incidents per year, traditional methods of network management can often be insufficient.  

To operate at this scale, we’re building and deploying AI solutions that help us manage our network more efficiently, respond to issues faster, and reduce manual work. This is a critical part of our role as the team that’s responsible for powering, protecting, and transforming our digital employee experience across devices, applications, and hybrid infrastructure at Microsoft.

“As the organization that acts as Customer Zero for the company, we are leading with AI to help power Microsoft and keep things like our network infrastructure secure and reliable. We must aggressively experiment and adopt AI agents to foster innovation and model the future of service engineering.”

Brian Fielder, vice president, Microsoft Digital

Within Microsoft Digital, our AIOps and Network Infrastructure Copilot (NiC) AI solutions have emerged as transformative new tools for enhancing network performance. These tools take advantage of AI-powered capabilities by turning data and knowledge into powerful insights and, eventually, meaningful actions to run the industry’s most secure and reliable enterprise network. They also share a common data architecture comprised of millions of telemetry points but perform unique AI functions in both running and supporting the network.

AIOps is an automation solution that uses data insights to prevent and resolve network issues before they become impactful. NiC is an interactive experience that helps network practitioners, and a variety of other personas more easily interact in natural language with complex network services to get rapid answers and intelligent suggestions.  

“As the organization that acts as Customer Zero for the company, we are leading with AI to help power Microsoft and keep things like our network infrastructure secure and reliable,” says Brian Fielder, vice president of Microsoft Digital. “We must aggressively experiment and adopt AI agents to foster innovation and model the future of service engineering.”

AIOps: Transforming how we deliver operational excellence 

AIOps integrates AI into our IT operations by automating and enhancing various aspects of network management. This approach significantly reduces manual intervention, allowing network engineers to focus on higher-value tasks. Key components of AIOps include: 

• Automated ticketing and remediation: AIOps automates the creation and resolution of tickets, reducing the time and effort required to manage incidents. This automation is particularly beneficial in environments with high ticket volumes, ensuring timely and efficient resolution of network issues. 
• Ticket noise reduction: AIOps uses AI-powered ticket correlation, suppression, and enrichment capabilities to significantly reduce ticketing noise, enabling engineers to concentrate on the most critical issues.  
• Automatic remediation: AIOps executes automatic troubleshooting and remediation actions on behalf of engineers to mitigate issues and keep outage duration and the associated business impact to a minimum. This is accomplished based on troubleshooting knowledge and successful remediation steps executed. 
• Postmortem report generation: AI-powered tools generate detailed postmortem reports for network incidents, providing insights into the root causes and recommended remediation steps. This capability enhances the learning process and helps prevent future occurrences. 

Network Infrastructure Copilot (NiC): The everyday AI assistant 

NiC is an AI assistant designed to support network engineers in managing complex network environments. NiC provides powerful data insights and documentation, enabling engineers to design, configure, analyze, and troubleshoot network issues using natural language queries. Key features of NiC include: 

• Data insights: NiC helps engineers extract valuable data insights from various sources, such as wikis, SharePoint libraries, troubleshooting guides, and the infrastructure data lake (IDL). This capability streamlines data analysis and enhances decision-making to take impactful actions. 
• Network artifacts interpretation: NiC understands key artifacts such as device logs and configurations, providing engineers with concise and relevant information. This capability greatly reduces the cognitive load on engineers to access and process the most critical data and insights required to manage a complex network environment. 
• Simplified network observability: NiC enables non-networking personas (such as conference room technicians and facilities managers) to get quick glances at the health and configuration of their services without requiring deep understanding of network protocols and taxonomies. 

“NiC and other AIOps agents have dramatically reduced the time engineers spend searching through documentation and other network artifacts to yield actionable insights, slashing effort from 25 minutes to under 5 minutes.”

Phil Suver, principal group product manager, Microsoft Digital

“NiC and other AI Ops agents have dramatically reduced the time engineers spend searching through documentation and other network artifacts to yield actionable insights, slashing effort from 25 minutes to under 5 minutes,” says Phil Suver, a principal group product manager in Microsoft Digital.

“By staying close to our teams’ real needs, we were able to turn AI opportunities into practical solutions, delivering near-term value while laying the groundwork for lasting innovation.”

Anand Meduri, principal PM manager, Microsoft Digital

Driving impact through AIOps and next-gen AI agents 

These AI-driven solutions have significantly improved network reliability in several ways: 

• Efficiency gains: The automation of routine tasks and the provision of actionable insights have drastically reduced the cognitive load on network engineers. In recent years, network practitioners have cumulatively saved over 20,000 hours on network infrastructure management. These efficiency gains free up engineers to focus on strategic initiatives that further enhance network performance.
• Rapid issue detection and resolution: AI-powered anomaly detection and automated remediation ensure that potential issues are identified and resolved before they impact network performance. This proactive approach minimizes downtime and enhances overall network reliability.

“By staying close to our teams’ real needs, we were able to turn AI opportunities into practical solutions, delivering near-term value while laying the groundwork for lasting innovation,” says Anand Meduri, a principal PM manager for Microsoft Digital.

Lessons learned in building and deploying AIOps agents

To deliver sustainable business value at enterprise scale, we adopted an iterative approach focused on rapid experimentation, measurable outcomes, and continuous learning. As we evolved from automation-centric operations to an agent-driven operating model, three major themes emerged:

“By embedding AIOps and AI agents into our operational fabric, we are transforming manual workflows into autonomous, scalable digital labor. This is accelerating our journey toward a human-led, Frontier Firm future.”

Suvodip Moitra, senior product manager, Microsoft Digital

• Prioritization and value realization: Not every workflow benefits equally from AI. We achieved the greatest impact by focusing on high-volume, repetitive, and time-sensitive operational activities such as incident triage, outage analysis, troubleshooting, and cross-system coordination. Prioritizing these use cases enabled us to demonstrate tangible productivity gains while building confidence in agent-led operations.
• Human-agent collaboration and change management: The transition to agentic operations required more than technology adoption—it demanded new ways of working. Success depended on positioning agents as trusted digital teammates, augmenting engineers rather than replace them. Continuous feedback loops, user engagement, and incremental rollout strategies were critical to help us drive adoption and improve agent effectiveness over time.
• Scalability, autonomous operations, and the Frontier Firm future: As our operational footprint continues to grow, we are moving from automated workflows to a scalable ecosystem of intelligent AI agents that can reason, coordinate, and act across the incident lifecycle. By embedding agents such as Smart Bonding, Outage Insights, and On-Demand Troubleshooting into daily operations, we are reducing human toil, accelerating resolution, and laying the foundation for a Frontier Firm operating model where engineers focus on strategy and innovation, while digital labor drives operational execution at scale.

“By embedding AIOps and AI agents into our operational fabric, we are transforming manual workflows into autonomous, scalable digital labor,” says Suvodip Moitra, a senior product manager in Microsoft Digital. “This is accelerating our journey toward a human-led, Frontier Firm future.”

The post Enhancing Microsoft network reliability with AIOps and Network Infrastructure Copilot appeared first on Inside Track.

To make this ideal a reality, our team in Microsoft Digital—the company’s IT organization—created an agentic AI assistant that we’re now using to connect new devices to our network. We built the agent into GetConnected, the internal portal that 18,000 of our employees, vendors, and network administrators use each month to register their new devices to our network when they turn them on for the first time.

Our new workflow is simple, fast, and intuitive—and it’s a significant step up from our previous experience.

Creating the GetConnected AI assistant is part of the role we play as the company’s Customer Zero, where we test and use our technology and platforms first and then share our lessons learned with customers. In this case, we’re sharing how we used the Microsoft Agent Framework (MAF) to enhance onsite device management for our employees. GetConnected does not apply to remote device registrations.

“We’ve been looking across our set of services and capabilities to find places where we can do some experimentation leveraging AI. We wanted to be able to test our hypothesis around those AI investments and then be able to double down if it proved correct.”

Jason Thompson, principal PM manager, Microsoft Digital

Improving a highly trafficked internal tool using AI

Our employees use GetConnected to ensure their wired and wireless devices are registered on the network, as well as to extend device expiration dates and check on the status of their devices.

Heavy employee traffic and the repetitive actions users tend to take on GetConnected led us to realize that the tool was the perfect candidate for an agentic transformation. Our goal was to turn what was a five- or six-step process into something that could be completed in just one or two actions.

“We’ve been looking across our set of services and capabilities to find places where we can do some experimentation leveraging AI,” says Jason Thompson, a principal PM manager in Microsoft Digital. “We wanted to be able to test our hypothesis around those AI investments and then be able to double down if it proved correct.”

The team decided to start small, focusing on a couple of the most popular and crucial functionalities within GetConnected.

“We’d seen previous projects that were very ambitious fail because they tried to achieve too much at one time. Based on customer feedback, we noticed that registration is the simplest, most common action that users were having trouble with. So we said, ‘Let’s do that first.’”

Aayush Dave, product manager, Microsoft Digital

It was also important to listen to our employees—our Customer Zero frontline users. They told us which actions in the experience mattered most to them.

“We’d seen previous projects that were very ambitious fail because they tried to achieve too much at one time,” says Aayush Dave, a product manager in Microsoft Digital. “Based on customer feedback, we noticed that registration is the simplest, most common action that users were having trouble with. So we said, ‘Let’s do that first.’”

Next up was deciding how the agent would appear in the portal. The Microsoft 365 Copilot model of a sidebar chat menu worked well for other workflows, so it seemed appropriate to approach the new GetConnected experience in a similar way. This enabled us to create a new experience alongside the existing workflow, so customers could still access the original process (should they need to) and compare the two experiences.

“Other teams might decide to automatically replace the UI with an agent,” says Faris Mango, a principal software engineering manager in Microsoft Digital. “But that’s hard, because now you’re forcing people to use the agent. If it’s not ready to be used at full capacity, they don’t have an alternative to accomplish what they intended. We wanted to avoid that situation.”

Testing out Microsoft Agent Framework (MAF)

To build the agent, we considered two paths.

The first was to directly call the Model Context Protocol using JavaScript, an option that would require significant amounts of coding on our part.

“Some declarative agent systems do all of the things in the background, and you don’t get to turn all the little knobs. MAF gives you the flexibility to make the experience exactly what you want.”

Darron Sullivan, principal software engineer, Microsoft Digital

The second was to use Microsoft Agent Framework (MAF), which proved to be simpler and more customizable for our needs.

“Some declarative agent systems do all of the things in the background, and you don’t get to turn all the little knobs,” says Darron Sullivan, a principal software engineer in Microsoft Digital. “MAF gives you the flexibility to make the experience exactly what you want.”

The tricky part, however, was that MAF was fairly new at the time. In fact, the week that the team started developing the GetConnected agent was the same week that MAF was released in preview internally. As we were building out our agent, the framework was going through its own updates, which threatened to hinder our progress. Even one small change to the framework could break our tool’s entire functionality.

“They were moving really fast, and we were adopting new features and finding new bugs all the time,” Sullivan says. “You had to go through that rapid iteration and development, which is a challenge, but it was also pretty awesome because we’re working on the cutting edge.”

The upside was that we were able to provide valuable feedback to the MAF engineers, which in turn could supercharge the work we were doing on our agent. As a bonus, our partnership drove other teams to pursue similar projects.

“The knowledge sharing across our org was notable and crucial,” Dave says. “Our team was one of the first to start building a solution like this, and we presented in numerous architecture forums to share the components and frameworks we were using, and the teams we were working with. This brought the tide up for all boats in our organization, encouraging other teams to start kicking off similar projects as well.”

Building a seamless, discoverable interface

The agent currently has several key functions, the most prominent of which is to register a device on your behalf.

Previously, employees would have to fill in a long, complicated form that asked for a lot of technical details that they often didn’t know offhand, like type of device or the preferred network.

Instead of just selecting options and approving, the flow is more conversational. The user can start with a suggested prompt like “Help me register a device,” and the agent will ask for the required information (with examples for each field). If the user isn’t sure about something (for example, how to find a MAC address), they can ask follow-up questions, and the agent will pull in FAQ and help content to guide them.

Once all the required details are collected, the agent can complete the registration on the user’s behalf after the user approves it.

Once it has your approval, the chatbot submits the request and replies whether or not it was successful. Users can also ask the agent to show devices that are expired or will soon expire, then prompt the agent to renew those devices if desired.

Seamlessly integrating the agent into GetConnected required upgrading the existing user interface using Fluent.

These updates were needed to support the AI interface integration. Specifically, we introduced a custom header action to launch the AI side panel. Prior to upgrading, doing this would have required using Coherence components outside of their intended patterns.

“We used Fluent AI components to build the AI interface. This helped ensure a consistent Microsoft look and feel across the experience, built-in accessibility for scenarios like screen readers and mobile usage, and components that are designed for conversational and agent-driven interactions.”

Nathan Chambers, software engineer, Microsoft Digital

To stay consistent with the existing app architecture, we upgraded core dependencies like Fluent UI and Coherence to their latest versions. As part of upgrading Coherence across several major versions, it also required us to move the feedback experience to Centro to align with the updated patterns. We then needed to update other parts of the experience like navigation, FAQ, and release notes to match those newer component patterns.

“We used Fluent AI components to build the AI interface,” says Nathan Chambers, a software engineer in Microsoft Digital. “This helped ensure a consistent Microsoft look and feel across the experience, built-in accessibility for scenarios like screen readers and mobile usage, and components that are designed for conversational and agent-driven interactions.”

While making these upgrades, we ran tests to ensure the experience was accessible—for example, for screen reader users or others who might access GetConnected on their phones.

“You can have an amazing, strong piece of software that is well built and focuses on security. But if you don’t have the traffic or people are not using it, it’s worthless.”

Faris Mango, principal software engineering manager, Microsoft Digital

Next, we wanted the agent to be as discoverable as possible. Without people actually navigating to it, there would be no way to show proof of concept. So, we built it so the agent automatically popped open via a side panel when someone loaded GetConnected.

“You can have an amazing, strong piece of software that is well built and focuses on security,” Mango says. “But if you don’t have the traffic or people are not using it, it’s worthless.”

We also wanted to gather early feedback from users. Before releasing it to the entire company, we had internal team members and frequent GetConnected users give the agent a try. Almost immediately, it was clear we had too many approval notices.

“At the beginning, we would have approvals for every single action. For example, if you wanted to see a device in different regions like Puget Sound, Latin America, or Canada, you had to do a separate approval for each region,” Dave says. “This was a very painful experience. So we removed all the approvals and pared it down to a one-click experience.”

Users also had issues with the approval language, which they said was hard to understand and looked like an error message. The next iteration took out much of the technical jargon, making the message more conversational and easier to read.

An agent experience driven by feedback

Our work as Customer Zero is never done. For GetConnected, we’re eager to keep collecting feedback. One major goal is to improve the agent’s performance, making it faster and more responsive.

Our feedback survey is tied directly to a performance dashboard, which tracks metrics like new and returning users, total unique users, conversions, and interactions. Each user submission generates a work item.

“When users leave feedback about something they don’t like, I feed that to the team, and then we sit down and figure out how we can improve that specific part of the experience,” Dave says.

With each update, we’re seeing the payoff of more users and more interactions. The traditional method of registering a device is also seeing a drop-off as more people lean on the agent for assistance.

“Before, you used to have to go into the system and change something about the experience manually. Now, our engineers are going to an AI model and telling it, ‘Hey, you’re doing this part wrong, please improve it.’”

Aayush Dave, product manager, Microsoft Digital

Looking ahead to more use cases

Building an agent has allowed the team to embrace an entirely new type of engineering.

“Before, you used to have to go into the system and change something about the experience manually,” Dave says. “Now, our engineers are going to an AI model and telling it, ‘Hey, you’re doing this part wrong, please improve it.’”

It’s also serving as a reminder to seek progress over perfection.

“AI is changing things so quickly,” Thompson says. “It’s better to do rapid prototyping and roll it out, and start getting the data in terms of how successful the experience is. Then you can let that guide you, in terms of how you iterate going forward.”

Because of the success we’ve had with the GetConnected device registration feature, we’re already exploring other capabilities, including bulk operations to accommodate our facilities managers who need to onboard many devices at once. As AI agents become mainstreamed in many workflows across our organization, we anticipate usage and functionality will continue to grow exponentially.

The post Simplifying device registration at Microsoft with an agentic AI assistant appeared first on Inside Track.

Research shows that 75% of consumers ignore calls from unknown numbers, and 92% assume unidentified calls are fraudulent. Meanwhile, phone-based fraud costs businesses more than $1 trillion a year globally, according to the 2024 Global State of Scams Report.

At Microsoft, we saw this issue directly affect our contact center, when our customers didn’t understand that our team was reaching out to address a ticket or follow up on a business need. In turn, some customers would complain that they never received a call back from our team.

“In the past, we were mitigating a lot of things, but now we have a fool-proof plan of how we’ll execute this solution and fix the issue once and for all.”

Annie Drago, senior software engineer, Commercial Engineering and AI

At first, we would contact our phone carriers in the region to ensure our calls were recognized, but this was difficult to implement across all the markets we operate in (more than 100 countries and regions total). So, our team in Commercial Engineering and AI (CEAI)—the engineering organization behind the company’s commercial business—set out to find a globally applicable solution.

Our Support Experience Group within CEAI recently launched a caller ID program in partnership with the Open Verifiable Calling (OVC) Alliance, run by the Global System for Mobile Communications Association (GSMA) Foundry. This framework assigns a verified identity to every call we initiate, no matter where the agent or customer is located—helping us to improve response rates and build trust with our clients.

“In the past, we were mitigating a lot of things,” says Annie Drago, a senior software engineer in CEAI. “But now we have a fool-proof plan of how we’ll execute this solution and fix the issue once and for all.”

Finding a global solution to a local problem

Not long ago, we moved our contact center in-house, using Microsoft Azure Communications Services (ACS). While this was happening, our team noticed that many of their calls to customers were getting marked as spam or blocked because of specific country regulations primarily due to the fact that ACS is a cloud-based solution and not on-premises.

For example, a country might automatically block or mark as spam any call from an international number. Cloud telephony can also make domestic numbers look foreign to carriers, further incentivizing them to mark the call as spam.

“Every country has their own telecom administration,” says Peter Nilsson, a principal engineering leader in CEAI focused on contact center solutions. “Many of them are tightening the noose around phone calls coming into their country.”

Our calling patterns have also changed, making verified calling that much more important.

“We’re doing a lot more outbound calls today than we were in the past,” Drago says. “For the sales line of businesses specifically, when a sales agent makes a call to a customer, it’s very important that a local caller ID is shown, so the chances of them accepting the call are higher.”

As a first step toward getting customers to understand it was Microsoft on the other end of the call, we partnered with telecom carriers in each region to verify the numbers we use there. The carrier could then ensure that the calls from these numbers are handed off to the customer without being flagged as spam or blocked.

“Our objective is to bring in a standard framework for verified calling that could be deployed internationally, instead of having piecemeal, country-by-country standards. It’s very hard to build a solution or technically design anything when you have to take every country into account individually.”

Elaine McNeill, senior tech solutions manager, CEAI

While effective enough for existing markets, this solution wasn’t sustainable, as it required around 40 different pipelines. On top of this, it couldn’t set us up for success long-term when we wanted to enter new markets.

It was at this stage, where we had set up verified calling with each individual carrier but still lacked a simplified, universal approach, that we came across the OVC Alliance.

“Our objective is to bring in a standard framework for verified calling that could be deployed internationally, instead of having piecemeal, country-by-country standards,” says Elaine McNeill, a senior tech solutions manager in CEAI. “It’s very hard to build a solution or technically design anything when you have to take every country into account individually. We’re at the forefront and will be one of the first users of the service.”

Standardizing verified calling across regions

Each call from our contact center now passes a set of credentials to prove the authentic origin of the call. These credentials stipulate that:

• Microsoft has the right to the telephone number that is being displayed.
• Microsoft Corporation is the actual legal entity responsible for the call, using a globally unique legal identifier.
• Microsoft has the right to use the brand that is being displayed.

These credentials were issued directly to us, granting us full control over how they’re communicated. They can also be used across multiple communications as a platform service (CPaaS) platforms, meaning you only need to vet a number once for it to work in multiple countries or for multiple carriers.

The signing service Provenant, our Verifiable Voice Protocol (VVP) partner on the project, controls this verification process.

“Provenant will say, ‘Okay, everything looks good. This is the right ID. This is with Microsoft. Microsoft owns the number,’” Drago says. “Then they send that information in the identity header back to us, and we send it back to the carrier.” From there, the terminating carrier delivers the call to the end party.

Avoiding dropped calls

To ensure that every Microsoft call reaches its desired customer, we had to collect a database of numbers to be validated and certified.

“If I don’t send them that information beforehand, any extra number will be rejected automatically,” Drago says. “With Provenant, we can manually certify our numbers through our own back-end sign-in.”

Another big challenge to standardizing verified calling is ensuring there’s a thorough, consistent, and region-specific vetting process. OVC’s governance model includes vetting agents that verify enterprises like Microsoft in specific regions and for specific communications channels. These agents are overseen by the governance authority, which sets the standards for credentials and can revoke them at any time if enterprises don’t meet those standards.

A future of increased trust

With OVC, we have a carrier-agnostic solution that boosts our reputation on a global scale.

“It’s a business need that we had to solve. And we’ve been able to demonstrate the technology to do that with our partner and our proof-of-concept MVP trial which was showcased at MWC 2026 in Barcelona. Now the hill to climb is to get this as a globally accepted standard.”

Peter Nilsson, principal engineering leader, CEAI

In the future, we hope to not just verify calls so that they aren’t blocked or marked as spam, but also brand them with the Microsoft logo and name. When customers can see right from the get-go that it’s Microsoft on the other end, this can further increase call acceptance rates.

“It’s a business need that we had to solve, and we’ve been able to demonstrate the technology to do that with Provenant and our proof-of-concept MVP,” Nilsson says. “Now the hill to climb is to get this to be a globally accepted standard.”

For other businesses, verified calling can deliver similar acceptance rate improvements, as well as stop impersonators and bad actors from reaching customers. That’s a big factor and a motivator to keep working on this issue.

“You have the opportunity in other sectors to really reduce fraud significantly,” McNeill says.

The post Advancing trusted calls with Open Verifiable Calling at Microsoft appeared first on Inside Track.

As AI capabilities advanced, we saw an opportunity to move beyond individual productivity gains and toward something more transformative: Empowering our developers to build intelligent agents that can automate workflows, streamline operations, and create new business value.

Realizing this vision required more than new tools. We needed to rethink how we foster development, govern innovation, and operate at scale.

“We’ve made a lot of progress enabling our developers to build agents that make us more productive. We’re Customer Zero at Microsoft, which means we’re the first to deploy and use the technology and services that we later sell to our customers. Those learnings give us a unique perspective and story to share about the journey our developers have been on with AI and agents.”

Brian Fielder, vice president, Microsoft Digital

Today, we’re sharing the foundation we built that supports this shift.

We’re driving employees across Microsoft to create and use AI agents—from simple, task-focused solutions to enterprise-grade applications available across the company. It’s all supported by a secure, governed, and extensible platform.

“We’ve made a lot of progress enabling our developers to build agents that make us more productive,” says Brian Fielder, vice president of Microsoft Digital, the company’s IT organization. “We’re Customer Zero at Microsoft, which means we’re the first to deploy and use the technology and services that we later sell to our customers. Those learnings give us a unique perspective and story to share about the journey our developers have been on with AI and agents.”

Within the context of Microsoft Build 2026, we’re sharing what it really takes to move from experimentation to impact. Through this collection of stories and resources, we highlight how we’re empowering our developers to build with agentic AI—from establishing governance and platform capabilities to driving adoption and delivering real-world outcomes. Our goal is to provide practical insights you can use to accelerate your own AI journey.

“We hope you find the journey we’ve been on practical and useful,” Fielder says. “When it comes to agents, we’re accelerating fast and scaling at an enterprise level. As our story continues to evolve, we look forward to sharing it with you.”

Guidance for developers: How we manage agentic AI at Microsoft

These articles outline our vision for agentic AI, showing how we’re building a secure, governed, and extensible foundation for AI agents—from Work IQ and Copilot Studio to Agent 365, Azure DevOps, and Model Context Protocol—so developers can create scalable, high-value solutions across the enterprise.

April 16, 2026

Alex Fleck

Becoming a Frontier Firm: A guide for deploying AI agents based on our experience at Microsoft

May 21, 2026

Alex Fleck

Governing AI agents at scale: Lessons from our journey at Microsoft

• How Work IQ is supercharging our AI usage at Microsoft
• Shaping AI management at Microsoft with Agent 365 and Copilot controls
• Deploying Microsoft Agent 365: How we’re extending our infrastructure to manage agents at Microsoft
• Unlocking enterprise AI extensibility at Microsoft with Microsoft Copilot Studio
• Powering AI value with Microsoft 365 Copilot extensibility at Microsoft
• How our employees are extending enterprise AI with custom retrieval agents
• Transforming our approach to sensitivity labels at Microsoft with Microsoft Entra
• Reclaiming engineering time with AI in Azure DevOps at Microsoft
• Protecting AI conversations at Microsoft with Model Context Protocol security and governance
• Intelligence on tap: How Work IQ enables AI and agents at Microsoft
• Taming our Python dependencies at Microsoft with AI
• AI for Knowledge Management: Keeping support content up-to-date at Microsoft

UPCOMING POSTS

• Our guide for deploying Agent 365 based on our experience at Microsoft

Our IT guide to becoming a Frontier Firm

These stories share our IT playbook for becoming a Frontier Firm, highlighting a practical path to enterprise AI maturity through agentic transformation, operational scale, responsible innovation, and partnership—showing how IT leaders can balance governance, modernization, and employee engagement while building an AI-first organization.

December 4, 2025

Keith Boyd

Becoming a Frontier Firm: Our IT playbook for the AI era

• Enterprise AI maturity in five steps: Our guide for IT leaders
• The agentic future: How we’re becoming an AI-first Frontier Firm at Microsoft
• AI at scale: How we’re transforming our enterprise IT operations at Microsoft
• Transforming into an AI-first Frontier Firm in partnership with our works councils
• Fast Train to the AI Frontier: Balancing risk and innovation in the era of AI at Microsoft

Working as developer in IT at Microsoft in the era of AI

These stories explore what it means to work in Microsoft Digital during the AI era, showing how developers and knowledge workers are reshaping engineering, the employee experience, and their own career growth through AI-powered tools, new ways of working, and personal journeys that reflect the evolving culture of IT at Microsoft.

May 21, 2026

Matthew Cooke

IT on the cutting edge: Working in Microsoft Digital in the era of AI

• Powering the new age of AI-led engineering in IT at Microsoft
• The Frontier Firm: How knowledge workers are forging their own AI tools at Microsoft
• The future of work is here: Transforming our employee experience with AI
• Olutunde Makinde: From Lagos to Redmond, a Microsoft IT engineer’s journey
• Building from the inside: Anahit Hovhannisyan’s impact on IT at Microsoft

Key takeaways

From our journey enabling agentic AI across Microsoft Digital, several key principles have emerged to help organizations move from experimentation to scalable, enterprise-wide impact.

• Treat your organization as Customer Zero. Use your own AI capabilities first to generate real-world insights, validate scenarios, and build credibility before scaling to customers.
• Build a foundation for scale. Establish a secure, governed, and extensible platform that enables developers to create AI agents—from simple solutions to enterprise-grade applications.
• Empower developers to drive transformation. Move beyond productivity gains by enabling developers to build intelligent agents that automate workflows and unlock new business value.
• Align governance with innovation. Rethink how you enable development, govern AI, and operate at scale to balance flexibility with responsible use.
• Connect tools, platforms, and workflows. Integrate AI capabilities across your ecosystem—linking platforms, governance models, and development tools to support consistent, scalable adoption.
• Translate experimentation into impact. Focus on turning early AI exploration into coordinated, enterprise-wide efforts that deliver measurable outcomes.

Try it out

Learn more about Microsoft Build.

Related links

• Read our guide for deploying AI agents based on our experience at Microsoft.
• Learn about how we’re governing AI agents at scale internally.
• Find out how Work IQ is supercharging our AI usage at Microsoft.
• Check out an IT playbook for the AI era and see how we’re becoming a Frontier Firm.

The post Microsoft Build 2026: Empowering our developers to adopt agentic AI at Microsoft appeared first on Inside Track.

For years, our security groups operated without consistent, policy‑based guardrails. As a result, we couldn’t uniformly control guest access to sensitive resources or apply governance consistently across different group types.

Addressing this required a complex, coordinated effort by our team here in Microsoft Digital, the company’s IT organization, and the Microsoft Entra product team.

“Because IT security is our highest priority at Microsoft, we knew we needed a better approach to limiting access to groups within our tenant. And we realized that Microsoft Entra was a powerful in-house solution that represented our best path forward to solve for this challenge.”

David Johnson, principal product manager architect, Microsoft Digital

The result is a new approach to sensitivity labels across the organization that strengthens our security posture, which benefits Microsoft and our customers.

“Because IT security is our highest priority at Microsoft, we knew we needed a better approach to limiting access to groups within our tenant,” says David Johnson, a principal product manager architect in Microsoft Digital. “And we realized that Microsoft Entra was a powerful in-house solution that represented our best path forward to solve for this challenge.”

Go deeper

Learn how to assign sensitivity labels to Microsoft Entra security groups.

Closing the security gap

Sensitivity labels for Microsoft 365 groups are labels that govern join and access restrictions for membership and sharing. They have been a product feature since 2020. But sensitivity labels for security groups—labels that enforce rules about who can join a group—had no equivalent.

This meant that organizations that wanted to govern who could join a security group or determine if guests are permitted and how group membership is managed had to either lock down the group creation process entirely, or rely on reactive scanning after the fact.

“Security groups are a key piece of our efforts to secure sensitive resources,” says Mohit Bhargava, a principal product manager on the Microsoft Entra team, which manages the Entra family of identity and network access products. “We wanted to apply policies to protect who could be in security groups so that the sensitive resources in those groups would remain secure.”

“Whoever gets into an Azure security group can have access to all the resources associated with the Azure subscription. That’s a potential high-severity threat.”

Basanth Kakumani, software engineer II, Microsoft Digital

The security risk is real. If an unauthorized guest account ends up as a member of a security group that governs access to an Azure subscription, that guest gains access to every resource inside that subscription.

“Whoever gets into an Azure security group can have access to all the resources associated with the Azure subscription,” says Basanth Kakumani, a software engineer II in Microsoft Digital. “That’s a potential high-severity threat.”

Another priority was the need for consistency across experiences.

“Microsoft 365 groups have supported labeling for a very long time,” Bhargava says. “Customers have an expectation that there’s parity across group types, so that they can govern them uniformly. That was another driving factor for this work.”

Security groups reuse the same sensitivity labels already configured for Microsoft 365 groups and SharePoint sites in Microsoft Purview—so admins don’t need to create or manage a separate set of labels. This reuse reduces configuration overhead and supports a more consistent governance model across group types.

Security workarounds, and why they fell short

Without sensitivity label support, we had to make do with alternative solutions. The most common one was simply preventing certain users from creating any security groups at all.

In the Microsoft tenant, this meant that employees who needed a security group had to fill out a form that had custom business logic behind it.

“We had on-premises, Active Directory, synchronization, tooling, and customization,” Johnson says. “This caused latency, from the time you created your group to the time it would show cloud membership. If you wanted to manage your membership, you had to do it on premises, AD, and then wait for it to sync to Entra.”

Neither centralized control nor reactive governance was a satisfying solution to prevent policy violations.

“This is really about making reactive things more proactive. We want to catch problems before they occur.”

John Begley, principal software engineer, Microsoft Digital

Typically, IT is going to manage this in one of two ways: Either we turn off self-service and manage everything on behalf of users, or we do reactive governance, which includes scanning groups and looking for policy violations.

Those aren’t super effective at preempting violations.

“This is really about making reactive things more proactive,” says John Begley, a principal software engineer in Microsoft Digital. “We want to catch problems before they occur.”

A collaborative solution

Coming up with a solution to this challenge required a genuine partnership.

We at Microsoft Digital approached the Entra product team and explained the problem we were trying to solve. Rather than simply handling this as a feature request, the two teams agreed to a co-development arrangement.

“Having access to a very large customer who cares deeply about security was extremely helpful. If it works for Microsoft, which is so complicated and huge, it’s going to work for smaller-sized tenants too.”

Mohit Bhargava, principal product manager, Microsoft Entra

Microsoft Digital team members would work alongside Entra engineers as the feature was built, serving simultaneously as implementation partner, design critic, and test environment—what we like to call our Customer Zero role.

Bhargava found the partnership equally illuminating from the product side.

“Having access to a very large customer who cares deeply about security was extremely helpful,” he says. “If it works for Microsoft, which is so complicated and huge, it’s going to work for smaller-sized tenants too.”

For Begley and his team, working closely with the product team revealed how complex the solution actually was.

“Both the product team and Microsoft Digital walked into this thinking a fix was going to be simpler than what it turned out to be,” Begley says. “It’s been eye-opening to see how the product is built, how it runs, what all the moving parts are. We learned early on that there was significant co‑development happening within Entra itself, across teams with very different areas of expertise.”

That dynamic played out in specific feature decisions. The team’s original plan did not include support for agent access controls and didn’t include the ability to prevent AI agents from joining sensitive security groups. This is something the product group quickly addressed and resolved after our team in Microsoft Digital raised it as a concern.

“One of the first customers who raised it was Microsoft Digital,” Bhargava says. “They said we needed need to start thinking about it ahead of time to get ahead of the problem.”

Sensitivity labels for Microsoft Entra cloud security groups are now in public preview. The same labels you publish in Microsoft Purview for Microsoft 365 groups and sites now apply to Entra security groups. Visit Microsoft Learn for scope, supported scenarios, and current preview behaviors.

Changes afoot for IT admins and employees

The practical impact of this solution lands on both sides of the relationship between Microsoft Digital and the company’s employees.

“Now I can’t accidentally have guests in an internal-only group, which changes the dynamic. Employees can create their own Entra security groups now, without us having to worry that they’ll be inviting guests where they shouldn’t be.”

David Johnson, principal product manager architect, Microsoft Digital

For IT admins, the shift is from reactive remediation to proactive prevention. For employees, it means self-service action with security groups become viable again, without the security risks that made organizations reluctant to enable it before.

“Now I can’t accidentally have guests in an internal-only group, which changes the dynamic,” Johnson says. “Employees can create their own Entra security groups now, without us having to worry that they’ll be inviting guests where they shouldn’t be.”

Johnson underscores the broader ambition behind the shift, which is to allow employees to create and manage groups directly in Entra.

“A company that can unblock self-service action by its employees with confidence, knowing that there’s an additional level of protection—that’s very important,” he says.

Looking ahead: AI and the expanding policy surface

Labeling support for security groups is already being extended across the organization, with AI governance in mind.

Adding the ability to block agents from joining sensitive security groups is our next logical step. Guest membership is enforced via allow-to-add guest policy, but agents won’t join in the same way. Rather, we will set policies in Purview and then use labels to control if an agent can join a group.

The longer-term vision involves extending oversharing prevention beyond Entra itself. This will make it impossible (not just detectable) to accidentally assign a highly confidential resource to an unlabeled or inappropriately scoped security group. The foundation we’ve built with labeling in Entra is what makes this vital step possible.

“We want to get into the preventative aspect,” Johnson says. “The goal is to make it so it’s not possible to overshare in the first place.”

Key takeaways

Here are some tips as you consider ways to address how you manage your own security labeling practices:  

• Reuse existing labels—no extra setup required. Security groups reuse the same sensitivity labels already configured for Microsoft 365 Groups and SharePoint sites in Microsoft Purview, eliminating duplicate configuration and helping admins apply a consistent governance model across group types.
• Understand label immutability at launch. Unlike Microsoft 365 Groups, sensitivity labels on security groups are initially immutable—a deliberate design choice to ensure protections are enforced from the moment a group is created. Controlled label mutability will be introduced in a subsequent update.
• Know what’s in scope today. Labeling currently applies to static, non–mail-enabled security groups. Dynamic membership groups, mail-enabled security groups, and distribution lists aren’t supported at launch, so admins should plan accordingly.
• Shift from reactive cleanup to proactive protection. Label-driven membership controls prevent policy violations—such as unintended guest access—before they occur, reducing the need for post-creation audits and remediation.
• Enable safe self-service with guardrails. With labels enforcing access rules automatically, employees can create and manage security groups without increasing risk, restoring self-service without sacrificing control.
• Lay the foundation for future governance scenarios. Using sensitivity labels as the backbone of access policy creates a scalable framework that can extend to additional protections over time, including broader enforcement and emerging governance needs.

Try it out

Learn more about configuring security with Microsoft Entra.

Related links

• Learn how we’re using sensitivity labels to make Microsoft more secure.
• Get an overview of Microsoft Entra fundamentals documentation.
• Find out how self-service sensitivity labels to help our employees stay productive without exposing sensitive information.
• See what it took to transition our company to a Zero Trust security model.
• Explore how we’re boosting our Secure Future Initiative with a new approach to wired network security.

The post Transforming our approach to sensitivity labels at Microsoft with Microsoft Entra appeared first on Inside Track.

At Microsoft Digital, the company’s IT organization, we’re using a set of employee councils to guide how we deploy and adopt AI across our organization. We took this approach for a simple reason: We need a model that can keep pace with technological change while staying grounded in business value.

Our baseline expectation for AI at Microsoft is practical.

Our AI initiatives need to deliver value every quarter, and we track progress through KPIs reviewed monthly at the leadership level. That standard creates healthy pressure. It also exposes a common gap many organizations experience in the beginning stages of their AI efforts: It’s easy to generate a lot of activity without producing business results.

“Our strategy council is how we separate signal from noise in our AI acceleration. It identifies the top scenarios with the greatest enterprise leverage, sharpens our executive focus on what truly matters, and enforces a one-to-one alignment between the work we resource and the outcomes we’re accountable to deliver.”

Don Campbell, principal group technical program manager, Microsoft Digital

In our council-based approach to AI, different councils focus on different needs. Together, they help us move from experimentation to repeatable, enterprise-grade outcomes. We think of these councils as building blocks that we can combine and evolve as the technology, the business, and our operating model change.

In this model, AI strategy needs its own council to help guide the overall approach and align our efforts across the enterprise. At the highest level, the strategy council is where we prioritize what matters most, decide how it maps to the outcomes we’re accountable for, and determine how we’ll judge progress month over month.

“Our strategy council is how we separate signal from noise in our AI acceleration,” says Don Campbell, a principal group technical program manager in Microsoft Digital. “It identifies the top scenarios with the greatest enterprise leverage, sharpens our executive focus on what truly matters, and enforces a one-to-one alignment between the work we resource and the outcomes we’re accountable to deliver.”

Strategy keeps our AI conversation at Microsoft from getting bogged down in discussions of tools and technology and forces us to keep our focus on the main goal: What are we trying to change in the business, and how will we know if we’ve succeeded?

“We need a single cohesive story to bring together what’s happening across the organization and how those efforts contribute to real impact. The goal is to stitch that story together and solve for redundancies—if one part of the org has already solved a problem, another team shouldn’t have to reinvent the solution.”

Mohit Chand, principal group engineering manager, Microsoft Digital

AI strategy in action: Focus, alignment, and a monthly cadence

As our AI work at Microsoft accelerates, we continuously balance two truths at the same time. We want broad experimentation, because it’s how teams and employees learn fast. At the same time, we want our people to focus on what matters most to our enterprise and to ensure we are identifying and reducing potential redundancy.

Maintaining this balance is the core work of our AI strategy council. It helps us identify the AI-enabled scenarios that will deliver the most value, then keeps us honest about whether we’re delivering against the outcomes we’ve committed to.

“We need a single cohesive story to bring together what’s happening across the organization and how those efforts contribute to real impact,” says Mohit Chand, a principal group engineering manager in Microsoft Digital. “The goal is to stitch that story together and solve for redundancies—if one part of the org has already solved a problem, another team shouldn’t have to reinvent the solution.”

We have a detailed process that relies on engaging with our subject matter experts to keep the most impactful AI portfolio visible and actionable. We use it to summarize and track our top scenarios. Our AI strategy council views this process as work that’s always in process—a living view that changes as products ship and priorities shift. Delivered items come off, emerging bets go on, and the continuing discussion stays anchored to our goals.

“The pace right now is incredible. There’s a lot of excitement, but there’s also a risk if it’s not sustainable. A big part of our focus is figuring out how to take churn out of the system and make this work long‑term—for the business and for our people.”

Myron Wan, principal group product manager, Microsoft Digital

A tight rhythm and monthly cadence ensures that our conversations stay focused on whether the biggest bets are moving the needles we care about. That cadence helps us answer the questions leaders and customers are asking on a regular basis:

• Where are you investing?
• Why?
• What’s working?
• What would you do differently next time?
• What did you learn along the way?
• Where are we reinvesting and creating additional agency or capabilities for our employees?

When these questions frame the conversation, the outcomes naturally align to the direction our enterprise wants to go.

Structuring strategy and execution

To make our strategy council effective, we needed more than just a monthly meeting. We needed a way to organize work, assign accountability, and compare progress across very different teams without forcing everyone into the same mold.

We use three practices to accomplish this:

• Group work into clear focus areas
• Rely on product owners to drive execution
• Use a shared approach for measuring value

“The pace right now is incredible,” says Myron Wan, a principal group product manager in Microsoft Digital. “There’s a lot of excitement, but there’s also a risk if it’s not sustainable. A big part of our focus is figuring out how to take churn out of the system and make this work long‑term—for the business and for our people.”

Working into focus areas

When we started to scale our initial AI efforts, our first challenge was simple: Everyone is building, but not always toward the same destination. That’s why we split the work into two primary focus areas that match how an IT organization operates. These areas include:

• AI for corporate functions. Our AI work supports teams like finance, legal, and HR. We focus on removing friction from core processes and helping people make faster, better decisions.
• AI for IT. We support AI initiatives across our IT operations in several areas:
  • Network and devices. We’re using AI for faster network device lifecycle management, more efficient incident management and remediations, and lower costs
  • Employee experience. We want to enable Microsoft employees to contribute real business value and enjoy how they do it.
  • Support. We’re reducing tickets, resolving issues faster, and helping support teams stay ahead instead of reacting.
  • Tenant management and security. Our AI investments strengthen how we run and protect our Microsoft 365 tenant.

From there, we map AI initiatives into those focus areas so we can see what’s happening across the landscape and spot gaps, overlaps, and opportunities to reuse what already exists.

“We operate a council which helps set direction, but product management oversees execution of the solutions. Without product management’s ownership, our council would degrade into just a low-level approval step, which quickly makes us a roadblock instead of an enabler.”

Bill O’Brien, principal group product manager, Microsoft Digital

This step sounds basic, but it changes the conversation. It moves us away from a list of disconnected projects and toward a portfolio view, where we can figure out which scenarios matter most, where we have duplication, and where we need to invest more.

Keeping execution with product owners

While our AI strategy council sets direction, execution lies strictly with our product owners. A strategy council can’t run delivery. If it tries, it slows everything down. We avoid that trap by separating direction from doing.

“We operate a council which helps set direction, but product management oversees execution of the solutions,” says Bill O’Brien, a principal group product manager in Microsoft Digital. “Without product management’s ownership, our council would degrade into just an approval step, which quickly makes us a roadblock instead of an enabler.”

This clarity on roles and responsibilities helps teams work fast and ensures the council remains strategic. Product owners can prioritize week by week, learning from usage, adjusting product features, and shipping value. The council can stay focused on the portfolio and which bets rise to the top, what tradeoffs to make, and how we communicate progress and business outcomes to leadership.

“The first part of our strategy was all about getting people to a point where they could identify what they were trying to accomplish and report on how they’re getting there. We created a value measurement framework in partnership across multiple key players to give teams an idea of what’s valuable to the organization.”

Keith Bunge, principal software engineer, Microsoft

Using a common value framework

Once we can see the portfolio and have identified clear ownership, we still need one more thing: A shared language for determining value. Early in our journey, we were tempted to declare success simply based on activity—how many pilots we launched, how many tools we built, or how many demos we could show.

That activity is critical for innovation, but it doesn’t help us understand and drive business value. We needed teams to define the value they expect to deliver, explain why, and show how they’ll measure it.

“The first part of our strategy was all about getting people to a point where they could identify what they were trying to accomplish and report on how they’re getting there,” says Keith Bunge, a principal software engineer at Microsoft. “We created a value measurement framework in partnership across multiple key players to give teams an idea of what’s valuable to the organization.”

That framework helps in two ways:

1. It forces upfront discipline: Teams clarify what value they’re chasing and how they’ll prove they’ve achieved it.
2. It allows for fair comparison across very different initiatives: Everyone is describing impact in consistent categories, rather than inventing a new scorecard each time.

As our approach matures, we’re also pushing past raw savings metrics to the harder question: What did we do with the time or money we saved, and how did this create increased agency or capabilities?

Combining strategy and execution: A practical example

Here’s how that looks when we apply this approach to a real-world scenario.

Say one of our teams is proposing an AI solution to automate energy management in buildings. On day one, the idea sounds great: use signals from internal temperature and movement sensors to automatically adjust HVAC usage across large buildings. But the role of the strategy council isn’t just to approve great ideas. We ask for a clear value claim and a measurement plan.

Bunge provides a solid value claim for the example above.

“I’m going to come up with an automation that allows me to automatically turn off air conditioning in a building based on signals that we have from our internal sensors,” he says. “I think I’m going to be able to save $100,000 a quarter with this project because of my usage projections overlaid on the HVAC costs over the past five years.”

That kind of statement is useful, because it’s specific. It also forces the next question: How do you prove it? We’re asking teams to explain what data they’ll use as a baseline, what counts as savings, and how they’ll report progress over time.

We’re also raising the bar as the program matures.

Early on, teams may be able to prove that they saved time or reduced effort. As we get more rigorous, we’re pushing the “so what” conversation: What happens with the time saved, and what changes in the business as a result? It’s all part of moving from value measures to business outcomes, including what gets reinvested and where impact actually accrues.

Connecting AI strategy to the rest of our councils

Our AI strategy council is not the final measure or a standalone solution. We use it as the front door to a broader ecosystem that helps us move AI from ideas to enterprise outcomes.

“Business strategy needs to lead the AI strategy. Business strategy defines the ‘what and why.’ AI defines the ‘how’ to get the business strategy implemented with real value. We need to use AI to help us achieve the business strategy, not the other way around.”

Qingsu Wu, principal group product manager, Microsoft Digital

Here’s how it fits together in practice. We use the strategy council to set our direction, and we keep a short list of top scenarios visible. Then we rely on complementary councils and capability groups to make those scenarios real: teams are building skills and patterns through enablement, strengthening foundations through data readiness, and applying Responsible AI practices so solutions scale safely.

We use process improvement and change management to drive adoption, because a strong model doesn’t matter if people don’t change how they work. And we use metrics and value tracking to keep the entire system accountable.

We’re also keeping a clear principle at the center: Business strategy leads, AI follows.

“Business strategy needs to lead the AI strategy,” says Qingsu Wu, a principal group product manager in Microsoft Digital. “Business strategy defines the “what and why.” AI defines the ‘how” to get the business strategy implemented with real value. We need to use AI to help us achieve the business strategy, not the other way around.”

That distinction matters as AI capabilities keep expanding and as teams continue to move faster.

Moving forward

As this work matures, one thing is clear: Strategy isn’t something we finish and move on from. It’s something we’re actively maintaining as AI adoption accelerates.

What we’ll do next is consistent with that mindset.

We plan to keep scaling what works while tightening and improving the system around it. We’re strengthening alignment across teams, pushing for more consistent measurement of impact, and sharpening how we choose the right approach for the right problem. We’re also treating strategy as a living motion, not an annual document, because business and technology are constantly changing.

We know that what got us here isn’t going to get us where we need to go next. We’re excited about the continued evolution of AI strategy here at Microsoft Digital as we focus on scale, alignment to real business problems, and making sure the pace is sustainable for our business.

Key takeaways

Leaders who are scaling AI across IT can apply these lessons from our experience to stay focused, move faster, and deliver measurable business impact.

• Treat strategy as an ongoing practice. We’re revisiting priorities regularly to keep our AI work aligned with changing business goals.
• Separate direction from execution. We’re using a small strategy group to set focus and expectations while product teams remain accountable for delivery.
• Create a shared language for value. A consistent way to describe impact helps leaders compare initiatives, make tradeoffs, and explain progress with confidence.
• Let experimentation mature into focus. Early exploration builds capability, but scaling requires narrowing attention to the AI scenarios that matter most.
• Design for scale and sustainability. We’re paying as much attention to reuse, data readiness, and team sustainability as we are to speed and innovation.

Try it out

New to Microsoft 365 Copilot? Check it out!

Related links

• Check out how our data council is powering our unified data strategy at Microsoft.
• Learn how we’re powering the technical veracity of AI at Microsoft with a Center of Excellence.
• Find out how we’re reshaping Microsoft with continuous improvement and AI.
• Learn more about our approach to Responsible AI at Microsoft.
• Read about the enterprise tools and solutions at Microsoft AI.
• Learn how Azure AI apps and agents can help you build enterprise-scale AI solutions.

The post Visualizing success: Steering your AI deployment with a strategy council appeared first on Inside Track.

Now, a team in Microsoft Digital—the company’s IT organization—is working to shrink that lengthy nine-month timeline to a single day.

The problem is architectural.

As our cloud footprint has grown, it has evolved into something richly segmented, tightly secured, and increasingly automated—a far cry from the relatively flat, monolithic corporate network that we originally extended into the cloud.

Getting those two worlds—on-premises and the cloud—to talk to each other securely and efficiently has become one of our most stubborn infrastructure challenges.

The solution we’re building is a fundamentally new operating model for hybrid cloud integration. It’s powered by AI-driven intake, end-to-end automation, and a set of repeatable patterns that treat the cloud as the new core of the network, rather than a distant branch of the old one.

The gap between cloud speed and network complexity

To understand the problem our team in Microsoft Digital set out to solve, it helps to understand how our company’s network architecture evolved over the past decade. When Microsoft first embraced Azure, the cloud was conceived as an extension of the existing corporate network.

“We have a development assembly line, and our goal is to give engineers the most efficient, frictionless experience doing software development for the company. Every day we delay solving this issue systemically is another day for the problem to get bigger.”

Tom McCleery, principal group cloud network engineering manager, Microsoft Digital

But the cloud grew faster than anyone anticipated.

Product engineering teams, drawn by the speed and flexibility of cloud-native tooling, began self-organizing their systems in Azure. They built segmented, purpose-built environments optimized for security and automation that looked nothing like the sprawling on-premises network they were supposed to connect to.

This shift had real consequences for Microsoft developers.

A software engineer sitting in building 32 on campus, for example, might have her Azure environment provisioned in half a day. But if she needed network connectivity to a physical Azure Stack lab down the hallway, getting that connection established—through firewalls, virtual routing frameworks, access control lists, and cross-team coordination—could take weeks or months.

“We have a development assembly line, and our goal is to give engineers the most efficient, frictionless experience doing software development for the company,” says Tom McCleery, principal group cloud network engineering manager in Microsoft Digital. “Every day we delay on solving this issue systemically is another day for the problem to get bigger.”

Why on-premises networks aren’t going away

Why not simply move everything to the cloud?

For Microsoft, the answer comes in many forms. As a company we build physical hardware, requiring hundreds of on-premises labs for software and hardware testing. We operate conference rooms, badge readers, thermostats, and wireless access points that will always require a physical network presence.

More fundamentally, Microsoft as a company hosts the cloud itself. If Azure were ever to go offline, our engineers responsible for recovery would need robust on-premises access that doesn’t rely on the very infrastructure they’re trying to restore.

Compounding all of these challenges are security requirements introduced by our Secure Future Initiative (SFI). The drive to reduce lateral threat movement across our network—limiting how far an attacker could reach if they compromised a single identity or device—has pushed our teams toward increasingly segmented environments. For our developers, that segmentation has meant navigating multiple networks, maintaining multiple identities, and juggling Yubikeys, smart cards, and authenticator apps just to move from one system to another.

The challenge, in short, is not that our network has too many pieces to be easily connected, it’s that those pieces weren’t designed to talk to each other efficiently.

This is what we had to fix.

Automation, patterns, and the path to ‘A Customer a Day’

Raghavendran Venkatraman is the principal engineering manager in Microsoft Digital who first pitched the vision of delivering a hybrid infrastructure in a single day.

“If we are not fast enough, our customers are going to outpace us and do it themselves—and they may not be adhering to all our enterprise security standards. The faster we deliver reliable infrastructure, the higher their confidence in us.”

Raghavendran Venkatraman, principal engineering manager, Microsoft Digital

The concept, which the team calls “A Customer a Day,” is built around the idea that it’s possible to deliver hybrid connectivity within 24 hours of finalizing requirements. Gathering, validating, and completing those requirements is where the team had to put their focus.

“If we are not fast enough, our customers are going to outpace us and do it themselves—and they may not be adhering to all our enterprise security standards,” Venkatraman says. “The faster we deliver reliable infrastructure, the higher their confidence in us.”

Three sequential domains of opportunity were identified, each a distinct bottleneck in the process. They all boasted impressive potential for improvement:

AI-driven unified intake

Customer describes requirements once. AI interprets and routes to the right pattern—no human coordination needed.

Replaces: Weeks of cross-team meetings before any build begins.

Predefined network patterns

A catalog of validated blueprints matches each request to a proven solution—no custom work from scratch.

Replaces: One-off negotiations restarted for every customer engagement.

End-to-end automation

A single workflow deploys from Azure all the way to the on-premises endpoint—no manual handoffs between teams.

Replaces: Days or weeks of manual steps after the cloud build is finished.

The result of these three innovations was the ability to make hybrid infrastructure live in one day, not months.

AI-driven unified intake. Today, when an engineering team needs hybrid connectivity, they become the conduit between multiple groups—networking teams, architecture teams, program managers, and security reviewers—that each have their own requirements, timelines, and vocabularies. The intake process alone can consume weeks of meetings before any actual implementation begins. The new model replaces that with an AI-powered interface that captures requirements directly from the customer, interprets them, and routes them to a predefined deployment pattern.

Predefined network patterns. Most hybrid workloads map to a small set of repeatable architectures. Rather than treating each onboarding as a custom engagement, the team has catalogued the most common hybrid connectivity scenarios and translated them into repeatable, validated patterns. The patterns drive both the AI intake and the automation layer, creating a system where the right solution can be identified and deployed without starting from scratch each time.

“The long pole in the tent used to be just getting the infrastructure up and running, but we are now able to do that pretty fast,” McCleery says. “Now, the challenge is sitting down with our customers, figuring out their requirements, and interpreting those into tasks that we can go implement in a matter of hours.”

End-to-end automation. On-premises, transport, and cloud network automation operate separately, but one-day delivery requires unified, pattern-aware orchestration. An AI orchestration agent manages sequencing, dependencies, and exceptions, enabling the hybrid stack to deploy as a single pipeline instead of in fragmented steps.

“The key architectural insight we reached is that any code touching device configuration should come from the service lines that own those devices. That’s a DevOps boundary—you own the customer experience, you specify the requirements, and then you call upon what we’ve built to interact with the back end. That’s a fundamentally different way of thinking about hybrid automation, and it’s what makes the end-to-end build possible.”

Juan Jimenez, principal cloud network engineer, Microsoft Digital

This is the work that Juan Jimenez, a principal cloud network engineer on the team, has been driving with multiple engineering cohorts.

“The key architectural insight we reached is that any code touching device configuration should come from the service lines that own those devices,” Jimenez says. “That’s a DevOps boundary—you own the customer experience, you specify the requirements, and then you call upon what we’ve built to interact with the backend. That’s a fundamentally different way of thinking about hybrid automation, and it’s what makes the end-to-end build possible.”

Building consensus across the network stack

Perhaps the hardest part of getting to “A Customer a Day” has been organizational. Bringing together cloud networking teams, on-premises network engineers, identity teams, security stakeholders, and program managers around a common framework requires a level of cross-disciplinary alignment that is extremely difficult.

What has helped is having a clear, human-scale goal that everyone can immediately understand and rally behind. When Venkatraman first named the initiative “A Customer a Day,” something shifted.

“You go over to the identity folks and say we’re trying to get a customer onboarded in a day—they’re like, ‘That would be great!’” McCleery says. “Same thing with on-premises networking. That message is easier to land than going in and saying, ‘Your engineers need to learn more about cloud.’ That’s when people start taking mental health days.”

One of the deeper mindset shifts the team has also been working to drive is a redefinition of what connectivity means. Historically, connectivity meant simply the network. In a cloud-first, AI-accelerated world, that definition is no longer sufficient.

“Connectivity means network and identity—together,” Venkatraman says. “That is the new definition, but it is not prevalent everywhere yet. Any CIO or CTO should pivot their entire organization to think about it that way. Don’t have two separate teams making decisions in silos and then trying to integrate. Get them in the room together from the start.”

Where we are today, and what comes next

Our Microsoft Digital team is candid about where we are in the journey: We’ve made meaningful progress, but we’re not yet at the finish line. The near-term goal is to complete the first customer launch scenarios within the next quarter, followed by broader adoption of the pattern framework in the quarter after that.

The goal isn’t 100% automation. The team is clear that a portion of hybrid networking will always require the custom work that complex or security-sensitive scenarios demand.

“We’re always going to have a longtail of scenarios that need human judgment,” McCleery says. “But for the 80% of common scenarios, if a customer is going down the compliant, paved path, things should happen a lot faster.”

For a team that’s spent years watching the gap between cloud and on-premises connectivity grow wider, the prospect of closing it—one customer, one day at a time—feels less like a moonshot and more like a welcome, needed correction.

Key takeaways

If your organization is wrestling with hybrid cloud integration, here are concrete steps you can act on today, informed by what we’ve learned on our journey:

• Audit your hybrid integration timeline. If connecting a new cloud environment to on-premises networks takes more than a few weeks, map where the delays actually live—requirements gathering, cross-team handoffs, on-premises automation gaps, or other issue. You can’t fix what you haven’t measured.
• Redefine connectivity to include identity. Bring your network and identity teams into the same room before any hybrid integration project begins. Treating these as separate workstreams is a primary source of rework, security gaps, and delay.
• Identify your most common connectivity scenarios and document them as repeatable patterns. Even before you build automation, codifying your top five to ten hybrid connectivity use cases into standard blueprints gives every team a shared vocabulary and an accelerated starting point.
• Set a single, human-scale goal your teams can align on. A unifying outcome (like “integrate a new environment in one day”) is more effective at driving cross-team alignment than a technical mandate. Find the shared aspiration before prescribing the solution.
• Extend cloud tooling and automation frameworks to your on-premises teams. Don’t wait for on-premises engineers to independently upskill on cloud-native tooling. Invest in democratizing that capability deliberately, or the automation gap between your two environments will continue to widen.
• Design intake around your systems, not your customers. Any hybrid integration process that requires an internal team to act as coordinator between multiple groups is a bottleneck by design. Use AI-assisted intake to make the requirements capturing self-service and the routing automatic.
• Promote the framework before the tooling is finished. Publishing your architectural principles and patterns early (even when implementation is still in progress) aligns teams, accelerates buy-in, and gives other organizations a head start on their own journey.

Try it out

Learn how to Integrate ARM templates with Azure Pipelines.

Related links

• See how we’re modernizing our cloud networking infrastructure with a DevOps mindset.
• Read more about how we made to the move to the cloud with Microsoft Azure.
• Get our seven tips for moving to a “cloud native” device management strategy.
• Find out how we’re using AI to help secure our network environment.
• Learn how we migrated our remote and VPN access infrastructure to a cloud-based solution.

The post Reinventing hybrid cloud integration at Microsoft—from months to one day appeared first on Inside Track.

• Introduction
• Chapter 1: Building your agent governance strategy
• Chapter 2: Establishing a solid data foundation for agent governance
• Chapter 3: A matrixed approach to agent governance
• Chapter 4: Tracking, impact, and value
• Conclusion: Governing the frontier

Empowering employees and protecting your organization through agent governance

Welcome to the agentic frontier

Agents are expanding the frontier of enterprise AI. By creating tools that surface knowledge, take actions, and even reinvent workflows, organizations can apply the power of AI to business processes in new and innovative ways.

But this shift raises questions for business and IT leaders: How do you get the benefits of agents without putting your organization and employees at risk? How do you encourage citizen developers to create agents freely while maintaining control, security, privacy, and compliance?

At Microsoft Digital, the company’s IT organization, we’re putting practical governance structures in place to ensure our internal agents are useful, safe, and properly scoped. Through a deliberate strategy of empowerment with established guardrails, we’re unlocking the potential of agentic transformation while maintaining the trust that defines our work.

Read and prepare

Check out our complete guide to deploying and adopting agents across the enterprise, based on our own experience here at Microsoft.

The AI maturity model and frontier transformation

Agentic AI has made a new operational model possible, one that blends machine intelligence with human judgment, creating AI-operated, human-led teams.

We call organizations that enact this model Frontier Firms.

As organizations move toward this new operational state, they progress from foundational AI assistance through escalating levels of agentic maturity and complexity. First, humans operate with help from an AI assistant like Microsoft 365 Copilot. Then, human-agent teams work together. But the future lies with humans leading teams of agent users: AI agents that perform core labor with relative autonomy.

Capturing the benefits of this model relies on many factors, but in our experience as Microsoft Digital, two main tenets are instrumental to a successful transformation:

1. Empowering employees and teams to create and experiment with their own agents
2. Properly governing those agents to protect the enterprise

It’s a balance. If you set agent builders free without the proper guardrails, you risk data overexposure, agent sprawl, and security vulnerabilities. However, being too restrictive about governance stifles individual imagination, workflow reinvention, and innovation that can come from agentic AI.

“At Microsoft, we’ve moved beyond envisioning the agentic future into operating within it every day. Our experience as Customer Zero gives us a unique perspective on what it takes to govern AI agents at scale, turning early lessons into proven practices that help organizations innovate with confidence.”

Brian Fielder, vice president, Microsoft Digital

We’re here to help you find the right balance for your organization.

This guide shares what we’ve learned along the way. As you read, you’ll follow our journey as Customer Zero at Microsoft, and you’ll gain access to tips and resources that we’ve assembled to help you apply our expertise to your own agent governance practice.

Every organization is different, and your experience will differ from ours in terms of risk tolerance, technical capability, resourcing, and more. This guide highlights some principles and best practices you can apply to your own business context, needs, and objectives.

“At Microsoft, we’ve moved beyond envisioning the agentic future into operating within it every day,” says Brian Fielder, vice president of Microsoft Digital. “Our experience as Customer Zero gives us a unique perspective on what it takes to govern AI agents at scale, turning early lessons into proven practices that help organizations innovate with confidence.”

Now is the time to seize this opportunity. Follow along to start your own journey toward frontier transformation and capture the benefits of trusted, connected agentic intelligence.

Learn from our experience governing agents

Within Microsoft Digital, we’ve been acting as Customer Zero for frontier transformation by creating the tools, infrastructure, and processes that power agents at Microsoft.

Our goal is to make it easy for employees to engage with agentic tools freely and adaptably while maintaining safety and responsibility. The path to this objective relies on a three-pronged approach to governance:

• Embedded governance functionality: Agent creation and publishing tools should incorporate good guidance, governance, and guardrails out of the box, making agents people create essentially self-governing.
• IT oversight: This is a new space and a new way of working, so it isn’t feasible for all agents to self-govern at this point. As an IT organization, we fill gaps in governance through reviews and oversight. We establish risk-based policies around types of agents, exposure and sharing, and other pivots.
• User education: It’s almost impossible to predict every governance gap and need, so educating our users helps them avoid accidentally increasing risk. Our Agents at Microsoft team and individual change managers are the guides for these efforts. Employees can also refer to resources like Microsoft Learn courses and the Agent Builders SharePoint hub.

Throughout this journey, we’ve empowered our employees to create all kinds of agents, ranging from simple personal tools built by people working in every function, with every level of technical skill, all the way to AI-powered enterprise tools designed by professional developers for use across lines of business and even the entire company.

As part of the process, we’ve incorporated guardrails to ensure less technical employees are limited to tools that simply retrieve enterprise knowledge, such as SharePoint Agent Builder or Copilot Studio, while software engineers get the full power of any tool they need that can take action or automate workflows, including Microsoft Foundry and Microsoft 365 Agent Toolkit.

Over the course of this journey, we’ve learned valuable lessons about effective agent governance, including:

• How to build an impactful but flexible governance strategy
• Strategies for creating an AI-ready data ecosystem
• Ways to apply appropriate policies and controls for highly diverse agents
• Approaches for tracking the impact and value of agents

Chapter 1: Building your agent governance strategy

Thinking through your organizational needs and building a framework to govern agents

As we’ve incorporated agents into different aspects of our organization, we’ve also deepened their involvement in employees’ daily workflows and core business processes. Because of this, we’re diligent about the governance guardrails and policies that protect our organization.

We’ve accumulated a wealth of knowledge and insights in this area through our efforts governing Microsoft 365 Copilot. Based on this experience, some of the key priorities that we made sure to adhere to included:

• Effectively applying controls to ensure users and apps don’t get access to privileged information
• Preventing employees from creating agents that violate company policies
• Balancing the freedom for employees to share their creations with the need to prevent agent sprawl
• Delineating which agents are authoritative and applicable for enterprise functions and which ones are meant for employees’ own personal use.
• Inventorying agents to provide lifecycle management
• Securing and protecting confidential data while respecting our responsible AI principles: Fairness, reliability and safety, privacy and security, transparency, accountability, and inclusiveness
• Unlocking telemetry that enables us to govern agents effectively

By focusing on each of these dimensions, our governance team has centered its efforts on the value these agents provide to the company while also ensuring organizational safety and trust. To realize this value, we emphasize three key principles that help protect both our employees and the organization:

Security

We’ve established standards for data classification, policies for handling confidential information, and other security measures to protect data from unauthorized access, misuse, and disclosures. Microsoft Purview powers these capabilities through data labeling, rights management, and data loss prevention.

Privacy

Privacy compliance measures keep personal data protected and ensure agents adhere to regulatory frameworks in the regions where we operate. We conduct regular privacy assessments for all applications, including high-impact agents.

Regulation

Regulatory compliance assessments ensure agents meet prevailing legal standards. Our legal and compliance teams carefully monitor AI guidelines, regulations, and laws as they evolve so we can understand and incorporate them into these assessments.

We incorporated elements of our tenant’s minimum bar for governance into how we secure agents. Those include Microsoft Purview Information Protection, a functional inventory, activity logging, lifecycle management, and the ability to properly isolate agents so that they don’t cross data boundaries.

Our overarching tenant governance strategy is to govern items like documents and data at the container level. However, within a SharePoint site, for example, the added functionality of agents demands that we introduce further controls like sharing limits, breadth of knowledge sources, agent metadata, and information about an agent’s behaviors.

Turning priorities into principles

To operationalize governance, we developed six principles that guide our approach to agents. They form the governance foundation for a wide matrix of agent creation and usage opportunities.

1. We ensure a strong data hygiene foundation so we can trust our data estate as employees build and use agents.
2. We empower employees to build personal agents that can access permitted services and data sources to help automate and accelerate their tasks.
3. We empower teams and lines of business to build agents with known lower-risk patterns to accelerate impact.
4. We provide a smooth release path for engineering teams to develop agents designed for enterprise functions so they can access all the services and sources they need. This includes the same software development lifecycle (SDLC) reviews and certifications as other enterprise software, which we outline in Chapter 3.
5. We accelerate innovation through agent and automation templates while maintaining an AI Center of Excellence (CoE) to help teams think through their opportunities.
6. We reimagine employee experiences and task execution to simplify and optimize productivity.

Read and prepare

Powering the technical veracity of AI at Microsoft with a Center of Excellence.

Securing control through agent lifecycles

As we strategized to operationalize good governance, agent lifecycles became one of our most crucial tools. We superimposed the enterprise lifecycle on top of these policies, with both user-based and attestation-based lifecycles.

This means we treat agents owned by individual employees like any other user app and delete them when they leave the organization. Meanwhile, we ensure that agents owned by teams have a lifecycle that’s defined by the tenant and tied to attestation, our internal enterprise SDLC, and accountability confirmations.

This approach helps us combat sprawl by eliminating agents that no longer serve a purpose. It provides a solid foundation for more fine-tuned, matrixed policies and practices.

Governing amid real-time technology acceleration

One recent development illustrates how the rapid advancement of AI technology requires us to stay ahead of policy for new features.

Model Context Protocol (MCP) adds new capabilities, but also new risks and challenges. It’s a simple standard that lets AI systems communicate with the right tools and data without custom integration work. Instead of building a new connection or API every time, teams plug into a common pattern.

That standardization delivers speed and flexibility, but it also changes the security equation. We’ve extended our security and governance practices to account for MCP servers.

Our practices and policies help us govern agents effectively in this new environment. First, we assess security across four layers: Applications and agents, the AI platform, data, and infrastructure. We establish a secure-by-default strategy by positioning every remote MCP server behind our API gateway and establishing practices for vetting, identity management, automation that slows agents at the right moments, context trimming, and server isolation.

As you define policies for governing your own agentic ecosystem, you can take inspiration from our process. Start by asking questions about what you want to accomplish and what you want to protect, then move on to establishing your most important priorities. From there, you can cement those priorities into policies.

Learning from our approach to agent governance strategy

Match policies to progress on your AI journey

The complexity of agent governance depends on the maturity of your organization and where you are in your adoption journey. Start slowly to let that maturity grow over time.

A strong policy framework is the foundation

Lean on existing app governance policies, then layer agent-specific structures on top.

Take your cues from established standards

Global regulations around privacy, security, and responsible AI provide a good baseline for establishing governance policies. Assign teams to work through these regulations and incorporate their insights into your agent governance strategy.

Decide on your comfort level with risk

Bring cross-disciplinary experts together from across your organization to determine what level of risk is acceptable for different agents and their use cases. Put guardrails in place for low-risk scenarios and establish processes for supporting more complex or sensitive use cases. Evaluate what data sources agents can extract information from. Establish whether users have shared sensitive data sources.

Change is constant

Plan to reassess and revise your governance structure regularly. Agents are evolving rapidly, as is the tooling surrounding them, so maintaining good governance policies will be an ongoing practice.

Governance is a value driver for employees

Governance isn’t just about protecting your organization. It also provides the right patterns to make sure your employees are getting value from agents. Establish strong measures of business value and a robust methodology for management and assessment of agents through ongoing tracking. This kind of observation and telemetry is foundational and should be a key part of your governance efforts.

Key takeaways

Use these tips based on what we learned here at Microsoft to build your strategy for agent governance at your company:

• Establish a cross-disciplinary agent Center of Excellence. Bring together stakeholders across the organization to define priorities, goals, and shared practices for agent adoption.
• Right-size oversight based on risk. Determine your organization’s risk tolerance and define which agents require more or less involvement from IT, security, and compliance teams.
• Operationalize agent oversight and management. Establish an oversight model and implement tools that help manage agents at scale.
• Establish change management and adoption. Determine and implement a strategy for driving adoption to educate and empower employees.
• Create a centralized governance and information hub. Provide employees and agent builders with a single place to find guidance, standards, and governance information.

Learn more

How we did it at Microsoft

• Find out how we’re protecting AI conversations at Microsoft with MCP security and governance. This post outlines how we’re streamlining MCP governance through secure-by-default architecture, automation, and inventory.
• Explore our IT playbook for the AI era and learn how we’re becoming a Frontier Firm. This article shares our journey as an IT organization in support of this new operating model.
• Discover how Microsoft is becoming an AI-first Frontier Firm. This story shares how we’re approaching the idea of an agentic future.
• Read our five-step guide for IT leaders who want to drive greater AI maturity. This resource can help you chart a course through AI maturity to reimagine what’s possible for the enterprise.
• Learn from our experience tackling Microsoft 365 Copilot governance. This guide details our governance efforts for Microsoft 365 Copilot and can serve as a starting point for agentic governance.

Further guidance for you

• Secure your agents at scale with Microsoft Agent 365 guidance for unified identity, compliance, and control across platforms.
• Learn about the responsible AI policies and practices that guide our use of AI at Microsoft.

Chapter 2: Establishing a solid data foundation for agent governance

Setting agents up for success using a secure, robust data foundation

Operating according to an escalating maturity model means we’ve done the foundational work to secure and govern our data estate for Microsoft 365 Copilot. Many of the same principles apply to agents, with the added complexity of incorporating additional data sources.

To lead these efforts, we established a cross-functional team of data professionals within our AI CoE. This team is mostly comprised of Microsoft Digital employees who support corporate functions like Corporate, External, and Legal Affairs (CELA) and Global Workplace Services. Together with our AI CoE, this team helped us define what it means to have AI-ready data.

In essence, AI-ready data just means information we’ve certified for AI workloads. We certify those data sources using Microsoft Purview to identify defects in our core data products, and we’ve also built AI-powered assessments to certify which data lakes are AI-ready.

In most ways, governance is tool-agnostic and rooted in basic principles. With robust data labeling, data hygiene, and permissions in place alongside our AI tools, which respect labels by default, we can confidently give every employee the ability to build basic agents and trust in our governance guardrails. For decades, the challenge of data analysts and engineers was maintaining a consistently reliable source of truth despite inconsistent data quality, insufficient governance, and years of collecting data in silos. Microsoft Fabric and Microsoft Purview can help resolve these issues.

We’re embracing a more balanced, federated approach to data management today. We call this approach a data mesh. Rather than allowing unchecked decentralization or forcing all our data into a single centralized system, the data mesh formalizes domain ownership while embedding governance, quality, and interoperability directly into shared platforms.

The data mesh connects and distributes, data products across domains, enabling shared data access and compute while scaling beyond centralized architectures.

Platform services are standardized blueprints that embed security, interoperability, policies, standards, and core capabilities — providing guardrails that enable speed without fragmentation.

Data management zones provide centralized governance capabilities for policy enforcement, lineage, observability, compliance, and enterprise-width trust.

With this approach, our domain teams publish data as well-defined, discoverable products, while common standards for security, metadata, and compliance are enforced through automation rather than manual processes. This model preserves enterprise trust and consistency without sacrificing speed or autonomy. By adopting a data mesh mindset, we can scale analytics and AI more effectively across the organization while still keeping ownership closely connected to the business focus.

Confidentiality labels, the practical framework for data protection

To operate according to Zero Trust principles, we needed a coherent system that lets us see, label, and protect data. Otherwise, the burden of data loss prevention would fall solely on employees, who would have to exercise individual discretion whenever they decided how to house and share potentially sensitive content.

With labeling, it’s important to strike a balance between the depth necessary for supporting an array of data governance controls and the simplicity to ensure labeling isn’t burdensome for users.

We decided on four overarching labels for container and file classification, each with its own sub-labels. The highest-level schema looks like this:

1. Highly confidential: We only share our most critical data with named recipients.
2. Confidential: Any items crucial to achieving our goals feature limited distribution.
3. General: Employees can share daily work–like personal settings and postal codes–internally throughout Microsoft.
4. Public: We share unrestricted data meant for public consumption freely. That includes information like publicly released source code and openly announced financials.

For our risk tolerance and organizational needs, we made the decision to protect data designated confidential or higher. As a result, we contain data flows to their tenants and only trust suitable storage destinations for content. That suitability depends on a storage location’s ability to gate which connectors can work with particular source data and sensitivity labels.

The administrators responsible for workspaces like SharePoint sites set default labels. These labels serve as a foundation for appropriate access and circulation for objects within those containers. It takes the burden of labeling off of employees. The sensitivity labels that administrators apply map to several different categories of policies that can anticipate and help to mitigate data loss and risk.

They communicate four key areas:

1. Breadth of availability: Labels determine whether the workspace is broadly available internally or is a private site.
2. External permissions: We administer guest allowance via the group’s classification, allowing specified partners to access teams when appropriate.
3. Sharing guidelines: We tie important governance policies to the container’s label. For example, can an employee share this workspace outside of Microsoft? Is this group limited to a specific division or team? Is it restricted to specific people? The label establishes these rules.
4. Conditional access: While we haven’t implemented this policy at Microsoft, tying identity and device verification to container labels can introduce additional governance controls.

Within Microsoft Digital, we’ve put a lot of thought into how each of our labels aligns with relevant policies. You can see more of the logic behind our sensitivity labels and their policies in this graphic:

If a container owner needs different policies for a set of files to provide greater external access, they can self-service new groups without accidentally violating our governance practices.

At Microsoft, we use Microsoft Purview, which is our suite of data estate management tools, but you can use your tool of choice to apply labels in your environment. Microsoft tools will respect them. Microsoft Purview helps us accomplish three important tasks: mapping our labeling structure onto the relevant policies, verifying them against our standards, and backstopping self-service data loss prevention practices through automation.

Automation is particularly useful. We’ve configured Microsoft Purview Information Protection to scan automatically for wayward credentials, malicious user behaviors, and other sensitive information in items without the proper protections. When Purview detects a violation, our governance team receives alerts that prompt them to contain the risk by upgrading an item’s sensitivity label or requiring employees to remedy the issue.

The result is a system that allows flexibility for employees to self-manage their digital workspaces while providing guardrails that help our governance experts take appropriate actions without overtaxing their time and resources.

Our approach within Microsoft Digital is just one way to create an AI-ready data estate, but aspects of our story will hold true for almost any organization. Consider establishing a body to take over responsibility for AI-ready data, developing your primary goals for AI-ready data, unifying your data estate, and implementing a system of confidentiality labels.

Learning from our approach to agent governance strategy

Define the responsibility for AI-ready data

Identify and assign enterprise data owners to implement and oversee the processes that guarantee data quality.

Create intuitive labels

Your employees will be the ones applying labels, so make those labels intuitive. For example, “highly confidential” is easy to understand, while “business-critical” could be interpreted in many ways from a sensitivity standpoint.

Don’t overwhelm your users

Make labeling simple and intuitive to ensure it isn’t overwhelming. Employees should have a limited set of choices to keep things comprehensible.

Use existing defaults

Identify the security needs and regulatory compliance that are specific to your organization and use built-in governance controls available through Microsoft tools.

Key takeaways

You can use these tips based on what we learned here at Microsoft to tackle agent governance at your company:

• Establish a cross-functional data council. Form a data council to help promote a culture of AI-ready data with professionals from all relevant disciplines, including human resources, legal, security, IT, and anyone else who can share relevant expertise.
• Certify datasets for AI workloads. Limit agents to datasets that have been certified as “AI-ready” to minimize hallucinations and reasoning errors.
• Define your labeling parameters. Keep the number of labels to five main labels with five sub-labels each. The fewer you use, the better.
• Align your sensitivity labels with policies. Consider how your labels line up with breadth of availability, external permissions, sharing guidelines, and conditional access.

Learn more

How we did it at Microsoft

• Follow our journey as we transform our data culture with AI-ready data. This story highlights how we’re using Microsoft Fabric and Microsoft Purview to revolutionize our approach to data governance and AI readiness here at Microsoft.
• Discover how a data council is powering our unified data strategy at Microsoft. This post tells the story of how the Microsoft Digital Data Council is leading our efforts to adopt an AI-ready data strategy.
• See how we’re conditioning our unstructured data for AI at Microsoft. This article explains our internal strategies for handling unstructured data, which can be surfaced by AI agents.

Further guidance for you

• Learn about governance and security for agents and how to keep your AI initiatives secure across your organization.
• Establish responsible AI policies for AI agents to support ethical, transparent, and accountable AI agent deployment across your organization.

Chapter 3: A matrixed approach to agent governance

Governing different types of agents for different contexts, built with different toolsets

Our customers have expressed a strong desire to start building agents, but they’re concerned about where to begin and how to manage those agents once they’re built. They worry about persistent problems such as hallucinations and agent sprawl. These concerns are especially pronounced on IT teams.

During our Customer Zero journey, we’ve learned that the diversity of agent types and creation methods means there’s no one-size-fits-all approach to governance. Generalized approaches will only get you so far.

We’ve found it helpful to think about different kinds of agents along an escalating spectrum of development complexity:

There’s an entire matrix of different parameters that apply to an agent at any level of this spectrum, and they all require different policies. Those parameters include:

• Level of reach: Personal agents, limited sharing (like development environments or team boundaries), or enterprise-wide distribution
• Agent-building tool: SharePoint agent builder, Agent Builder in Microsoft 365 Copilot, Microsoft Copilot Studio, or tools geared to more professional developers (such as Microsoft Foundry or Microsoft 365 Agent Toolkit)
• Knowledge sources and content accuracy: Public sites, SharePoint and OneDrive, directly uploaded files, enterprise apps and systems, or third-party knowledge bases

Each of these parameters creates a pivot that we need to govern, and we’ve carefully assembled a set of policies and controls to account for them. As our understanding and use of agents advances, we’re continually updating how we match their characteristics and capabilities with relevant policies and any applicable reviews.

Within Microsoft Digital, we’ve adopted a risk-based approach that helps us establish a matrixed model for agent governance. The foundational idea is that we identify potential harms for each kind of agent, then assign policies for the level of review and oversight they require.

For example, simple agents that can only read and present data tend to be low risk. Because their access is tied to their creators’ identities and access, our data governance structures and guardrails can prevent overexposure. But for agents that have capabilities like writing data, taking action, or creating items, more reviews are necessary.

A matrix of agent governance policies, pivoted by parameter

The following matrix enumerates the factors that determine how we govern different kinds of agents created using different tools. This matrix helps our employees understand the agent creation process and helps us maintain safety and control.

In addition to mapping out our policies for governing agents, the matrix illustrates how we see their relative utility across the organization. It demonstrates an escalation from personally useful to organizationally useful agents. Their governance policies and controls escalate accordingly.

Regionality is an additional concern. Regulatory compliance might vary, but it’s important to keep in mind that certain kinds of data access and actions might be perfectly permissible in one region, but not in another.

One example is our Employee Self-Service Agent, a central resource employees can turn to for help with IT support, HR questions, and facilities requests. Because it can access potentially sensitive personal information, this agent required additional review from European works councils to ensure it met all relevant workplace standards.

As you facilitate the experimentation and innovation with agents across your workforce from citizen developers to pro developers, consider adopting a similar matrixed approach to agent governance. It starts with understanding your organization’s needs, your risk tolerance, and the different employee populations you want to equip with agent-building capabilities.

Learning from our matrixed approach to agent governance

Figure out your building environment strategy

Decide which scenarios match up with specific environments and make those environments available to the relevant employees.

Design governance structures that scale from low-code to more advanced agentic tools

With the proliferation of AI agents, platform-level approvals similar to the Power Platform model at Microsoft can ensure rapid innovation while requiring review for individual high-impact scenarios.

Build trust through transparency and structure

A clear, well-documented approval process helps internal regulatory advisors understand new AI technologies and establishes the trust needed for productive, long-term collaboration.

Treat regional partners as strategic allies in the agentic future

Early feedback on digital agents from regional partners like works councils helps improve product design, accelerate approvals, and reduce fear or misconceptions about AI in the workplace.

Don’t forget that Copilot Studio is part of Power Platform

You can use what you’ve learned empowering citizen developers in Power Platform to guide your work with agents.

Key takeaways

Use these tips based on what we learned here at Microsoft to tackle agent governance at your company:

• Establish your tolerance for risk. Determine where the most prevalent risks emerge across different populations and kinds of agents. Remember, you control the guardrails in your environment.
• Determine what agent-building tools you want to roll out and who can use them. Different populations benefit from different agent-building capabilities. Put thought into what individuals and teams can create and the degree of partnership each level will need from IT.
• Define your governance parameters for different kinds of agents. Determine the best ways to hedge against risk at every level. For example, you might choose to trust in tenant governance for simple agents and establish reviews for more complex tools.

Learn more

How we did it at Microsoft

• See how we’re empowering employees with the Power Platform. This article explains how our Power Platform governance model influenced our matrixed approach to agent governance.
• Learn how our employees are building their own AI tools. This article describes how knowledge workers at Microsoft are forging their own agents to help improve efficiency and get more done.
• Check out our lessons learned using SharePoint agents at Microsoft. This post shows how we approached governance for low-risk, knowledge-only agents through our deployment of SharePoint agents.
• Read how we’re unlocking enterprise AI extensibility with Copilot Studio. This story explores how we govern more advanced agents built with Copilot Studio, including connectors, orchestration, and scaled governance.

Further guidance for you

• Explore governance and security for AI agents across the organization with Microsoft Learn content.
• Check out this industry-standard framework that validates matrixed, risk-based governance approaches for AI systems.

Chapter 4: Tracking, impact, and value

Managing agents and assessing their business impact for the organization

It’s clear that agents bring astonishing capabilities to the enterprise. For many organizations, what remains unclear is exactly how to measure their impact. Without that information, businesses are at a loss for ways to articulate value and drive improvement.

Tracking agents is also a crucial component of preventing sprawl: We need to understand what agents we have, how employees are using them, what critical processes they’re supporting, and if they’re contributing value or need to be retired.

We’re at the beginning of our impact-tracking journey, but our work can provide a starting point for your own efforts to measure the value of AI initiatives at your organization.

Managing our agent catalog through comprehensive tracking

Microsoft Digital partners with other internal organizations to ensure we’re prioritizing the right agents and avoiding agent sprawl. Ideally, these engagements take place before teams start building their agents so we can avoid wasted effort or duplicated work.

Still, ongoing management efforts are crucial to keeping our agent ecosystem healthy. Telemetry is the key to assessing usage and ensuring compliance. We’ve developed our own internal tooling to ensure that:

• Metadata is complete and available
• The tooling tells us the right information about our agents
• The tools connect properly with other compliance tooling, like Microsoft Purview

This telemetry also reveals agent behaviors, shows how agents do their work, and tracks events, actions, and policy baselines.

These capabilities help us gain visibility into policy adherence and violations, and then to conduct enforcement actions. We also track the speed of reaction and mitigation. AI-ready data and robust guardrails mean we head off most violations before they occur.

A robust inventory, an agile policy framework, and an automated workflow for enforcement are cornerstones for successfully governing agents at scale.

The release of Microsoft Agent 365, now in early access, represents the next step in agent observability and management, two key aspects of agent governance and sprawl mitigation. This control pane for agents incorporates many of our learnings as we’ve bridged governance gaps through IT intervention.

Some of the key aspects of the control pane:

The registry

Provides a complete view of agents, and the enterprise agent store makes it easy to find the right agents for each role and business process within familiar workflows in Microsoft 365 Copilot and Teams.

Visualization

Delivers the observability layer, including role-specific oversight, compliance and audit features, and performance measurements that can help organizations track their agents’ impact and see where they contribute value.

Interoperability

Ensures Agent 365 is open to any Microsoft-built or partner ecosystem, while delivering work intelligence through access to data and Microsoft 365 apps.

Security features

Provide crucial confidence through visibility into security posture, detection and response capabilities, and intelligent runtime defense.

As Customer Zero for Agent 365, we’re excited to have a platform for observability and telemetry that encompasses everything from agentic creation through usage.

Tracking governance from agent inception

Professionally developed agents add a new dimension of tracking and governance, because we need standards in place for ensuring compliant agent-building and to remediate any issues.

We use our Azure DevOps instance to catalog apps on our tenant, and we’ve applied this practice to agents created professionally for lines of business and enterprise agents. This tool contains our service tree with product and app log registration, which is tied to our KPI dashboard and scoring system that validates agent data against our policies.

Our expectation is that all new apps and agents start from a place of compliance. Any new agent is registered through this platform, and we expect adherence within the first 14 days. In our experience, the introduction of new metrics, policies, or timeframes as our governance policies evolve is where agents tend to drop out of compliance. The priority is restoring compliant status.

We’ve established a series of metrics to help track and manage these expectations:

• Enablement velocity
• Renewal velocity
• Agents in compliance
• Time to remediation of noncompliance

Through a DevOps process built on our preexisting software development lifecycle practices, we’ve applied governance not only to agents themselves, but to the process of building them professionally.

Measuring progress and unlocking value

Properly measuring value depends on concrete definitions of success and metrics that support it. Articulating AI’s impact came with several challenges. First, we had to land on a consistent taxonomy for different measurement areas. Then we needed to make the relevant data accessible, ensure its quality, and confirm it made sense.

The Microsoft Digital AI Value Framework is our flexible, modular tool for measuring the impact of our AI initiatives. With tools for measurement firmly in place, we can effectively demonstrate value and guide further decision-making.

We plan to use the following capabilities to improve the overall ecosystem:

• Filtering our agent inventory on specific criteria like the type of agent or how it was built
• Enhancing governance-specific actions we can take with agents in areas like ownership and quarantining
• Gaining visibility into trends like agent usage
• Ingesting agent blueprints and defining policy templates

We’re still in the midst of our agentic measurement journey at Microsoft, but the blueprint for tracking already exists. Your organization might be in the early stages of agent readiness and deployment. If that’s the case, it could be helpful for you to internalize the lessons we’ve learned as Customer Zero and apply them as early as possible in your own journey toward AI maturity.

Learning from our agent adoption experience

Think proactively, not retroactively

If you put effort into tracking agentic impact early in your AI maturity journey, you’ll be poised to start capturing insights immediately instead of applying your methodology retroactively.

Involve a wide array of stakeholders

This workstream needs oversight from different kinds of stakeholders, including your leadership team, IT, Microsoft 365 administrators, agent developers and builders, and employee champions. That will provide the sponsorship, expertise, and perspective you need for success.

Different measurements will be appropriate for different phases of your initiatives

These measurements include monthly, weekly, or daily active usage; consider which metrics make sense at each phase of an AI initiative.

Establish a continuum of value

Agents need to tie into real business goals, so it’s important to establish metrics that actually speak to those objectives. Cascade business goals to concrete KPIs with well-defined timelines and track those diligently.

Embrace the red

Try to think of underperformance not as failure, but as data. Performance data over time helps you course correct or pivot, making sure you invest where it matters.

Key takeaways

Here are some important steps to keep in mind as you embark on your own tracking and measurement efforts for agents:

• Establish priorities and parameters for tracking agents. Consider measurements that relate to sprawl, usage, and coverage, and build them into your telemetry tooling.
• Pull your stakeholders together to establish measurement parameters. Cascade business priorities into measurable value.
• Conduct ongoing tracking. Establish a cadence for tracking and reviewing progress with your team.

Learn more

How we did it at Microsoft

• Learn how we’re measuring the impact of Microsoft 365 Copilot and AI at Microsoft. Discover our framework for tracking the impact of the investments in AI that we’re making internally.
• Find out how we’re deploying Microsoft Agent 365 internally. This story shares our intentions for using our unified control pane for agents.
• See how we’re building an AI-powered continuous improvement culture at Microsoft. This article outlines our approach to continuous improvement.
• Check out how we’re reshaping Microsoft with continuous improvement and AI. This post discusses the importance of continuous improvement for accelerating AI at Microsoft, including three initiatives already underway.

Further guidance for you

• This Microsoft Learn guidance helps organizations align AI investments with strategic goals and measurable outcomes over time.
• Explore a cloud adoption framework that provides practical guidance for defining success metrics, tracking ROI, and tying AI initiatives to business outcomes.

Governing the frontier to scale innovation

AI agents are rapidly becoming core contributors to how work gets done. As our experience within Microsoft Digital demonstrates, realizing their full potential demands more than powerful tools or enthusiastic builders. It requires thoughtful governance that evolves alongside your AI maturity, protects what matters, and gives employees the confidence to innovate responsibly.

As you consider your own strategy for managing agents, it can be helpful to keep one truth in mind: Governance is a catalyst for progress, not a barrier. By embedding guardrails into tools, grounding agent creation in AI‑ready data, applying risk‑based and matrixed policies, and reinforcing all of it through adoption and education, we’ve been able to expand agentic capability without sacrificing security, privacy, or trust.

From our experience, we’ve learned that governance works best when it’s:

• Proportional, scaling with risk and agent complexity
• Embedded, not bolted on after the fact
• Human‑led, recognizing that accountability and judgment remain essential
• Iterative, adapting as technology, regulations, and business needs evolve

When you design governance this way, it allows experimentation, learning, and impact at scale. Employees feel empowered to build agents that solve real problems, while IT and compliance teams gain visibility and control without becoming bottlenecks. Crucially, leaders can measure value, manage risk, and make informed decisions about where to invest next.

“At Microsoft, we believe the future of agentic AI depends on governance that empowers people first. The structures should be invisible when they’re working, intentional when they’re needed, and trusted by everyone they serve.”

Vijaya Alaparthi, principal group product manager, Microsoft Digital

This is the foundation of the Frontier Firm: Organizations where humans lead and agents operate, guided by clear principles and trusted systems.

As you continue your AI maturity journey, remember that there is no single, correct governance model. Your approach will reflect your risk tolerance, regulatory environment, data maturity, and organizational culture. The practices outlined here provide a proven starting point informed by real-world deployment at enterprise scale.

“At Microsoft, we believe the future of agentic AI depends on governance that empowers people first,” says Vijaya Alaparthi, principal group product manager in Microsoft Digital. “The structures should be invisible when they’re working, intentional when they’re needed, and trusted by everyone they serve.”

Now is the moment to act. Start with strong foundations. Empower your builders. Measure what matters. And treat governance not as a constraint, but as a strategic advantage that allows your organization to move faster, innovate safely, and lead confidently on the agentic frontier.

Key takeaways

Here are the high-level learnings and insights that you need to consider as you embark on your own agent governance journey, based on what we’ve learned here at Microsoft:

• Treat governance as an enabler of innovation, not a brake. Effective agent governance is what makes large‑scale innovation possible. When you embed guardrails into platforms, data, and processes, employees can build and experiment confidently without exposing the organization to unnecessary risk or slowing progress.
• Match governance rigor to agent risk and maturity. Not all agents need the same level of oversight. A risk‑based, matrixed approach lets organizations trust lightweight, personal agents while applying deeper reviews to agents that write data, take actions, or operate across business‑critical systems.
• Start with AI‑ready data and zero‑trust foundations. Strong agent governance rests on secure, well‑labeled, high‑quality data. Clear ownership, intuitive sensitivity labels, default protections, and automation reduce reliance on user judgment and allow agents to operate safely at scale.
• Embed governance where agents are built and used. The most effective governance is built into tools and workflows, not enforced through manual reviews alone. Defaults, limits, identity‑based access, lifecycle controls, and telemetry should apply automatically so agents are governed by design.
• Plan for the full agent lifecycle to prevent sprawl. Agent inventories, ownership models, attestation, and retirement processes are essential. Governance needs to account for how you create, share, evolve, audit, and ultimately decommission agents, whether individuals or enterprise teams are responsible for building them.
• Reinforce governance through adoption and education. Guardrails work best when employees understand them. Targeted adoption programs, clear guidance, prerequisites for advanced tools, and visible leadership sponsorship can help employees build responsibly and recognize their role in protecting the organization.
• Measure what matters to prove value and drive improvement. Visibility drives trust. Telemetry, observability, and clear metrics that span productivity, quality, risk reduction, and experience allow organizations to track impact, course‑correct early, and continuously improve their agent ecosystem.

Learn more

• Discover our IT playbook for becoming an AI-driven Frontier Firm.
• Learn how to secure your agents at scale with Microsoft Agent 365 guidance.
• Read a guide to governance and security for AI agents at your organization.
• Check out this detailed guide to our governance process for the internal rollout of Microsoft 365 Copilot.  
• Explore ways to establish responsible AI policies for agents across the organization.  
• Find out how a data council is powering our unified data strategy at Microsoft.

Try it out

Get started building and managing agents at your company with Microsoft Agent 365.

The post Governing AI agents at scale: Lessons from our journey at Microsoft appeared first on Inside Track.

But this kind of fragmentation slows down reasoning. Engineers spend more time navigating tools than diagnosing issues.

To address this, the Microsoft Infrastructure, Networking, and Tenant organization in Microsoft Digital, the company’s IT organization, is building Infrastructure Graph (IGraph), a unified platform that brings topology, real-time telemetry, and operational context into a single view.

On top of this foundation, agentic capabilities enable AI agents to reason across these signals, surfacing insights, explaining issues, and recommending next steps. This shifts the experience from exploring data to making decisions faster and with greater confidence.

“Engineers increasingly face fragmented visibility. We wanted to unify live telemetry, topology, and context into one single intelligent visualization experience and show engineers what’s really important, so they don’t have to dive into oceans of data.”

Astha Sinha, product manager, Infrastructure, Networking, and Tenant team, Microsoft Digital

This visualization layer and intelligence platform provides a view of our entire Microsoft enterprise network—including more than 20,000 on-premises devices across 900 sites worldwide—to instantly surface the most critical issues and offer proactive recommendations to our engineers.

“Engineers increasingly face fragmented visibility,” says Astha Sinha, a product manager in the Infrastructure, Networking, and Tenant team in Microsoft Digital. “We wanted to unify live telemetry, topology, and context into one single intelligent visualization experience and show engineers what’s really important, so they don’t have to dive into oceans of data.”

Network insight at speed

IGraph displays the following in a single pane-of-glass view for a given site:

• Topology and dependency context: Visualizes routers, switches, access points, client devices, and their relationships, enriched with path and dependency awareness to localize impact areas
• Real-time health and telemetry insights: Surfaces live performance signals (utilization, errors, abnormal behavior) correlates directly onto the topology to highlight where the network is degraded or “running hot”
• Operational and incident context: Integrates incidents, tickets, and change signals into the graph, enabling engineers to understand what is happening and where and what systems are affected in a single view

“Fragmentation across operational data sources was only part of the problem. The harder challenge was externalizing and structuring the implicit domain knowledge engineers rely on, then integrating it with real-time telemetry and topology to enable low-latency, context-aware reasoning in the agentic layer.”

Vinod Kumar Singh, principal software engineer, Infrastructure, Networking, and Tenant team, Microsoft Digital

On top of this visualization layer, the team is building an agentic layer using Azure Foundry that allows AI agents to discover and use external tools and data sources.

Without IGraph agent, accessing data involves pulling from multiple existing sources, including servers and logs, with mixed latency (from minutes to hours). This fragmentation makes near-real-time reasoning almost impossible, as agents lack a unified, low-latency view of topology and telemetry.

“Fragmentation across operational data sources was only part of the problem,” says Vinod Kumar Singh, a principal software engineer in the Infrastructure, Networking, and Tenant team in Microsoft Digital. “The harder challenge was externalizing and structuring the implicit domain knowledge engineers rely on, the integrating it with real-time telemetry and topology to enable low latency, context-aware reasoning in the agentic layer.”

How IGraph works

The user starts in context. Say they’re on the IGraph UI for Building 32. They can already see the building topology, recent incidents, support tickets, and live health and performance metrics.

The engineer can ask a natural language question such as, “The internet is not working in Building 32—what’s going on?”

The AI agent begins reasoning across UI context (location, devices, open incidents), topology (involved devices and neighbors), historical metrics, and real-time device calls. It works with specialized MCP servers and agents to identify impacted devices, test live responsiveness, measure neighboring impact, verify data flow, and flag abnormal utilization or error trends.

“Engineers spend a lot of time firefighting. The visualization layer gives them the view they need to quickly solve the incidents. It helps free up their time to engage in more systemic improvements on their applications.”

Abhijit Vijay, principal software engineer manager, Infrastructure, Networking, and Tenant team, Microsoft Digital

Using this context, IGraph pulls in the relevant logs, real-time telemetry, and incident history to complete the analysis.

Instead of raw metrics and hundreds of rows of data, the agent returns a clean summary that provides a view of the failing device, the health of neighboring devices, and the blast radius. It shows what’s broken, what’s still healthy, the likely causes, and next actions.

The engineer stays in one UI for all this, and isn’t forced to use different tools or manually correlate data.

“Engineers spend a lot of time firefighting,” says Abhijit Vijay, a principal software engineer manager on the team in Microsoft Digital. “The visualization layer gives them the view they need to quickly solve the incidents. It helps free up their time to engage in more systemic improvements on their applications.”

The impact of incident visibility

IGraph offers a new real-time telemetry layer that:

• Uses a UI that surfaces telemetry and topology by correlating data from upstream systems
• Decreases effective latency for users, enabling near-real-time insights (often within seconds)
• Provides near-real-time signals in the UI on health, performance, routing state, and neighboring device relationships

“Our goal is to accelerate how network engineers understand what’s happening, enabling them to shift from reactive troubleshooting to proactive prevention—identifying and mitigating issues before they occur.”

Nevedita Mallick, principal product manager, Infrastructure, Networking, and Tenant team, Microsoft Digital

Combined, these capabilities give network engineers an up-to-the moment view of what’s happening across the network, before small issues can cascade into larger incidents.

By making live telemetry easier to access and interpret, IGraph helps teams move from reactive troubleshooting to proactive prevention.

“Our goal is to accelerate how network engineers understand what’s happening, enabling them to shift from reactive troubleshooting to proactive prevention—identifying and mitigating issues before they occur,” says Nevedita Mallick, a principal product manager for the Infrastructure, Networking, and Tenant team in Microsoft Digital.

That speed and clarity are especially important for new engineers.

“The tool delivers value right away, especially for newer engineers. Instead of having to piece things together, they get an instant view of the network that shows how devices are connected and displays the already-surfaced incidents directly on the graph.”

Manjiri Keskar, principal cloud network engineer, Infrastructure, Networking, and Tenant team, Microsoft Digital

Complex networks rely on unwritten knowledge and experience built up over time, which can slow onboarding and make troubleshooting harder than it needs to be. IGraph shortens that learning curve by making the network’s relationships and current state immediately visible.

“The tool delivers value right away, especially for newer engineers,” says Manjiri Keskar, a principal cloud network engineer in the Infrastructure, Networking, and Tenant team in Microsoft Digital. “Instead of having to piece things together, they get an instant view of the network that shows how devices are connected and displays the already-surfaced incidents directly on the graph.”

What’s next for IGraph Agent

Without IGraph Agent, network analysis is largely reactive.

Teams often address failures after customers have already felt the impact, instead of preventing issues by acting when early warning signs appear.

“Agentic AI is transforming networking DevOps from manual, reactive operations into intelligent intent-driven systems that can provision, validate, and troubleshoot networks autonomously. Looking ahead, it will power self-healing networks and dramatically accelerate buildouts, allowing engineers to focus on architecture, strategy, and innovation.”

Sonika Munde, senior network engineer, Infrastructure, Networking, and Tenant team, Microsoft Digital

Teams often address failures after customers have already felt the impact, instead of preventing issues by acting when early warning signs appear.

“Agentic AI is transforming networking DevOps from manual, reactive operations into intelligent, intent-driven systems that can provision, validate, and troubleshoot networks autonomously,” says Sonika Munde, a senior network engineer in the Infrastructure, Networking, and Tenant team in Microsoft Digital. “Looking ahead, it will power self-healing networks and dramatically accelerate buildouts, allowing engineers to focus on architecture, strategy, and innovation.”

That unified network intelligence will let IGraph Agent communicate with multiple lightweight agents that continuously analyze network conditions, dramatically compressing response times.

“What used to happen in hours will happen in minutes,” Munde says.

Now, the team is pushing further. One example is layering in weather intelligence to help engineers anticipate issues before they materialize, as big storms can trigger power fluctuations that ripple through the network. By visualizing this data, engineers can proactively communicate with customers and take mitigation steps that protect operational workloads.

Overall, IGraph lets teams focus on prevention. Engineers spend less time navigating dashboards and cross-checking data and more time detecting patterns and surfacing emerging risks. Manual analysis is reduced as the agent highlights insights in real time.

“By bringing telemetry, topology, and AI together in one intelligent layer, we’re turning fragmented signals into real-time intelligence so teams can move faster, act earlier, and protect the critical workloads that power Microsoft.”

Jason Thompson, principal group product manager, Infrastructure, Networking, and Tenant team, Microsoft Digital

The technology is poised to go even further. IGraph will eventually help power self-healing networks and speed up network build-outs, freeing engineers to focus on architecture and innovation. The future vision for the tool includes fully automated predictive network intelligence across all Microsoft campuses, with agents that monitor, reason, recommend responses, and safely take action.

“By bringing telemetry, topology, and AI together in one intelligent layer, we’re turning fragmented signals into real-time intelligence so teams can move faster, act earlier, and protect the critical workloads that power Microsoft,” says Jason Thompson, a principal group product manager for the Infrastructure, Networking, and Tenant team in Microsoft Digital.

Key takeaways

To move from reactive operations to proactive AI-supported network management, we recommend starting with these steps:

• Start consolidating real-time telemetry into a single view. Even a lightweight dashboard is enough to prepare for AI-driven insights later.
• Identify high-frequency incident types to target for AI triage. Pick the most common or disruptive scenarios and map out what data engineers currently review for them.
• Document the decision logic your engineers use today. Before implementing AI, capture the human reasoning steps to help guide your approach.
• Pilot an agentic solution with one network segment or site. Start with one building, one lab, or a small testbed.

Try it out

Learn more about what Microsoft Azure can do for you.

Related links

• See how we’re boosting network performance at Microsoft with real-time telemetry and performance visualization.
• Discover how we’re reclaiming engineering time with AI tools in Azure DevOps at Microsoft.
• Learn how Microsoft is reducing operational overload with AI-guided insights.

The post Supercharging network operations at Microsoft with AI-based unified network intelligence appeared first on Inside Track.

But in practice, the technical side of transformation is only part of the story. The missing piece is us humans.

When we encounter these kinds of challenges internally at Microsoft, we think of ourselves as “Customer Zero.” We roll out our technology across our own organization first, learning what works and what doesn’t in real time and at scale so we can pass our lessons on to you.

“After an early wave of enthusiasm for Copilot, adoption declined. People questioned whether AI was relevant to their role, worried about what it might mean for their work, and disengaged when the change they experienced didn’t match the change they imagined.”

Daniel Bertrand, senior director, AI Transformation Office

We learned valuable lessons about AI adoption and sustainable change when we deployed Microsoft 365 Copilot across our Microsoft Commercial organization, one of the company’s largest sales and service organizations. What we observed led us to reset our strategy and build a more human-centered process for deploying and driving adoption of our AI technology.

Driving AI adoption with role relevance and daily habits

Here on the Customer Zero team in Microsoft Customer and Partner Solutions (MCAPS), our 60,000-employee strong sales organization, we saw that getting access to Copilot didn’t automatically result in widespread AI adoption.

“After an early wave of enthusiasm for Copilot, adoption declined,” says Daniel Bertrand, a senior director on the AI Transformation Office team in MCAPS. “People questioned whether AI was relevant to their role, worried about what it might mean for their work, and disengaged when the change they experienced didn’t match the change they imagined.”

Initially, people used Copilot like a search engine and expected it to make work go away. When that didn’t happen automatically, they didn’t know how to approach prompting the AI, or how to create value with it. The gap between access and know‑how is where adoption slowed.

“I knew from experience that people prefer to hear from—and learn alongside—those closest to their day-to-day work, to build trust and confidence.”

Susan Neece Robien, senior director of adoption and change, AI Transformation Office

We reframed the problem from “How do we scale the technology?” to, “What does this change feel like for people doing the work every day?”

By talking to people in our larger organization about why they were reluctant to work with Copilot, we discovered the adoption barrier was less about the technology being available and more about whether people trusted it, understood how it fit their role, and felt confident enough to build new habits around it.

The ‘Adoption-in-a-Box’ approach

After these conversations, we changed our strategy across the board.

“I knew from experience that people prefer to hear from—and learn alongside—those closest to their day‑to‑day work, to build trust and confidence,” says Susan Neece Robien, a senior director of adoption and change on the AI Transformation Office team. “That led me to conceptualize Adoption‑in‑a‑Box—a repeatable approach that combines behavior‑change guidance, peer influence, habit‑forming activities, and light gamification so people can experiment with AI in a non‑threatening way and build confidence over time.”

We rolled out the Adoption-in-a-Box concept across the team in the following ways:

• Emphasized visible leadership support: We circulated videos and “day in the life” PowerPoint 1-pagers of how our leaders were using Copilot.
• Formed a community of early adopters: They becamepeer champions for adoption, evangelizing best practices and leading workshops.
• Created a Role Hub: The hub contained practical, role-specific learning about how to use Copilot rather than doing high-level general trainings.
• Ran prompt campaigns: To get our team started with habitually using AI in their daily roles, we ran prompt campaigns to make prompt learning accessible and actionable.
• Created the Copilot Cup: We encouraged friendly competitions with leadership support. We also ran hackathons and prompt-based scavenger hunts to gamify learning about and using the AI for our team.
• Created ongoing measurement mechanisms: We stood up dashboards with monthly, weekly, and daily average usage reports. We also ran quarterly surveys to track sentiment around AI adoption on the team.

After our initial success with Adoption-in-a-Box, we scaled it to adoption leads, who brought the model to life within their teams.

When people feel safe in experimenting with AI and incorporating it into their day-to-day work, that’s when it provides real value for the organization and the individual. We’ve learned that sustainable, scalable AI transformation succeeds when we put people first.

Key takeaways

If you’re wondering how to encourage your own team to adopt new AI technology into their workflows, you can learn from our experience:

• Prioritize visible leadership participation. Leaders set the tone of any transformation, and AI adoption is no exception.
• Roll out for role relevance. Specificity is the key here: How does AI relate to each person’s individual role? If the tool provides value and saves time, people will incorporate it into their workflow.
• Establishing habits is crucial. Sustainable adoption means people use the tool on a daily basis in the natural flow of their work. Give them low-friction opportunities to learn the ropes.
• Encourage peer-to-peer experimentation. Early adopters can be a valuable resource for showing others the way. Lowering the stakes by having a peer guide employees in a workshop or one-on-one can take the pressure off as they experiment with the tech.

Try it out

Test drive an AI-assisted workflow of your own with Microsoft 365 Copilot to see how agentic AI can transform your team.

Related links

• Discover the five lessons we learned about how to make AI stick for sellers during our Copilot rollout.
• Check out our full guide describing how we deployed and drove adoption of Microsoft 365 Copilot across our global organization.
• Read about our internal change management strategy for Copilot and how it helps us drive the future of work.
• Learn how the creation of a Copilot Expo propelled AI usage at Microsoft.
• See our seven tips for driving Copilot adoption with a virtual skilling event.
• Discover how one Microsoft Digital employee powers her typical workday using Copilot.

The post Staying human: How we’re using AI to transform the sales experience at Microsoft appeared first on Inside Track.

These innovations have come in many different forms across every group and function at the company. It’s impossible to capture them all in a single concept or story, but one of the ways that we’ve activated the power of AI for our workforce is Work IQ.

Work IQ isn’t a product.

It’s a shared intelligence layer that enables Microsoft 365 Copilot and AI agents to reason over and understand your organization’s work data, then use that context to generate more relevant responses and actions. This means that the entire Microsoft Graph—including rich unstructured data from your Teams chats and meetings, Outlook emails, Word documents, PowerPoint presentations, and more—is now part of your AI-powered work experience.

“It’s not really a brand-new capability, but more an evolution of what users already know, which is access to the grounding data in their Microsoft tenant. The difference is that Work IQ adds an additional layer to provide more context, allowing for richer and more relevant results.”

Aisha Hasan, principal product manager, Microsoft Digital

Work IQ enables Copilot to not only tailor answers to your role and responsibilities, but also to understand who your most frequent collaborators are, comprehend details about your latest projects, surface deliverables and deadlines, and intuit next steps. Additionally, Work IQ makes it easy for any AI agent to take advantage of the same rich enterprise data to return and act on more contextual results.

“It’s not really a brand-new capability, but more an evolution of what users already know, which is access to the grounding data in their Microsoft tenant,” says Aisha Hasan, a principal product manager in Microsoft Digital. “The difference is that Work IQ adds an additional layer to provide more context, allowing for richer and more relevant results.”

At Microsoft Digital, the company’s IT organization, we’ve seen firsthand how this intelligence layer is accelerating employee adoption of Copilot and agentic AI as outputs become more perceptive and valuable. Work IQ is a foundational step toward a future where AI has moved beyond isolated assistance and become a trusted professional helper—sometimes described as a digital colleague—that carries out tasks and anticipates needs in every aspect of daily work.

How Work IQ impacts everyday work

One of the most instructive aspects of Work IQ’s impact across our organization is that it happened without a traditional deployment. There was no enablement event for employees or operational playbook distributed to administrators. It didn’t require any changes to the application interfaces. Yet over time, our employee Copilot interactions improved in measurable ways.

“There was a period where we weren’t adding new content to Copilot, and yet I noticed our metrics for quality and user satisfaction kept going up. Why was that? It was because of all these incremental improvements that we refer to as Work IQ.”

Dodd Willingham, principal product manager, Microsoft Digital

This was a direct consequence of introducing a shared intelligence layer into a Microsoft environment that was already rich in work signals. Those work signals are extremely valuable data that was difficult to extract meaning from before the advent of AI. As the technology advanced, we could take full advantage of this data to inform and improve agentic responses.

As Customer Zero for the company, Microsoft Digital was at the forefront of measuring the impact of Work IQ. Our employees saw significant gains in relevance, grounding, and answer coherence in Copilot that were visible in the metrics, even during times when the underlying content remained relatively static. That’s the Work IQ difference.

“There was a period where we weren’t adding new content to Copilot, and yet I noticed our metrics for quality and user satisfaction kept going up,” says Dodd Willingham, a principal product manager in Microsoft Digital. “Why was that? It was because of all these incremental improvements that we refer to as Work IQ.”

At a systems level, Work IQ reasons across a broad cross-section of Microsoft 365 data, including:

• Outlook email content, thread structure, and interaction patterns
• Teams chats, channels, and meeting transcripts
• Calendar events and scheduling metadata
• Documents and files across Word, PowerPoint, Excel, OneDrive, and SharePoint
• Signals that show who collaborates with whom, how often, and in what context

Work IQ can also access structured data in tools like Dynamics 365, Power BI, Power Apps, and other business applications. The ability to extract context and interpret structured and unstructured data in a unified intelligence layer is the reason why Work IQ is making such a difference for our employees.

Making Outlook better

Outlook provides a useful lens on how Work IQ functions because it’s both heavily used by our employees and a highly contextual tool. Although the application hasn’t outwardly changed, the way Copilot interacts with inbox and calendar data has evolved, in part due to richer context provided by Work IQ.

“The intelligence works behind the scenes as you use Outlook. Your inbox just gradually feels more relevant. Outlook adapts to your work patterns, making your inbox feel more like an assistant, instead of a filing cabinet of communications.”

Matthew Marzynski, principal product manager, core experiences, Microsoft Digital

Now when you turn to Copilot in Outlook to summarize email threads, it can surface decision points, action owners, and unresolved issues. Instead of treating email as a collection of messages and providing rote summaries, Copilot perceives it as a record of decisions and commitments over time.

Calendar-related experiences are on a similar trajectory. Meeting preparation and follow‑up suggestions are now drawing on prior interactions with the same participants, relevant documents that were previously shared, and historical patterns around similar meetings.

Work IQ isn’t rule-based automation layered on top of Outlook. Users aren’t configuring new filters or workflows. Instead, the system is adapting based on observed patterns, meaning user behavior can remain the same while output quality improves

“The intelligence works behind the scenes as you use Outlook,” says Matthew Marzynski, a principal product manager for core experiences in Microsoft Digital. “Your inbox just gradually feels more relevant. Outlook adapts to your work patterns, making your inbox feel more like an assistant, instead of a filing cabinet of communications.”

Applying persistent memory

Another important aspect of Work IQ is the ability to retain persistent memory of each employee’s role, responsibilities, and work context. Copilot and other agents no longer need to be continually prompted with details about who the user is and what they’re working on. It learns that information and remembers it going forward.

This feature, also called persistent understanding, builds trust and increases efficiency each time an employee turns to AI for help with their work. AI systems that depend on manual context-setting don’t scale well across large organizations, which we at Microsoft Digital learned as we tested and deployed Copilot across the company.

“The user no longer has to tell the agent, ‘I work in this area, so please tailor your response to that’ every time,” says Anishkumar Ramakrishnan, a principal PM manager in Microsoft Digital. “With Work IQ, Copilot and agents recall it going forward. It remembers things that the user doesn’t even remember themselves about their past work and actions. This is the promise of intelligent context.”

From answers to action: Work IQ and AI agents

As organizations move toward integrating AI agents into all aspects of their day-to-day work, the value of Work IQ increases. Any agent—not just a general-purpose agent like Copilot—that can interpret vast amounts of your unstructured work data is going to produce results that are far more relevant than one that simply draws on general knowledge about a topic or process.

“Before, a builder had to go connector by connector and be very prescriptive—calendar read, email read, meeting access—just to build an agent. Now they can simply point the agent to Work IQ, and it gains contextual access across mail, calendar, meetings, and files through a single connector (API or MCP server).”

Naveen Jangir, principal architect, Microsoft Digital

Early agent implementations relied on narrower task-specific access to data. For each agent, a developer would have to build connections to a particular document library, mailbox, or set of calendar data. Each connection required separate consent and management, which generally resulted in a more limited scope.

But with Work IQ, builders can create agents using Microsoft Copilot Studio or other development platforms (such as Microsoft Foundry) that use APIs or Model Context Protocol (MCP) servers to connect to Microsoft Graph data. This enables them to bring the full power of enterprise data to any agentic creation, not just Microsoft 365 agents.

“Before, a builder had to go connector by connector and be very prescriptive—calendar read, email read, meeting access—just to build an agent,” says Naveen Jangir, a principal architect in Microsoft Digital. “Now they can simply point the agent to Work IQ, and it gains contextual access across mail, calendar, meetings, and files through a single connector (API or MCP server).”

This shift doesn’t just simplify agent development—it fundamentally expands what agents are capable of. Instead of operating within narrow, predefined tasks, agents can now reason across a broader work context to deliver better outcomes. For example, an agent supporting a project manager can surface relevant email threads, identify key stakeholders from meeting activity, reference the latest project documents, and highlight upcoming deadlines—all within a single interaction.

Intelligence without bypassing governance

From a governance perspective, Work IQ doesn’t introduce a new security model. Instead, it operates entirely within the existing Microsoft 365 data protection boundaries that our company and our customers already rely on.

The intelligence layer can access this enterprise data, but it does so while honoring permissions, sensitivity labels, access policies, and compliance controls defined at the source. Work IQ can only surface or act on information that the user—or an agent identity acting on the user’s behalf—is already authorized to access.

This inheritance model is intentional. Governance remains rooted in the data layer, not in the AI layer. Work IQ respects established controls such as identity‑based access and tenant policies, which means agents are generally given less access than human users.

“An agent user only gets access to what is explicitly shared with it,” Jangir says. “Human users typically have broader default access. By design in Work IQ, agents can usually see less than people, not more.”

For IT and security teams, this places the emphasis squarely on data discipline and identity controls, which are complementary security layers. Work IQ amplifies the value of well‑governed data and exposes weaknesses where governance is inconsistent. Admins remain in control of access and can turn off APIs and MCP server connections if they want to limit an agent’s data access.

Work IQ, Fabric IQ, and Foundry IQ

As we’ve scaled up Copilot and agentic AI internally, one lesson has become clear: Intelligence works best when it’s part of a layered infrastructure rather than working on its own.

That’s why Work IQ is just one context layer we’re using at Microsoft. We’ve also developed Fabric IQ and Foundry IQ, which are complementary layers in our overall data strategy. Each of these addresses a different aspect of enterprise intelligence.

The three layers serve distinct but connected purposes:

• Work IQ focuses on unstructured productivity data, helping AI understand how people work across email, meetings, documents, and collaboration signals.
• Fabric IQ applies similar reasoning to analytical and structured data, adding context and explanation to metrics, trends, KPIs, and other business signals.
• Foundry IQ provides the foundation for builders to create agents that draw from both worlds, connecting intelligence across Microsoft 365, analytics platforms, and line‑of‑business systems.

Taken together, these layers also contribute to something deeper: the emergence of a shared business ontology. By extracting and aligning business entities—such as people, projects, and processes—from both structured data in Fabric IQ and the unstructured signals captured by Work IQ, the system perceives meaningful connections that previously were hidden. This unified understanding allows agents to reason across domains with greater precision, linking metrics to the real work and making insights more actionable in context.

This architecture matters because it removes artificial seams. Agents shouldn’t need to shift between separate contexts for work content, enterprise data, or application logic. The IQ layers make it possible to deliver a single agentic experience that reasons consistently, applies governance uniformly, and moves with users across environments. Just as importantly, the same controls—identity, permissions, labeling, and policy—flow through each layer, keeping trust intact as capability expands.

At Microsoft, Work IQ and the other context layers are helping Copilot and agents to accelerate beyond AI experimentation. They are now vital operational tools that make everyone more productive across the global enterprise. Context and intelligence in agentic tools are a key part of the future of work, at Microsoft and for our customers as well.

Key takeaways

Here are some things to keep in mind as you prepare your own organization to take full advantage of Work IQ:

• Treat the technology as infrastructure, not a feature. We didn’t formally roll out Work IQ. Its value emerged gradually as it improved Copilot responses and as our agent builders could more easily tap into unstructured enterprise data.
• Expect improvements in AI quality without changes to your data. We saw measurable gains in relevance and user satisfaction even when underlying content remained the same, driven by better contextual reasoning across existing work signals.
• Focus on how employees work, not just what content exists. Work IQ improves AI outcomes by connecting people, relationships, and activity patterns, resulting in more actionable and grounded responses.
• Use Work IQ to move from assistance to action with agents. By giving agents access to contextual enterprise data through a unified layer, we enabled more automated workflows without requiring developers to manage dozens of connectors manually.
• Invest in data governance early to maximize AI value. Because Work IQ inherits permissions and policies from the data layer, its effectiveness—and safety—relies on clear labeling, intentional access design, and disciplined data management.
• Enable self-service collaboration data so it’s available for Work IQ. WorkIQ can only ground on data that is both available and not purposefully hidden. We make sure that our meetings are AI-enabled (and often recorded) and allow self-service in Teams and SharePoint, so the data is not hidden from Work IQ.
• Build toward a unified intelligence model across work and data. Combining Work IQ with Fabric IQ and Foundry IQ means agents can operate seamlessly across different kinds of data and incorporate more intelligence into their output and actions.

Try it out

Get a closer look at Work IQ.

Related links

• Check out how we’re embracing this agentic moment at Microsoft.
• Explore a Microsoft Learn article for more technical details about how Work IQ works.
• Learn how to get started building agents with Microsoft tools.
• Discover our detailed guide on how we deploy AI agents internally at Microsoft.
• Read an IT playbook for the AI era and learn how we’re becoming a Frontier Firm at Microsoft.
• See how we’re using Model Context Protocol security and governance to protect AI conversations at Microsoft.

The post How Work IQ is supercharging our AI usage at Microsoft appeared first on Inside Track.

In 2026, we’re celebrating 25 years of SharePoint at Microsoft. Microsoft Digital, the company’s IT organization, is commemorating this anniversary by reflecting on the journey we’ve taken with the product over the last quarter-century.

In this article, we’ll share our journey as SharePoint’s Customer Zero and step through the lessons we’ve learned building and maintaining an IT stack in the age of agentic AI.

Why SharePoint?

In the early 2000s, we faced a technical challenge familiar to just about any organization: We had important documents and data scattered across siloed file shares, institutional knowledge hidden away in email attachments, and access challenges preventing different teams from collaborating across geographical borders and departmental boundaries.

SharePoint offered the solution to these challenges.

Its flexible, web-based platform gave us the ability to collaborate using shared sites, centralized document libraries, and widely accessible workspaces. The application also fundamentally reshaped our corporate communications and publishing capabilities, providing features that would power key internal portals like Microsoft Web (our longtime internal company homepage, often called MSW), HRWeb, and MS Library.

“At the time, because there were so few customers running SharePoint at scale, the product was in many ways directly built to meet our IT needs.”

Sam Crewdson, principal program manager, Microsoft Digital

The evolution of how we used SharePoint in Microsoft Digital can best be described in three phases:

1. Our on-premises expansion and optimization
2. Our migration to the cloud, self-service growth, and modernization
3. Our incorporation of agentic AI

On-premises expansion and growing pains

When we first adopted on-premises SharePoint at scale, it became indispensable almost immediately. Internal teams used SharePoint to replace their existing file shares, publish information internally, and create many custom workflows and applications tailored to their needs.

Our team at Microsoft Digital was responsible for deploying SharePoint on an enterprise scale. Because we were one of the first enterprise customers to fully use SharePoint’s capabilities, we worked closely with the SharePoint product team from the beginning of its existence as a company. This meant we played a sizable role in influencing what SharePoint ultimately became.

“At the time, because there were so few customers running SharePoint at scale, the product was in many ways directly built to meet our IT needs,” says Sam Crewdson, a principal program manager in Microsoft Digital. “A result of our being their first and best customer at the time was that the SharePoint team often built capabilities for us that no one else was asking for yet, such as specific portals features and supportability needs.”

Our initial adoption of SharePoint exposed some structural limitations and gaps. To meet the goals of our internal customers, we often relied on custom code, which made upgrades more difficult. And data governance and lifecycle management could be challenging, with our internal teams creating thousands of sites with little or no ownership tracking.

Using SharePoint in this way meant rapidly accumulating abandoned sites and outdated content. Trying to conduct even routine maintenance became difficult because there was no reliable way to contact site owners.

“Because of the initial difficulties, SharePoint was frustrating at first, especially for admins. But then I realized how important it was for our users—the product saved them so much time, and they were so happy that it was available. It was a complete 180-degree shift in my mindset towards SharePoint.”

Thomas Snyder, principal service engineer, Microsoft Digital

These challenges meant tensions often ran high for the IT team during the initial adoption phase. Tempers sometimes flared as we navigated this period in SharePoint’s evolution at Microsoft.

However, the time and effort we put into overcoming these growing pains—time and effort our customers didn’t have to invest themselves—made the frustrations well worth it.

“Because of the initial difficulties, SharePoint was frustrating at first, especially for admins,” says Thomas Snyder, a principal service engineer in Microsoft Digital. “But then I realized how important it was for our users—the product saved them so much time, and they were so happy that it was available. It was a complete 180-degree shift in my mindset towards SharePoint.”

Scalable self-service, effective governance, and the cloud

SharePoint’s role at Microsoft quickly expanded from a collaboration platform into a more powerful application where our teams could build workflows, forms, dashboards, and other solutions.

Thanks to a decision to enable SharePoint’s self-service site creation capabilities, our internal customers were able to use it to build the sites they needed without having to wait for us in IT. By removing the friction of having to work with IT, they innovated faster and built new capabilities on their own using SharePoint’s out-of-the-box technology.

However, this self-service power we gave to our users also drove some sprawl that we were not initially ready to manage. By the late 2000s, the information explosion that SharePoint sparked at the company was increasing our operational and governance burden. The rapid growth in sites delayed upgrades and introduced security and compliance issues stemming from a lack of clear ownership when site owners changed jobs or left the company.

As a result of this growth, we made the decision to invest heavily in building up our governance and lifecycle management for SharePoint. We prioritized defining clear ownership for all SharePoint sites, establishing best practices around data cleanup, and building the guardrails necessary to make widespread adoption and use more manageable.

Moving SharePoint to the cloud

Our cloud migration started in late 2010 and quickly became the driving force for us in IT. Rather than see the migration as a simple lift-and-shift activity, we took the opportunity to strategically reconfigure the architecture and customization level of our SharePoint instance.

This was a huge undertaking.

We had to think globally across all our sites in different regions and countries. The tooling suite for migration was immature at the time, meaning some of our portals and sites would require refactoring. We also had to contend with the constraints of varied and sometimes conflicting regional data residency requirements.

“It’s effectively filtering, so you don’t migrate everything. You’re cleaning your house before you move. You don’t move everything in your garage—you clean it out first. The easiest move is the one you don’t have to do.”

David Johnson, principal product manager architect, Microsoft Digital

Our approach to moving SharePoint to the cloud took several phases

First, early adopters who expressed active interest in migrating were provisioned the first sites in the cloud. By harnessing their enthusiasm for cloud services, we allowed them to self-migrate their own site content

Second, we did extensive analysis of all sites to establish actively used sites. Sites where we had no recent usage were backed up, stored offline, and deleted. If nobody screamed, we didn’t move them to the cloud.

Third, we moved the zero- and low-customization sites. These were sites using out-of-box features that had the highest likelihood of a successful migration

Finally, all we had left were the highly customized sites, which often used customization approaches which were not supported in the cloud. These we chose to manually rebuild and often to refactor as part of our migration approach.

While we were making these first-in-the-world migrations, we spent a lot of time with our SharePoint product team partners to learn how best to move sites and to document the approaches for the millions of sites that would follow. Sites which had high levels of customization or features that the cloud couldn’t support were instead rebuilt in the cloud environment from the ground up.

We treated our SharePoint cloud migration as an opportunity to take stock of what we had and decide what we didn’t want to bring with us into the new age of SharePoint at Microsoft. We cleaned our data and retired unused sites based on which content and functions employees told us they regularly used and relied on.

“It’s effectively filtering, so you don’t migrate everything. You’re cleaning your house before you move,” says David Johnson, a principal product manager architect in Microsoft Digital. “You don’t move everything in your garage—you clean it out first. The easiest move is the one you don’t have to do.”

Cloud migration also presented fresh governance challenges for our team. Governance practices had to be established for this new environment that would allow for effective self-service across multiple sites.

Building governance around lifecycle management, attestation, ownership policies, and guarding against oversharing required a significant amount of effort from the team, but it was necessary to ensure a smooth transition from an on-premises tool to the cloud.

Site modernization: Reducing the need for customization

Around 2016, SharePoint rolled out what came to be known as SharePoint Modern. This new version was a game changer for our major portals, as it reduced the need for heavy, developer-driven customization and replaced it with powerful out-of-the-box page creation capabilities, responsive design, and improved accessibility. The product also eventually added seamless built-in integration with solutions like Microsoft Teams and OneDrive.

Less custom code meant we could upgrade faster and dramatically lower our development, support, and maintenance costs. But the best part was the improved user experience and better navigability of the new version. Before this, our IT team fielded numerous questions about SharePoint on a weekly basis. The more intuitive, user-friendly experience of modern SharePoint reduced the volume of inquiries and service requests drastically. Our internal users were happier, and so were we.

SharePoint in the age of agentic AI

We see SharePoint as a key “knowledge platform” for AI. It’s a critical enterprise-scale repository for our documents and data and other information that we use to power our global enterprise.

“Security through obscurity is dead. It’s the double-edged sword of semantic search.”

Thomas Snyder, principal service engineer, Microsoft Digital

As such, it’s one of our key “knowledge platforms,” locations where we store the information that is the lifeblood of our enterprise. And as our enterprise-scale repository for documents, data, and other information used to run our global multinational, it has become the launching point for many of our AI-powered experiences.

AI is only as effective as the quality of the data it can access, which is why we’ve prioritized governance best practices as we make this transition. With these new tools, we’ve had to overcome new challenges.  For example, in the early days of AI, the discovery of previously well-buried personal data is becoming a common occurrence.

“Security through obscurity is dead,” Snyder says. “It’s the double-edged sword of semantic search.”

Prioritizing good governance helps ensure agentic AI only has access to the data it’s permitted to use, avoiding accidental oversharing and related hallucinations.

As an AI-driven Frontier Firm, we’re empowering our non-technical users and engineering and development teams alike to begin building custom AI agents to drive innovation at Microsoft. Our teams can now use agents in SharePoint for tasks like creating applications, knowledge depositories, and sites, saving huge amounts of time and effort.

Many of these agents will eventually be available in Azure DevOps and GitHub, so we’re focused on helping SharePoint site owners put the appropriate data ownership and permissions in place to effectively manage and govern the data for use by agentic AI.

After 25 years, SharePoint remains a core part of IT operations across Microsoft. We look forward to growing alongside it as it continues to evolve and improve.

Key takeaways

These insights can help you mature and transform how you use SharePoint at your company:

• Self-service and good governance go together. Without solid guardrails for your SharePoint instance, your organization could contend with information sprawl and internal friction between departments.
• Cloud migration is a golden opportunity. Before you migrate from on-premises IT to the cloud, take the time to clean your data to avoid carrying technical debt and outdated information into the future.
• Out-of-the-box capabilities are your friend. Customization is useful, but too much of it can be unwieldy and expensive to maintain.
• Make data hygiene a priority. Poorly governed data can undermine users’ trust in AI, expose sensitive information, and delay widespread adoption.

Try it out

Explore how Microsoft SharePoint can help your team collaborate more effectively and be ready for the agentic AI future.

Related links

• Read how we keep our content fresh, findable, and governed with AI-powered SharePoint at Microsoft.
• Learn about how we’re handling Microsoft 365 Copilot governance issues internally in this guide.
• Discover ways to use SharePoint agents to surface knowledge and improve how employees find answers.
• Explore how we’re supercharging SharePoint sites with Microsoft 365 Copilot.

The post 25 Years of SharePoint at Microsoft: Our lessons learned as Customer Zero appeared first on Inside Track.