If you are in the Microsoft frontier program and have a GitHub copilot license then you can use Microsoft Scout, the “Autopilot” AI agent, designed to work autonomously on your desktop. Unlike standard AI chat assistants, Scout can read and write local files, browse the web, run shell commands, and manage your Microsoft 365 environment while you are away.

My first use case was to keep track of the “latest-and-greatest” in D365. I know we have roadmaps and excel sheets explaining what are new/changed. But I wanted to go much deeper. I wanted Microsoft Scout to actually compare the code for each build and report back when there are changes. And to do this autonomously.

To make this happen, I’m using the Unified Developer Experience (UDE), so that each build is actually available as source code on my local PC.

So each time I’m updating my UDE, Visual Studio are downloading all source code, and placing them at:

C:\Users\XXXX\AppData\Local\Microsoft\Dynamics365.

In this folder you will see each build like this:

Each of these folder contain ALL of D365 source code for each build.

The next ting I do, is to create create a Microsoft Scout automation, and tell it to make a comparison between builds, and then report back to me.

I then ask it to check daily and report back any changes. As I love Commerce and Unified Pricing, I’m asking it to focus on this.

I then get reports like this:

It also reports back the business impact:

I did get some AI help in defining the steps, but I now have an “autopilot” that checks and validates the source code and the business impact of changes in a new released, and reports back to me.

I’m exited to see other use cases this can give us, and no support tickets were escalated to Microsoft while writing this article. Yet.

Reference:

Here are my “steps” I used for the automation:

For a D365 code-monitoring agent, I would structure it as multiple focused steps instead of one large instruction. That improves consistency and reduces noise.

Suggested automation: D365 Code Monitor

Goal:
Monitor newly downloaded D365 builds and identify:

• New features
• New flights
• Commerce changes
• Global Unified Pricing changes
• Performance improvements
• Potential bugs/regressions
• New extension points

Step 1 – Detect New Build

Name:
Check for new D365 build

Instructions:

Monitor the Dynamics 365 source code located in:

C:\Users\KurtHatlevik\AppData\Local\Microsoft\Dynamics365

Determine whether a new application or platform build has been added since the previous run.

Compare against the last analyzed build.

If no new build is found:

• Stop processing
• Return “No new build detected”

If a new build is detected:

• Continue with all remaining steps

---

Step 2 – Discover New Flights

Name:
Analyze flights

Instructions:

Scan the new build for:

• Flight classes
• Feature management classes
• SysFlighting references
• FeatureStateProvider usage
• Feature classes inheriting from feature frameworks

Focus especially on:

• Commerce
• Retail
• Pricing
• Global Unified Pricing
• Supply Chain

For every discovered flight:

Report:

• Flight name
• Area
• Description (inferred)
• Enabled/disabled status if detectable
• Related classes
• Business impact

Prioritize flights that appear new compared to previous builds.

---

Step 3 – Monitor Global Unified Pricing

Name:
Analyze GUP changes

Instructions:

Search for changes involving:

• Classes prefixed with GUP
• Unified pricing framework
• Pricing management
• Trade agreements
• Price calculation engines
• Discount calculation
• Attribute pricing

Identify:

• New classes
• New methods
• Modified logic
• New extension points
• Refactoring

Explain the likely functional impact.

This should be your highest-priority analysis area.

---

Step 4 – Monitor Commerce

Name:
Analyze Commerce changes

Instructions:

Focus on:

• Commerce Runtime (CRT)
• Retail Server
• CSU
• POS
• Call Center
• E-Commerce
• Site Builder
• Search
• Cart and checkout

Report:

• New APIs
• New extension points
• New handlers
• Breaking changes
• Performance improvements
• Security changes

Prioritize anything affecting B2B Commerce.

---

Step 5 – Detect Performance Improvements

Name:
Performance analysis

Instructions:

Search for:

• Query optimizations
• Cache improvements
• Batch improvements
• Memory optimizations
• SQL changes
• Retail pricing performance changes

Highlight changes likely to affect:

• Product search
• Pricing
• Cart calculations
• Sales order creation
• Inventory availability

Estimate expected performance impact where possible.

---

Step 6 – Find Potential Bugs

Name:
Bug detection

Instructions:

Review changed code for:

• Null reference risks
• Missing transaction scopes
• Incorrect caching
• Feature flag inconsistencies
• Potential race conditions
• SQL inefficiencies
• Incorrect collection handling
• Breaking API changes

Focus especially on:

• GUP classes
• Commerce classes
• Pricing engines

Provide:

• Risk level
• Reasoning
• Affected classes

---

Step 7 – New Extension Points

Name:
Extension point discovery

Instructions:

Search for:

• New delegates
• New CoC opportunities
• New events
• New extension interfaces
• New request handlers
• New overridable methods

Explain:

• Why the extension point was likely introduced
• Possible implementation scenarios
• Customer use cases

---

Step 8 – Weekly Executive Summary

Name:
Generate report

Instructions:

Produce a concise report with sections:

1. New Flights
2. Commerce Changes
3. GUP Changes
4. Performance Improvements
5. Potential Bugs
6. New Extension Points
7. Recommended Investigation Areas

Rank findings:

• Critical
• High
• Medium
• Low

Include direct class names and method names whenever possible.

One additional instruction I would add globally:

Ignore cosmetic changes, label changes, comments, formatting changes, generated metadata, and localization updates. Focus only on code that changes behavior, performance, extensibility, security, or functionality. Prioritize Commerce and Global Unified Pricing over all other application areas.