What's new: Agentic Developer Loop

0:05 Hello everyone and welcome to this session about what's new in agentic development for the 20126 release wave 2. I'm Kberis and I'm presenting together with Artur Wensel. Today's agenda. First we are going to talk about the agentic developer loop. Then about the snapshot debugging MCP. Then Arur will perform a presentation of the snapshot debugging MCP. Then I will talk about the AI language server protocol the sampling profiling MCP and then I will finish with a demo of the sampling profiling MCP.

0:45 This is the big picture from 10,000 ft. The developer starts with a prompt because there is a real problem to solve. Maybe the production environment is slow or maybe user found a bug that was not seen during development and testing. The prompt describes the problem. The agent then plans the investigation and calls the right standard protocols. Let's see the architecture behind the process.

1:16 ALSP grounds the agent in the source code by providing exact definition references and type information. AL tool acts as the local proxy. It handles standard input and output communication, authentication, business center routing and delivery of the captured artifacts. The business central MCP server provides the runtime tools and resources for snapshot debugging and sampling profiling.

1:49 Together, these interfaces produce grounded evidence, capture call stacks and variables and sample AICPU profile data. This is the agentic developer loop. understand the source, collect evidence from the real environment, and use that evidence to explain and fix the problem. Snapshot debugging. We already know snapshot debugging as a tool available to developers in Visual Studio Code. The agentic workflow follows the same principles,

2:23 but the agent can now coordinate the investigation. A typical scenario is that you have a bug in a production environment. Let's say a web client. You configure the snapshot debugging MCP server for the business central environment. Ask the agent to capture the next matching web client session. Reproduce the AL exception. Tell the agent that the reproduction is complete. and then let the agent collect the snapshot and analyze the capture call stacks and variables.

2:59 If the first snapshot does not contain enough information, the agent can use the als to find the exact callers of the failing function and place snap points at better locations. The agent can then arm another capture for the known session ID or the next matching web client session. And this loop can be repeated until the reason for failure is found. So how we set up snapshot debugging? The snapshot debugging MCP server is built into the standard Microsoft business central MCP infrastructure.

3:39 There are three ways to connect. Our AL tool Swiss Army knife can act as a proxy. It is an MCP host for the business central MCP server and an MCP server for your local client. Visual Studio Code can configure the same business center target in the launch.json extension registers and starts the snapshot MCP proxy and then can reuse the existing AI development signin.

4:12 The third option is to create your own MCP host that accesses the Microsoft Business Center MCP servers troubleshooting infrastructure. Arthur will now demonstrate how the snapshot debugging MCP server works. >> Um thank you Coleman. So uh my demo going to be exactly what you said that user is uh working in business central and uh performing the very standard um procedure is trying to post the purchase invoice

4:43 um and face the error which is not clear for the user. It says advanced checked failed and apparently what user can do it uh can just copy that error message and send to engineer to um to debug and then figure out what is wrong. But now with the great capabilities that you presented, uh here is what we can do. Let me just open first Visual Studio Code to show you the very small sample of the code. So this is the PT that I installed. I um subscribe to the event for the posting and then in that um subscriber uh I verify if any of those three fields are blank.

5:20 Uh and in this case I throw an error. Um very simple for this demo. I have uh my MCPJ JSON with um snapshot debugging. I have LSP everything is ready um in this setup. So how do I how do we debug? How do I understand what is the problem there? I can actually use the snapshot debugging and the user session for this. Let me switch to GitHub copilot CLI. I have a long prompt and I will explain to you um the important part of it. So the first one I say that the user reports the advanced check failed problem. So I explicitly tell the agent the exact error message.

5:58 Why it is important? Because the agent should find it and I say when posting the purchase invoice then I instruct the agent to initialize the snapshot debugging in the next session. This is the important part because by the time user tell me that there is an error they might log off. There's no current session. I cannot attach to the session. So there's going to be some next session probably the other day. So I instruct the agent agent to attach to the next session. Then I say find the place in the code where this error throws and set the snap points to troubleshoot this. So I rely on the agent to go through the code and then set those snap points individ individual uh places in the code and they collect all the variables around this one and uh we know that the agent they are smart enough with the LSP to to do that.

6:45 Um and then when I want to say because I don't know when when the user going to log in to the to the session. So what I want to do I want to combine the scenario with telemetry. I want to instruct agent to start pulling the telemetry every 15 seconds. Again for the sake of the demo in the real world it's going to be uh hours. Um and I want to start pulling for the exact error in telemetry. And once it found agent found it it will stop pulling download the snapshot and investigate the root cause. So this is all the explanation for that prompt. Let's see how it works in practice. So I'm going to run it and uh a couple of things going to happen. I will explain all of them one by one.

7:24 So first I mention telemetry. There's a certain scale that uh captured to understand how to work with telemetry. Then uh agent going to start looking for the exact error uh in the in the code unit to identify how to set the snap points. So we run the search. So let's see how that's going. And then there's a tool that is called initialize snapshot debugging. So it is called in the next session with all the snap points that the agent currently collected. Um so it is identified the agent was able to figure out where is the error message comes from. This is great. Uh and then it should start polling for this specific um error message.

8:06 So let's see how it works. Yes, it says scheduling every 15 seconds. That's great. Snapshot debugging is armed for the next web client session. Great. I think we are we're all set. The agent was able to identify everything. And you see uh we already have the schedule prompt executed. There is a long prompt that agent automatically generated or what exactly needs to happen. It loads the scale. It goes to telemetry and you see no matching telemetry evident event. What's going to happen next? Now I'm switching my hat. Now I'm a user again.

8:39 Uh the next day I log into that session. Uh and I went and log in. I see the the same thing like we had with a snapshot debugging. I see that the snapshot debugging is turned on for my session. That's great. Uh and me as a user understand that uh probably engineer going to help me with that. So I do the very same thing. I want to post the document to see the same error and that's great. And when it's happened and let me go back to GitHub compile CLI. So the next um schedule prompt is running um and then it should be able to retrieve from telemetry the exact event.

9:16 Uh it takes the call stack the exact error and now we can see that the uh error is appeared. it stopped the snapshot debugging and now it's trying to download uh the snapshot and investigate um the call stack and the values of of all the variables and it will try to reason over that snapshot and um uh and uh give me the uh understanding of what is happening. So let's give it just a second to download the snapshot and uh reason over it. it will um take some time to reading all the snapshots and then collecting all the values and comparing u to the code that I have in the code unit and finally I have a root cause found um agent was able to identify that

9:59 one of those three fields was actually filled in by the user but two other fields were not. So now me as an engineer I can get back to the user and then tell what exactly um is going wrong and uh help them to move forward to fill in those fields and uh successfully post the document. Back to you common. >> Thank you Arthur. Let's continue. Let's talk about the AI language server protocol. The language server protocol is an industry standard that connects development environments

10:30 to language specific intelligence. It is also how the AL extension provides AL language features in Visual Studio Code. The same protocol is now available to agents. Instead of relying only on text search, an agent can resolve exact definition, references, types, symbols, implementations, and callers. The semantic grounding is valuable throughout the developer loop for our troubleshooting scenarios. It helps the agent place correct snap points, follow a capture stack frame into the source and understand the functions identified by a performance profile.

11:11 Let's continue with the sampling profiling MCP. The story here is very similar to the snapshot debugging MCP server. Sampling profiling is exposed through the business central MCP server. The MCP host that we provide is again a tool. There is however one important difference from snapshot debugging. To start a profiling schedule, the agent needs the numeric business central session ID that it should target.

11:45 Let me show you two ways to obtain the session ID. For a web client session, the user can find it on the help and support page and provide it directly or the session ID can be inferred. As an example, the agent can use telemetry to identify the relevant session from the workload and environment. Once the session ID is known, the agent starts a limited sampling schedule. Business center watches the matching activities and returns AI CPU profile files.

12:22 It also returns an overview of activity duration, CQL calls, HTTP calls and only for the MCP server memory information. The permissions are again checked by Business Central for the signin user. They are the same permission as for the manual workflow. To profile your own session, you need permission to create profile schedules and read the resulting performance profile. To profile another user session, you need the D365 attach debug permission set. So let's do some demos.

13:05 We have seen how an agent can investigate a failure from captured runtime state. Now let's ask a different question. What if nothing fails but business center is simply slow? Let me first show you how I set up the MCP server. It is very similar to the information available in a launch.json file. You need to specify the environment, the environment type. These are things you know from the launch.json, JSON aren't they the extra parameter in the option to save the CPU profile files locally for further analysis.

13:42 Now assume that I have a schedule task that makes business center very slow. Here is a small demo app that creates this slow workload. It hammers SQL server with an abnormally high number of SQL statements as a batch schedule task would do. So let's start. Now I'm going to use copilot cle to start sampling this session. The prompt that I'm going to use is the following.

14:13 Business center is slow on session one. Profile it please until I say done and tell me why. So what will happen here is uh that uh we are going to connect to the business central MCP server and the sampling profiling session is going to be started. While this is going on I'm going to do the second demo. I'm not going to do it live because it takes five minutes but we are going to go through it because it's a very interesting demo.

14:45 So let's start that one. Here I have a special agent that I ask to look for special telemetry tags. If a tag measures if a tag that measures slow CQL calls a hit, it should find the associated NSD session ID. With that session ID, the agent will instruct itself to analyze why is it slow. From there, it will hook into the sampling debugging MCP server, get her samples, and create a verdict. So this was my original prompt. The BCL background workload is slow.

15:21 Find the correct NSD session capture. Capture one complete workload pass and tell me why. Do a full analysis at the end emphasizing the slow sequels and their associated AI code. So I will scroll through the result and you can see how detailed it is. In the first part, it described what it did and what logic it used to start sampling. So it was you looking for this tag. When it found this tag, it found this session. When it found this session, it initiated a sampling uh session.

15:56 It waited until it found three complete activities. And when it that when it finished with that one, it came with a verdict. And well, let's see what is in the verdict. The verdict says that it has used CQL for 58% and it sampled AI files for 40%. It used 30,000 CQL statements in 5 seconds. It actually shows which statements it has used and it bound to the methods that were causing it.

16:33 More importantly, it actually says another issue that there was an issue with the index because we were indexing by category code. So as you can see this is a very very detailed uh analysis. So let's go back to the original problem and say that we are done here. You know we actually have done the same thing should happen here. There was a distinction between these two scenarios. I called the left hand side a user scenario because I was using a session ID and I called the second one a full agentic scenario because here an agent was doing everything

17:16 by itself. As you can see the schedule will be stopped and we should get to the same result. Just going back to the second scenario the agent provides root causes and fixes. It actually told us what was the problem and what we should do to prevent these things happening again. The first demo is still running. As you can see, it's using the language server right now to understand the source code and come to probably same result as the agent was coming to.

17:55 Let's wait a little bit more until it finishes. Yep. Task complete. Root cause NSD session was repeatedly running background code unit and it reached exactly the same conclusion that it found 30,000 rows. Now here we have a brief overview of what happened. But you know that depends on the prompt. Had I been prompted I want a detailed result I would have got something similar like here.

18:29 This finishes our two demos. The key takeaway is that these are not isolated tools. ALSP snapshot debugging and the sampling profiling MCP should the business central MCP server work together as one agenting developer loop. Understand, capture, measure, and fix. Thank you. >> Thank you.