Our Microsoft Digital engineers saw a better way forward: a single intelligent workspace, powered by an AI agent that makes identifying problems, troubleshooting them, and sharing context much quicker and simpler.

What began as a side project, inspired by a hackathon, quickly grew into a cross-team initiative.

“People were passionate about this project,” says Payal Awasthi, a senior software engineer in Microsoft Digital, the company’s IT organization. “Whenever people had some free capacity, they were coming in and contributing to it.”

The tool, called Smart DRI Agent, now supports over 40 teams at Microsoft, delivering more than 7,800 AI-assisted interactions and nearly 6,000 proactive incident notifications. This has saved the company an estimated 600 engineering hours per month, with bigger gains projected in the future.

“It saves a lot of time on context switching,” says Bhupesh Guptha Muthiyalu, a principal engineering manager in Microsoft HR. “The DRIs have ready-made information in hand, and based on that they’re typically able to resolve the incident quickly.”

Bringing all incident info into one place

In Microsoft Digital, our engineers serve as designated responsible individuals, or DRIs, who oversee production scenarios on a rotating basis. Their responsibilities include investigating incidents, monitoring service health, reviewing security work, and responding to other operational issues—work that can be both time sensitive and stressful.

“Whenever a new incident comes in, a DRI might have to elevate a lot of production permissions before they can get any insight into it. That’s one of the reasons we wanted to build something that can bring all the information into one place.”

Payal Awasthi, senior software engineer, Microsoft Digital

Meanwhile, the information that our DRIs need to take action on is typically distributed across several different portals and dashboards, along with troubleshooting guides, SharePoint sites, OneNote notebooks, and other engineering documentation.

Finding and assembling that information takes a while. For engineers who are new to a service or take over an unfamiliar DRI rotation, it can take even longer, as they may have to seek out the right subject matter expert to understand the situation.

“Whenever a new incident comes in, a DRI might have to elevate a lot of production permissions before they can get any insight into it,” Awasthi says. “That’s one of the reasons we wanted to build something that can bring all the information into one place; you don’t have to spend a lot of time switching between portals and elevating permissions.”

In some cases, important context can get lost in the shuffle, which can bog down the process and make it harder for DRIs to take the necessary next steps to resolve an issue.

“We depend on DRIs to be very proactive, and monitor these services 24/7 to make sure that everything is running smoothly,” says Sudhakar Sadasivuni, a principal group engineering manager in Microsoft Digital. “As part of our company’s native AI transformation, our idea was to make live site monitoring more proactive than reactive. We thought, why not use AI to make these decisions more intelligent, so that when DRIs come into the live site situation they’re already well informed.”

“We created goals and a 30-60-90-day plan and started making it more generic, where any service could simply onboard and start using that intelligence. It’s been one of the most successful open-source projects I’ve ever seen internally.”

Sudhakar Sadasivuni, a principal group engineering manager, Microsoft Digital

Teams in Microsoft Digital and the Microsoft HR organization were exploring related ideas for helping their DRIs, although the solutions they were considering were not identical. Once the teams recognized that they were addressing the same underlying operational problem, they decided to join forces.

Engineers from the two organizations created the first iteration of the agent during a Microsoft hackathon. As the prototype developed, they decided to treat it as a more structured effort.

“Later, we realized this was something that we should seriously invest in,” Sadasivuni says. “So we did a reset: We created goals and a 30-60-90-day plan and started making it more generic, where any service could simply onboard and start using that intelligence. It’s been one of the most successful open-source projects I’ve ever seen internally.”

Fine-tuning the product

One particularly challenging part of developing the agent was taking a scattered system and making it more uniform.

“Some services respond in different ways, and the reports that DRIs generate during handoffs can differ,” Sadasivuni says. “As we started interviewing various DRI teams, the requirements were piling up. We struggled with that for two or three months; eventually, we made some design changes to make it more generic.”

The initial implementation included more hard-coded behavior, but the team later separated configuration from the core logic and allowed teams to supply templates for workflows, such as DRI handoff reporting.

“We leveraged the framework functionality, but we also built a lot of custom code to support good results and good navigation through the system,” Awasthi says.

The team used Microsoft Semantic Kernel as an orchestrator. Different operational domains, such as incident management and Service 360, use separate sets of functions. The orchestrator determines which functions to call in response to a request.

“It’s easy, and there’s no limit on the number of services that I can query. That’s one of the biggest advantages that this agent brings.”

Lakshmi Kothamasu, principal engineering manager, Microsoft Digital

For similar-incident retrieval, the solution indexes incident information in Azure AI Search. The team found that search indexing alone didn’t always return useful matches, so developers added custom logic to assess similarity and improve the results supplied to DRIs. 

“It’s easy, and there’s no limit on the number of services that I can query,” says Lakshmi Kothamasu, a principal engineering manager in Microsoft Digital. “That’s one of the biggest advantages that this agent brings.”

When an incident comes in, the agent automatically provides an analysis that includes suggested troubleshooting steps and historical context from similar issues in the past, which speeds up the resolution process.

“It will connect to your telemetry and get all the relevant traces, logs, and exceptions that happened in the last few minutes.”

Bhupesh Guptha Muthiyalu, principal engineering manager, Microsoft HR

Based on the incident details, title, description, and other data, the agent will search your troubleshooting guide, identify all the matching patterns, explain how to troubleshoot this issue, and give you needed context.

“It will connect to your telemetry and get all the relevant traces, logs, and exceptions that happened in the last few minutes,” Guptha Muthiyalu says.

It can also function proactively, such as delivering a summary first thing in the morning that identifies what an engineer needs to complete that day. All of the information is presented directly in Teams, helping it to seamlessly fit into engineers’ workflows.

Looking ahead: Agentic incident management

In future iterations, the team hopes to train the agent to actually take action and mitigate some incidents for the DRIs, keeping them in the loop and enabling them to sign off on the steps the agent takes.

For teams considering a similar project, the starting point is the DRI workflow itself. Identify where engineers spend time, where information is fragmented, and which repeated steps are strong candidates for assistance. Then, connect the workflow from detection and context gathering through to mitigation and continuous improvement, while keeping real people responsible for operational decisions.

“Without a strong live site culture, where the reliability and health of production services are a priority, this agent is of no use at all,” Sadasivuni says. “They go hand in hand; otherwise, it’s an unnecessary use of computing and artificial intelligence. This agent was designed with a single goal: to empower the human DRI. So, the more the DRI is demanding, the more the system will respond.”

End-to-end coverage is also key. DRIs should be able to turn to the agent anytime, at any stage for guidance, helping engineers to move faster and with more confidence. And with even more proactive measures in place, DRI work will only become more seamless in the future.

The post Automating engineering operations at Microsoft with a Smart DRI Agent appeared first on Inside Track.

• Introduction: How empowering employees to create agents generates value for your organization
• Chapter 1: Choosing the right path for agent creation
• Chapter 2: Empowering every employee with Agent Builder
• Chapter 3: Leveling up citizen developers with Microsoft Copilot Studio
• Chapter 4: Building enterprise AI solutions with Microsoft Foundry and pro-code tools
• Conclusion: Creating pathways for every type of agent builder

Generating value by empowering your employees to build agents

AI agents are an increasingly important way for organizations to scale knowledge, help their employees boost productivity, and automate business processes.

In Microsoft Digital, the company’s IT organization, we think of agents as more than tools that the company rolls out and employees adopt. They represent a new way of working, where employees have the power to create and modify their own AI tools to help them solve problems, streamline their work, and create value in their unique roles.

As our use of AI has matured, we’ve seen employees across the company identify opportunities to create agents that help them retrieve information, answer common questions, automate repetitive tasks, and reimagine workflows. Rather than limiting agent creation to developers, we’ve made agent-building capabilities available for every employee at Microsoft. Our goal is to enable the people closest to the work to build their own agentic solutions.

Meeting the needs of different builders across the organization

As we expanded agent adoption across Microsoft, we quickly discovered that not all employees need to build the same kinds of agents. A knowledge worker who wants to create a simple retrieval agent for a project team has very different requirements from a business unit building workflow automations or an engineering organization tasked with creating enterprise-scale agentic solutions.

In the course of this journey, we’ve faced a challenge that’s becoming common for many organizations: Equipping different groups of employees to build agents without forcing everyone into the same development model.

“Frontier transformation depends on empowering every employee to turn ideas into AI-powered solutions. This democratization of AI creation can unlock new levels of productivity, innovation, and business value.”

Mohit Chand, general manager, Corporate Functions Engineering, Microsoft Digital

We’ve learned that effective agent enablement is about matching the right tools to the right builders and scenarios:

• Some employees benefit from natural-language tools that allow them to build agents with little or no technical experience.
• Others need low-code environments that support more sophisticated workflows and integrations.
• Still other workers require pro-code platforms that provide the flexibility, extensibility, and governance needed for enterprise-scale solutions.

Creating pathways for every type of agent builder

Our approach has been to enable a spectrum of agent-building pathways that meet employees where they are. We focus on providing clear guidance, skilling resources, governance frameworks, and tool recommendations that help people move from ideas to working solutions with the appropriate level of complexity and oversight. Crucially, this approach helps us ensure innovation can scale responsibly as agent usage continues to grow.

“Frontier transformation depends on empowering every employee to turn ideas into AI-powered solutions,” says Mohit Chand, general manager of Corporate Functions Engineering in Microsoft Digital. “This democratization of AI creation can unlock new levels of productivity, innovation, and business value.”

In this IT playbook, we’ll share how we’ve approached agent enablement across Microsoft, how we think about different agent-building audiences and tools, and the lessons we’ve learned along the way. We believe these insights can act as a blueprint for your own strategy as you empower employees to build agents with confidence, regardless of their level of technical knowledge.

Chapter 1: Choosing the right path for agent creation

Laying the foundation for different builders to meet their needs with agents

As agent creation became more widespread at Microsoft, one question stood out: How could we help employees use the tool that’s best for the problem they’re trying to solve or the opportunity for innovation they’re trying to explore?

Early on in our journey, we observed a common pattern: Employees would often gravitate toward the most powerful and flexible tools available because they seemed like the safest choice. If a platform could handle every scenario, why not start there?

In practice, that approach often introduced unnecessary complexity. Some builders found themselves navigating security, privacy, and compliance requirements that far exceeded the scope of their projects, let alone their level of technical expertise. Others invested time learning advanced capabilities they ultimately never needed to use.

“The most successful agents often start with a practical business problem. Once builders see the results, they quickly discover new opportunities to automate and improve adjacent processes.”

Naveen Jangir, principal architect, Microsoft Digital

We’ve learned that enabling successful agent building depends on providing the right development path. The goal is to help employees innovate quickly with AI agents while applying the right level of governance and technical complexity. When employees start with a clear objective and work backwards from there, they tend to build faster, encounter fewer obstacles, and achieve stronger results.

“The most successful agents often start with a practical business problem,” says Naveen Jangir, a principal architect in Microsoft Digital. “Once builders see the results, they quickly discover new opportunities to automate and improve adjacent processes.”

We also learned that choosing the wrong tool can have unintended consequences. Employees may run into compliance reviews they weren’t expecting. Projects might slow down as builders try to understand governance processes.

Choosing the tool that isn’t the right fit for a builder’s scenario might also direct them to the wrong model for their agent. In some cases, that could lead to using something more complex and expensive instead of a lower-cost model that’s ideal for a simpler scenario. More advanced tools often assume more advanced models that aren’t inherently necessary for every task.

In some cases, builders abandon promising ideas before they deliver value. The result is losing out on innovation, not because an idea wasn’t worthwhile, but because the path to implementation became more difficult than necessary.

To avoid these situations, we encourage builders to start by considering their problem scenario, rather than the tool itself. When evaluating an idea, we ask employees to think through a few key questions:

• What business outcome are they intending to achieve?
• What data does the agent need to access?
• Is that data personal, team-based, or enterprise-wide?
• Is the agent retrieving information, taking actions, or operating autonomously?
• How broadly do they intend to share the agent?

Understanding the needs of different builders

Roughly speaking, we describe agents as belonging to three categories, ranging from simpler and lower risk to more complex and more reliant on sensitive or external data.

As AI maturity at Microsoft has advanced, three primary sets of needs and cohorts of agent builders have emerged, based on user scenarios, needs, and technical capability.

1. Simple retrieval agents for any employee: Agent Builder in Microsoft 365 Copilot

The first cohort consists of employees solving everyday productivity challenges. These builders need agents that retrieve information, summarize content, answer questions, evaluate inputs against a declared rubric to provide feedback, and help them work more efficiently with existing knowledge sources.

For these scenarios, Agent Builder in Microsoft 365 Copilot provides an accessible starting point. Employees can use natural language to create lightweight retrieval agents grounded in their Microsoft 365 knowledge and data. It lets employees begin creating value without requiring extensive technical skills or development experience.

Many employees discover that this level of functionality meets their needs. By starting here, they can experiment quickly without introducing unnecessary complexity.

2. Citizen development without DevOps overhead: Microsoft Copilot Studio

Some employees want agents to do more than retrieve information. These builders need tools that can connect to business systems, automate workflows, orchestrate processes, and take actions on behalf of users.

Copilot Studio serves as an important middle ground for agent development, supporting retrieval, task, and autonomous agent scenarios while providing access to a broad ecosystem of connectors and integrations. It combines low-code development with broader connector capabilities, workflow automation, built-in telemetry, and evaluation tools.

These features allow employees to create more sophisticated business solutions without needing to be professional software developers.

3. Professionally developed agents that meet organizational needs: Microsoft Foundry and pro-code tools

The most complex and flexible tools are primarily the domain of professional developers and engineering teams building line-of-business or enterprise-scale solutions. These builders need architectural control, advanced integrations, specialized security requirements, and custom orchestration capabilities. For these scenarios, Microsoft Foundry and other pro-code pathways like Microsoft 365 Agents Toolkit provide the flexibility they need to design highly customized systems.

But they also introduce additional responsibility. Teams operating at this level assume ownership for architecture, compliance, privacy, security reviews, operational monitoring, and lifecycle management.

The distinction is important. Advanced development platforms create tremendous possibilities, but they’re most effective when a scenario truly requires that level of control.

“Get people excited about agents first, and then educate them. Encourage people to become builders and get their hands dirty through advocacy and education.”

Myron Wan, principal group product manager, Microsoft Digital

These aren’t rigid boundaries, but they’re helpful in understanding what each agent creation tool can accomplish. We’ve distilled our perspective into the following list of characteristics of different agent builders and of the creation platforms most appropriate for their needs:

Whatever your potential builder’s level of expertise or needs, we’ve discovered that encouraging experimentation while providing learning opportunities is key.

“Get people excited about agents first, and then educate them,” says Myron Wan, a principal group product manager in Microsoft Digital. “Encourage people to become builders and get their hands dirty through advocacy and education.”

What IT organizations should consider

In Microsoft Digital, our objective is to enable innovation while maintaining appropriate safeguards.

Good agentic architecture starts with data

Whenever we’re considering any agent development path, data is at the center of our thinking. Where data resides, how agents access it, who can use it, and the actions agents will execute with it form the foundation of every agent-building solution. In many cases, the data itself determines the appropriate platform.

We take a “self-service with guardrails” approach to our productivity estate, which means we give employees the ability to create new workspaces across their Microsoft 365 applications while securing assets by default and expanding access based on employee needs. The same is true for agent creation. We rely on well-established governance in the form of sensitivity labels, established software development lifecycle procedures, and risk-based app and agent management policies that trigger reviews when we detect risk.

We also frame governance in terms of who owns the risk: the platform itself, the administrator, or the organization.

• Agent Builder operates according to intrinsic governance, where the platform itself is responsible for managing risk. Users build agents within existing Microsoft 365 boundaries, which include built-in guardrails that simplify governance for lower-risk scenarios. Builders can create meaningful experiences while staying within well-understood security and compliance frameworks.
• Copilot Studio follows a configurable governance model where the administrator owns the risk. It introduces greater flexibility through workflows, actions, and connectors. That flexibility creates powerful opportunities, but it also requires thoughtful governance around how data moves between systems and which connectors are approved for use.
• Microsoft Foundry features explicit governance, where the organization owns the risk. That need arises from more complex capabilities like model selection, custom orchestration, architectural design capabilities, and more.

Regardless of the agent-creation platform your employees use, investing in data classification, labeling, and governance will put you in a better position to scale safely.

AI-ready data is especially crucial for more advanced agent creation tools like Foundry. It ensures secure access to the high-quality, accurate information employees need when they need it.

AI-ready data rests on five pillars:

• Accelerating time to value through managing powerful AI models
• Data democratization to promote informed decision-making, innovation, and continuous learning
• Connectivity among subject matter experts across domains and regulatory divisions to accelerate innovation
• Quality and governance to maintain data accuracy, reliability, and compliance
• Unification, delivering accessible and scalable infrastructure by breaking down silos

Balancing risk and innovation

A risk-based approach informs one of our primary guiding principles: reviews should scale with risk.

Thanks to the guardrails we’ve established, we don’t subject a personal productivity agent created in Agent Builder to the same review process as an autonomous agent operating across enterprise systems. The result is a matrixed model of agent governance that matches the need for oversight and review to the level of risk, access, or action-taking ability an agent presents.

This principle helps employees experiment early, validate ideas quickly, and gain confidence as builders. It also helps us avoid creating unnecessary barriers that can discourage adoption before builders can realize value.

We also learned that excessive control isn’t necessarily a safe default; it’s another category of risk. Over-restriction doesn’t eliminate risk, but redirects it to shadow AI, where we lose both productivity and compliance visibility.

Before setting your employees free to create, speak with stakeholders from IT, security, privacy, legal, compliance, data, and other teams responsible for policy and protection. Together, these groups can help you work toward a cohesive but flexible approach to agents and the risks they present.

Throughout this process, it’s important to stay curious about the processes builders will face before, during, and after creating their agents. Administrators should ask several key questions:

• What is the origin of this process, how relevant is it for agent creation, and which products are affected?
• What can we do to remove friction and allow safer innovation?
• Where can we get involved with processes when agents present more risk, while allowing agents that meet our standards to get built and shared broadly, with minimum friction?

Adoption through intention

We’ve invested a lot of time, strategy, and effort into adoption efforts across Microsoft. First, builders can use self-serve tools to meet their own needs. Builders Central is our internal SharePoint page dedicated to supporting agent builders at Microsoft. Crucially, it features a section that helps people understand which agent-creation tool might be best for them, along with instructions and factors to consider throughout the process.

AskMica (Ask Microsoft Intelligent Compliance Agent) is our IT agent built on top of this content. It walks makers through the decision-making process and answers questions about what tool to use, what environment to choose, how to get exceptions for security, privacy, sensitive data access, and more.

AI Skills Navigator, a program now available to customers, extends AI learning by allowing leaders to create structured paths that guide teams toward specific outcomes, such as becoming AI literate, managing agents in the enterprise, or building expertise in agent development. In Microsoft Digital, we’ve tailored AI Skills Navigator content to differentiate learning for our IT employees.

This is an essential piece of the equation, because IT teams are so integral to AI implementation efforts. As you promote AI more widely, it’s important to ensure your own IT team has the skills they need to support this technology.

Since we’ve put these efforts in place at Microsoft, the number of active makers has grown roughly 10 times, from around 2,000 to 20,000 a month. We now have about 150,000 personal development environments under governance, and we drove measured maker friction down from roughly 50% to 5%.

Letting outcomes drive platform selection

We encourage teams to focus on business outcomes first. Before selecting a platform, builders should identify the process they want to improve, define success criteria, and determine whether an agent is the best solution. We have an entire SharePoint site dedicated to helping employees navigate agent creation, including decisions around which agent tool to choose.

In some cases, a traditional workflow, existing application, or agent that someone else has already created may be the better choice. But if an employee or team sees a genuine need, starting small allows them to validate assumptions, measure impact, and expand capabilities over time.

As you consider ways to empower your own employees to create agents of their own, the lessons we’ve learned can form a foundation for creating policy, enabling workers, and protecting your organization.

Chapter 2: Empowering every employee with Agent Builder

Giving employees a starting point for agent creation

As agents began to show their potential for significant impact on day-to-day work, we wanted employees across the organization to participate in creating them—not just developers and technical specialists. We found that the people closest to a business problem were often the ones best positioned to identify opportunities for AI to help. That insight helped shape our approach to Agent Builder in Microsoft 365 Copilot.

“Everyone at Microsoft is a potential builder. The key is giving people opportunities to learn through hands-on experience, because reading about AI is very different from building with it. Agent Builder provides a safe environment where they can do just that.”

Tom Heath, change management lead, Microsoft Digital

Agent Builder provides an accessible entry point into agent creation. Employees can create simple retrieval agents using natural language and ground them in approved knowledge sources, including SharePoint sites, websites, and Microsoft Graph connectors. The experience allows users to create agents that retrieve information, summarize content, answer questions, and help employees navigate organizational knowledge without requiring software development expertise.

The audience for Agent Builder is intentionally broad. It serves knowledge workers, subject matter experts, project teams, and employees looking to solve specific productivity challenges without learning advanced development tools. It also provides an important first step for employees who are new to building AI solutions.

“Everyone at Microsoft is a potential builder,” says Tom Heath, a change management lead in Microsoft Digital. “The key is giving people opportunities to learn through hands-on experience, because reading about AI is very different from building with it. Agent Builder provides a safe environment where they can do just that.”

Understanding Agent Builder’s place in the agent journey

Agent creation should scale with the complexity of the problem an employee wants to solve. Agent Builder creates agents devoted to knowledge-centric experiences: finding information, accessing expertise, navigating documentation, and surfacing insights from existing content.

We encourage employees to start with a simple question: Does this agent primarily need to help people find, understand, use, interpret, or validate information? If the answer is yes, Agent Builder is usually the right starting point.

Common use cases include team knowledge hubs, readiness and adoption resources, project-specific information assistants, meeting preparation support, and product or policy guidance. These scenarios allow employees to create immediate value without taking on unnecessary complexity.

As they experimented with agent building tools, many employees assumed they needed a more advanced platform than they actually did. In practice, we’ve observed that most use cases are knowledge-centric, and employees can address them effectively with Agent Builder.

“Agents are only as good as the data behind them. Strong data governance and protection practices create the foundation for successful agent experiences.”

Ken Auguillard, principal program manager, Power Platform

At the same time, it’s important to understand where the tool’s boundaries lie. Organizations should consider moving to Microsoft Copilot Studio when requirements expand beyond knowledge retrieval and begin to include higher-order capabilities:

• Accessing data outside Microsoft 365
• Integrating with external business applications
• Automating business processes
• Triggering workflows and actions
• Including advanced telemetry and evaluation capabilities

This distinction helps employees select the right platform without overwhelming them with technical decisions: Agent Builder helps people interact with information, while Copilot Studio helps them take action on it.

The Customer Zero story: Implementing Agent Builder internally at Microsoft

Because Agent Builder is intentionally simple, most of our work enabling it within Microsoft has been organizational rather than technical.

Skilling and education

Employees understand Microsoft 365 Copilot, but they’re often less familiar with the role agents can play in their daily work. Successful adoption means helping people understand when prompting alone is sufficient and when an agent they build can deliver more value. Adoption initiatives like Agent Launchpad that feature hands-on ideation and gamified building activities have helped our employees make those leaps.

Agent sprawl

As adoption grows, organizations need visibility into what agents exist, who owns them, and whether they remain relevant over time. Ownership, automation, explicit lifecycle policy, and governance become increasingly important for monitoring the proliferation of agents. For example, we use a 60-day inactivity threshold that triggers alerts and automated cleanup. In this context, Microsoft Agent 365, the control plane for agents, is emerging as a powerful tool for observability, management, tracking, and security.

Data readiness

Agent Builder surfaces information users can already access, which means the quality of an agent experience depends heavily on the quality of the underlying data. We saw this principle in action repeatedly during our adoption efforts. Well organized, properly governed content consistently led to stronger agent experiences. Meanwhile, poorly maintained data limits an agent’s usefulness, regardless of how well it was designed. The systems we’ve put in place for governing agents provide the necessary guardrails for this level of agent.

“Agents are only as good as the data behind them,” says Ken Auguillard, a principal program manager in the Power Platform product group. “Strong data governance and protection practices create the foundation for successful agent experiences.”

We also found that many employees wanted agents to perform actions, automate workflows, or orchestrate processes across systems. Those are valuable scenarios, but they sit outside the scope of Agent Builder. Helping employees understand boundaries reduced frustration and created clearer pathways into Copilot Studio when additional functionality was needed.

Enabling Agent Builder at Microsoft

As adoption accelerated, our focus shifted from simply making Agent Builder available to helping employees use it successfully.

It may seem elementary, but people need to understand why they may want to create an agent instead of simply using Copilot. They do that by learning how agents apply AI capabilities more specifically than a broad-based assistant. Then, they need help knowing how to make their idea a reality.

We invested heavily in hands-on learning experiences. Employees learned fastest when they could experiment with real scenarios, test ideas, and refine agents in the context of their own work. Workshops, guided exercises, office hours, and peer-to-peer sharing all played important roles in helping employees build confidence. Real examples from early adopters were especially useful for encouraging people to take their first steps.

Our priority was making agent creation approachable, so we positioned Agent Builder as a capability available to everyone, not just technical users. We then encouraged employees to start with a business problem, build agents with a clear purpose, and focus on measurable outcomes rather than experimentation for its own sake.

We also emphasized thoughtful agent design. We found that employees who spent more time defining an agent’s purpose, instructions, and knowledge sources produced significantly better outcomes.

“Be direct, be descriptive,” Heath says. “Spending more time in the ‘Describe’ interface typically means spending less time troubleshooting later.”

Because Agent Builder benefited from the governance foundation already present in Microsoft 365, we had already embedded identity controls, permissions models, data loss prevention policies, sensitivity labels, and compliance protections within the environment. As a result, we didn’t need to invest too heavily in building employees’ understanding of governance structures. Instead, we could focus more on helping them understand how to use the platform effectively.

As a result, much of our enablement work centered on communication, celebrating wins, peer-led support, and helping employees understand where Agent Builder fit within the broader agent ecosystem.

For us, Agent Builder became an important foundation for employee agent creation. It provides a low-friction way for our employees to build, learn, and solve business problems quickly. While many builders remain within the platform long-term, others use it as a stepping stone to more advanced tools. In both cases, it helps create a culture where building with AI is accessible to everyone.

As you look for ways to empower a workforce of agent builders at your organization, consider ways that our efforts can provide a framework for secure and empowering experiences for employees who want to solve their day-to-day business challenges.

Chapter 3: Leveling up citizen developers with Microsoft Copilot Studio

A bridge between simple and advanced agent development

Plenty of agentic scenarios require more than knowledge retrieval but less than a fully custom agentic application. At Microsoft, we wanted employees and teams to have the opportunity to connect their agents with business systems, automate workflows, retrieve information from external sources, and take action on behalf of users without necessarily demanding a full-featured DevOps process complete with reviews. We also wanted to provide greater capabilities while still allowing for a lightweight coding approach that accommodates citizen developers.

Copilot Studio is a low-code platform for creating agents that can automate processes, connect to enterprise systems, and extend Microsoft 365 Copilot with organizational data and business workflows. It supports both custom agent creation and agentic automations while remaining accessible to users without extensive software development experience. Everyone at the company has the freedom to create their own agents in their own Copilot Studio environment.

Unlike Agent Builder, which focuses primarily on knowledge-based experiences, Copilot Studio gives builders the tools to sync up agents to external systems through approved connectors, workflows, skills, and actions. These capabilities allow agents to move beyond answering questions and begin supporting real business processes.

At Microsoft, we’ve identified several primary builder cohorts for Copilot Studio:

• Citizen developers and makers who want to build beyond knowledge retrieval
• Business teams that seek to automate departmental processes
• Power Platform users who need to extend existing workflows
• Technical teams that want low-code flexibility instead of moving to pro-code development

Understanding Copilot Studio’s place in the agent creation journey

One of the most important lessons we learned is that not every scenario requires Copilot Studio. In the simplest terms, agents created using this platform are more suited for organizational or team-level tools, or for individuals who need more complexity than Agent Builder can accommodate.

Copilot Studio becomes the natural next step when teams need more capabilities or connections:

• Access to data that resides outside Microsoft 365
• Connectors that provide access to external business systems
• Workflow automation
• Triggered or autonomous behaviors
• Agents that perform actions rather than simply retrieving information
• Broader publishing and sharing options

Within Microsoft, we often describe the progression between platforms as moving from knowledge to action. A retrieval agent might answer questions about policies or project documentation. A task agent built in Copilot Studio can retrieve information from multiple systems, generate reports, update records, trigger workflows, and communicate with users based on business events.

“Once builders need data beyond Microsoft 365, connectors become a critical part of the solution,” says Aisha Hasan, a principal product manager in Microsoft Digital. “Copilot Studio is often the next step, because it lets teams combine enterprise data, workflows, and actions in a way that scales with business complexity.”

Most employees only have access to a subset of approved connectors that Microsoft Digital and our Office of the Chief Information Security Officer (CISO) govern. That helps us enable the Copilot Studio experience for all employees while limiting the most advanced capabilities to qualified engineers.

Copilot Studio may not be ideal for all scenarios, which is why we have pro-code alternatives. But many business processes never require that level of complexity. We’ve consistently found that Copilot Studio can support a broad range of organizational and team-level solutions before additional development investment becomes necessary.

---

What our experts say:

“We focus on helping builders understand the risk profile of their agents as early as possible. By providing guidance during development, we can reduce friction, increase accountability, and move solutions through the process more efficiently.”

Aisha Hasan, principal product manager, Microsoft Digital

“Copilot Studio provides far more visibility into how agents perform over time. The evaluation and telemetry capabilities help builders improve quality, identify gaps, and build confidence that agents are delivering meaningful business value.”

Jean Hsu, product designer, Copilot Studio

---

The Customer Zero story: Implementing Copilot Studio internally at Microsoft

Our experience implementing Copilot Studio has helped us identify some of the key areas to carefully consider while enabling Copilot Studio at your organization.

Managing governance without slowing innovation

As capabilities increase, governance naturally becomes more important.

The reality is straightforward. When agents connect to additional data sources, integrate with external systems, and perform actions on behalf of users, organizations need appropriate safeguards.

At the outset of our journey, we already had robust systems in place for securing custom connectors, and Microsoft 365’s built-in governance capabilities ensure Microsoft 365 agents respect our labeling taxonomy and the policies it articulates. We have the power to introduce sharing limits that restrict how widely builders can distribute their agents depending on their purpose and scope.

“We focus on helping builders understand the risk profile of their agents as early as possible,” Hasan says. “By providing guidance during development, we can reduce friction, increase accountability, and move solutions through the process more efficiently.”

Three agents help us do this work:

The Risk-O-Meter

Auto-classifies submissions as green, yellow, or red based on their risk profile, then auto-approves, auto-declines, or routes them to the relevant reviewer

The Action-O-Meter

Applies the same logic to new connectors and MCP servers

The Friction Meter

Surfaces maker pain as a first-class metric

For simpler self-service agents that individual employees create and use, we define policies at the Copilot Studio environment level. Tenant administrators and partners on the security team apply data loss prevention policies to configure what individual employees can and can’t do. At this level, everyone in the company has the same configuration and tools available, and automation largely handles agent reviews and assessments based on pre-configured settings.

For more wide-reaching apps that operate at the line-of-business level or that we might publish enterprise-wide, we need to apply greater rigor. Discipline-specific professionals in security, privacy, and other spaces conduct robust reviews to ensure internal teams meet our high standards.

Governance expands through bounded, risk-based arguments, not a general philosophy of openness. Internally at Microsoft, it was more than just flipping a switch. We negotiated incrementally with the Office of the CISO, then scoped sharing. That supported the CISO’s need to only approve precise, bounded requests with measurable controls.

Telemetry and evaluation matter

As agents become more sophisticated, understanding performance is increasingly important.

Observability is one area where Copilot Studio provides significant value. Agent administrators gain access to telemetry, analytics, evaluation capabilities, and performance insights that help them understand how their organization is using agents and where improvements are necessary.

We’ve found that these features become particularly important as agents move beyond personal productivity and begin supporting larger groups of users. Data-driven evaluation helps teams improve outputs, validate business outcomes, and build trust in agent experiences.

“Copilot Studio provides far more visibility into how agents perform over time,” says Jean Hsu, a product designer for Copilot Studio. “The evaluation and telemetry capabilities help builders improve quality, identify gaps, and build confidence that agents are delivering meaningful business value.”

Consider both areas carefully as you put Copilot Studio in the hands of your employees and teams. Because it straddles both simple and more complex agents, you’ll need to consider the implications of flexibility and how to maintain proper oversight and governance.

Empowering employees to use Copilot Studio at Microsoft

As adoption grew, we worked to balance empowerment and responsibility. Our Builders Central SharePoint page provides guidance on prerequisites, agent creation environments, types of agents people can build, and more.

It’s worth noting that builders who are already familiar with Power Platform concepts like environments, connectors, and data loss prevention policies will have an advantage when they use Copilot Studio, but they typically won’t need deep technical expertise.

More broadly, we’ve implemented support systems to help our employees and teams create agents safely and effectively, without a massive knowledge burden. They include:

• Making a wide variety of approved connectors available by default so builders can move quickly.
• Clearly defining when builders should transition from self-service to IT-guided development.
• Providing automated guidance during development rather than waiting until publication.
• Using AI-assisted compliance resources to keep builders working in context.
• Investing in maker education around connectors, data governance, and Power Platform fundamentals.
• Encouraging teams to validate business outcomes before scaling solutions broadly.
• Creating dedicated pathways for both self-service and enterprise scenarios.

Our experience showed that user education is just as important as technical controls. Builders need help understanding what they’re creating, what data their agents access, and what responsibilities accompany increasing capability.

We often use this statement to guide our work internally: Build compliantly, use intelligently.

As you explore ways to help employees create more advanced and capable AI agents, our experience can provide an example of how low-code platforms can enable sophisticated business solutions without requiring every scenario to become a large-scale software development effort.

Chapter 4: Building enterprise AI solutions with Microsoft Foundry and pro-code tools

Applying software development practices to agent creation

Some business challenges require capabilities beyond the reach of low-code development. Teams need to build solutions that can operate across complex business processes. At Microsoft, these scenarios made it necessary to cultivate a professional developer practice for building agents centered around pro-code tools, especially Microsoft Foundry. It provides a flexible environment for building sophisticated AI solutions using a broad catalog of foundation models, evaluation frameworks, orchestration tools, enterprise AI services, and unique dashboard experiences.

Foundry empowers teams to compare and evaluate models, fine-tune them for domain-specific scenarios, integrate large volumes of enterprise data, orchestrate multiple agents, build custom agentic applications, and monitor performance over time. It also allows builders to combine AI capabilities with enterprise architecture patterns, security controls, observability tools, and operational workflows.

“Model selection is one of the most important decisions in enterprise AI. Different model families excel at different tasks, and understanding those tradeoffs helps teams build solutions that align with business goals while minimizing spend and maximizing ROI.”

Michael Leung, senior software engineer, Microsoft Digital

Microsoft 365 Agents Toolkit provides a simplified creation path for pro-code builders. Using Visual Studio Code, developers can create agents grounded in multiple data sources, integrated with APIs, enhanced through adaptive cards, and customized through instructions, plug-ins, and manifests. The toolkit enables developers to build and deploy role-specific and task-oriented agents without creating extensive back-end services from scratch.

The primary audience for Foundry and Agents Toolkit includes software engineers, enterprise architects, IT solution owners, and advanced AI builders responsible for delivering production-grade capabilities at organizational scale.

“Model selection is one of the most important decisions in enterprise AI,” says Michael Leung, a senior software engineer in Microsoft Digital. “Different model families excel at different tasks, and understanding those tradeoffs helps teams build solutions that align with business goals while minimizing spend and maximizing ROI.”

Understanding when Microsoft Foundry and pro-code tools are right for the job

One of the most important lessons we learned is that the right platform depends on the problem we want to solve. Not every solution requires pro-code development.

In many cases, Copilot Studio provides more than enough functionality, even for agents meant to serve enterprise needs. Teams can create agents that connect to business systems, automate workflows, retrieve external information, and support business processes without requiring custom engineering. Copilot Studio supports knowledge retrieval, actions, autonomous behaviors, and extensive connector ecosystems.

Employees should consider moving to Foundry or other pro-code tools when they require greater technical depth to accomplish the following goals:

• Fine-tune foundation models using domain-specific data
• Compare and evaluate multiple model families
• Build custom multi-agent orchestration frameworks
• Implement advanced observability and evaluation pipelines
• Develop autonomous systems that operate across multiple enterprise services
• Integrate custom APIs, services, or proprietary architectures
• Build solutions that require extensive engineering control and customization

The distinction between different agent-builder tools often comes down to three dimensions:

• Low-code versus pro-code requirements
• Solution complexity and organizational maturity
• Short-term delivery goals versus long-term platform strategy

Don’t select Foundry simply because it is the most powerful option. Instead, start with the simplest platform that supports your business needs. That accelerates deployment and adoption while minimizing cost and operational overhead.

---

What our experts say:

“Foundry helps us bring together data, expertise, and capabilities that often exist across separate teams. Many enterprise AI challenges are collaboration challenges, and the platform gives us a way to break down those silos.”

Naval Tripathi, principal software engineering manager, Microsoft Digital

“Enterprise AI depends on data access and integration. The technology is powerful, but success ultimately comes from ensuring models have access to trustworthy, well-governed information.”

Shweta Mallurwar, senior software engineer, Microsoft Digital

---

Enabling enterprise AI development at Microsoft

At Microsoft, our approach focuses on helping teams build responsibly while maintaining flexibility for innovation.

As organizations expand beyond information retrieval, complexity increases. AI solutions begin interacting with multiple data sources, business systems, APIs, and operational workflows. Governance, architecture, and engineering practices become increasingly important.

“Foundry helps us bring together data, expertise, and capabilities that often exist across separate teams,” says Naval Tripathi, a principal software engineering manager in Microsoft Digital. “Many enterprise AI challenges are collaboration challenges, and the platform gives us a way to break down those silos.”

Several principles guide how we enable professional developers working with agents:

• Start with clearly defined business outcomes before selecting architecture.
• Align development approaches with the complexity of the scenario.
• Involve domain experts early when designing AI solutions.
• Establish evaluation frameworks before deploying agents at scale.
• Build governance and compliance requirements directly into development workflows.
• Use human-in-the-loop models when introducing autonomous decision-making.

This approach helps teams focus on solving problems, rather than pursuing technology for its own sake.

The Customer Zero story: Implementing Microsoft Foundry internally

While Foundry enables powerful capabilities, it also introduces new areas for oversight. In Microsoft Digital, we play an integral role helping teams to create agents responsibly and effectively.

Security and compliance

Data integration and retrieval quality

Evaluation and continuous improvement

Microsoft Foundry and other pro-code agent creation tools help developers bring high-value opportunities to life through agentic AI. By following our approach to enablement, management, and governance, you have a solid starting point for unlocking these capabilities in your own organization.

Conclusion: Creating pathways for every type of agent builder

As we’ve advanced our Frontier Transformation journey, we’ve learned that successful agent adoption is not about choosing a single tool or creating a single development model. The main goal is to give employees the right pathways to solve problems at the level of complexity their scenarios require.

“The future of agentic AI depends on giving people the freedom to create while providing the structure they need to do so responsibly. When organizations establish clear pathways, strong governance, and the right enablement support, they can empower every employee to become a builder and accelerate innovation at scale.”

Stephan Kerametlian, senior director, Microsoft Digital

At Microsoft, we’ve worked to create an ecosystem where every employee can participate in agent creation.

• Some begin with Agent Builder, creating retrieval agents grounded in trusted organizational knowledge.
• Others expand into Copilot Studio to automate workflows, connect systems, and support business processes.
• Professional developers can build sophisticated enterprise solutions with Microsoft Foundry and other pro-code tools.

Each pathway serves a different audience, but they all share the common goal of empowering employees to turn ideas into innovation.

Throughout this guide, we’ve emphasized a principle that has shaped our own approach: Start with the business problem, not the technology, then choose the simplest tool to achieve your goal. When employees focus first on the outcome they’re trying to achieve, they’re in a better position to select the right platform, apply the appropriate level of governance, and create solutions that deliver measurable impact. We’ve found that this approach not only reduces cost but also accelerates adoption and builds confidence as employees move from simple use cases to more advanced scenarios.

Just as importantly, we’ve learned that agent enablement requires more than providing access to tools. Success depends on creating an environment where employees understand when to use each platform, how to build responsibly, and where to find support when they need it. Hands-on learning, strong data governance, clear guidance, and risk-based oversight have all played important roles in helping us scale agent creation while maintaining trust.

As agents become more capable, governance continues to evolve alongside them. Our goal is never to slow innovation. Instead, we’ve focused on creating guardrails that help employees build safely and confidently. Whether someone is creating a personal productivity agent or developing an enterprise-scale solution, the same foundational roadmap applies: Experiment, govern, scale, and optimize. All along, keep business outcomes at the center of the effort.

The AI-native organization of the future isn’t one where IT says yes to everything or no to everything. It’s one where governance is intelligent enough to know the difference and fast enough to act at machine speed.

“The future of agentic AI depends on giving people the freedom to create while providing the structure they need to do so responsibly,” says Stephan Kerametlian, a senior director for Microsoft Digital. “When organizations establish clear pathways, strong governance, and the right enablement support, they can empower every employee to become a builder and accelerate innovation at scale.”

Our experience has shown that there is no single destination in the agent journey. Employees will continue discovering new opportunities to automate work, scale expertise, and solve business challenges.

New capabilities, tools, and methods of building will emerge over time. What matters most is creating a framework that allows employees to begin where they are today and grow as their needs evolve.

As your organization develops its own approach to agent creation, we hope the lessons we’ve learned and shared can help you build a strategy that balances empowerment with oversight, innovation with governance, and experimentation with long-term value. By creating pathways for every type of builder, you can unlock the collective creativity of your workforce and help transform great ideas into lasting business impact.

The post Our Customer Zero guide: Enabling agent creation across Microsoft 365 Copilot, Copilot Studio, and Foundry appeared first on Inside Track.

Across Microsoft, our researchers, engineers, and product teams are building new models, agent frameworks, benchmarks, applications, and research projects at a steady pace. But even when innovative work exists, it has limited impact if people can’t find it, understand it, or put it to use.

That challenge inspired the transformation of our Microsoft Foundry Labs website.

Originally launched as a simple online catalog of AI innovations across Microsoft, Foundry Labs gave teams a place to showcase their research projects, models, and experiments.

But as the volume of innovations increased, the experience became difficult to navigate.

In response, principal product manager Saumil Shrivastava brought together a small cross-functional team of three—a product manager, a marketer, and an engineer—to rebuild the site. Along the way, they discovered something: Modern AI tools could fundamentally change how digital products are designed, prototyped, and delivered.

The team used AI throughout the development process to move from concept to production in approximately three months. The result was a new Foundry Labs experience that helps customers discover innovations across Microsoft while serving as an example of AI-assisted product development in practice.

“The whole purpose of Foundry Labs is to bridge the gap between Microsoft’s latest AI innovations and the people building with them, turning breakthroughs into tools you can explore, test, and build with today.”

Gulsimo Osimi, technical program manager, Microsoft Foundry

Solving the discoverability problem

The mission of Foundry Labs has remained consistent since its creation: Provide a destination where our teams can showcase AI innovations and help people learn about emerging technologies. These innovations come from organizations including Microsoft Research, Microsoft AI, Microsoft Planetary Computer, and other Microsoft teams and collaborators.

But the original site had been designed when the catalog was much smaller.

“When we had 20 innovations, it was pretty reasonable to scroll and click on each innovation,” says Gulsimo Osimi, a technical program manager at Microsoft and member of the three-person site build team, alongside Pratyansh Agrawal, a software engineer, and Patrick Widjaja, a senior product marketing manager. “As the number of projects grew, we wanted the user experience to provide the option to filter by innovation, domains, status, capability, or simply browse with images that help visualize what the innovation is about.”

The challenge was compounded by the pace of AI innovation itself.

“So many teams have lots of AI innovation happening, and staying on top of it is really hard,” Osimi says. “The whole purpose of Foundry Labs is to bridge the gap between Microsoft’s latest AI innovations and the people building with them, turning breakthroughs and experiments into tools you can explore, test, and build with today.”

From traditional specs to a working prototype

The project began with a traditional product management process. Shrivastava set the broader Foundry Labs product vision and strategy, and Osimi translated that direction into a detailed, 32-page specification for the new site experience. But as the document grew, the team realized it wasn’t the ideal way to communicate the vision. Osimi began experimenting with AI-assisted prototyping.

Using AI development tools, Osimi rapidly transformed product concepts into interactive experiences. The process became highly iterative: Specification informed prototype development, and the prototype informed revisions to the specs.

The resulting prototype helped stakeholders understand the vision much more quickly than a document alone.

As the prototype gained visibility, the team presented it at a CoreAI demo fair, where it attracted attention from stakeholders and leadership. That validation helped secure support from engineering and marketing partners, accelerating the site rebuild.

“We’re able to take the project from a sketch to a prototype and then to a full website in only a month.”

Patrick Widjaja, senior product marketing manager, Microsoft Foundry

Three people, multiple disciplines, supported by AI

A key aspect of the project was its deliberately small team. The initiative brought together expertise from product, marketing, and engineering, with AI tools helping each discipline contribute in new ways.

Shrivastava created the broader strategy and brought together the cross-functional team. Osimi led detailed product requirements, user experience design, and AI-assisted prototyping; Widjaja focused on brand identity, community experiences, content strategy, and site storytelling; and Agrawal transformed the prototype into a production-ready experience.

“We used AI extensively in different ways,” Widjaja says. “Gulsimo, from the product side, used it to prototype the website, and I used it to make all of the branding, design, copy, and images. We were able to take the project from a sketch to a prototype and then to a full website in only a month.”

The team’s approach highlighted how AI could support different stages of the development lifecycle.

Building an AI-assisted development workflow

The development process followed a repeatable pattern: receive intent, inspect the codebase, plan changes, create isolated branches, implement functionality, validate outcomes, and merge approved work.

“Microsoft is producing extraordinary AI innovation across research and product teams, but breakthroughs create value only when customers can discover, understand, and put them to use. Our strategy for Foundry Labs is to create a shared path from emerging innovation to real-world impact—giving teams a way to bring promising work forward, learn from customer engagement, and use those insights to accelerate the journey from research into practical use.”

Saumil Shrivastava, principal product manager, Microsoft Foundry

AI-assisted workflows were used to help deliver features across the site, including:

• Interactive innovation catalogs
• Storytelling and community experiences
• Taxonomy-based discovery and filtering
• Searchable innovation pages
• Responsive user experiences
• Performance and accessibility improvements

The engineering team also developed a structured WordPress content model, creating custom content types, taxonomies, field groups, and content management workflows designed to keep the growing catalog maintainable over time.

This focus on content architecture proved especially important because Foundry Labs was never intended to be a static destination. The catalog continues to grow as more innovations are added across Microsoft.

“Microsoft is producing extraordinary AI innovation across research and product teams, but breakthroughs create value only when customers can discover, understand, and put them to use,” Shrivastava says. “Our strategy for Foundry Labs is to create a shared path from emerging innovation to real-world impact—giving teams a way to bring promising work forward, learn from customer engagement, and use those insights to accelerate the journey from research into practical use.”

Designing for discovery

The new experience places discoverability at the center of the user journey.

Visitors can browse innovations by domain, capability, and innovation type. Innovation pages provide concise descriptions, technical details, links to research papers, GitHub repositories, deployment experiences, and related resources.

The site supports a broad range of innovations, including models, SDKs, agent systems, benchmarks, applications, and research projects. Those innovations span disciplines ranging from biomedical research and chemistry to earth science, geospatial intelligence, and general-purpose AI models.

For users, the goal is simple: Arrive with an area of interest and leave with a clear next step.

A central lesson from the site build is that successful AI-assisted development still depends on clear direction and continuous feedback. During prototyping, Osimi found that starting with broad concepts and iterating produced better outcomes than attempting to define every detail up-front.

“I found that having a general idea of what I want and then going back and forth between refining the specification and building the UI has been really effective,” Osimi says.

The team also relied heavily on stakeholder conversations and user feedback throughout development. Those interactions helped clarify assumptions, identify gaps, and refine the final experience.

Human expertise still leads the way

Although AI accelerated many aspects of development, the team emphasized that human expertise remained critical.

“Developing a prototype is one thing, but making it a product is different. You have to ensure performance, security, architecture, and privacy considerations.”

Gulsimo Osimi, technical program manager, Microsoft Foundry

Prototypes can be generated quickly, but production systems require additional considerations, including architecture, scalability, security, privacy, accessibility, and performance.

“Developing a prototype is one thing, but making it a product is different,” Osimi says. “You have to ensure performance, security, architecture, and privacy considerations.”

That collaboration between product, marketing, and engineering helped ensure that Foundry Labs delivered a polished experience rather than just a working prototype.

The result is a platform that continues to evolve as new innovations are added and new community experiences emerge.

The post Rebuilding our Microsoft Foundry Labs site with a three-people build team and AI appeared first on Inside Track.

It worked, up to a point. Individual developers got faster. But the gains stopped there.

“We quickly identified that improving the individual productivity of a developer was not resulting in a boost to team productivity. That was our hard lesson.”

Sudhakar Sadasivuni, principal group engineering manager, Microsoft Digital

The problem wasn’t the tools, but rather the process around them. The traditional software development lifecycle was built for human handoffs, and every handoff introduces a gap in intent.

“We quickly identified that improving the individual productivity of a developer was not resulting in a boost to team productivity,” says Sudhakar Sadasivuni, a principal group engineering manager in Microsoft Digital, who leads our AI-native engineering initiative. “That was our hard lesson.”

Eventually, our leadership posed the question: What would the lifecycle look like if it were designed from the start as a collaboration between humans and AI agents?

Exploring that concept led us to spec-driven development (SDD), an AI-native engineering approach that treats specifications as the primary artifact in the software development lifecycle. Instead of relying on code, documents, or prompts as the main source of truth, our teams now anchor development around a living specification, which captures the business intent and acceptance criteria before implementation begins.

Our engineers can now generate code faster, accelerate testing, and move from idea to implementation more quickly than ever before, thanks to the power and speed of AI.  

This is a step towards Frontier Firm ways of working, where humans provide oversight and direction and AI tools handle task execution. And because we serve as the company’s Customer Zero, the solution is a model that our customers can learn from and use in their own engineering organizations.

Shifting left

By shifting critical thinking and collaboration to the requirements phase of development, SDD resolves ambiguities, surfaces edge cases, and gets everyone on board early in the process, dramatically reducing late-stage chaos.

“Speed without direction is just expensive chaos—and we learned that the hard way through vibe coding. After burning our hands on those traps, we realized that SDD gives you both velocity and vector.”

Mridul Verma, senior software engineer, Microsoft Digital

The result is a development process that helps teams align stakeholders earlier, reduce rework, and make more effective use of AI coding agents while maintaining a clear connection to business goals.

Another advantage of SDD, according to Mridul Verma, a senior software engineer in Microsoft Digital, is that it focuses not only on velocity, but also on vector. (Velocity is how fast your development moves, while vector reflects the direction you’re moving.)

“Speed without direction is just expensive chaos—and we learned that the hard way through vibe coding,” Verma says. “After burning our hands on those traps, we realized that SDD gives you both velocity and vector.”

Why specs matter more in the AI era

Traditional software development often treats specifications as planning documents. After development begins, these documents can quickly become outdated as requirements evolve and implementation details change.

“In the AI era, the best dev teams aren’t the ones that generate the most code. It’s about how they’re best able to preserve intent.”

Vignesh Vijayaraghavan, senior software engineer, Microsoft Digital

SDD flips that model.

The specification becomes a living artifact that evolves alongside the product, serving as a shared reference point for product managers, software engineers, architects, designers, testers, and AI coding agents.

That shift is especially important in AI-native development environments. While AI tools can generate large amounts of code quickly, they depend on clear instructions and guardrails. Teams that can’t consistently communicate intent typically discover that increased coding velocity simply produces more variability and additional rework.

“In the AI era, the best dev teams aren’t the ones that generate the most code,” says Vignesh Vijayaraghavan, a senior software engineer in Microsoft Digital. “It’s about how they’re best able to preserve intent.”

There are five pillars that drive the transformational value of spec-driven development, based on our experience at Microsoft:

Spec as the source of truth

The spec becomes the single authoritative reference for all stakeholders.

Living, executable artifacts

Specs evolve alongside the project, remaining synchronized with the code and tests. They are co-authored by various stakeholders.

AI-assisted automation

SDD leverages AI coding agents to generate, test, and validate code, accelerating development and enhancing productivity.

Human validation and collaboration

Automation is central to SDD, human expertise is crucial for reviewing specs, refining requirements, and validating outcomes.

Predictability and measurability

SDD enables teams to track progress, measure outcomes, and improve predictability.

How the SDD workflow works

At Microsoft Digital, our developers and PMs begin by creating specifications that capture business goals, user requirements, edge cases, and acceptance tests. These specifications are version-controlled and continuously updated as the project evolves. Rather than serving as static documentation, they guide every major decision throughout the lifecycle.

“The spec becomes the shared source of truth for the entire team. Instead of handing requirements from one group to another, everyone collaborates around a living document that guides development and keeps decisions aligned.”

Garima Gaurav, senior product manager, Microsoft Digital

It’s important to note that before creating the specs, the team agrees on a constitution: A shared set of architectural principles, governance requirements, security standards, and development limitations that everyone adheres to. Developing this constitution is a team-wide exercise rather than an individual one, allowing employees and AI agents to work from the same facts and the same context.

“The spec becomes the shared source of truth for the entire team,” says Garima Gaurav, a senior product manager in Microsoft Digital. “Instead of handing requirements from one group to another, everyone collaborates around a living document that guides development and keeps decisions aligned.”

Our teams use GitHub Spec Kit to support the process. This workflow includes six major stages:

1. Define the business problem and expected outcomes
2. Clarify ambiguities and unanswered questions
3. Create a technical implementation plan
4. Break work into traceable tasks
5. Validate alignment between requirements and plans
6. Implement and test the solution

“As teams mature, they learn the right level of granularity, and breaking large requirements into multiple specs becomes a key practice for maintaining quality and preserving intent.”

Ajeya Kumar, principal software engineer, Microsoft Digital

Because each stage builds on the spec, teams can trace implementation decisions back to their related business requirements more easily than with traditional code-first approaches. AI coding agents enhance the spec and then generate code, tests, documentation, and other tasks from it. (Specs are version-controlled in the same repository to aid tracking and avoid confusion.) Engineers focus on validating intent, reviewing outputs, and refining requirements.

“Effective SDD adoption relies on well-scoped specifications,” says Ajeya Kumar, a principal software engineer in Microsoft Digital. “Smaller, focused specs generate outputs that are easier to review and validate, enabling teams to build incrementally rather than all at once. As teams mature, they learn the right level of granularity, and breaking large requirements into multiple specs becomes a key practice for maintaining quality and preserving intent.”

How SDD impacts different roles

Adopting spec-driven development across our organization involved more than just introducing new tools. Existing roles were tightly coupled to the old software development lifecycle, so some had to change while other new roles and skills were created. Microsoft Digital teams documented these changes at every step, because the shift in mindset is what makes SDD work.

Overall, we found that the biggest change was behavioral: Specifications stopped being documents that simply supported development and actually became the artifact that drove it.

Here’s how Microsoft’s shift toward an SDD-driven approach has impacted various roles across the company:

Leadership

For engineering leaders, success is no longer measured solely by development activity. Leaders need to create an environment that rewards clarity, alignment, and collaboration before actual implementation begins. Dev teams are encouraged to invest time in resolving ambiguities and documenting expectations early in the software development lifecycle because this reduces costly rework later.

Leaders also play an important role in driving adoption. Our dev teams say that SDD delivered the greatest value when it became a standard way of working rather than an optional process that individuals can bypass. The adoption has to be deliberate.

“It’s not something where you decide, today I woke up and I’ll start using SDD,” says Apoorv Gupta, a principal software engineer in Microsoft Digital. “It doesn’t work like that. It’s a mindset shift and a learning curve.”

Developers

For developers, the transition to SDD often requires breaking long-standing work patterns. For years, software engineers were encouraged to move quickly from requirements to implementation. Under SDD, their first step is developing a complete understanding of the problem, including defining success, before any code is created.

“As developers, we get excited and want to jump directly into coding,” Verma says. “Changing that habit was really tricky.”

That change runs deeper than just a habit. The developers must make sure the agent fully understands the task before starting the coding process.

“SDD makes you clarify and refine your thoughts first for agents, not for yourself,” Sadasivuni says. “This is agent-first solutioning, not human-first solutioning.”

Our Microsoft Digital engineers now spend more time refining requirements, identifying edge cases, evaluating plans, and validating AI-generated outputs. Their role has shifted away from producing every line of code to making sure that code implementation accurately reflects intent.

Program and product managers

Our program and product managers continue to perform many of their traditional responsibilities, including stakeholder management, prioritization, and roadmap planning. What’s changed is the degree of ownership that they maintain throughout the development lifecycle.

“In spec-driven development, PMs become the owners of the spec; they’re no longer just responsible for planning and prioritization. Everything starts with the spec, so they become the starting point for the entire system.”

Apoorv Gupta, principal software engineer, Microsoft Digital

In an SDD environment, product managers become stewards of the specification itself. They help define success criteria, resolve ambiguities, document business requirements, and check to make sure that priorities remain visible throughout implementation. The specification becomes a shared contract among stakeholders and a common source of truth for the entire team.

“In spec-driven development, PMs become the owners of the spec; they’re no longer just responsible for planning and prioritization,” Gupta says. “Everything starts with the spec, so they become the starting point for the entire system. If the specs are right, then everything falls into place.”

Architects

Architects establish the guardrails that govern the development process. One of the SDD first activities is defining a constitutionthat captures architectural principles, governance requirements, security standards, and development constraints. Architects are responsible for creating and maintaining those guardrails.

Because architectural decisions are made earlier in the process, teams can identify issues before implementation begins rather than discovering them during code reviews or testing cycles.

Looking ahead

Spec-driven development continues to evolve at Microsoft. But our development teams already view it as a vital component of AI-native engineering. The goal is to create a system that preserves intent as work moves from business requirements to implementation.

“SDD gives PMs a level of empowerment that wasn’t there before. You can move from an idea to a prototype, show it to customers and leaders, and start generating feedback much faster. Once teams experience that, they keep creating value, generating new ideas, and building on what they’ve learned.”

Gopal Panigrahy, principal product manager, Microsoft Digital

As AI coding agents become more capable, clear specifications become more valuable. Teams that can define requirements, establish guardrails, and maintain shared ownership of intent will be better positioned to scale AI-assisted engineering without sacrificing quality or governance.

For Microsoft Digital, SDD represents an important step toward Frontier Firm ways of working, where humans provide direction, judgment, and accountability while AI helps accelerate execution. Preserving intent, not simply generating code, is what enables teams to move faster while continuing to deliver outcomes that meet business needs.

“SDD gives PMs a level of empowerment that wasn’t there before,” says Gopal Panigrahy, a principal product manager in Microsoft Digital. “You can move from an idea to a prototype, show it to customers and leaders, and start generating feedback much faster. Once teams experience that, they keep creating value, generating new ideas, and building on what they’ve learned.”

The post Engineering the Frontier Firm: Sharing our AI-native approach to software development appeared first on Inside Track.

At Microsoft Digital, the company’s IT organization, we now offer Managed Cloud Labs (formerly known as MyWorkspace), a self-service, Azure-based platform that enables our employees to create and manage the lab environments they need. With more than 150,000 VMs hosted in Managed Cloud Labs across the organization, keeping those environments healthy is essential to maintaining engineering productivity.

When a VM becomes unavailable, however, diagnosing the issue can require significant manual effort. Today, an engineer may begin troubleshooting by attempting to access the VM, reviewing logs, and running diagnostic commands to identify the root cause. While this process can sometimes resolve the problem, it requires the engineer to remain actively involved throughout the investigation, validating findings and testing potential fixes.

At the scale of Managed Cloud Labs, even routine VM issues can add up to a significant productivity cost. That’s why our team went looking for a way to automate troubleshooting. The answer was AI.

“The Troubleshooting Agent is the first integration of Azure Serial Console and AI that streamlines VM troubleshooting. It significantly reduces the toll on support engineers and speeds up problem resolution.”

Dominika Bobik, technical lead, Azure Serial Console

We and our partners on the product group side engineered a solution for Managed Cloud Labs VMs using Azure Serial Console and agentic AI. This approach—which includes an Info Agent and a Troubleshooting Agent—has been a great success, allowing engineers to identify what’s broken and repair the issue in minutes instead of hours.

“The Troubleshooting Agent is the first integration of Azure Serial Console and AI that streamlines VM troubleshooting,” says Dominika Bobik, a technical lead in the Azure Serial Console product group. “It significantly reduces the toll on support engineers and speeds up problem resolution.”

Learn more

Read more of our stories about Managed Cloud Labs.

A new path for VM support issues

When we analyzed our support incidents, two recurring challenges emerged: Users needed faster answers to everyday how-to questions, and they needed a quicker path to resolution when remote access to their virtual machines via Remote Desktop Protocol (RDP) failed.

For how-to questions, the issue usually wasn’t the platform. Our employees were often blocked because they needed assistance with straightforward tasks: How to change a password, update a lab quota, or deploy a custom workspace.

“We had a lot of repetitive how-to questions, where the answers could be found in our user guide. An AI agent made more sense because as the product changes, we update the user guide—our one source of truth—and the Info Agent always provides the latest instructions.”

Thien-Y Le, senior product manager, Microsoft Digital

Connectivity issues are more disruptive. When our employees can’t use RDP to connect to a virtual machine, diagnosing the problem means checking across networks, OS configuration, and Azure infrastructure to determine which layer has failed. This typically results in a work stoppage, unless they can quicky recreate the lab.

In some cases, rebuilding a lab may take only a few minutes. However, many of our customers rely on highly customized virtual machines that have been fine-tuned over years to fit their environments. These labs are essential for investigations, troubleshooting, and development work, and rebuilding them can take much longer. Being unable to remotely access a provisioned lab can also become a critical blocker for active customer case work. These kinds of labs require immediate attention.

Those experiences shaped our Managed Cloud Labs Agent Experience solution, which pairs an Info Agent for user education and a Troubleshooting Agent for connectivity issues. The Info Agent answers how-to questions conversationally, using retrieval-augmented generation (RAG) to draw from internal documentation as well as the user guide.

“We had a lot of repetitive how-to questions, where the answers could be found in our user guide,” says Thien-Y Le, a senior product manager in Microsoft Digital. “An AI agent made more sense because as the product changes, we update the user guide—our one source of truth—and the Info Agent always provides the latest instructions.”

Automating the troubleshooting process

The Troubleshooting Agent changes the support model. When one of our engineers selects a virtual and reports an RDP problem, the agent investigates the VM, diagnoses the cause, and attempts a repair. Throughout the session, it gives the user a running summary of what it’s detecting and the actions it’s taking, making the automated work visible to the user but also “hands-free.”

When RDP or run commands are broken, our support engineers would typically turn to Azure Serial Console as an expedient path to the VM when all else fails. The Troubleshooting Agent automatically takes that same serial console path, but adding an AI agent to the process required retooling to automate the human action.

Our team built an orchestrated crew of AI agents behind that user experience. We used Microsoft Foundry to host our models and Microsoft Agent Framework to manage the overall troubleshooting workflow and orchestrate the different agents. To help with evaluations, we utilized the Azure AI Evaluation software development kit.

A session begins with programmatic checks, then moves on to a read-only diagnostic orchestrator agent that decides what information to gather and tools to use. It can query Azure resource health, call Managed Cloud Labs APIs, and route work to a specialized Windows RDP diagnostic agent that drives the serial console.

“We deliberately break test VMs in dozens of ways and expect the Troubleshooting Agent to repair them, then run evals to make sure the fixes are safe and consistent.”

Joshua Deans, senior software engineer, Microsoft Digital

The process reads early signals. For example, if Azure resource health points to a clear problem, the orchestrator stops there instead of running more complex diagnostics. When the system identifies an issue it can safely address, an auto-repair orchestrator restarts the VM, resets a password and network interface, or sends serial console commands to correct a configuration problem. It then validates whether the fix has succeeded before closing the loop.

When the agent can’t safely resolve something, because the fix carries risk or the issue falls outside its known scenarios, it provides the full diagnostic context to the user. This context can then be given to a human support engineer, who can pick up the thread from there instead of starting over.

Making that reliable across the many Windows operating systems that Managed Cloud Labs supports took a lot of testing and careful tuning under close collaboration with the Azure Serial Console product group.

“We deliberately break test VMs in dozens of ways and expect the Troubleshooting Agent to repair them, then run evals to make sure the fixes are safe and consistent,” says Joshua Deans, a senior software engineer in Microsoft Digital.

Decreasing wait times

Our Troubleshooting Agent targets the 20% of ticket volume that comes from the common issues our support team typically resolves without escalation. The Info Agent addresses another 30% to 40%. Together, the team aims to take on about half of all ticket volume.

“With the Troubleshooting Agent, the same class of issue that once took more than 90 minutes to resolve is identified in less than 10 minutes. The agent provides immediate self-remediation to reduce downtime and has become an essential part of my workflow.”

Hrishi Deshpande, senior tech support engineer, Microsoft Exchange

In the first month of using the Troubleshooting Agent, we were able to:

• Reduce the average time to mitigate a common connectivity ticket from 16 hours to 15 minutes.
• Save our employees more than 1,200 hours a month in wait time.

“With the Troubleshooting Agent, the same class of issue that once took more than 90 minutes to resolve is identified in less than 10 minutes,” says Hrishi Deshpande, a senior tech support engineer in Microsoft Exchange. “The agent provides immediate self-remediation to reduce downtime and has become an essential part of my workflow.”

What’s next on our journey

We intend to add tooling for firewall issues to the Troubleshooting Agent and keep expanding the orchestrator to cover more signals over time.

“Every transformative platform starts with a single capability that proves what’s possible. For us, that’s the VM Troubleshooting Agent, the foundation beneath it, and the future it unlocks.”

Vikram Dadwal, principal software engineering manager, Microsoft Digital

Our team sees the next chapter as helping inform broader Azure capabilities, so the same self-healing approach can reach anyone running Azure VMs.

“Every transformative platform starts with a single capability that proves what’s possible,” says Vikram Dadwal, a principal software engineering manager on the Managed Cloud Labs team in Microsoft Digital. “For us, that’s the VM Troubleshooting Agent, the foundation beneath it, and the future it unlocks.”

For Le, that future is about what AI is making possible for users: intelligent support that feels immediate and always within reach. She likens it to giving every user their own personal support engineer. That shift from reactive troubleshooting to proactive, self-healing support is the larger opportunity that Managed Cloud Labs is addressing.

“We envision a future where troubleshooting becomes invisible,” Le says “It’s a world where systems automatically identify and remediate issues, eliminating the need for customers to open support tickets or seek assistance.”

While Managed Cloud Labs is an internal Microsoft platform, the principles behind it—self-service provisioning, governance guardrails, automation, AI-driven optimization, and cost management—can be implemented using Microsoft Azure services. Click through to learn more about how Azure helps organizations build and manage cloud environments at scale and how to get started building your own static web apps.

The post Resolving repetitive support tickets at Microsoft with AI automation appeared first on Inside Track.

AI tools for testing are everywhere, but for most organizations, they’re still experiments, not infrastructure.

When our Commerce Platforms team, which owns the company’s core commerce and financial platform services, found itself staring down a critical SAP migration with a hard deadline, they decided it was time to try a different approach.

They wanted to know if enterprise-grade AI testing was actually achievable.

A growing challenge

Behind the scenes, we run much of our global business on SAP. From finance and supply chain management to HR and procurement, SAP serves as a critical enterprise platform across the company.

Testing across our 40-plus SAP service lines had long relied on third-party tools. Our licensed infrastructure had finite capacity and required manual test-case authoring. And the vendor we were working with wasn’t able to move as quickly as we wanted.

As a result, costs compounded in every direction. Reliance on third-party testing tools to automate SAP regression testing came with high licensing costs, infrastructure requirements, and operational complexity. Together, those tools cost us about $500,000 a year to maintain. With only 80 third-party tool licenses spread across more than 40 service lines, teams were perpetually competing for capacity.

Additionally, security vulnerabilities and compliance findings in third-party testing tools became an ongoing liability. Vendor remediation timelines stretched to 9 or 10 months, far beyond our requirements.

Then came the deadline that forced us to act.

One of the first major tests came from the Global Trade Services (GTS) system, which handles customs and invoice generation processes required to move products across international borders. As part of our broader SAP modernization effort, GTS had to migrate from SAP ERP Central Component to SAP Business Suite 4 HANA before a December 2025 deadline or shipments would stop. The team had 10 months. The traditional testing approach wouldn’t get us there.

The time had come to explore AI as a solution for a testing model that was becoming unsustainable. With an ambitious goal, and the GTS team’s blessing, we developed Enterprise Test Platform, an AI-driven testing solution.

Building with an incremental approach

Our team started narrow. Rather than replacing their third-party testing platform overnight, they focused first on test-case authoring. It was a practical starting point: Teams already had years of business process documentation, but turning that knowledge into structured, executable test cases still required significant manual effort.

“We realized that enterprise teams already had the documentation AI needs. Once we saw that AI could convert that knowledge into reliable, structured test cases, it changed the trajectory of the entire project.”

Neeraj Tripathi, principal program manager, Commerce Platforms team

Process documentation, API references, business requirement documents, and functional flows were already there, scattered across systems. The missing piece was converting that existing knowledge into structured, executable test assets.

“We realized that enterprise teams already had the documentation AI needs,” says Neeraj Tripathi, a principal program manager on the Commerce Platforms team. “Once we saw that AI could convert that knowledge into reliable, structured test cases, it changed the trajectory of the entire project.”

Early results exceeded expectations. That momentum gave the team confidence to expand beyond test-case authoring to eventually encompass execution, validation, orchestration, and reporting, consolidating fragmented testing capabilities into a unified first-party platform.

Making a dramatic impact

The GTS migration became the proof point. The team ran three full mock drills using the Enterprise Test Platform throughout, and the numbers tell the story of a team learning in real time.

“The migration of delta was completed in 11 minutes. We have set an industry benchmark with this project.”

Priyanka Alva, program manager lead, Global Trade Services

In the first mock drill, the system cutover alone took 144 hours. In the second, it was 36 hours. In the third, 11 hours. Finally, the GTS system went live on SAP S4 Migration on Azure in six hours, with SAP Support flying a team in from overseas to be on site.

“The migration of delta was completed in 11 minutes,” Alva says. “We have set an industry benchmark with this project.”

The in-house migration tool and Enterprise Test Platform contributed directly. Weekly regression testing that previously consumed three full days dropped to under an hour. Alva’s team achieved 57% automation across the full migration effort, a result that came during the first pilot, while the tool was still being actively developed in parallel. The go-live produced zero post-launch defects.

Since then, the Enterprise Test Platform has been used for other service lines. The broader organizational results are just as striking:

• Across service lines that have adopted the platform, teams are seeing 80% efficiency gains in end-to-end testing cycles. More than 10,000 test cases now execute in 10 to 12 minutes.
• Hundreds of thousands of dollars spent annually on third-party licensing and infrastructure are coming off the books as each service line retires its legacy tools.
• The security compliance problem that once left findings open for the better part of a year is resolved; first-party tooling means we now own the remediation timeline.

SAP has since cited the GTS migration at TechEd and Sapphire as a model for S4 migrations at scale.

“We’ve achieved something the industry has been struggling with,” Tripathi says. “Our journey is a case study for other organizations working toward their S4 migrations. That story is now being told by SAP to their customers.”

Solving the challenge AI skeptics raise first

Generative AI is probabilistic by nature. For compliance-sensitive enterprise testing, that’s a disqualifying concern. The Commerce Platforms team knew it, and they built their answer into the architecture.

When a tester prompts the agent to generate test cases, the agent draws on the service line’s knowledge base and proposes test steps for human review. Nothing is committed until a person approves. Once approved, the agent produces a test execution context, or TC JSON file: a lightweight, human-readable script that locks in every step, API mapping, input payload, expected output, and validation assertion for that test case.

“The nature of AI is probabilistic, but testing requires deterministic responses,” Tripathi says. “Every time that test case runs, it runs the same way.”

“Each time some action is done by the AI, another agent comes and challenges it. The agent probes more questions and makes sure the output is accurate.”

Ram Mohan Reddy Gudupalli, software engineering manager, Commerce Platforms team

That handles execution. But what about authoring itself?

To solve that, the team added a second layer: A dedicated “policing” agent built into the multi-agent architecture that re-interrogates every output before it’s finalized.

“Each time some action is done by the AI, another agent comes and challenges it,” says Ram Mohan Reddy Gudupalli, the software engineering manager who led the build. “The agent probes more questions and makes sure the output is accurate. The real innovation wasn’t adding AI to testing, it was making AI accountable through deterministic execution, independent validation, and enterprise governance.”

The TC JSON makes execution deterministic and auditable. The policing agent makes the authoring step trustworthy. Together, they give a probabilistic technology the governance profile that enterprise requires.

The Enterprise Test Platform connects existing business knowledge to AI-assisted test creation, deterministic execution, traceable results, and automated validation/insights:

1. Knowledge base:​ Business process docs, wikis, APIs, and test artifacts become the source of truth.​
2. Test case authoring​: AI proposes test scenarios and creates Azure DevOps test cases for human review.​
3. Test process engine​: Creates a Test Execution Context file that standardizes execution logic, inputs, and validations.​
4. Deterministic execution​: Runs approved test cases at scale in Azure DevOps through controlled, repeatable execution.​
5. Results and traceability: ​Captures outcomes, evidence, and summaries back in Azure DevOps for end-to-end traceability.​
6. Validation, analysis, and insights​: Validates results across enterprise systems, identifies anomalies, and provides actionable testing insights.​

At execution time, an orchestration engine fans test cases out for parallel execution across multiple simultaneous instances. Results flow back to Azure DevOps, where the agent analyzes outputs, flags mismatches, and automatically creates bug work items with AI-recommended fixes.

“We could have chosen a safer pilot. But if GTS succeeded, it would become a much bigger story. They came through with flying colors, and now they speak on our behalf.”

Adrivit Bhattacharya, program manager lead, Commerce Platforms team

Adoption is its own engineering problem

Building the platform was the easier part of the project. Adrivit Bhattacharya, program manager lead for the platform team, chose GTS as the first pilot not because it was the safest bet, but because it was the highest-stakes one.

“We could have chosen a safer pilot,” Bhattacharya says. “But if GTS succeeded, it would become a much bigger story. They came through with flying colors, and now they speak on our behalf.”

Before claiming any efficiency gains, our team ran the same test cases manually to establish a real baseline, then had service lines review and sign off on the comparison.

As of now, seven service lines are fully onboarded, 11 are in progress, and more than 15 are in the pipeline.

“Building solutions is easy; adoption is where the challenges are because there is no one size fits all. If a service line only needs one of our solutions, they should be able to leverage it without having to connect to everything we offer.”

Umamaheswar Charabudla, engineering group manager, Commerce Platforms team

Umamaheswar Charabudla, the engineering group manager on the team, made the platform modular from the start, so teams can adopt one capability at a time—authoring, execution, or validation—without committing to the full stack up front.

“Building solutions is easy; adoption is where the challenges are because there is no one size fits all,” Charabudla says. “If a service line only needs one of our solutions, they should be able to leverage it without having to connect to everything we offer. There should be no ‘all or nothing.’”

What’s next—and why it matters beyond Microsoft

Our team built this solution under pressure, proved it on one of the most business-critical systems in the company, and is now fielding interest from enterprises around the world facing identical problems. The tool that started as a scrappy experiment to save a migration timeline has become a case study that SAP is presenting to its own customer base.

For organizations navigating the same pressures, the Commerce Platforms team playbook is open.

The post Making AI testing work at scale at Microsoft with Enterprise Test Platform appeared first on Inside Track.

At that scale, Python dependencies have emerged as a significant source of risk for us—representing the third-largest vulnerability surface across the company.

The good news is that we have strong visibility into these vulnerabilities, with tools that continuously detect and surface risks across our codebases. The bad news is that turning those insights into action required a complex remediation process.

Updating a single code package often caused changes across multiple interdependent libraries. This required coordinated updates, validation, and testing to maintain system stability.

“When AI arrived, I saw it as a great opportunity to finally fix a very complex problem we had: The level of entanglement involved in Python code dependencies. A simple script wasn’t going to resolve it—you needed the power of AI.”

Humberto Arias, senior product manager, Microsoft Digital

Multiply this by thousands of projects throughout our enterprise, and vulnerabilities accumulated much faster than we could resolve them. To address this challenge, we turned to AI.

Microsoft Digital—the company’s IT organization—has developed an AI-powered solution called Python Dependency Remediation. Designed to work directly within the developer workflow, this solution analyzes dependency chains, applies required updates, and automatically adjusts the code. This enables our engineers to remediate vulnerabilities quickly and consistently at enterprise scale.

“I’ve worked for years in the vulnerability management space at Microsoft,” says Humberto Arias, a senior product manager in Microsoft Digital. “When AI arrived, I saw it as a great opportunity to finally fix a very complex problem we had: The level of entanglement involved in Python code dependencies. A simple script wasn’t going to resolve it—you needed the power of AI.”

The tool has shown so much promise that we have begun releasing it externally, so that millions of Python developers around the world can take advantage of it.

“I used to have this problem all the time. I upgrade one library, and then I’ve got to upgrade 17 other things, and something else breaks, and now my code is completely different.”

Rich Chiodo, principal software engineer, Python and Tools for AI

Get started

Try using the Python Dependency Remediation tool

Flexibility leads to dependencies and risk

Python is a very flexible language, which is why it’s so popular among software developers. But that same flexible nature—it can be used across a wide range of scenarios—also means it forms deeply interconnected dependency chains. When one code library is updated, it can trigger changes across many others.

“I used to have this problem all the time,” says Rich Chiodo, a principal software engineer on the team responsible for Python Tools and AI. “I upgrade one library, and then I’ve got to upgrade 17 other things, and something else breaks, and now my code is completely different.”

“Developers avoid the upgrades because the dependency web is so complex. This means the vulnerabilities accumulate over time and can become a real security risk.”

Chintan Sheth, principal engineering manager, Viva Glint

Because the code is so interdependent and remediation is time-consuming, many developers skip updating their code packages, which can lead to security vulnerabilities.

Security compliance was often seen as a burden because it slows people down.

“Developers avoid the upgrades because the dependency web is so complex,” says Chintan Sheth, a principal engineering manager on the Viva Glint product team. “This means the vulnerabilities accumulate over time and can become a real security risk.”

“After my manager mentioned it, I reviewed the idea on the hackathon page, and it looked really interesting to me. So I jumped in, and we created a prototype and a demo video with a quick solution. That’s how it started.”

Shiva Krishna Gollapelly, senior software engineer, Microsoft Digital

Hacking our way to a solution

Like some of the best internally developed tools and processes, Python Dependency Remediation came out of a Microsoft hackathon project. These grassroots events allow our engineers to tackle interesting technical challenges in a collaborative, creative way.

“After my manager mentioned it, I reviewed the idea on the hackathon page, and it looked really interesting to me,” says Shiva Krishna Gollapelly, a senior software engineer in Microsoft Digital and the lead developer on the project. “So I jumped in, and we created a prototype and a demo video with a quick solution. That’s how it started.”

The fact that this solution came from a hackathon highlights the ideas-driven culture that we promote at the company.

“This really speaks to our special culture of innovation,” says Snigdha Bora, a principal group engineering manager for Employee Experience. “After this emerged from the hackathon, our developers realized it could solve a problem at scale—that it was worth taking through the full development cycle so we can release it for all of Microsoft, and maybe beyond.”

Solving the issue with one click (and AI)

Because the challenge was not detecting vulnerabilities but fixing them, we had to rethink how we addressed Python dependencies.

“The extension automatically finds the right updates and then fixes the vulnerabilities, so developers don’t need to do the research, the manual upgrades and fixes, run test cases, debugging—all those things that used to take so much time. With our solution, it’s just one button click and it does all of that automatically.”

Shiva Krishna Gollapelly, senior software engineer, Microsoft Digital

In the past, when engineers received a vulnerability notification, they would have to step outside their development workflow and address the issue. What was needed was a solution that could be enacted within their normal workflow—integrating remediation directly into the tools they were already using.

So, we created the Python Dependency Remediation extension for Visual Studio Code, a common Python development environment. Once installed, engineers can address vulnerabilities in the flow of their work.

“The extension automatically finds the right updates and then fixes the vulnerabilities, so developers don’t need to do the research, the manual upgrades and fixes, run test cases, debugging—all those things that used to take so much time,” Gollapelly says. “With our solution, it’s just one button click and it does all of that automatically, with the help of AI.”

The extension uses the APIs built into Visual Studio Code to connect with any AI model the user has access to. (If there is no AI model available, Gollapelly explains, the extension will still make the package updates but won’t do the remediation fixes to the code.) It also produces a report of the changes for the developer to review in case there’s a snag that needs troubleshooting.

“This tool removes a significant burden from our developers,” Bora says. “We are shifting the entire remediation process left, embedding it early in the development workflow. Developers can review the changes and move forward immediately, making the whole process more efficient.”

“We’ve upgraded the library with new methods, calls, and structures. Now, let’s make sure everything works, check for errors in the code, etc. That’s the gap we’re bridging with AI.”

Angel Saldivia, software engineer, SharePoint

The result is that fixes and upgrades that used to take multiple hours of developer time now take minutes, and the code is much more reliable.

What the agent does in this solution is help close that loop, something that the engineer used to have to do.

“We’ve upgraded the library with new methods, calls, and structures,” says Angel Saldivia, a software engineer on the SharePoint product team. “Now, let’s make sure everything works, check for errors in the code, etc. That’s the gap we’re bridging with AI.”

From Customer Zero to global impact

One of the powerful things about working at Microsoft is that you get to help develop technology tools that can change the world. This is the case with Python Dependency Remediation as well.

“We realized this technology had much broader value. There are hundreds of millions of Python users worldwide, so the impact could be massive.”

Snigdha Bora, principal group engineering manager, Employee Experience

As Bora explains, while the solution was being developed it was presented to Guido van Rossum, the creator of Python (and a Microsoft employee). He immediately saw the incredible potential of the concept.

“He suggested that we could take this solution to the world, not just to Microsoft,” Bora says. “We realized this technology had much broader value. There are millions of Python users, so the impact could be massive.”

To help make this happen, Microsoft Digital approached Graham Wheeler, a principal group engineering manager on the Python and Tools for AI team. Wheeler’s team is responsible for shipping Pylance, a development extension for Visual Studio Code used by more than 180 million developers worldwide.

“One of the things we could do was provide a jumping-off point for this extension, so that when users installed Pylance they’d be prompted to also download Python Dependency Remediation. It can help raise awareness, because many users don’t actually do the dependency scanning and updating that they should.”

Graham Wheeler, principal group engineering manager, Python and Tools for AI

Wheeler and his team are in the process of incorporating the Python Dependency Remediation extension as an option during Pylance installation. This will open up a convenient vector for getting the tool in front of a huge audience, potentially revolutionizing Python development.

“One of the things we could do was provide a jumping-off point for this extension, so that when users installed Pylance they’d be prompted to also download Python Dependency Remediation,” Wheeler says. “It can help raise awareness, because so many users don’t actually do the dependency scanning and updates that they should. So, we’re helping with that challenge.”

Beyond Python, the AI-powered technology behind this extension might be applied to other dependency challenges as well. What started as a simple hackathon project could have huge ramifications for the future of software development.

“This solution can easily be adapted to other libraries, other programming languages,” Gollapelly says. “Whether you’re talking about C#, Angular, React, or another language, the concept is the same. The implications are vast.”

The post Taming our Python dependencies at Microsoft with AI 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.

At Microsoft, we’ve put that potential into action by building the Employee Self-Service Agent, a centralized “front door” for employee support inquiries on all things Microsoft. Whether the question is related to an IT, human resources (HR), or campus services-related challenge, this agentic solution delivers geographically relevant, role-specific content on demand.

Our agent was rolled out in stages to our global workforce, as we continually added topic categories, features, and geographic availability. It eventually reached our entire workforce—more than 300,000 employees and vendors in 103 countries and regions—before being publicly released last November.

Our team in Microsoft Digital—the company’s IT organization—played a pivotal role in our global rollout, working closely with the product team and providing valuable feedback throughout development. It’s all part of our Customer Zero philosophy here at the company.

The agent proved its value early, piloting in large, primarily English-speaking regions—including Canada, India, the UK, and the US—and reaching more than half of our global workforce. But we wanted to raise the bar, so we turned to the rest of Europe.

The next chapter in the rollout was the Europe North region, which brought in 21 countries that are home to a wide variety of languages, cultures, country-specific HR policies, and nuanced IT support requirements.

“For the Employee Self‑Service Agent to work in Europe North, we had to listen locally to understand each country’s realities and respect those differences, rather than forcing a single global approach.”

Allan Hvass, director, Employee Experience in Europe North, Microsoft Digital

However, early deployments in smaller markets in the region revealed that when local content for a specific geography was missing, the agent sometimes defaulted to policies related to the US or other unrelated countries. Sensitive HR scenarios and strict country-level rules increased the complexity and resulting challenges.

Our team in Microsoft Digital met the challenge by working through front‑end field adoption and back‑end product updates to successfully land the Employee Self-Service Agent in Europe North’s small and midsize countries. This included adapting the product to distinct local realities in each country.

“For the Employee Self‑Service Agent to work in Europe North, we had to listen locally to understand each country’s realities and respect those differences, rather than forcing a single global approach,” says Allan Hvass, director for Employee Experience in the Europe North region of Microsoft Digital.

Mobilizing field representatives

To help with the tricky aspects of driving local adoption of  the Employee Self-Service Agent, our team in Microsoft Digital formed an adoption advisory team. The team included leadership representatives from all major countries and business divisions.

The group established on‑the‑ground field representatives to create better communications channels with the Europe North countries. This helped us learn what was and wasn’t working locally while we extended support for neighboring countries and kept excitement around the agent alive.

“I encouraged my colleagues to use the agent, and then to tell customers about their experience,” Rusen says. “A story grounded in real use is much more powerful and authentic than any slide deck.”

Daniel Rusen, sales enablement and operations leader, Europe North

Because the team had already been communicating about the agent internally, including hosting all-hands meetings to spark early usage, we were able to collect thousands of instances of employee feedback. Key themes surfaced, including policy accuracy by country, quality of language, and IT support variance by market.

Daniel Rusen, a sales enablement and operations leader for Europe North, served as one of the field representatives. He helped the advisory team close the loop between the field and the core project by highlighting the language and local relevancy issues that were reported. He also became an evangelist for the agent, encouraging other sales executives to use the tool and experience it first-hand.

“I encouraged my colleagues to use the agent, and then to tell customers about their experience,” Rusen says. “A story grounded in real use is much more powerful and authentic than any slide deck.”

Driving adoption with contextual experiences

To support the rollout of the Employee Self-Service Agent across Europe North, we designed an adoption approach aligned with regional priorities and local ways of working.

We focused on making the value of the agent immediately tangible. Through Microsoft Viva Engage communications, we connected the agent directly to Europe North business goals and highlighted the most relevant, high-impact scenarios—helping employees quickly recognize when the agent was the right “front door” for their support needs.

“Adoption is not about pushing a tool, it’s about helping people recognize, in their own context, when it truly makes their day easier. By focusing on relevant scenarios, simple communication, and hands-on experiences, we made the Employee Self-Service Agent useful from the start.”

Edith Dubuisson, senior business program manager, Employee Experience in Europe North, Microsoft Digital

To avoid overwhelming users, we prioritized simple, focused communication formats. For example, an Advent calendar campaign combined the agent with Copilot capabilities, enabling employees to discover one practical, actionable use case at a time.

In parallel, we hosted targeted readiness sessions to demonstrate key end-to-end scenarios and share practical tips and best practices. This ensured employees not only understood the value of the agent, but also felt confident using it from day one—creating a strong and positive first experience.

“Adoption is not about pushing a tool, it’s about helping people recognize, in their own context, when it truly makes their day easier,” says Edith Dubuisson, a senior business program manager in Microsoft Digital. “By focusing on relevant scenarios, simple communication, and hands-on experiences, we made the Employee Self-Service Agent useful from the start.”

Fine-tuning the agent

Built in Copilot Studio, the Employee Self-Service Agent works on global, regional, and area levels to make sure that users receive the content that corresponds to their geographical location and preferred language.

The Microsoft Global Support Services group manages the agent capability and improvements, driven by a strong partnership with internal engineering teams. The team triaged feedback and partnered with the product group to tag accurate policies and knowledge by country, and to tune agent behavior and guardrails for localized content. They prioritized quick fixes and high-impact content gaps.

Updating the Employee Self-Service Agent to fix content mismatches in Europe North wasn’t about tweaking the AI in isolation. Instead, we needed to overhaul the content that the agent relies on.

“Instead of treating mismatches as failures alone, we used them as signals to improve the underlying content—revising articles, correcting categorization, and closing gaps in coverage. Over time, this combination of tightly scoped data sources, country-level tagging, and ongoing content curation turned the agent into a far more reliable assistant.”

David Finney, director, IT Service Management, Microsoft Digital

The team “grounded” the agent in a set of trusted, IT-approved sources: About 250,000 vetted knowledge base articles and 15-20 different internal SharePoint sites containing policies, guidelines, how-to articles, and related information.

Then they tackled regional nuances, one of the biggest drivers of content mismatches (when a user gets a reply based on content that doesn’t match their country or region). The team tagged content by geography (such as UK-only or Romania-only), so the agent would be fed the correct information for that geographic area.

The process of fixing mismatches also yielded insights.

David Finney, a director of IT Service Management in Microsoft Digital, frames the process as a clear lesson: AI is only as good as the content behind it, so the real work is often on the back end.

“Instead of treating mismatches as failures alone, we used them as signals to improve the underlying content—revising articles, correcting categorization, and closing gaps in coverage,” Finney says. “Over time, this combination of tightly scoped data sources, country‑level tagging, and ongoing content curation turned the agent into a far more reliable assistant.”

Impact and results

The Global Support team added a continuous feedback loop to keep the agent’s content aligned with reality. Users can flag low-quality and inaccurate answers directly through the agent interface. That data flows to a dedicated knowledge management team, creating an efficient pipeline for feedback to inform back‑end fixes and product improvements.

“We’re measuring success by a reduction in tickets, but that’s based on the user having a better experience using the Employee Self-Service Agent versus calling our global help desk and talking to a person. We can only be truly successful if we are creating a better experience for our users.”

Anders Jepsen, director, Field IT Management, Microsoft Digital

Today, the Employee Self-Service Agent’s metrics are moving in the right direction.

The team is optimistic as the Global Support Services data shows agent activity steadily increasing after it officially went live last October, as shown in the following image. At the same time, usage of Legacy Bot (an existing digital support chatbot) decreased, along with support interactions via phone, email, and web.

This data suggests the agent is meeting its ultimate goal: To provide users with an improved support experience, including better first‑touch answers that build employee confidence and yield faster issue resolution. This reduces escalation to human-run support channels and decreases the volume of tickets our employees have to create.

“We’re measuring success by a reduction in tickets, but that’s based on the user having a better experience using the Employee Self-Service Agent versus calling our global help desk and talking to a person,” says Anders Jepsen, a director of Field IT Management in Microsoft Digital. “We can only be truly successful if we are creating a better experience for our users.”

What’s next for self-service support

Our experience deploying the Employee Self-Service Agent in Europe North has allowed us to create a playbook for other small and midsize countries in similar situations, including dealing with multiple languages and specific regional policies.

“Our long-term ambition is to reduce our human-led support tickets by 40 percent. In some areas, like Europe North, we are already taking a significant step toward that.”

Trent Berghofer, general manager, Microsoft Digital Modern Support

The agent now serves as both a self-service tool and the first contact point for employee questions. It doesn’t completely remove humans from support, because if that first point of contact doesn’t resolve the IT issue, a team of humans is available to help.

In the end, the fewer support tickets that are opened, the more time employees can have back for higher-value tasks.

“Our long-term ambition is to reduce our human-led support tickets by 40 percent,” says Trent Berghofer, a general manager in Microsoft Digital Modern Support. “In some areas, like Europe North, we are already taking a significant step toward that.”

The Employee Self-Service Agent is a great example of using the power of AI to increase employee productivity and efficiency, as they access highly curated support through the tool on demand. It fits in with our company’s overall strategic efforts to evolve into an AI-driven Frontier Firm.

“The agent brings IT, HR, and facilities together in one place,” Dubuisson says. “It’s not just a Q&A bot. It gives you information, guides you, and even holds your hand through troubleshooting. The agent tells you what to do and can even do it for you. It standardizes, simplifies, and still lets you chat with someone or get a call back when you need it.”

Key takeaways

Here are steps organizations can take today to implement an AI-powered employee support hub:

• Evaluate your employee support systems. Assess whether employees have a single, trusted “front door” for support issues, or if your organization’s support is still fragmented across different tools.
• Audit local policy coverage in your AI solutions. Identify where tools may be defaulting to global or geographically incorrect content–especially in regions with multiple countries or languages–to validate accuracy and boost trust.
• Pilot localized AI support efforts in a diversified region. Engage regional HR, IT, and field adoption teams early on to make sure that AI experiences reflect real, country-specific employee needs.

Try it out

Learn all about the Employee Self-Service Agent.

Related links

• Check out our in-depth guide to deploying the Employee Self-Service Agent.
• See how we’re accelerating support services at Microsoft with the Employee Self-Service Agent.
• Read about how the agent improves campus and facilities-related support at Microsoft.
• Explore Microsoft Learn content about the Employee Self-Service Agent.
• Watch a Microsoft Ignite Session about the Employee Self-Service Agent.

The post Transforming IT support across Microsoft with the Employee Self-Service Agent appeared first on Inside Track.

Microsoft Azure DevOps (ADO) is our company’s end-to-end software development lifecycle (SDLC) solution for planning, coding, testing, and delivery. It combines tools for work tracking, source control, pipelines, and artifacts so teams can manage the entire SDLC in one environment.

Although ADO excels at streamlining the development process, we found that users were still spending significant time performing repetitive administrative tasks, like creating and breaking down work items, writing and managing queries for reporting, and reclaiming lost permissions.

Our Engineering Systems Platform team successfully embedded AI into ADO, resulting in ADO experiences that replace manual workflows and free up our IT professionals to concentrate on work that makes a real impact.

Identifying the opportunity

The Engineering Systems Platform team supports 15,000 active users across one of the largest ADO platforms at Microsoft.

“We saw the toll these processes took on users, whether they were compiling information or performing manual tasks. Even with automation, there was still an opportunity to give time back to engineers.”

Gopal Panigrahy, principal product manager, Microsoft Digital

Three years ago, the team began exploring opportunities to automate repetitive ADO tasks like creating and updating work items, navigating project data, gathering statuses, and breaking large initiatives into sprint-ready work.

While they found ways to automate some of these tasks, they discovered decision-making and information synthesis still consumed valuable time and occasionally introduced some human errors.

“We saw the toll these processes took on users, whether they were compiling information or performing manual tasks,” says Gopal Panigrahy, a principal product manager in Microsoft Digital. “Even with automation, there was still an opportunity to give time back to engineers.”

Adding AI to ADO workflows

ADO spans a vast area at Microsoft, serving a wide range of enterprise use cases and personas. What these workers have in common is heavy workloads. With this in mind, different categories of ADO users expressed the desire for AI-powered experiences that could help streamline workflows and speed up day-to-day development tasks.

As generative AI matured, our team explored whether they could embed AI technology inside ADO to act as a real-time assistant, handling administrative work and answering contextual questions using natural language.

“We saw it as a win-win experiment. If we could give engineers back in ADO, they could spend it building, not managing artifacts.”

Debashis Sahoo, principal group engineering manager, Microsoft Digital

The guiding principles of the experiment were simple: Stay in context and preserve user control while aligning with existing ADO permissions and processes.

That vision led to the creation of two complementary Microsoft Copilot agents: The DevOps Assistant and the AI Work Item Assistant.

“We saw it as a win-win experiment,” says Debashis Sahoo, a principal group engineering manager in Microsoft Digital. “If we could give engineers time back in ADO, they could spend it building, not managing artifacts.”

What makes this initiative distinctive is it brings AI closer to the core ADO product and its users. It allows for secure, confidential, and context-rich ADO data to be used safely for meaningful AI-powered experiences.

DevOps Assistant offers conversational, in-context support

DevOps Assistant is a chat‑based experience present in the ADO user interface (UI). It’s activated in a side panel where users can ask natural language questions to retrieve information, check project statuses, and run common DevOps actions without navigating away from their main ADO display.

The DevOps Assistant enables cross-source discovery, which reduces context switching and discovery time and helps lower the cognitive load for engineers and product managers. By reducing the time it takes to switch contexts and search for information, the DevOps Assistant helps ADO users move faster and stay focused on product delivery.

Under the hood, the DevOps Assistant is a constellation of specialized agents, each of which is focused on a different segment of the DevOps lifecycle:

• Work Item Agent creates, refines, and scopes work into sprint-ready backlogs
• Knowledge Board Agent surfaces the right DevOps knowledge at the right moment
• Permission Agent handles access and permission requests
• Bulk Complete Agent runs repetitive, large-scale updates
• Sprint Board Agent summarizes sprint status and provides instant, prompt‑driven insights

“We didn’t just build a chatbot. We built a distributed system of agents that understands the intent of the DevOps user and acts on it securely and in context.”

Apoorv Gupta, principal software engineer, Microsoft Digital

Agents are built in Copilot Studio and coordinated by Orchestrator Agent, Copilot Studio’s front door.

For example, if a user asks to create or refine work items, the Orchestrator Agent routes the request to the Work Item Agent to handle. If the question is about permissions, then it delegates the work to the Permission Agent. It does this for each task.

“We didn’t just build a chatbot,” says Apoorv Gupta, a principal software engineer in Microsoft Digital. “We built a distributed system of agents that understands the intent of DevOps user and acts on it securely and in context.”

At present, the DevOps Assistant is available across all our internal ADO environments at Microsoft. The plan is to make it available to external customers soon.

AI Work Item Assistant provides inline assistance

The AI Work Item Assistant is a real-time embedded experience within ADO work items. Powered by Microsoft Foundry, it helps users create and refine work items using context and business requirements.

The assistant works immersively, keeping users focused and within ADO as they structure work items or generate child items from the parent.

For product and program managers who start with high‑level ideas, the assistant understands intent. It can automatically suggest logical, sprint‑ready breakdowns, helping to dramatically reduce the time spent on planning, sorting, and prioritizing work items.

Turning newfound time into innovation

The key to reclaiming time for your workforce isn’t just the introduction of new AI-driven features. It’s using the technology to enforce structure and quality at the beginning, so that everything downstream moves faster.

Panigrahy describes the practice as three reinforcing feedback loops.

The first loop is upstream quality amplification. AI agents help consistently structure work items with clear acceptance criteria and templates. The structure then feeds other tools (such as GitHub Copilot), allowing them to generate higher-quality code and more predictable outcomes—shortening the overall software development lifecycle.

The second feedback loop is acceleration of execution. In a typical sprint planning session, a team of eight engineers might:

• Take an hour (or more) to manually break user stories into more than 100 tasks
• Create different tasks in their own style, introducing inconsistency and ambiguity
• Generate uneven details, then spend time clarifying data later

With DevOps Assistant and AI Work Item Assistant, that same task breakdown turns into a prompt-driven action that no longer requires hours of work.

“It burns a lot of time for everyone to manually create each item in their own way, making sure they’re using the correct inputs from the product manager and confirming they aren’t missing anything,” Panigrahy says. “Now, with AI magic, it takes less than three minutes.”

The third feedback loop is capacity reinvestment. Instead of spending hours on tactical DevOps mechanics, teams can now spend more time on engineering judgment, resulting in better estimation, technical decisions, and design. They can use these reclaimed hours to learn new tools, experiment with new agents, and innovate on the SDLC.

“Capacity saving keeps giving back, in a loop,” Gupta says. “You get more capacity back. You innovate. You learn. You do better.”

What’s next on the AI-in-ADO journey

The DevOps Assistant and the AI Work Item Assistant can help change user behavior, shifting from time spent doing tactical DevOps tasks to performing higher‑value, judgment-based work. These tools can help teams increase work quality and reduce wasted time.

“Our next chapter is about making AI smarter, more action-oriented, and truly agentic,” Sahoo says. “The goal is to reduce cognitive load and allow the experience to live wherever users are—from Azure DevOps to Microsoft Teams and Microsoft 365—so the agent works seamlessly across their workflow.”

AI-driven productivity gains are arguably the biggest opportunity in the industry. It’s fundamentally redefining the engineering experience at an unprecedented pace.

“While we’ve made huge strides embedding AI into the everyday Azure DevOps experience, it still feels like we’re just getting started,” Sahoo says. “Staying relevant means continuously evolving to deliver ever-greater value and efficiency to engineers.”

Key takeaways

Keep these tips in mind as you get started on your own journey with AI and Microsoft ADO:

• Treat AI as a strategic accelerator, not as an add-on. Identify where your engineering process can use AI to move from simple assistance to transforming your workflows.
• Target high-effort, high-volume tasks first. Analyze where your teams are spending significant manual time, even if AI tools are already in place in those workflows.
• Validate productivity with measurable data, not intuition. Track time reclaimed, workflow efficiency, reduction in manual steps, and user satisfaction. Tangible data can help your initiative earn trust and justify the expansion of AI tool use on your team.

Try it out

Get started using the AI Work Item Assistant in Azure DevOps.

Related links

• Discover how we’re powering the new age of AI-powered engineering in Microsoft IT.
• Learn how to build and manage agents in Copilot Studio.
• Read about ways we’re transforming our enterprise IT operations at Microsoft using AI.
• Check out our IT playbook for becoming a Frontier Firm in the era of AI.

The post Reclaiming engineering time with AI in Azure DevOps at Microsoft appeared first on Inside Track.

There was excitement, curiosity, skepticism, and no shortage of questions about what this technology meant for the future of IT.

At Microsoft Digital—the company’s IT organization—we didn’t start with a grand transformation plan. Instead, we started with a realization: AI wasn’t just another tool to roll out. It was a fundamental shift in how engineering work could happen.

For years, our IT teams have been focused on scale, reliability, and operational excellence. Those priorities didn’t change. What changed were the possibilities.

Suddenly, engineers could draft code in seconds, summarize complex systems instantly, or automate work that had once consumed hours or days. It was an opportunity to take the skills and capabilities of our people and amplify them with AI.

That realization forced us to step back and ask harder questions.

How do you help thousands of engineers understand what AI can actually do to impact their day-to-day work? How do you move from experimentation to trust? And how do you adopt AI in a way that strengthens engineering fundamentals instead of eroding them?

The answer came in the form of a phased journey grounded in people, culture, and continuous learning.

Phase 1: Awareness and access

It might sound surprising when speaking about engineering processes, but our first challenge wasn’t technology; it was understanding.

When generative AI entered the conversation, most engineers saw the headlines and dabbled in various tools, but few understood fully what it meant for their work. Some were excited, others were wary. Many simply didn’t know where to start. That gap between awareness and practical value was the first barrier we had to address.

We realized early that top-down mandates wouldn’t work. Telling engineers to “use AI” without context or relevance would only deepen skepticism. Instead, we focused on something both simpler and more difficult: Exposure.

We started by making AI visible and accessible in the tools engineers already used. GitHub Copilot. Microsoft 365 Copilot. Early copilots embedded directly into engineering workflows. The goal wasn’t immediate productivity gains. It was familiarity. Letting engineers see, firsthand, what AI could and couldn’t do.

“We encouraged tool usage and adoption so people would at least play around with AI. And once they did, they started seeing the value. That’s when the mindset shifted from ‘AI might replace me’ to ‘AI can be my companion.’”

Mukul Singhal, partner group engineering manager, Microsoft Digital

Just as important, we talked openly about limitations.

AI wasn’t perfect. It hallucinated. It made confident mistakes. And that honesty mattered. By framing AI as an assistant, we reinforced the role of engineering judgment. Engineers didn’t need to fear losing control. They needed to understand how to stay in control.

We also made experimentation safe.

No quotas. No forced adoption metrics. Engineers were encouraged to try AI on low‑risk tasks: summarizing documentation, generating test cases, or exploring unfamiliar codebases. Small wins built confidence, confidence built curiosity, and curiosity drove organic adoption.

As that experimentation took hold, the mindset began to shift.

“We encouraged tool usage and adoption so people would at least play around with AI,” says Mukul Singhal, a partner group engineering manager in Microsoft Digital. “And once they did, they started seeing the value. That’s when the mindset shifted from ‘AI might replace me’ to ‘AI can be my companion.’”

Over time, conversations changed from ‘Should we use AI?’ to ‘Where does AI help most?’

Engineers began sharing prompts, tips, and lessons learned with one another. What started as individual exploration turned into community learning. Awareness gave way to momentum.

Phase one was about providing access to explore, to question, and to learn. And that foundation made everything that followed possible.

Phase 2: Culture shift

Access created awareness and awareness created curiosity.

As more engineers began experimenting with AI, we noticed a pattern. Some teams were moving faster, learning faster, and reducing friction in their day‑to‑day work. Others stalled after initial trials. The difference wasn’t technical skill or capability, it was mindset.

“People started shifting from the mindset of ‘Will AI work?’ to ‘AI is working for me.’ I think that was a very transformational shift, to where I believe a lot of engineers in the organization started believing in AI.”

Veera Mamilla, principal group engineering manager, Microsoft Digital

To move forward, we had to shift how AI was perceived from something optional or experimental to something that was simply part of how modern engineering gets done.

That meant normalizing AI as a trusted partner in the engineering process.

Leaders played a critical role in that shift. Rather than positioning AI as a productivity shortcut, they framed it as a way to strengthen engineering fundamentals: clearer design discussions, better documentation, faster feedback loops, and more time for deep problem‑solving. The message was intentional and consistent. Using AI wasn’t about cutting corners, it was about reimagining how work gets done.

We also had to address a fear that surfaced early: that AI adoption was a signal of replacement rather than empowerment.

“People started shifting from the mindset of ‘Will AI work?’ to ‘AI is working for me,’” says Veera Mamilla, a principal group engineering manager in Microsoft Digital. “I think that was a very transformational shift, to where I believe a lot of engineers in the organization started believing in AI.”

That framing mattered.

As engineers incorporated AI into their workflows, success stopped being measured by output alone. The focus shifted to outcomes. Did AI help you understand a system faster? Did it surface risks earlier? Did it free up time to focus on higher‑value work?

Over time, AI stopped feeling like a novelty. It became part of the engineering fabric. We reinforced it through leadership modeling, peer learning, and shared success stories. Teams no longer asked whether AI belonged in their workflows. They asked how to use it responsibly and effectively.

Phase 3: Upskilling and role evolution

Once AI moved from curiosity to expectation, the challenge of skill building became unavoidable.

From the start, we made a deliberate choice: This would be an upskilling and reskilling journey, not a wholesale replacement of roles. The goal wasn’t a new workforce. It was an investment in the one we had.

That decision shaped everything that followed.

Early upskilling efforts focused on practical entry points. Prompt engineering. Tool literacy. Understanding how copilots and early agents behaved in real engineering workflows. We treated these as something every engineer needed to experiment with, regardless of discipline.

But it quickly became clear that skills alone weren’t the full story. Roles themselves were starting to evolve.

“Your title might still be software engineer or principal engineer. But if you’re acting like an AI engineer, what does that actually mean? That question helped us start defining how these roles were evolving.”

Ragini Singh, partner group engineering manager, Microsoft Digital

Across software development, service engineering, and cloud network engineering, the work was shifting from manual execution toward orchestration and oversight. Engineers were no longer expected to do every task end‑to‑end by hand. Instead, they were learning how to guide AI, review its output, and decide where automation made sense and where it didn’t.

As part of this shift, we began researching how the industry itself was redefining engineering roles. Leaders examined emerging job descriptions from across the market and compared them with Microsoft’s own role frameworks. At the time, there was no formal “AI engineer” role in the internal job library. Rather than creating a new title, the focus stayed on evolving expectations within existing roles.

The idea of an “AI‑native engineer” emerged not as a job description, but as a mindset.

An AI‑native engineer still understands systems, architecture, and risk. What’s different is how that expertise gets applied. Routine tasks are delegated to AI. Judgment, design, and accountability stay with the human. Engineers move from doing all the work themselves to supervising work done in partnership with AI.

“Your title might still be software engineer or principal engineer,” says Ragini Singh, a partner group engineering manager in Microsoft Digital. “But if you’re acting like an AI engineer, what does that actually mean? That question helped us start defining how these roles were evolving.”

This evolution looked different across disciplines. Software engineers focused on AI‑assisted coding, test generation, and spec‑driven development. Service engineers leaned into AI for incident response, knowledge capture, and operational decision support. Cloud network engineers began moving from manual intervention toward intelligent orchestration and agent‑assisted troubleshooting. The common thread wasn’t identical tooling, it was a shared shift toward higher‑order work and reduced toil.

Phase 4: Embedding AI across the engineering lifecycle

By this phase, we knew individual productivity gains were simply the starting point for larger and broader benefits.

Early on, most AI usage showed up in familiar places: Code suggestions, documentation summaries, quick answers. Useful, but fragmented. The bigger opportunity emerged when we stepped back and asked a harder question: What would it look like if AI were embedded across the entire engineering lifecycle, not just used at isolated moments?

We stopped thinking in terms of tools and started thinking in terms of flow. Design. Build. Test. Deploy. Operate. Improve. AI needed to show up across all of it, in ways that reinforced how engineers already worked.

“If AI is only showing up at one step, you don’t get the full value. The real impact comes when it’s integrated across the lifecycle, where engineers can design, build, operate, and learn faster as a system.”

Sudhakar Sadasivuni, principal group engineering manager, Microsoft Digital

In software engineering, that meant pulling AI earlier into the process. We began using it to help draft requirements, reason through design options, and review code with broader system context to accelerate how quickly we could get to informed decisions. Coding assistance mattered, but it was no longer the center of gravity.

Testing and quality followed a similar pattern. AI supported test generation, defect analysis, and code review, reducing repetitive effort and helping issues surface sooner. That gave engineers more time to focus on quality and architecture instead of cleanup.

In service engineering, we embedded AI into incident management and operational workflows. Engineers used it to summarize incidents, surface relevant knowledge, and analyze signals across systems. In cloud network engineering, AI helped shift work away from manual intervention toward orchestration and intelligent troubleshooting. Across disciplines, the principle stayed the same: AI should reduce friction, not introduce it.

As we scaled this approach, one thing became clear. Embedding AI wasn’t just a technical exercise. It was a systems change.

“If AI is only showing up at one step, you don’t get the full value,” says Sudhakar Sadasivuni, a principal group engineering manager in Microsoft Digital. “The real impact comes when it’s integrated across the lifecycle, where engineers can design, build, operate, and learn faster as a system.”

As AI became part of core workflows, engineers remained accountable for outcomes. AI output was reviewed, tested, and validated like any other engineering input. Embedding AI didn’t lower the bar for rigor. It raised expectations around judgment, oversight, and data quality. We became more deliberate about responsibility and governance.

Over time, these integrations created compound benefits.

Faster design cycles reduced downstream rework. Better testing lowered operational noise. Improved operational insight shortened recovery times. AI stopped being something we used occasionally and became something the engineering system itself was built around.

Phase 5: Eliminating toil and accelerating outcomes

At some point, every AI story hits the same test. Does it actually make engineers’ days better? For us, that proof showed up fastest in elimination of toil.

Across Microsoft Digital, engineers have always spent time on work that was necessary but draining. It included tasks such as manual troubleshooting, repetitive diagnostics, log analysis, and routine operational tasks that kept systems running but didn’t move the organization forward.

AI gave us a chance to change that.

“Toil reduction is the biggest thing. That’s where engineers’ eyes light up. If we can eliminate toil, people engineers will flock to use AI. I really believe it.”

Beth Garrison, principal cloud network engineer, Microsoft Digital

In cloud network engineering, for example, troubleshooting used to require manually reconstructing what happened, such as logging into devices, chasing configurations, and piecing together context after the fact. As we began introducing agents and machine learning into these workflows, that work shifted. Instead of spending time assembling the picture, engineers could generate the views they needed faster and focus on resolving issues.

The same shift showed up in how we used operational data.

Rather than reacting to incidents after impact, we started using machine learning to analyze logs, identify patterns, and surface anomalies earlier. That moved teams from reactive response toward proactive monitoring and prevention.

One thing became clear very quickly: Toil reduction wasn’t just a benefit; it was the catalyst for adoption.

“Toil reduction is the biggest thing. That’s where engineers’ eyes light up,” says Beth Garrison, a principal cloud network engineer at Microsoft Digital. “If we can eliminate toil, people engineers will flock to use AI. I really believe it.”

Service engineering followed a similar arc.

Across governance, operations, productivity, and cost management, we began applying agents and automation to simplify complex work and reduce manual review cycles. Governance and compliance workflows became faster and more consistent. Operational processes benefited from guided remediation and earlier insight. Knowledge capture improved as documentation and remediation guidance could be generated and updated automatically.

When we removed repetitive work such as manual triage, rote diagnostics, endless documentation cleanup, we transformed how engineers spent their time. More focus on design. More proactive problem‑solving. More energy directed toward improving systems instead of just maintaining them.

Toil reduction made the value of AI tangible. It’s the moment AI stopped being interesting and became indispensable, and our engineering teams started asking where else we can apply it next.

Measuring what matters

By the time AI was embedded across our engineering lifecycle, a new question came into focus: “How do we know it’s working?”

In the early days, we paid close attention to usage. Which tools engineers were trying, where adoption was growing, or where it stalled. Those signals mattered and adoption was the leading indicator that people were getting comfortable and starting to integrate AI into real work.

“Adoption was always the starting point. But we were clear from the beginning that usage isn’t the destination. The real goal is impact; more time for engineers to focus on the work that truly matters.”

Ullas Kumble, principal group software engineering manager, Microsoft Digital

But using AI doesn’t automatically mean better outcomes. So, we shifted the conversation and started asking, “What’s different now that our engineers are using AI?”

That change reframed how we thought about measurement. We began looking beyond tool activity to understand impact across the engineering system. Faster design cycles. Earlier defect detection. Reduced time spent on repetitive operational work. Shorter incident resolution. Clearer documentation. Fewer handoffs. Less rework.

These weren’t abstract metrics. They showed up in the flow of work.

We were intentional about not forcing a single definition of value across every role. Software engineers, service engineers, and cloud network engineers experience impact differently. What mattered was that each team could point to tangible improvements in how work moved through the system.

That perspective shaped how leadership talked about success.

“Adoption was always the starting point,” says Ullas Kumble, a principal group software engineering manager at Microsoft Digital. “But we were clear from the beginning that usage isn’t the destination. The real goal is impact; more time for engineers to focus on the work that truly matters.”

Over time, this approach changed the quality of our conversations. Instead of debating whether AI was worth the investment, teams talked about where it was removing friction and where it still wasn’t delivering enough value. Measurement became a tool for learning and prioritization.

Moving forward

Looking ahead, one lesson stands out: this journey isn’t complete.

AI tools will continue to evolve. Agents will become more capable. Roles will keep shifting. What it means to be an engineer will continue to change. And that means our approach must stay grounded in the same principles that guided us from the start: invest in people, reinforce fundamentals, embed AI into real workflows, and stay honest about what’s working and what isn’t.

We didn’t set out to build an AI‑driven engineering organization overnight, we built it phase by phase.

By meeting engineers where they were
By reshaping culture before redefining roles.
By embedding AI across the lifecycle, not bolting it on.
By reducing toil and measuring impact where it mattered most.

The result is better engineering: powered by AI, guided by human judgment, and built to keep evolving.

Key takeaways

Here’s a set of approaches you can take to establish AI-led engineering for your organization:

• Start with access and understanding. Give engineers safe, easy access to AI in the tools they already use so curiosity and confidence can develop organically before you push for outcomes.
• Frame AI as a partner, not a replacement. Position AI as an assistant that strengthens engineering judgment and fundamentals rather than a shortcut or a threat to roles.
• Normalize experimentation without pressure. Encourage low‑risk experimentation and peer sharing instead of mandates, allowing adoption to grow through visible, practical wins.
• Invest in upskilling. Focus on evolving skills and expectations within existing roles so engineers learn how to guide, review, and stay accountable for AI‑assisted work.
• Embed AI across the full engineering lifecycle. Look beyond isolated productivity gains and integrate AI into design, build, test, operate, and improve workflows to unlock system‑level impact.
• Measure impact where engineers feel it. Move past usage metrics and track outcomes like reduced toil, faster feedback, and improved flow so teams can see where AI is truly making work better.

Try it out

Try GitHub Copilot.

Related links

• Learn how an AI-led SDLC builds an end-to-end agentic software development lifecycle with Azure and GitHub.
• Discover why developers will lead AI transformation across the enterprise.

The post Powering the new age of AI-led engineering in IT at Microsoft appeared first on Inside Track.

Maybe you’re a product manager with a backlog that you can’t ever get to. Perhaps you’re a designer who can never seem to get engineering resources assigned to you. Or maybe you’re a program manager who routinely gets stuck copying data between systems by hand.

These are common challenges knowledge workers face everywhere, including here at Microsoft. A year ago, AI enthusiasts knew agents with tools could fix these problems—they just didn’t know where to start.

Some of our employees in Microsoft Digital, the company’s IT organization and Customer Zero for the company, took a grassroots approach to solving this problem. They built something called the Frontier Forge, our pro‑code “harness” that enables our less-technical employees to get work done with agents. They use it to quickly build agentic instructions and instantly share their solutions with peers, which accelerates our productivity across the company.

The Frontier Forge represents a cultural shift in how our product managers, designers, program managers and other “I’m not an engineer but I want to build stuff” employees now apply AI tools directly to their work.

What first began as a hackathon experiment has evolved into a thriving Microsoft-internal community with nearly 100 engaged contributors, an active Teams channel, and a GitHub repository filled with templates, learning modules, and ready-to-use AI agents. The impact is measurable: Forecasting, backlog grooming and communication tasks that collectively took weeks now take hours or minutes.

“I saw myself and others spending too much of our time on data wrangling and admin tasks when we wanted to be strategizing. Nobody was building what felt truly agentic. So, we did it ourselves.”

Brett Reifers, senior product manager, Microsoft Digital

Employees who never saw themselves as technical are now building sophisticated data visualizations, automating workflows, creating prototypes, and generating learning modules. These were capabilities previously reserved for specialized engineering teams.

The “Forge” is where it’s all happening now.

From a hackathon to a movement

In early 2025, Brett Reifers, a senior product manager in Microsoft Digital, spotted a problem he couldn’t ignore. His peers, smart and driven product managers, kept asking the same question: “How do I use agents for my actual work?”

Beginner tutorials about prompt engineering felt trivial. Advanced agents with tools assumed engineering expertise. The middle ground, where AI meets real jobs, didn’t exist.

“I saw myself and others spending too much of our time on data wrangling and admin tasks when we wanted to be strategizing,” Reifers says. “Nobody was building what felt truly agentic. So, we did it ourselves.”

So, Reifers partnered with colleague Humberto Arias, a senior product manager in Microsoft Digital whose work explores the intersection of AI and productivity. Arias had been independently researching agentic solutions that could click through interfaces, open applications, and complete tasks autonomously.

The insight that unlocked everything came from a deceptively simple observation:

“Everything on the internet is a form—every site, mobile app, every click,” Reifers says. “If agents could fill out my forms in Azure DevOps, they could handle any web-based task.”

They pitched the concept of Copilot fulfilling form-based processes as an entry for Microsoft’s annual hackathon to Sean MacDonald, partner director of product management in Microsoft Employee Experience. MacDonald immediately recognized its potential.

“My reaction was simply, ‘This sounds amazing,’” MacDonald says. “This solution was exactly what we needed.”

The event proved agents could automate PM workflows: managing Azure DevOps items, generating summaries, and querying data systems. After the hackathon validated the concept, Arias suggested pushing the project to GitHub for wider exposure. Reifers then used GitHub Copilot itself, recursively using the very tools they were building, to open source the first Frontier Forge repository in 15 minutes.

A pro-code environment with natural language accessibility

The Forge combines GitHub Copilot, Visual Studio Code (VS Code), and MCPs into a framework that makes professional development tools easily accessible to non-engineers.

“The Frontier Forge is a place where you can learn regardless of your skill level. You can adopt what’s out there, even if you don’t know where to start.”

Sean MacDonald, partner director of product management, Microsoft Employee Experience

The core idea: Give employees a workspace seeded with community-created templates, learning modules, and custom agents tailored to Microsoft Digital contexts. Then let them build from there.

For MacDonald, the Forge has proven to be an accessible entry point for almost anyone, regardless of experience.

“The Frontier Forge is a place where you can learn regardless of your skill level,” MacDonald says. “You can adopt what’s out there, even if you don’t know where to start.”

An architecture for context-first AI

The technical architecture of The Frontier Forge leverages three layers simultaneously:

• VS Code provides the enterprise managed workspace where everything happens.
• GitHub Copilot offers chat functionality and AI assistance, with access to multiple models including Claude, GPT, and Gemini.
• Tools like Model Context Protocols (MCPs) act as standardized connectors that let agents access tools, data, and services locally. This unlocked what Copilot could decide and do with user approval.

“With GitHub Copilot and MCPs, there are literally no boundaries. It’s hard to explain just how transformational this can be for a product manager. Whatever you ask is transformed into code with a purpose, allowing you to do something you couldn’t before.”

Humberto Arias, senior product manager, Microsoft Digital

The MCPs connect to services like Azure DevOps (for roadmap planning and backlog management), Microsoft Documentation, Figma (for design work), and dozens of other platforms that are essential to product manager workflows. New MCPs appear daily, expanding capabilities organically as the community builds them.

Employees can even ask GitHub Copilot to build custom MCPs for services lacking official integrations. When Arias needed a PowerPoint creator that didn’t exist, he asked GitHub Copilot to create one.

“With GitHub Copilot and MCPs, there are literally no boundaries,” Arias says. “It’s hard to explain just how transformational this can be for a product manager. Whatever you ask is transformed into code with a purpose, allowing you to do something you couldn’t before.”

The shift from prompt engineering towards context engineering is another reason why the Forge works. Its workspace settings, agent instructions, skills and hooks provide a harness with guardrails that help colleagues adopt and use this.

The Forge provides a curated starting point: Microsoft Digital-specific templates, governance frameworks, security guidelines grounded in Microsoft’s Responsible AI framework, and working examples employees can immediately use and modify.

Transformational impact

The productivity gains generated by The Frontier Forge are very real. Our employees report saving weeks or even months on certain projects, especially those that previously required extensive manual work or specialized technical skills.

Case in point: Laura Oxford, a senior content program manager in Microsoft Digital, had four years’ worth of Excel files and communication metrics reports. She had always intended to use the data to create marketing forecasts, but she could never find the necessary time or resources to perform the analysis.

“The key to creating the agent was going deep into the context. It was an iterative conversation, going back and forth to fine-tune the agent until I was consistently getting the output I wanted. But it truly was just a conversation—no tech skills needed.”

Laura Oxford, senior content program manager, Microsoft Digital

Through iterative, conversation-based prompting, Oxford’s agent analyzed patterns, created projections, and produced visualizations. Oxford now has a robust historical analysis that enables prediction of future campaign performance.

“The key to creating the agent was going deep into the context,” Oxford says. “It was an iterative conversation, going back and forth to fine-tune the agent until I was consistently getting the output I wanted. But it truly was just a conversation—no tech skills needed.”

Drafting clear, executive-ready communications for complex initiatives was what brought Mark Stratford, a senior product manager with the email and calendaring service team in Microsoft Digital, to the Forge.

Before the Forge, communicating status updates to leadership meant he had to manually synthesize data from CSVs, track several approval chains at once—often in messy emails—and iterate on visualizations for what seemed like days and days.

Put more succinctly, these tasks are time-consuming chores that are perfect for AI.

“The Forge’s architecture changes how you think about the problem,” Stratford says. “Instead of iterating on prompts, you declare intent and desired outcome. The Forge’s architecture handles the rest.”

Using this pattern, Stratford created:

• Over a dozen interactive dashboards for portfolio roadmaps, migration tracking, and service health monitoring.
• Approval matrix visualizations mapping multi-stakeholder sign-off dependencies.
• Data analysis pipelines transforming raw telemetry into executive-ready narratives.

“I didn’t need to fight ambiguity or handhold the model. The architecture gave the agent a stable, skills-driven foundation from the start, which dramatically accelerated development time and improved clarity.”

Mark Stratford, senior product manager, Microsoft Digital

The Forge’s clean separation between intent, constraints, tools, and data inputs eliminated the prompt-tuning loop. Stratford mapped his objectives into the agent framework once, relying on built-in structure and guardrails.

His analysis and drafting time dropped from days to minutes. Outputs like roadmaps and data visualizations went directly into decision workflows with no manual cleanup required.

“I didn’t need to fight ambiguity or handhold the model,” Stratford says. “The architecture gave the agent a stable, skills-driven foundation from the start, which dramatically accelerated development time and improved clarity.”

Building community and sharing knowledge

A simple continuously improving repository has grown into something larger: a community of nearly 100 enthusiasts. Contributors are building templates, learning modules, and specialized MCPs tailored to their job functions. Teams are sharing wins and unlocked achievements.

“At its core, The Frontier Forge is an open-source, community‑driven experience. It’s a safer environment that will help people learn and apply Microsoft’s AI at work.”

Brett Reifers, senior product manager, Microsoft Digital

The Forge succeeds because of its emphasis on community and knowledge sharing. Its GitHub repository serves as collaborative workspace where employees contribute agents, templates, and learning resources.

This sharing culture creates a compounding cycle. One employee’s outcome becomes another’s starting point. Contributors share useful agents immediately, without lengthy approvals. This grassroots approach lets innovation spread at the pace of curiosity.

“At its core, The Frontier Forge is an open-source, community‑driven experience,” Reifers says. “The Forge is a safer environment that will help people learn and apply Microsoft’s AI at work.”

Building a safe-to-fail path

For IT leaders looking to replicate something like the Forge, MacDonald’s guidance starts with reframing the challenge.

“Find the people who are super curious and who want to learn. They will be the ones who drive innovation with AI agents and other newly developed tools.”

Sean MacDonald, partner director of product management, Microsoft Employee Experience

The barrier to agent adoption for non-engineering roles isn’t access to tools. It’s all about giving them the confidence needed to build them and then put them to work. Providing a safe, hands-on environment where people can learn at their own pace, regardless of skill level, has been an essential key to success.

Another key has been to empower the people in your organization who are eager to innovate and try new things. The Forge began with two curious product managers who decided to experiment and then shared their idea with peers.

“Find the people who are super curious and who want to learn,” MacDonald says. “They will be the ones who drive innovation with AI agents and other newly developed tools.”

For IT leaders currently trying to prepare their organizations for an AI-driven future, the story shows that the answer isn’t to wait around for perfect tools or comprehensive employee training.

“The leaders that create safe spaces for non-engineers to build with AI now will compound that advantage for years,” Reifers says. “The ones that wait will spend 2027 trying to catch-up.”

Our knowledge workers don’t need to wait for help any longer, now they can forge their own path with an agent or other AI tool they build themselves.

Key takeaways

Here are some insights your leaders can use to build grassroots-led, AI-forward communities in your organization:

• Start with volunteers, not mandates. The Forge grew to 100 contributors with zero top-down requirements. Organic growth from curious employees creates sustainable adoption.
• Highlight your quick wins. Reifers’ and Arias’ live demos of MCPs, Oxford’s 90-minute forecast and Stratford’s 20-minute drafts became the recruiting pitch for the next wave of adopters. Show your people results like these, then hand them the tools.
• Lower barriers without lowering standards. Accessibility and quality aren’t mutually exclusive. Governance and security are non-negotiable. Configure it all into the harness.
• Prioritize knowledge sharing and attribution. When one person solves a problem and shares it, dozens benefit immediately. Reward provenance.
• Ship fast, improve later. The Forge repo was built in 15 minutes. Four months later, it contained 50+ templates and agents. As much of 80% what is produced in the Forge is rewritten every other week as tools evolve. Ship MVPs and evolve based on real usage.
• Reframe outcomes > tools. Shifting from “developer tool” to “Copilot workspace” helps knowledge workers see they belong.

Try it out

Start building and sharing AI agents today with GitHub Copilot.

Related links

• See how we enable Microsoft employees to build AI agents that help them complete important tasks.
• Learn more about GitHub Copilot for Azure.
• Discover how we’re transforming our employee experience with AI. 
• Take a course on building AI agents for beginners in GitHub Copilot.
• Follow our step-by-step guide to building API-powered agents. 
• Find out how continuous improvement helps us identify agentic opportunities, and how it can help your company, too. 

The post The Frontier Firm: How knowledge workers are forging their own AI tools at Microsoft appeared first on Inside Track.