At Microsoft Digital, the company’s IT organization, we manage an enterprise network that supports employees, services, devices, and business-critical operations around the world. Over the years, we’ve invested heavily in automation, infrastructure as code, and self-service capabilities to improve consistency and reduce operational overhead.

But as our environment has grown, so has the number of systems, workflows, repositories, and tools that our engineers have to navigate. So we decided to take a different approach. We asked, “What if engineers only needed to describe the outcome they wanted, instead of manually figuring out which tools to use?”

That idea became the foundation for Autonet AI Agent, our natural language platform for network configuration management that is saving us time and driving greater efficiency for our engineering teams.

Creating a ‘conversational front door’

In the past, our network engineers often needed to know where information lived before they could solve a problem. Different workflows required different tools, and different tasks relied on familiarity with a variety of systems.

A single network request could start a complex workflow. where engineers needed to gather information from multiple tools and systems. They might use one tool to review existing configurations, another to validate the current state, and still others to identify affected devices, generate changes, prepare rollback plans, and route updates through established governance processes.

Autonet AI Agent simplifies that process by giving our engineers a single place to start.

When engineers access the portal, they use natural language to describe the outcome they’re looking for. We describe it as a “conversational front door.”

The agentic platform gathers the required information and context, then coordinates the appropriate actions. It also alerts a human engineer for approval before making any changes.

Specialized agents support specific network configuration tasks. For example, our IP Helper Agent retrieves IP helper data. Our Core WAN agent manages configuration templates.

“The goal was to create a conversational front door that could connect people with the right network data, workflows, and specialist capabilities without requiring them to understand everything happening behind the scenes.”

Sai Madhav Tiruvuri, senior product manager, Microsoft Digital

Agents also work together more broadly. For example, our IP Helper Agent can connect with our Intake Agent, which is responsible for handling incoming workflows. Autonet AI Agent coordinates these workflows, reducing the number of systems that network engineers manage directly.

“We wanted engineers to focus on outcomes rather than tooling,” says Sai Madhav Tiruvuri, a senior product manager in Microsoft Digital. “The goal was to create a conversational front door that could connect people with the right network data, workflows, and specialist capabilities without requiring them to understand everything happening behind the scenes.”

It wasn’t just up to our platform team to develop the agents that make up this solution. Because we’re committed to Frontier Transformation at Microsoft, we’re actively exploring ways for every team to put AI to work, build trust, and scale transformation across everyday workflows.

As a result, we’ve been empowering different network engineering teams to build their own agents. To support their work, we’ve implemented review and governance processes to ensure they meet our standards for security, privacy, and responsible AI.

As we created Autonet AI Agent, we collaborated with those teams to understand their needs. From there, we incorporated the agents they had already created into the platform by designing the portal, shell, components, and model context protocol (MCP) rules and servers that connect all of the pieces.

This approach capitalizes on the expertise of teams that know the work best while giving our engineers a simpler experience overall. It also allows the platform to accommodate new capabilities. We can add new agents for specialized tasks behind one consistent interface, and engineers will use the same entry point as new workflows and agents become available.

Building on a trusted source of truth

Before we introduced agentic AI into network engineering workflows, we focused on something more fundamental: trusted data.

We knew that any agentic experience would only be as useful as the information available to the agent in question. Rather than connecting AI to multiple disconnected systems, we grounded it in a single, governed source-of-truth repository that captures configuration data.

This repository provides a common foundation for engineers, APIs, partner tools, automation workflows, and AI-powered experiences. As a result, we can funnel trusted network data through a consistent interface.

The lesson applies beyond networking. Any organization that’s interested in agentic workflows should first focus on establishing authoritative operational data.

“The opportunity wasn’t simply to replace our existing automations. We wanted to reduce the effort required to prepare work for automation and help engineers move more quickly from intent to action.”

Faris Mango, principal software engineering manager, Microsoft Digital

The quality of the experience depends on the quality of the underlying source of truth. From there, AI can help users find, understand, and act on information.

Combining AI with deterministic automation

Many network operations processes are deterministic by design. Validation routines, deployment pipelines, approval workflows, and configuration distribution systems all depend on predictable and repeatable outcomes.

As part of our agentic workflows, existing automation continues to perform deterministic steps. But on top of those more rigid automations, our new agents support processes that require interpretation, coordination, and connections across systems.

This division of work became an important design principle. We use AI for interpretation and coordination, and deterministic automation for predictable execution.

“The opportunity wasn’t simply to replace our existing automations,” says Faris Mango, a principal software engineering manager in Microsoft Digital. “We wanted to reduce the effort required to prepare work for automation and help engineers move more quickly from intent to action.”

Making network engineering jobs easier

Network configuration rendering and validation was one of our first use cases.

Configurations rely on templates, business logic, and facts stored in source-of-truth systems. Small changes can affect how we render configurations across multiple device types and deployment scenarios.

Traditionally, testing those changes could require significant manual effort. Engineers might need to compare template versions, validate outputs, investigate unexpected behavior, and move information between systems.

With Autonet AI Agent, users initiate those workflows in one place using natural language. Engineers can retrieve network facts, render configurations using current source-of-truth information, compare results across versions, identify differences, and investigate issues in a process that looks more like a conversation than navigating a series of tools.

“The more conversational experience makes it easier to test changes, compare outputs, understand what changed, and continue iterating until the configuration behaves the way you expect.”

Pruthvish Panakanti, senior network engineer, Microsoft Digital

Imagine a network engineer who receives a ticket requesting a configuration update. Once they’ve accessed Autonet AI Agent, the platform would execute the following steps as part of an agentic workflow:

1. Interpret the request’s intent
2. Identify affected devices and locations
3. Retrieve relevant configuration information
4. Compare current and intended states
5. Detect potential conflicts
6. Generate proposed configuration updates.
7. Create rollback guidance
8. Produce reviewable artifacts

“Rendering and validating changes used to involve a lot of manual comparison,” says Pruthvish Panakanti, a senior network engineer in Microsoft Digital. “The more conversational experience makes it easier to test changes, compare outputs, understand what changed, and continue iterating until the configuration behaves the way you expect.”

The benefit extends beyond the configuration change itself. Before engineers can decide what to do, they need to assemble a reliable picture of the current environment and understand how a proposed update might affect it. That preparation can require gathering network facts, reviewing existing configurations, comparing intended and current states, and identifying potential conflicts.

“A significant amount of operational work happens before we ever make a configuration change. Engineers spend time gathering context, validating information, and making sure they have what they need. That’s where these conversational workflows remove friction.”

Christopher Kuilan, senior cloud network engineer, Microsoft Digital

Autonet AI Agent brings those steps into a connected workflow. Instead of manually moving information between systems, engineers can use a conversational experience to retrieve relevant context, examine differences, and develop a proposed change for review. The platform can also prepare supporting artifacts and rollback guidance, helping engineers evaluate the change before deciding whether it should proceed.

This allows engineers to spend less time assembling the inputs needed for a decision and more time applying their expertise. The platform does not remove that responsibility. It makes the information easier to access and review while keeping engineers in control of the final decision.

“A significant amount of operational work happens before we ever make a configuration change,” says Christopher Kuilan, a senior cloud network engineer in Microsoft Digital. “Engineers spend time gathering context, validating information, and making sure they have what they need. That’s where these conversational workflows remove friction.”

Preserving governance and human review

Introducing AI into infrastructure operations requires robust governance. Throughout development, we prioritized human-in-the-loop oversight as a requirement.

For us, trust depends on transparency. Engineers need visibility into how agents generate recommendations and the ability to inspect supporting information before taking action.

“We wanted to make it easier for engineers to get the information they need while keeping governance and review in place.”

Darron Sullivan, principal software engineer, Microsoft Digital

Autonet AI Agent can retrieve information, prepare recommendations, generate artifacts, and help users understand potential actions. But engineers remain responsible for reviewing recommendations and determining whether proposed changes should move forward.

When an agent proposes an action or change, the platform alerts an engineer and waits for approval.

“Agentic systems are most effective when they’re working in established operational controls,” says Darron Sullivan, a principal software engineer in Microsoft Digital. “We wanted to make it easier for engineers to get the information they need while keeping governance and review in place.”

Looking ahead

We’re currently piloting Autonet AI Agent across a relatively small set of processes, but we see it as the beginning of a broader platform approach rather than a standalone solution.

“When we can bring the right information, automation, and specialized capabilities together through one experience, our engineers can spend less time figuring out which system to use and more time applying their expertise to the network.”

Jason Thompson, principal group product manager, Microsoft Digital

And we’ve already seen impressive results. In some cases, IP helper data retrieval that used to take up to three weeks can now be accomplished within a day or less.

The conversational front door gives us a framework for introducing additional specialist capabilities over time while still maintaining a consistent user experience. As more workflows and domains become available, engineers can continue interacting through a familiar interface while the platform expands behind the scenes.

“When we can bring the right information, automation, and specialized capabilities together through one experience, our engineers can spend less time figuring out which system to use and more time applying their expertise to the network,” says Jason Thompson, a principal group product manager in Microsoft Digital. “That’s where we see the real value of this technology.”

Autonet AI Agent reflects how we’re applying agentic AI to our own network operations at Microsoft. Organizations interested in building similar agentic experiences can explore the Microsoft agent ecosystem to determine the right approach for their needs. Get started with Microsoft Agent 365 to manage and govern agents across your organization or explore our agent development tools to build your own solutions.

The post Turning network configuration management into a conversation at Microsoft with Autonet AI 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.

On the Infrastructure Engineering Services (IES) team within Microsoft Digital, our product managers (PMs) support the tools and services that keep Microsoft’s global network secure, resilient, and available. As Microsoft’s Customer Zero, our larger Microsoft Digital team—the company’s IT organization—is exploring how AI can accelerate individual tasks and help reshape the operating model that our PMs use to plan, govern, and communicate their work.

“One of the key things we do is make sure the most important work is getting done by the engineering teams, because our engineers are a pretty precious resource,” says Martin O’Flaherty, a principal PM manager in IES. “We need to be able to prioritize the work as it flows in. We have to understand what the engineering teams need, make trade-off decisions constantly, and make sure we’re delivering requirements and specifications that are essential for building the right thing.” 

That has led O’Flaherty and his team to experiment with AI across a broader Continuous Planning model. Rather than treat planning as a periodic exercise, this approach creates an ongoing view of the work in progress as well as upcoming priorities, deliverables, engineering investment, and strategic alignment. Planning dashboards, engineering-capacity visibility, ADO data quality, recurring leadership reviews, monthly delivery reporting, and AI-generated summaries work together as parts of the same operating model.

“We need to make sure that we’re getting the right level of leadership visibility and support. Senior leaders understand that engineering resources are finite, so they want to make sure we’re investing the right amount of resourcing in the appropriate areas.”

Martin O’Flaherty, principal PM manager, Microsoft Digital

The objective isn’t simply to automate existing PM tasks, but to also create a better feedback loop between planning, execution, data quality, reporting, and decision making, giving our PMs more time to work directly with customers and engineering partners.

Turning planning data into leadership insight

As a product management leader, O’Flaherty often has to gather reporting on his team’s scenarios, including which are active versus closed, how the work aligns to organizational priories, and how engineering capacity is being invested. This not only helps him and his team make better prioritization and trade-off decisions but also provides crucial information for advocating with senior leadership.

“We need to make sure that we’re getting the right level of leadership visibility and support,” O’Flaherty says. “Senior leaders understand that engineering resources are finite, so they want to make sure we’re investing the right amount of resourcing in the appropriate areas.”

Most of that data already exists within systems such as Azure DevOps. The challenge is gathering the information and turning it into easily digestible insights. For O’Flaherty, that became an opportunity to use AI not simply to automate reports but also to connect planning data, data quality, and leadership reporting together into a more continuous system.

To accomplish this, O’Flaherty and his team built an AI-assisted reporting capability that can comb through all scenarios completed during the previous month, organize them around established strategic priorities, and summarize the details into leadership-ready reporting and visualizations. These show where the engineering investment is going and outcomes that the organization is delivering.

Below is an anonymized example of a dashboard O’Flaherty might use in an operational planning discussion or business review to provide near real-time visibility into planning health, delivery progress, resource allocation, and overall execution:

Early on, the AI-generated reporting wasn’t always accurate or complete.

Rather than treating those missing details as an AI problem, O’Flaherty and team used them to improve the system around it. He and the team refined the reporting logic, strengthened the underlying planning data, and improved how this capability weighs the documented evidence of what was actually delivered. Human review remains an important part of the process, but the amount of manual effort required has fallen significantly.

“Last month, we had almost no feedback. We looked at the report and were like, ‘Yep, it’s good to go,'” O’Flaherty says. “We’re talking about a task that used to take weeks to do. It would be the end of August by the time you’d have July’s report. We can now send that report on the first day of August.”

During this process, O’Flaherty also learned the importance of clean, comprehensive data in getting the right outputs. Initially, missing or inconsistent information in Azure DevOps could lead to incomplete insights. And because that same planning data informs leadership reporting, improving the quality at the source became more important than improving the AI consuming it.

So, he built a second AI-assigned “hygiene” capability that continuously checks in-scope scenarios against a defined set of rules. It can identify data gaps and prompt team members with specific guidance on how to fill those gaps within Azure DevOps.

“The agent has driven the right behavior, and that’s honestly the key reason why our end-of-month reports don’t really require much human review anymore.”

Martin O’Flaherty, principal PM manager, Microsoft Digital

Together, the capabilities create a feedback loop: Better planning data produces better AI-generated insights, while AI continuously helps identify the data-quality issues that could undermine those insights.

“At the end of the day, the AI can only be as accurate as the data it has in front of it, and we were potentially making bad decisions based on that data,” O’Flaherty says. “The agent has driven the right behavior, and that’s honestly the key reason why our end-of-month reports don’t really require much human review anymore.”

Upskilling a diverse workforce

A common misconception with agents is that you need to be an AI expert to build one. O’Flaherty wanted to remove that barrier by making the process accessible to all product managers with a wide range of technical expertise. The goal was to teach people about AI and also encourage them to build capabilities against real problems in their own workflows.

As he and other team members developed their skills, they created short how-to videos of their process that broke the learning curve down into manageable steps. He began this effort by assuming the viewers knew nothing about the tools.

“We made a video on how you install Visual Studio Code, how you log into GitHub Copilot,” O’Flaherty says. “And then when you’ve done that, here’s how you access an MCP server.”

Those bite-sized explainers gave PMs a practical path into the tools and helped them to get comfortable applying what they learned directly to their own work. Rather than requiring everyone to become an AI expert first, the approach allowed people to start small, solve something useful, and build their skills through experience.

But as adoption grew, another challenge emerged: Product managers sometimes created multiple agents to solve similar problems. That presented a different scaling question: How do you encourage experimentation without recreating the same solution over and over again?

In response, the team began promoting reusable skills and encouraging PMs to build on existing work rather than starting from scratch.

“Our challenge was, how do we empower people to build without removing all the efficiencies?” O’Flaherty says. “We’ve partially solved that by creating a repository that gives people an easy way to upload stuff and encourages them to reuse where they can. Or to take the skill that’s there and customize it for their organization.”

That shift, from individual experimentation to reusable building blocks, helped turn AI adoption into more of a shared engineering discipline. PMs could still tailor capabilities to their own needs, but successful patterns could be reused, improved, and extended instead of repeatedly rebuilt.

Speeding up product planning and prototyping

For individual PM contributors, agents have made context gathering faster and simpler.

For example, Astha Sinha, a senior product manager on the IES team, says sorting through documents, meeting notes, and the various stacks her team leverages and turning that into reports could take hours every day. That was before she started using Copilot to summarize all the information for her.

Now she uses agentic skills to automate the reports that she sends to different PMs each month, further simplifying her everyday routine.

“One of the biggest benefits has been automation, which I’m empowered to achieve very easily,” Sinha says. “I support multiple partners, all with different reporting rhythms, so I created a set of skills that automatically generate reports for them on the right schedule.”

What used to be a recurring manual task for her now happens in the background. It’s reduced administrative overhead and freed up more time for strategic product work, making her workload lighter.

“Now, by making my agent aware of the code base and incident reporting, and stitching together the logs and the data models, I can get that insight faster without using engineering time. Then I can take it back to my customers and actually get down to what really matters to them.”

Owais Khan, senior product manager, Microsoft Digital

Senior product manager Owais Khan, who also works on the IES team in Microsoft Digital, has also set up agents to analyze usage data.

Previously, it might have taken him a few hours to sit down and look at where customers are clicking, what kind of APIs they’re using, and what their call patterns look like, then actually investigate improvements on that site.

“Now, by making my agent aware of the code base and incident reporting, and stitching together the logs and the data models, I can get that insight faster without using engineering time,” Khan says. “Then I can take it back to my customers and actually get down to what really matters to them.”   

AI builder tools like Copilot Studio also provide a low-code solution for product managers that allows them to produce prototypes communicating their vision to engineers.

Nevedita Mallick, a principal product manager on the IES team, owns a lot of the UI experience on our corporate network. Her typical process for prototyping used to be to create a one-pager, then build out the idea manually in Figma.

“With Copilot Studio, it’s much faster,” Mallick says. “Things that used to take a day or two I can now be done in less than an hour, even in minutes. I can give a very rough sketch to Copilot Studio and it’s able to render the mockup really quickly. It also gives me the complete HTML with all the CSS and JavaScript, so I can just click through and explain to my developers, ‘This is what I want,’ or, ‘This is the enhancement I’m looking for.'”

Using AI-generated prototypes, PMs can also show customers interactive experiences earlier in the design cycle. This helps everyone align on requirements faster and reduces the amount of work required later in the development cycle.

The value of AI is amplified through thoughtful prompting and clear context.

“Prompting is everything,” Mallick says. “When troubleshooting a network issue, I asked Copilot to think like a network engineer so it could evaluate the problem through the lens of network topology, dependencies, and operational context. It moved from delivering generic answers to providing insights tailored to the problem at hand.”

The result, she says, is that the quality of your outcome is directly tied to the context and expertise you bring into the prompt.

“What once required specialized expertise and significant development time can now be done in minutes. For example, I recently created a custom skill for a specific business need in under five minutes, allowing me to move from idea to solution almost instantly.”

Astha Sinha, senior product manager,
Microsoft Digital

Practice truly does make perfect. Creating their first agents took some time, but the PMs say that the ramp-up period has significantly shortened the more they do it.

“What once required specialized expertise and significant development time can now be done in minutes,” Sinha says. “For example, I recently created a custom skill for a specific business need in under five minutes, allowing me to move from idea to solution almost instantly.”

The future of PM work

The PMs all agree that human oversight of agentic AI will always be necessary, even as they allow agents to take over some tasks.  

O’Flaherty notes that even as his agent can estimate time spent on scenarios, there are still a lot of nuances in how productivity is evaluated.

For example, while the agent can predict how many hours a specific task might take, someone also needs to factor in who’s completing the task and how fast they can work. There’s also the need for a fact-checking pass. Because of these variables, O’Flaherty believes we still need humans to gather the full picture and oversee the process.

“We’ve become agent bosses—the agents do the work and we review and approve it,” he says. “We’re almost like a governance layer for the agents in how we do our work.”

“The real opportunity with agents isn’t just efficiency, it’s prevention. By embedding intelligence throughout the operational lifecycle, we can identify and address issues before they become incidents, fundamentally changing how we operate at scale.”

Nevedita Mallick, principal product manager, Microsoft Digital

PMs are also already seeing how their work has changed, and that it will continue to evolve in the age of AI. Mallick observes how AI is enabling product managers to have more room for deep, critical thinking and broader product vision work. She’s excited to see how agents work proactively down the line.

“The real opportunity with agents isn’t just efficiency, it’s prevention,” Mallick says. “By embedding intelligence throughout the operational lifecycle, we can identify and address issues before they become incidents, fundamentally changing how we operate at scale.”

The team’s ultimate goal isn’t to automate product management, but to make it easier for PMs to apply their expertise where it matters most.

As Microsoft Digital continues its important Customer Zero work, that mission is helping shape how product managers use AI to scale their impact while maintaining human judgment, collaboration, and accountability.

The post Boosting product manager productivity at Microsoft with AI 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.

In those early days, training sessions, nudges, champions, and outreach campaigns kept us learning and growing through experimentation—but it was difficult to build momentum.

Today, the situation is fundamentally different. With the growing acceptance of agentic AI, adoption seems less like pushing a boulder and more like tending a garden where a million flowers bloom. It’s something we cultivate rather than force, planting seeds that continue to grow as our people discover new possibilities for themselves and their teams.

How did that shift happen? A great example comes from the experience of our field teams in Microsoft Europe South.

As they discovered, the challenge of enterprise AI has definitely changed. Adoption today is no longer the primary obstacle. As agents become easier to build and use, the harder questions are shifting towards governance, trust, and helping teams navigate a safe path from experimentation to production.

Early challenges with AI adoption: The prompt gap 

The generative AI era has taught us discipline. Rolling out Microsoft 365 Copilot at scale across a company of more than 200,000 employees was never really about the model. It was about the unglamorous foundations underneath it: clean data, clear governance, and relentless change management.

Where those foundations were solid, Copilot delivered. Where they were thin, no amount of enthusiasm could compensate.

There was a quieter challenge in those early days that we rarely named: The prompt gap. Copilot worked brilliantly if you knew what to ask it, but most people did not know exactly what—or how—to ask. Successful adoption depended on teaching tens of thousands of our Microsoft colleagues to clearly phrase their intent, and every gain faded the moment their attention moved elsewhere.

It was akin to the frustrating experience of pushing a boulder up a hill only to watch it roll back down, over and over. The value of AI was real, but progress was slow.

How the physics changed

Agentic AI changed the physics. Now, an agent doesn’t need to be prompted at every step. It carries context, can take multi-step actions, and returns a result instead of a suggestion. The interaction shifted from prompting to delegating, from “help me draft this” to “handle this task for me.”

That change rewired the incentives for AI adoption. People no longer had to translate every task into the perfect prompt. Instead, they could delegate meaningful work to agentic AI and stay in the loop as it progressed. The value became easier to see, because it showed up in completed work, not just generated content.

When we introduced Copilot agents such as Cowork and Scout into our everyday work, we stopped having to repeatedly sell the idea. People no longer needed a campaign to understand the value of a digital colleague that could do the work; they just needed one good proof point from someone they trusted.

What surprised us most was how the spread of Cowork and Scout happened: Not top-down through a rollout plan, but sideways, desk to desk and team to team. Someone would use these agents to handle a recurring task, show how it worked in a meeting, and within a week three more colleagues had their own ideas for agentic workflows. The change management challenge had switched from driving adoption to creating the conditions for it—providing fertile soil, as it were.

Organic adoption: Cultivating the garden

The organic spread of agentic AI was not an accident; it was a deliberate change in how we worked with our employees. In Microsoft Europe South we tested this change most fully with local teams, such as Customer and Partner Solutions Spain.

In a pilot program for this group, we didn’t launch with an AI training initiative. Instead, we started with a pattern we had observed from hackathons and previous community sessions.

Previously, participants were enthusiastic about agentic AI, but often lacked meaningful end-to-end business problems to solve. Many of the strongest ideas overlapped with solutions already being built elsewhere, while other scenarios could be addressed through existing Copilot capabilities. Often, the biggest barrier was the perceived complexity of making sure an agent met security, privacy, accessibility, and responsible AI requirements.

So, we changed our adoption efforts, focusing more on helping employees examine their own processes and identify workflows they could automate, and then assisting them in navigating through the compliance issues.  We were asking people to challenge everything they did at work—even the routines they had never thought to question—and identify the most repetitive, manual, decision-heavy tasks that quietly consumed their week.

Across a series of ideation workshops, teams generated a wealth of agentic AI opportunities. Yet the true success of the program was not measured by the number of ideas produced, but by the rigor applied to each one. Every idea was scrutinized not only for its potential value and feasibility, but also based on a more fundamental question: Does this problem truly require an agent, or is there a simpler path to solving it?

As a result, our team introduced a basic but powerful principle: Build, Reuse, or Prompt.

Rather than assuming every problem required a new agent, opportunities were explicitly routed to the most appropriate path. Many ideas were already covered by existing solutions. Others could be solved through one or more of the following:

• Better prompts
• Copilot capabilities
• Existing agents like Cowork, Scout, or even GitHub Copilot

Only a subset of challenges justified building a new agent. This reduced duplication, clarified ownership, and ensured that effort was invested where genuinely new value could be created.

The assessment process itself became part of the adoption journey. Ideas were evaluated against existing agent usage, technical feasibility, role readiness, value measurement, and data and security considerations. We also applied an important principle borrowed from continuous improvement: Sometimes a process should be improved before it’s automated.

The shift from just “knowing how to use AI” to “thinking differently about work” was the real outcome.

By the end, a number of colleagues had moved from passive consumers of AI to active builders. The strongest agent ideas rarely came from technical teams. Instead, they came from the people closest to the work. Once someone questioned a process, identified friction, and built a solution to reduce or remove it, they rarely stopped at one idea.

Our pilot program also reinforced another lesson: AI adoption is not only about learning technology. It’s about seeing how work can change. The next measures of success are whether those agents reduce friction, shorten cycle times, improve follow-through, and free people to focus on higher-value activities.

Trust, orchestration, and tending to what grows

The tough questions we face today regarding AI adoption are about trust, orchestration, and control. Will our people feel comfortable with an agent acting on their behalf? How do dozens of independently built agents coordinate across an organization, instead of colliding? And how do we govern software that actually does the work?

To help answer these questions, agent governance became our center of gravity. We learned to build these considerations into our process, beginning with our first interactions with field teams, and not just bolt it on at the end.

“The technology opens extraordinary possibilities, but the greatest impact comes when it is combined with the right methodology, governance, collaboration, and continuous learning. Transforming ourselves in this way is helping us become a more effective organization while also making us better equipped to guide our customers through their own AI transformation.”

Doris Gomes, customer success lead, Microsoft Spain

At Microsoft, every agent has to tread the same garden path before it can be published through approved channels:

• Service Tree registration
• Security Development Lifecycle and Secure Future Initiative validation
• Privacy assessments
• Accessibility checks
• Responsible AI review

Framed early, these stopped being obstacles and became part of what it means to build well.

We also learned that agentic AI adoption accelerates when publishing feels achievable. Making the governance process visible early helped teams understand the path to production and reduced the uncertainty that often discourages experimentation.

Governing what grows also demands visibility, and this is where Agent 365 has become our control plane. It lets us monitor every agent across all environments in the Microsoft tenant, making sure the ones appearing at the edge are discoverable, secured, and accountable rather than turning into invisible sprawl.

The principle is simple: Let ideas grow freely, but never lose sight of what your garden contains.

“The technology opens extraordinary possibilities, but the greatest impact comes when it is combined with the right methodology, governance, collaboration, and continuous learning,” says Doris Gomes, a customer success lead for Microsoft Spain. “Transforming ourselves in this way is helping us become a more effective organization while also making us better equipped to guide our customers through their own AI transformation.”

Growing the agentic future

The organizations that succeed in the next phase of AI adoption will not be the organizations that push the hardest. Success will be achieved by those that cultivate with care: helping employees rethink their work, creating the conditions for experimentation, and ensuring that what grows can scale safely.

“Agentic AI is helping our teams move from working harder to working smarter. We are simplifying processes, improving operational quality, better leveraging information and insights, and creating more scalable ways to serve our customers.”

Paco Salcedo, general manager, Microsoft Spain

This is the difference between pushing a boulder and planting a seed. A boulder needs continuous force. A seed needs the right conditions—good soil, a little light, a healthy environment. The plant then grows on its own and reseeds.

We are still early on the path to the Frontier Firm future, and there are many ways for us to keep growing and improving. Trust has to be earned, governance has to keep pace with autonomy, and not every seed takes. But with the right nurturing, a brighter agentic future can flower.

“Agentic AI is helping our teams move from working harder to working smarter,” says Paco Salcedo, a general manager for Microsoft Spain. “We are simplifying processes, improving operational quality, better leveraging information and insights, and creating more scalable ways to serve our customers.”

Salcedo points to innovations such as MSX-IQ, an AI assistant built by our team for Microsoft sellers that provides a “chat with your pipeline” experience and is now used across multiple countries. Its adoption demonstrates how giving people the right tools, governance, and support can accelerate meaningful business transformation.

The post From the field: How agentic AI is reshaping adoption at Microsoft appeared first on Inside Track.

“I’ve always dreamt of being an engineer, and at the time engineering was not a common path for girls in our community,” she says. “But I was always encouraged by my parents and my teachers to pursue my ambitions.”

With the “unwavering support” of her mother, father, and community, those ambitions have led her to a thriving career in software engineering in IT at Microsoft. Priya now works on AI-powered employee experiences, Copilot agents, and enterprise solutions that improve the ways people interact with technology.

From her first day in Microsoft Digital—the company’s IT organization—in 2021, Priya learned to embrace a culture of ownership, working closely across disciplines to support her colleagues.

“At Microsoft, you are always a full-stack engineer,” Priya says. “You’re not a back-end developer, you’re not a front-end developer, you’re not a dev ops engineer—you are everything. And that was a great thing to know. You do not just own one part of the application, you own everything. That gives you a sense of responsibility.”

Forging a career path at an early age

That sense of responsibility, ownership, and leadership started for Priya within her own family. Her mother has a master’s degree in architecture, and Priya grew up seeing how education, leadership, and perseverance could open doors for a family and a community.

Priya carried that lesson into school. She had excellent grades in high school and earned admission to the computer science and engineering program at NIT Jalandhar, a well-respected engineering institute. Entering this field still felt like a challenging step for Priya.

Her early career experiences gave her a broad view of how software supports different kinds of businesses. At Publicis Sapient, she worked across e-commerce, fintech, and retail customers. Moving on to Expedia Group, Priya worked as a software development engineer on large-scale systems serving customers globally.

Learning the Microsoft way of engineering

Joining Microsoft nearly five years ago meant learning a new technical stack and a different operating model. Priya came from a Java and Python background, learning .NET and C# as she moved into the company’s engineering environment.

“A growth mindset means being comfortable with being uncomfortable. Every major step in my career happened when I chose to leave something familiar and challenge myself to learn something new.”

Kanu Priya, software engineer, Microsoft Digital

The bigger shift was not about the language or framework, but a change of mindset. It was the expectation that an engineer should understand the customer problem, build the solution, monitor production health, and keep improving the experience after release.

“A growth mindset means being comfortable with being uncomfortable,” Priya says. “Every major step in my career happened when I chose to leave something familiar and challenge myself to learn something new.”

That philosophy matched the way Amit Raghuwanshi, a principal software engineering manager at Microsoft, describes Priya’s approach to her work. Priya has been part of Raghuwanshi’s team for more than four years, keeping up as the work ranged across asset management, ServiceNow development, and—more recently—agentic development using Azure AI Foundry and Copilot Studio.

“Throughout this journey, we keep changing the tech stack and the challenges, and Kanu has shown a really good growth mindset,” Raghuwanshi says. “She’s always willing to take on new challenges in whichever tech stack it may be.”

For Priya, ownership also means staying connected to what happens after the first release.

“Microsoft taught me that engineering doesn’t end when the code is written,” she says. “Real ownership means understanding the problem, delivering the solution, supporting it in production, and continuously improving the experience for customers.”

Building experiences with AI agents

Priya’s current work brings that ownership model into the world of AI-powered employee experiences. She contributed to the development of our Employee Device Information agent, a self-service experience that helps Microsoft employees manage primary devices and correct inaccurate device information and assignments.

The work matters to our organization, because device data can create friction for employees and support teams when it’s wrong or difficult to update. The agent reduced 70% of manual effort for support teams and BPO organizations by automating work that previously required human intervention.

Priya also contributed to the first version of a purchase experience agent that helps employees explore available devices, compare options, and understand recommendations based on employee persona and company requirements. Then they can move through device selection using a unified, conversational experience.

Raghuwanshi points to the enterprise device work as an example of Priya’s ability to learn quickly and work from the problem outward. Priya was part of that work from the very beginning, helping launch the agent with Copilot Studio so employees could answer device questions and resolve requests quickly.

“The AI era is one of the most exciting shifts I’ve seen in technology. It isn’t just helping us work faster; it’s helping us reimagine how we solve problems and create experiences for people.”

Kanu Priya, software engineer, Microsoft Digital

Microsoft dev teams are also changing how they approach solving future problems. Raghuwanshi says AI is now part of the software development lifecycle, from requirements and specifications through code and deployment. The power of AI has also added a new design question for just about any business process: Can an agent help solve this?

Priya sees that change as more than just a productivity gain.

“The AI era is one of the most exciting shifts I’ve seen in technology,” she says. “It isn’t just helping us work faster; it’s helping us reimagine how we solve problems and create experiences for people.”

Today, Priya is working on next-generation multi-agent experiences that bring device selection and purchasing workflows directly into Microsoft 365 through Copilot-powered experiences.

Raghuwanshi connects that work back to the same trait that brought Priya into engineering in the first place: Agility.

“She is a very fast learner,” Raghuwanshi says. “You give her a new problem and she quickly adapts, then starts showing further curiosity.”

Priya’s promotion in 2023 was an important career milestone, and she credits mentorship from Raghuwanshi and support from teammate Shreekantha Tarikere Indraiah as important factors in that growth.

Helping others follow her path

Priya’s story circles back to Nangal-Shama. During a recent visit home, a young woman from her neighborhood told her, “I want to be like you; I want to be where you are one day.” She says the moment filled her with pride.

“I think that’s what matters: clearing paths for the kids who can dream big,” Priya says. “I always want to make sure people from my hometown are getting resources and opportunities.”

For Priya, this is what it means to succeed at Microsoft—and beyond.

“I think success is not about reaching a destination,” she says. “It’s about continuing to grow, learn, and create opportunities for others along the way.”

The post Building a career in IT with a growth mindset: Kanu Priya’s Microsoft journey appeared first on Inside Track.

“We have different tools to detect if there’s some outage in the network. After we have those alerts converted into tickets, we work to make sure the corporate network gets back up and running.”

Neeraj Mohan, senior site reliability engineering manager, Microsoft Digital

At the scale of Microsoft, a company with more than 900 sites, 500 datacenters, and tens of thousands of network devices, those incidents translate into thousands of tickets. And each ticket requires some combination of decision making, action, collaboration, and communication.

Managing connectivity for that internal network falls to Microsoft Digital, the company’s IT organization.

“We’re like a backbone for supporting the business,” says Neeraj Mohan, a site reliability engineering manager in Microsoft Digital. “We have different tools to detect if there’s some outage in the network. After we have those alerts converted into tickets, we work to make sure the corporate network gets back up and running.”

Through agentic AI, we’re changing how that work gets done. Instead of asking people to chase every diagnostic, status update, ticket handoff, and stakeholder question, our teams are building AI agents that can sense what’s happening, act within clear limits, and validate outcomes before we do the work.

The labor behind every alert

Network operations has always depended on strong tooling, disciplined processes, and experienced engineers. The challenge is that the volume of work keeps rising.

The Microsoft environment includes more than 75,000 devices, over 300,000 users, and in excess of 1 million connected endpoints. The monthly volume of tickets that require human intervention rose as high as 70,000 in January 2025. Eighteen months later, we’d reduced it to less than half—about 27,000—through the application of automation and AI.

That showed great progress, but this many tickets a month still demands a lot of effort. Many of these tickets require enrichment to provide engineers with information like the current device state, neighboring device status, links, logs, and prior troubleshooting. Others require coordination with internal teams, datacenter operations, site services, telecommunications providers, or network device vendors.

The difficult aspect isn’t just the technical fix. It’s the time spent changing context from one system to another, checking partner portals, scheduling work windows, answering leadership questions, and validating whether a fix has actually restored service.

To make matters more complicated, we can’t let just anyone log in to network devices or run changes in a secure environment. We need to design read access, execution permissions, and human approvals deliberately.

To address these challenges, we looked across the incident lifecycle, reviewed ticket volume and manual effort, and prioritized agent opportunities based on impact, user need, and development effort. The first set of agents focused on three connected problems: dynamic troubleshooting, cross-system handoffs, and outage communications.

Three agents, one operating model

The network operations agents we’ve created aren’t a single monolithic utility. They’re a set of focused tools that map to how operations work already happens. We created them using first-party, cloud-based technologies that include Microsoft Azure OpenAI, Microsoft Foundry, Microsoft Agent Framework, Microsoft Copilot Studio, and Microsoft Teams, and then integrated them into our internal incident management (ICM) tool.

Each agent sits close to the work, respects the permissions required for network operations, and gives engineers or stakeholders the next useful action without forcing them to assemble context manually.

Falcon Agent: Fresh diagnostics on demand

Falcon Agent is the action engine in our AI network operations loop. Before this expansion of agentic capabilities, Falcon already supported automated troubleshooting and remediation for known scenarios like access-point-down incidents. A service line could onboard a scenario once, define the troubleshooting steps, and let Falcon handle repeat tickets without asking a directly responsible individual (DRI) to rerun the same actions every time.

The Falcon Agent adds an on-demand layer. If Falcon has already run a workflow and a DRI starts work later in the day, the earlier results might be stale.

“We want to be where the users are. Falcon Agent is available through Teams and the incident management tool, giving engineers a choice of where to work while keeping the controls in place.”

Shayoni (mononym only), product manager 2, Microsoft Digital

With the agent, authorized engineers can refresh troubleshooting, retrieve current logs, check device reachability, validate service restoration, and enrich the ticket with updated information. By the time an engineer opens a ticket, the agent has already refreshed and summarized the ticket.

Falcon Agent also restricts executional prompts to the right engineering users on secure admin workstations (SAWs). Meanwhile, informational prompts can serve a broader audience without exposing device-level control.

“We want to be where the users are,” says Shayoni, a product manager for Falcon in Microsoft Digital. “Falcon Agent is available through Teams and the incident management tool, giving engineers a choice of where to work while keeping the controls in place.”

Smart Bonding Agent: Closing the handoff gap

We can’t fix every incident remotely. If we need to restart a router on site, reseat a cable, access a power supply, or call in a telecommunications provider for a fiber cut, the work shifts from remediation to coordination. That’s where the Smart Bonding Agent comes in.

“This agent provides for lifecycle continuity across systems. It closes the handoff gaps where we would often lose context in the past.”

Suvodip Moitra, senior product manager, Microsoft Digital

The Smart Bonding Agent contains several flows:

• A recommendation agent reviews the incident and identifies the likely issue and the team to engage.
• A ticket steward agent creates the right ticket after human approval and monitors updates.
• A work-window scheduling flow helps connect the right people when the receiving team needs help from Microsoft engineers.

The goal is to keep the engineer in the incident record instead of asking them to jump across portals, emails, and partner systems. At the same time, human approval is intentional by design. We don’t want to reduce one team’s work by flooding a partner with unnecessary tickets.

“This agent provides for lifecycle continuity across systems,” says Suvodip Moitra, a senior product manager responsible for the Smart Bonding Agent in Microsoft Digital. “It closes the handoff gaps where we would often lose context in the past.”

As confidence improves, lower-risk workflows can move toward more automation. The agent already covers Global Datacenter Operations and Puget Sound Network Operations, with expansion underway across more issue types, telecommunications providers, and network device vendors.

Network Outage Insights Agent: Less talk, faster restoration

When a site has a network problem, engineers aren’t the only people who need information.

IT managers want to know whether their location has connectivity. Leaders are responsible for answering to business stakeholders. Help-desk teams need to know whether an employee issue is local to a device or tied to a site-level outage.

“Part of our role is knowing the people we support. This agent helps us understand who we’re serving and what the best forums are where we can interact with them, all in one place.”

Laxman Bhinnale, senior technical program manager, Microsoft Digital

Built on Copilot Studio, the Network Outage Insights Agent supports both push and pull communications. It can send targeted Teams notifications to impacted IT managers on the push side and answer natural-language queries when people need to pull answers.

An IT leader might ask, “Are there any active site outages on my campus?” The agent returns the incident link, current status, estimated time to resolve, impact, region-level details, and historical trends that can help teams spot recurring issues with a site or provider.

The agent also changes how the team learns. It can track feedback in a backlog and connect improvements back to the people who requested them.

“Part of our role is knowing the people we support,” says Laxman Bhinnale, a senior technical program manager in Microsoft Digital. “This agent helps us understand who we’re serving and what the best forums are where we can interact with them, all in one place.”

Great results, exciting opportunities

The measurable impact of our AI network operations agents is still emerging, but the signals of success are clear.

Falcon Agent users report saving around 300 hours in the first few months of operation, equating to 10–15 minutes saved per ticket. The agent has a 60% retention rate and 100% positive user feedback.

We’ve observed that Falcon can handle about 60% of total incident volume already, with an expectation it can reach about 80% as more scenarios mature. The remaining work is likely to include physical or cross-team activity where the Smart Bonding Agent is a better fit.

Meanwhile, our Network Outage Insights dashboard showed 149 outages in one month, with 32 hours saved on communications and reporting.

“The future is multi-agent orchestration: monitoring, troubleshooting, partner engagement, and communication working together.”

Raghavendran Loganathan, principal software engineering manager, Microsoft Digital

The next step is connecting these agents’ efforts. In future flows, the Smart Bonding Agent will be able to engage the right internal or external party while Falcon Agent validates that the issue is resolved. Finally, Outage Agent Insights will communicate impact and recovery status before a post-incident agent generates the postmortem. Each agent keeps its focus, but the work moves as one incident lifecycle.

“The future is multi-agent orchestration: monitoring, troubleshooting, partner engagement, and communication working together,” says Raghavendran Loganathan, a principal software engineering manager in Microsoft Digital.

For our customers, the lesson is that you don’t need to copy our exact network or ticketing model. Instead, study your own top sources of work. Analyze telemetry and see what constitutes your most significant pain points, then try to attack the problem with agents.

That’s the practical pattern: Start with the work that repeats, put agents where people already operate, keep humans in the loop in places where actions carry risk, and measure whether the agent changes real behavior. At Microsoft scale, that’s meant fewer stale tickets, fewer missed handoffs, clearer communications, and more engineering time spent on restoring service so the company can achieve at top performance.

The post From alerts to action: How AI agents are reshaping network operations at Microsoft 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, we’re developing a growing agent ecosystem that offers diverse options for your workplace demands. This collection of tools acknowledges that there is no single “right” way to build an agent.

“The best agent architecture isn’t the most powerful one. It’s the simplest one that delivers value today while giving you the flexibility to grow tomorrow.”

Patrice Pelland, partner engineering manager, HR Employee Experience

Microsoft 365 Copilot, declarative agents, Copilot Studio, Microsoft Fabric data agents, and Microsoft Foundry agent service all represent valid patterns that are optimized for different kinds of work. Newer ideas like scout-style personal agents and Frontier Tuning (how we fine-tune our agent compliance) offer even more flexibility.

When choosing the best agentic technology for you, the rule of thumb is simple: Select the lightest architecture that fits your user experience, data needs, action model, and governance requirements.

“The best agent architecture isn’t the most powerful one,” says Patrice Pelland, a partner engineering manager in HR Employee Experience. “It’s the simplest one that delivers value today, while giving you the flexibility to grow tomorrow.”

Start with the surface, not the stack

The fastest way to get agent architecture wrong is to begin with technology instead of the workload. A better starting point is the user surface—where the work happens and how people expect to interact with it.

Our agent ecosystem is broad, but each of the core options map cleanly to a different kind of challenge:

• Microsoft 365 Copilot is the default entry point for AI in daily work, embedded across apps like Teams, Outlook, and Word. It excels at summarization, drafting, and reasoning over Microsoft Graph data without requiring users to leave their most familiar tools.
• Microsoft Copilot Cowork takes Microsoft 365 Copilot beyond just answering questions to actually executing on work assignments. Designed for complex, multi-step tasks, it can plan, coordinate, and carry out work across Microsoft 365 applications and connected systems while keeping users in control through approval checkpoints and oversight.
• Declarative agents extend Microsoft 365 Copilot with scoped instructions, knowledge, and lightweight actions. They’re the simplest way to create focused, role-based assistants while staying entirely within the Copilot experience.
• Copilot Studio agents provide a low-code environment for building workflow-driven agents with connectors, triggers, approvals, and multi-channel delivery. They’re best suited for business processes that need structure, governance, and integration across systems.
• Microsoft Foundry Agent Service is a code-first platform for building and operating custom agents with full control over models, orchestration, and runtime. It fits engineering-heavy scenarios that require scalability and tailored architecture.
• Microsoft Fabric data agents specialize in governed analytics over business data, using semantic models, ontologies, and curated datasets. They are designed to answer questions about KPIs, entities, and operations with trusted, auditable context rather than general document retrieval.
• Microsoft Scout and Autopilots introduce always-on personal agents that can coordinate work in the background across Microsoft 365. They focus on continuity—tracking commitments, preparing context, and proactively surfacing what matters next.
• Frontier Tuning enables organizations to teach agents how work actually gets done using company-specific data, workflows, and evaluation signals. It’s a later-stage capability that refines behavior inside compliance boundaries, rather than serving as a starting point.

Taken together, these are layers in a system. The practical decision is to pick the one closest to the user.

Picking the right agentic tool

Use Microsoft 365 Copilot as the default front door for broad productivity and Microsoft 365-grounded experiences. Extend it with declarative agents, connectors, plugins, or APIs when a scenario needs more domain-specific knowledge or actions. Do not treat plain Copilot as the primary architecture when the real need is a departmental specialist, governed workflow, analytics specialist, custom channel, or custom runtime. Those needs fit Copilot Studio, Fabric, or Foundry patterns better.

Use Microsoft Cowork when you want to complete a meaningful piece of work across multiple steps, files, applications, and systems. Cowork is best suited for long-running tasks that require planning, orchestration, and execution over time, while remaining grounded in Microsoft 365 context. Do not use Cowork as a replacement for workflow platforms, analytics specialists, or custom agent architectures. When a task requires governed business processes, specialized analytics, or deep runtime customization, Cowork should coordinate with other agentic tools rather than replace them.

Use Copilot Studio when governed workflow, connectors, approvals, and channel reach matter as much as the chat experience. Do not use it as the default for a small Microsoft 365 Copilot extension or for engineering-first scenarios that require custom model choice, runtime hosting, private networking, or deep orchestration; those fit declarative agents or Foundry better.

Use Microsoft Foundry when low-code or Microsoft 365-native layers hit real limits around orchestration, runtime control, model selection, deployment architecture, or engineering operations. Do not start here for a simple business workflow, no/low-code service agent, or focused Microsoft 365 assistant unless custom runtime control is truly the differentiator.

Use Fabric data agents when you’re looking for analytics expertise in a broader architecture. Fabric IQ, semantic models, and ontology can help translate raw data into business meaning. Do not use them as a general enterprise assistant or workflow engine: they are read-only, analytics-focused, and not intended for broad action-taking, unstructured document help, or custom model/runtime control.

Use Microsoft Scout when you need a personal front-door and coordination layer. It should not serve as a replacement for every enterprise agent architecture. When work crosses into governed process, business analytics, custom orchestration, or domain systems, Scout should delegate to Copilot Studio, Fabric data agents, MCP tools, or Foundry specialists.

Use Frontier Tuning only after the basics are in place: clear workflows, governed data, meaningful evaluation signals, and operational maturity. It is a later-stage optimization for institutional know-how, not the first step for a lightweight assistant or a substitute for sound architecture, data governance, or human-in-the-loop controls.

AI-ready data: The foundation of effective agents

The success of an AI agent depends less on the model it uses and more on the quality of the data that grounds it. Agents can only reason effectively when they have access to information that is trusted, discoverable, secure, and connected to the broader decision-making context. Organizations that invest in AI-ready data create the foundation for more reliable and useful AI experiences.

“The competitive advantage in the age of AI won’t come from access to models alone. Organizations also need to prioritize AI-ready data, which allows agents to reason accurately, securely, and at enterprise scale.”

Ravi Goripathy, principal software engineering manager, HR Employee Experience

AI-ready data goes beyond standard measures of data quality, such as accuracy, completeness, and consistency. It also includes the semantics, governance, and contextual information that help AI systems understand what the data means, how it should be used, and the way it relates to other information across the business. High-quality data is essential, but AI systems need data that is also meaningful, connected, and trustworthy.

As organizations deploy more copilots and agents, data readiness increasingly becomes the limiting factor for success, rather than model availability. A strong AI-ready data foundation helps agents produce better results, apply business context consistently, and operate within appropriate security and governance boundaries. The most effective AI strategies treat data readiness as a core architectural requirement.

“The competitive advantage in the age of AI won’t come from access to models alone,” says Ravi Goripathy, a principal software engineering manager in HR Employee Experience. “Organizations also need to prioritize AI-ready data, which allows agents to reason accurately, securely, and at enterprise scale.”

Building reliable agent systems

As soon as an agent moves from answering questions to taking actions, architecture matters more.

A useful pattern is to separate responsibilities into layers:

MCP tools play a key role here by exposing actions as controlled, reusable capabilities. Instead of giving an agent broad access to systems, you expose bounded functions with defined inputs, permissions, and telemetry. This improves reliability, governance, and auditability.

Similarly, not every interaction belongs in free-form chat. Tasks that require review, approval, or comparison—like approving a budget or evaluating candidates—benefit from structured UI components. MCP apps let you surface those experiences inside conversational flows without rebuilding entire applications. Rather than sending users to a separate system to complete a task, MCP apps can render forms, grids, dashboards, and other transactional experiences directly within the conversation, enabling users to review information, approve requests, update records, and take action in context.

As solutions mature, new patterns emerge. Always-on personal agents—like Scout-style Autopilots—can monitor commitments, prepare context, and proactively surface issues. In parallel, Frontier Tuning introduces a way to teach agents how work actually gets done in a specific organization, using real workflows, evaluation signals, and internal knowledge.

These are powerful capabilities, but they’re not starting points. They’re extensions of an architecture that already works.

A layered approach beats a ‘super agent’

It’s tempting to imagine a single agent that handles context, analytics, workflows, and actions. In practice, a more durable approach is a set of loosely connected specialists that each focus on a specific responsibility.

A Microsoft 365–native assistant can serve as the front door for user interaction, delegating analytics to Fabric data agents, actions to Copilot Studio workflows or MCP tools, and more complex orchestration to Foundry-based agents when needed. This separation makes systems easier to govern, test, and evolve over time.

Before moving to production, architecture should include clear ownership, permission design, governance controls, human approval for sensitive actions, evaluation processes, and monitoring. These are all essential aspects of building an agent system that can be trusted.

Deciding where to start

When faced with multiple valid options, a simple decision path helps:

• If a packaged Microsoft experience already meets most of the need, use it.
• If the experience should live in Microsoft 365, start with Copilot and a declarative agent.
• If the core problem is workflow—approvals, routing, integration—lean toward Copilot Studio.
• If the value depends on governed business data, bring in Fabric data agents early.
• If you need deep control over orchestration, models, or runtime behavior, step up to Foundry.

And across all of these: add structure only where the workload demands it. Use MCP tools for actions, structured UI where chat breaks down, and human review where risk increases.

Most importantly, resist the urge to start at the most complex layer. Many successful solutions begin as simple Microsoft 365 extensions and evolve incrementally into multi-layered systems.

Looking ahead: From tools to systems of work

The trajectory of agent architecture is clear. We’re moving from isolated assistants toward interconnected systems that combine personal productivity, business data, workflows, and continuous coordination.

“Agentic AI is shifting from isolated capabilities to connected systems of work. The organizations that lead will be those that design for evolution—starting simple, learning continuously, and scaling with intention.”

Ravi Goripathy, principal software engineering manager, HR Employee Experience

In the near term, that means more layering: personal agents coordinating work, workflow agents handling processes, analytics agents grounding decisions, and platform agents orchestrating across systems. Over time, capabilities like Frontier Tuning will make these systems more adaptive, learning from how organizations actually operate while staying within governance boundaries.

But the core principle is unlikely to change. The most successful teams won’t be the ones who adopt the most advanced architecture first. They’ll be the ones who start with the smallest viable solution, validate it in real workflows, and scale intentionally—adding complexity only when it delivers clear value.

“Agentic AI is shifting from isolated capabilities to connected systems of work,” Goripathy says. “The organizations that lead will be those that design for evolution—starting simple, learning continuously, and scaling with intention.”

The post Start light, scale intentionally: Choosing the right Microsoft agent architecture 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.