.NET 11 introduces comprehensive platform improvements including enhanced performance through TLS optimization and Zstandard compression, strengthened security with CSRF protection and AI-powered security scans, and native OpenTelemetry observability. The modern stack receives significant innovation with async validation support, OpenAPI 3.2, and Blazor server-side rendering parity with MVC. Distributed app development is simplified through Aspire integration with Blazor gateway support. The platform enables agentic web applications via Microsoft Agent Framework integration supporting AGI protocol for agent-user interactions, while AI-assisted development is enhanced through curated skills, custom agents, and evaluation test suites.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
Building for the agentic web with .NET 11Added:
Hi everyone. I'm Daniel Roth, principal product manager for ASP.NET Core and Blazer on the.NET team. Welcome to building for the agentic web with.NET 11.
The demands on modern web apps, they just keep going up. Users want more performance, airtight security, and full observability into how their apps behave in production.
Apps need to be modern and interactive.
Most are cloud-native and distributed, and increasingly they need agentic capabilities. Apps that reason, use tools, and collaborate with people in real time.
Developers want to build more faster, which means building with AI as a partner.
And the platforms underneath all of this need to constantly improve to keep up.
In.NET 11, we're investing to address the needs of the most demanding modern web apps.
Earlier this year, we published our ASP.NET Core roadmap for.NET 11 on GitHub. You can find it at akms/aspnet/roadmap.
Everything we're doing this release is organized around these six themes.
First, address top feedback and pain points. Your feedback helps us constantly improve the.NET platform.
The issues you open, the comments you post, the thumbs up reactions, they directly drive what we work on.
We're addressing as many top-voted issues this release as we can.
Strengthen the foundation.
Performance, security, observability, these underpin everything we do and are what make.NET a platform that you can trust.
.NET runs some of the biggest services in the world at Microsoft, like Entra, Bing, Teams, Xbox, and most of Azure.
And the demands of those workloads push us to keep raising the bar.
As a result, everyone benefits.
Next, invest in our modern stack.
Minimal APIs, SignalR, Blazer, these are where we're actively innovating and adding new capabilities to help you build great modern web apps.
Simplify building distributed web apps.
Modern web apps are distributed and cloud-ready. We're working closely with our friends on the Aspire team so that building, running, and deploying multi-service apps that integrate with a variety of cloud services feels easy and natural.
Enable building agentic web apps. This includes integration with the Microsoft Agent Framework, the MCPC sharp SDK, and supporting new UI patterns for AI-driven experiences. We want ASP.NET Core and Blazor to be the best way to build agentic web apps. And then finally, Copilot assisted web development. We want AI coding assistants to love working with.NET as much as you do.
Through agent skills, custom agents, tools, and evaluation test suites that measure real-world coding agent effectiveness.
Let's dive into each of these themes.
First, let's look at how we're strengthening the foundation.
Fundamentals are something that we focus on with every.NET release, because that's what make makes.NET a platform that you can count on.
And the great thing is, you get many of these improvements just by upgrading.
First of all, performance. We try to make every release of.NET the fastest release ever. This release, we're reducing TLS handshake overhead in Kestrel, so short-lived connections are faster. We're also optimizing how we handle malformed requests, so you can shed bad traffic efficiently and free up that capacity for your real users.
We've added Zstandard compression support, which gives you Brotli level compression ratios at much lower CPU cost. And we're working with the runtime team on runtime async, a more efficient async implementation, to make sure that it works great across the platform, including for web.
Next, security. We're hardening Kestrel, our cross-platform high-performance web server, and running security scans on our code base using the latest AI models to ensure our platform is secure and trustworthy.
We're modernizing our cross-site request forgery support using fetch metadata headers like fetch site and fetch mode based on the latest OWASP recommendations. And for long-lived connections like you have with SignalR and Blazor Server, we're also adding automatic off token refresh, a long-standing request that closes a real usability gap.
Then finally for observability, ASP.NET Core now emits open telemetry semantic convention tags natively. Every request is automatically traced using the OTEL conventions without requiring external instrumentation.
And we're working on full open telemetry support for Blazor WebAssembly so that component level metrics and traces from the browser show up in the same dashboards as your server telemetry. The end result is that when you upgrade to.NET 11, your apps run faster, safer, and are more observable. No code changes required.
Next, our modern stack.
We're focusing our ASP.NET Core investments in.NET 11 on our modern stack, minimal APIs, SignalR, and Blazor. That's where we're pushing boundaries and adding new capabilities.
Other parts of ASP.NET Core like MVC, Razor Pages, API Controllers, they'll of course continue to be supported and will benefit from the foundational improvements that I mentioned earlier.
But that's not really where we're innovating. Our investments are focused on our modern web stack that most clearly aligns with modern web app need web app needs.
For minimal APIs and also for Blazor in this case, we're adding support for async validation so that your validation logic can perform long-running operations without blocking like checking a database or external service.
We now support the latest OpenAPI version, OpenAPI 3.2 with proper support for binary file responses.
And we're fixing a long-standing testing pain point when using web application factory with minimal APIs and trying to set up custom configuration.
SignalR is getting off token refresh support like I mentioned earlier for the for long-lived connections and we're also adding a correlation ID support for distributed tracing.
Blazor has a lot happening. We're filling out Blazor's server-side rendering model so that you can use static server-side rendering without compromise.
We're writing support for temp data, binding to session state, output caching, client validation without requiring interactivity, adding async validation and much more.
We're trying to make it easier also to scale your Blazor server apps using pause and resume so that you can free up those resources when they're being held by idle circuits.
On WebAssembly, the big story is our runtime consolidation effort. We're transitioning the.NET WebAssembly runtime from Mono to CoreCLR.
We'll preview that in.NET 11 and then ship it stable in.NET 12.
New runtime capabilities like multi-threading, 64-bit memory and all the other WASM 3.0 features will land on the CoreCLR base runtime so that we don't have to build them twice.
In the meantime, we are also shipping a new project template for Blazor web workers that allow you to move CPU-intensive work off of the UI thread today.
And lastly, support for C# unions. Union support is coming to C# finally and we're lighting it up across the the entire ASP.NET Core stack for richer API contracts, more expressive component parameters and better type safety.
All right, enough slides. Let me show you some of these new improvements that we've shipped in the.NET 11 previews so far.
So here I have some sample applications to demonstrate a lot of the new functionality in.NET 11. First, let's look at some of the new minimal API improvements. Here in this minimal API project, you can see that right here we've got support for OpenAPI 3.2 wired up and configured, ready to go. We can see that if we go ahead and start this app and get it running.
Actually, let's make sure we actually start the API project.
All right, great. Let's go ahead and open this up in a browser so we can just see the open API document.
There we go. And if we zoom in, you can see, yep, in fact, this is using open API 3.2. What does this give you? Open API 3.2 adds support for structured tags, better support for streaming responses like server-sent events, and better representation of different off flows. Also, if we look at what's happening in the console, we can see that we're currently dumping to the console all of the the activity tags, and we can see that we're getting out of the box open telemetry semantic conventions for the HP request, for the response, for the route, and that's without having to add any additional instrumentation. If we go back to the code for the app, here we can see that all we're doing is is adding the trace source for Microsoft ASP.NET Core. We don't have to add the open telemetry ASP.NET instrumentation ASP.NET Core package anymore. Although, you probably still want to cuz it does bring some niceties. Hopefully, this native support for the the open telemetry semantic conventions will just make it more efficient.
Okay, so that's open telemetry and minimal APIs. Let's look at some Blazer features. Switch this over to Blazer.
Run this.
There we go. Okay, so for Blazer, we got all sorts of new goodies.
A major focus for Blazer in.NET 11 is giving you parity with static server-side rendering features that you probably are used to with MVC, but it hasn't been available in Blazer yet. Let me go ahead and snap this side by side with Visual Studio so we can see these things together with the code.
Let's try and like that. Okay, so first of all, uh environment boundary, this is a new component that we've added in.NET 11 that lets you conditionally render some content based off of the current ASP.NET Core environment. For example, you might want to render some content only if you're in development or in development and staging. You can also say that I want to exclude this content like don't render this content when I'm like in production. And you can see the corresponding content being rendered over here on the in the application. So, that's the new environment boundary component. Corresponds to like the environment tag helper in in MVC.
We also have a new label component that makes it much easier for you to set up labels for your Blazor forms. Here's the label label component in action. You can see that we're using just the normal C# expression to point to the model property that we want it to generate this label for. And that's generating us a nice label in our form with a a friendly display name properly associated with its input text uh uh HTML element. You can also of course use the the label component using the wrapping pattern where you wrap the the input. That works, too.
Uh display name's a new component that actually will give you that friendly name for the for the property. Here in this table, you can see we've got friendly names being displayed for each column in this quick grid data grid component. If we look at the code for that, it's over here. So, here's the where all those table headings are being generated and they're being generated this new display name component, which again you just pass in a C# expression and it will pull out the the friendly name for that particular property. Down below, you can see that we're also showing an example of using that display name component for generating a label.
This is effectively what the new label component is doing for you.
Uh quick grid has some new bells and whistles as well. Let me make this a little bit wider so we can see. Quick grid now has a new, uh, on row click, uh, uh, per, uh, component parameter that you can use to wire up an event handler for when the user clicks on a particular row and then gives you the the model instance that was used to render that row. So, if I click on rows in this table, you can see that it selects the specific person and then displays it.
So, that's pretty nice. It's pretty cool. Uh, we don't have time to go through all these, but we'll get through as many as we can. Uh, temp data is a, uh, actually, let's do the supply parameter from temp data version of this. Temp data is a feature that if you've used MVC before, you're probably familiar with. It's where you want to, uh, save a little piece of data so that it can be, uh, read again on a, on a subsequent page navigation. Often, this is used when you have a form and you do like a post and then a redirect get. Uh, you want to save a little data to to display on, uh, that, uh, subsequent redirect. So, you can now do that in Blazor. We support, uh, temp data. Like here, uh, if I click on this button, it'll do a post request and it'll save a little piece of information, in this case, the the server, uh, time into a message that can be read from the the page when it when then renders. If we look at the code for what that looks like, let me bring this over to the side and let's look at the, uh, supply parameter from form example. So, here's our our edit form. And then we're we're, uh, there's this the submit button that's, uh, when you click on the button, that actually will, uh, capture the the server time. Go to definition, we should be able to see that. So, here you can see that we're grabbing the server time and then we're saving it in this status message property. We'll look at that in just a second. And then we do that navigation. So, this was a full page navigation. It's not an interactive rendering scenario. If we then scroll back above, we can see that that status message property has this new supply parameter from temp data attribute, which is saying that this parameter should be saved in temp data, uh, and then, uh, made available, read out of temp data when the when the page loads.
That's how we're able to then, uh, uh, render that, uh, that message. If we then refresh the page, the temp data, of course, goes away cuz it's just a a temporary place to store some information. Usually stored in a cookie, although you can use other providers as well.
That's new temp data support.
There's some new enhancements to virtualization.
Let me show this example. So here we are using the virtualized component to render a very long list of items. I think it's in this case it's like yeah, 10,000 items that we're rendering in this list. Virtualized is a nice component that lets you display a long list of stuff, but only have to render the parts that are currently currently visible. And you just basically create a virtualized component and provide it the items you want to render and then how you want them to be rendered. Previously, you had to specify a fixed item size, like a fixed height for each item, so it could figure out which items were actually visible.
Now it does the even more complicated logic of figuring out how to render the right items when they even have different heights as you can see here in this example. So we're rendering 10,000 rows really efficiently and very fast.
Very nice. And now a couple other improvements with validation. So on this page, again in another example of where we're improving static server-side rendering. This is a form where we have client-side validation logic. Like if I go and let's try and type my name, but I only put a single character. If I tab off, you can see that it validates. But unlike other Blazor forms in the past, this page is not interactive. If we open up the Let me open up the browser dev tools.
And let's clear all filters and just refresh the page more time so we can see what's happening.
If we look at like, you know, the web socket connections on this page, there is a web socket, but that's just like this browser refresh thing from Visual Studio. There's no Blazor server web socket. There's also no web assembly being loaded on this page. It's just a normal static server-side rendered page, but we're still getting that rich client-side validation support. How is that happening? Well, Blazor now has built-in client-side validation logic that can be run even when you're running without interactivity. We have a a new a JavaScript based validation library that's incorporated with Blazor that enables these scenarios so you don't fall off that cliff from going from static server server side rendering to having to to enable interactivity just because you want some validation on your form. So that's pretty cool. It works also when you send the message. It's a very lightweight library too. It has no jQuery dependency which is which is really nice. But if we look at how it's being implemented like on the the actual elements here, you can see that it's using the same data validation attributes that are used by MVC and Razor Pages.
If we then switch the language for this form from English to Spanish and then let's trigger the validation again, you can see that now my validation error messages are being rendered localized which is fantastic. So data annotation based validation messages now get localization long standing pain point now now addressed in.NET 11. And then lastly for validation, I want to show this form. This form's a little bit oh, we should probably switch back to to English so we can for us English speakers out there.
Let's refresh. Great. Okay. So here what I want to do is I want to select a like a username for an account, but this username needs to be unique. If I select a username that's already taken, then I should get a validation error. Like let's say I try to grab the admin username that's almost certainly taken. Notice that I get a little bit of UI experience there saying hold on, I'm checking the database to see if that username's taken already and it is. That was an asynchronous validation check.
You know, it didn't it wasn't it wasn't synchronous. It was a long running activity and we were able to even add some UI experience as part of the the check happening. Right, then select a username that maybe it's not already taken like my favorite username. Then yeah, that one's kind of currently available. So if we look at the code for this page, the async validation page here. When we look at the um the edit form, we can see that there's some nice new APIs that have been added to the edit context. Like here's the uh the edit context that now has uh APIs for checking are we in the process of validating, has the validation faulted in some way, and is validation uh messages available. And if we look at the handle submit uh implementation, we can see that there is now a validate async method on on edit context. So, this is part of the story. In.NET 11, we're also working on actually adding uh async validation support to uh the system component model data annotations uh APIs as well in the core libraries. That's still coming, but once that's done, you'll be able to just annotate your types with asynchronous validation attributes and have that plug into this experience, too.
Okay? Cool. So, those are some of the server-based Blazor improvements. What about WebAssembly? Well, there are WebAssembly improvements as well. Let me close that app, and let's switch.
Let's shut this down. Okay, so we also in you can see in the the the solution we have a Blazor a standalone Blazor WebAssembly app. And then we also have a new Blazor web worker project. So, a Blazor web worker is a way to run some.NET code on WebAssembly in the browser, but not on the UI thread. Have it run in a separate web worker. If you want to create one, there's a new project template you can use.
If you just search here for web worker, we should find it. Yep, uh there it is. So, this guy right here, that's the new Blazor web worker uh project template that I used for this sample application, and it's just referenced from the um uh from the uh uh the Blazor WASM features project, which is just a standalone Blazor WebAssembly app. And what this gives you is it gives you this web worker uh client uh class that you can use to create web worker clients, and that will then, you know, run a bunch of JavaScript, which will set up the.NET runtime uh to run in a worker uh instead of on the the UI thread. And then you have this invoke async method that you can then use to call some some code that you want to have executed on that on on that on that worker thread. So here in this app I've got a what is it a data this data worker class that's sitting in the the web the Blazer web assembly project and it has this analyze sales data method that you can see is labeled for as a JS export so it can be called from that web worker. And this just does a whole bunch of like you know, compute like it takes a bunch of sales records and does a bunch of number crunching on them some CPU intensive task. If we try to do this on the UI thread it would probably freeze the UI thread and prevent UI interactions. But with the new web worker we can push it off onto the uh onto a separate web worker so it doesn't doesn't block the the flow. Let's see what that looks like if we run it. We switch to this one features and let's run this.
Okay, so there'll be two variations of this app. One where we're going to run it locally like on the UI thread and then one where we run it on the web worker. So here you can see there's this counter that's chugging away that's showing us that the UI thread is healthy. If we try to process like you know, a quarter million of these sales records on the main thread notice that the counter freezes you know, things aren't running anymore we've blocked threads and that's not great. But if we instead choose to process it on the a web worker let's do that.
Notice that the counter continues to chug along we haven't blocked the UI thread we can still navigate around the app and we're able to to to do that processing. Okay? Now to be clear this is not like true multi-threading.
There's no shared memory here between the web worker and your UI thread. Uh you can think of it more like a like a separate process. It's just message passing between the two. And you are actually loading a second dot net web assembly runtime in that web worker. So it can be a bit memory heavy. So you know, be judicious in in how you use this feature. But still very cool cool way for you to move that uh CPU-intensive work uh off of the UI thread with the existing runtime.
All right. Those are some of the new improvements that are already available with.NET 11 to.NET 11 previews.
All right, next let's talk about how we're making uh easier to build distributed and cloud-ready uh.NET web apps with our uh with Aspire, with our friends on the Aspire team.
Modern web apps are, of course, distributed. Uh you've typically got a front end, you've got back-end APIs, you have AI services that you're talking to, databases, caches. That's a lot of moving parts. Aspire solves these development and deployment prob- uh concerns. It gives you orchestration, observability, and configuration management for distributed apps. You get a great local development experience and a clean deployment story.
In the.NET 11 timeframe, we're deepening our Blazer and Aspire integration.
We're making Blazer WebAssembly work properly uh with Aspire so that you get configuration, service discovery, OpenTelemetry, and simplified debugging from the browser all the way through to the back end.
We're also integrating with Aspire to simplify Blazer server scaling. Now, to make all this work, we're adding a new Blazer-specific Aspire host integration package and a new Blazer gateway service that sits between the browser and your back end.
It serves your standalone Blazer WebAssembly apps using map static assets, so it gets all the um the optimizations there. It also handles proxying API calls uh to any back-end services, so no no need for CORS. It will flow configuration data uh like your service discovery uh data uh to the client, and it also collects OpenTelemetry information uh for like populating the Aspire dashboard. And it can handle uh um uh session affinity as well.
It replaces our existing Blazer dev server that we've used for many years for local development with something that is now production grade. It's good for local development, but also when you deploy the app, it can be used as a production service to host your standalone Blazer web assembly apps with all the appropriate optimizations and integrations. Let me show you what I mean.
Okay, let me switch out of this app.
Let's look at a standalone Blazer web assembly app that has now been integrated fully with with Aspire.
Okay, so here in this solution, we've got a few things going on. We have a This is a Blazer web assembly project, just a standalone project. So no no server component. And then we have a back-end API, like a minimal API for getting some some weather that the the Blazer web assembly front end calls. And then we have some normal Aspire stuff, like we see the Aspire app host, which is orchestrating all the parts, our front end and our back end. And we see the the service defaults project, which wires up things like you know, health checks, resiliency, and all that stuff. What's new is we also now have this client service defaults project, which can be used to set up specific service defaults that are needed for the Blazer web assembly apps, like specific concerns that are needed when running from the the browser browser. Similar to the the new service defaults template that Maui has for building native mobile applications. Now, to create that client service defaults project, there's a new project template. You can see it here if we go looking for Blazer service defaults. There it is. There's the new Blazer web assembly service defaults template that you can use to set up your Blazer web assembly app to work great with Aspire.
Okay, now let's take a look at the the app host project. Notice that it's referencing the new Blazer Aspire hosting integration package. And inside app host.cs, we've got a couple things going on.
First of all, we're we're setting up the API project. That's nothing new there.
It's pretty standard. But then we have this new app Blazer Wasm project for our Blazer WebAssembly app, and it has a reference to that API project. So, Aspire now knows that this front-end client app wants to talk to that API and needs to make it available so that it can actually be be called with an actual endpoint. Then we have our new Blazer gateway that we're setting up to actually host the Blazer WebAssembly app. That's what this with Blazer client app call is doing. And it will also expose the API endpoints that that app needs to call, and it will also collect the OpenTelemetry data from the client so that you can see the whole flow end to end in your application. Let's go ahead and run this so we can see what it looks like.
I'm going to run the app host project.
Okay, cool. And that should bring up the Aspire dashboard.
Awesome. Okay, so what do we got here?
We have a couple thing a couple resources that are showing. We have our gateway which is the new service that's going to host our Blazer WebAssembly app, and you can see that the Blazer WebAssembly app is sort of nested underneath it. And then we have the API that the Blazer WebAssembly app will call. Now, if we browse to our Blazer app, let's make sure it's working so we can navigate around. We can click the counter. We click on the weather page and that was able to looks like it got some weather data so it was able to call the weather that weather API and get some data back. Now, a few things to to note in the code, I can go and look at how the client project, like I think it's this one, right? Is that what I'm looking at? Yes, great. So, here in the Blazer WebAssembly app, you can see when we set up the HTTP client that we're going to use to talk to that weather API, notice that it's using the Aspire service discovery convention to say like, "I want to talk to the weather API. Aspire, you figure out what the actual URL is that I need to talk to."
And so, with the gateway and all this the machinery that's set up, the the gateway will flow the service discovery config data into the Blazer WebAssembly app so it can correctly resolve this this this URL.
And it seems like it that worked. So, let's go back and now check a couple things. Let's Let's look in like the the Let's look in the structured logs.
So, here we should be able to see that call.
Uh yeah, like right here we see start processing HP request and made It says start sending the requests, and sending it, and then proxying it through the through the gateway to the back end, and that succeeded. So, like we can even see this actually in the traces. Like if we scroll down here at the bottom, yeah, there we go. So, here we can see the you know, we browsed to the weather page. It issued an HP request from the browser to our server. The the the gateway got the the this the service discovery information and was able to proxy it to the right API, which it then returned the the weather data. So, there's that that flow end-to-end. And we can even get like metrics from our Blazer WebAssembly app because it's uh uh ex- exporting open telemetry uh to the the the dashboard. So, if we click the app, we should be able to see in here things like I don't know. Let's look at like the page number of page navigations.
Yeah, we we navigated around three times. And if we scroll down, we can even tell like which pages got browsed to and so on. All the the normal Blazer uh metrics and telemetry is now being surfaced even from the from the browser.
Super cool. And the additional experience that we also plan to add is like a debugging experience where from the dashboard, you can have like a a gesture here where you can uh launch the app uh also with the debugging attached so that you can debug into your your code while you're running it.
That's that's also coming.
All right. Now, let's talk about making your web apps agentic.
Modern web apps are increasingly agentic. They include AI agents that reason, plan, use tools, interact with and interact with the user in real time.
Uh that's a new set of requirements for a web framework. And we want ASP.NET Core and Blazer to be the best place to build these kinds of apps.
We've been working closely with our friends on the Microsoft Agent Framework team so that you can host agents directly inside your ASP.NET Core apps and tap into the capabilities of AI services like Microsoft Foundry.
Uh that includes built-in hosting support for uh different uh agentic protocols like the OpenAI responses uh protocol for chat completions and function calling. Uh the uh A2A or agent-to-agent protocol for multi-agent orchestration and also for AGI, a protocol for real-time agent-to-human or user interface interactions.
You can expose your app's functionality also as uh an MCP server to other agentic apps or have your app act as a client uh that can consume tools and resources from other MCP servers using the MCP C# SDK.
All of this integrates naturally with ASP.NET Core's middleware, dependency injection system, authentication, and observability.
Now, building agentic UIs is a is a uh is its own challenge. Uh you have streaming messages, you want to show tool execution and reasoning in progress, you want to synchronize state between your agent and the user interface so it knows what the user is looking at. You might want to have multimodal inputs like speech and and images or video, and you often want to have human-in-the-loop workflows where the human and the agent work together and the human stays in control.
With the AGI protocol or agent-user interaction protocol, um you get an open uh event-driven protocol that standardizes the wire format between agents and user interfaces. AGI lets you focus on your UI instead of all that plumbing. AGI support in Microsoft Agent Framework is currently in preview, and we're also looking to build a set of Blazor AI components to make building agentic UIs straightforward.
Let me show you what that looks like.
Now, if uh you're unfamiliar with AGUI, I encourage you to to learn more about it by going to agui. uh dot com uh which will bring you to the AGUI specification page. They also have a really nice sample application, which is this uh AGUI Dojo app, which showcases a whole bunch of different AGUI scenarios using a a variety of different uh agentic framework backends, including the Microsoft Agent Framework. So, you can see here that you can do, you know, standard things like have the uh chat interfaces. Like if we ask it to generate a sonnet, it will of course then stream us back a uh a uh a a lovely sonnet. So, pretty cool stuff, and there's a bunch of other scenarios uh uh showcased here. Now, this front end is built using JavaScript and React. It's built using a set of uh components provided uh by Copilot Kit, which you can absolutely use. It might be a great fit for your um for your.NET backend.
But, what if you wanted to build experiences like this with Blazer? Well, that's what we've been working on.
So, here in this uh project, I have a sample application that is a a a.NET and Blazer implementation of the AGUI Dojo.
Now, uh I'm going to go I It takes a second to get this up and running, so let me go ahead and kick this off so it starts to execute, and I'll show you some of the code. So, here uh on this in the server project, this is where we're hosting our our our agents using uh Microsoft Agent Framework. Uh you can see that in order to create uh Microsoft um Agent Framework AGUI endpoint, all you have to do is call map AGUI, and then you just point at the agent that you want to to host there. You can see that we've got a uh you know, a bunch of agents that we're we're wiring up that way. Um with Agent Framework, one of the cool things it does is it integrates with my uh it's built on top of the Microsoft Extensions AI abstractions, so you can do things like wire up uh support for tools. Like here, we have a um an agent that has access to this uh get weather tool, so I can figure out what the current weather is from from the server. So, it integrates nicely with that with that functionality.
Then on the client, we also provide an AGUI client chat client implementation, which you can see right like for example right here.
Here's an example of one. AGUI chat client is actually an implementation of the I chat client interface from Microsoft extensions AI. So, it plugs in seamlessly with all of that infrastructure, but it also has specific affordances for UI scenarios based off the AGUI protocol. Like for example, one of the things you can do with the with AGUI is you can actually have front end tools, tools that aren't just available from the server, but can also be available from the from the client. Like down here, you can see that we're setting up a tool that allows the agent if it wants to to call down into the client and change the the color of the of the background in the the user interface.
So, let's check this out. Let let me see if the app's up and running. Looks like it is.
Let's now go back here, and let's run the Blazer version of the AGUI Dojo. We should be able to still do the same things like you know, generate a sonnet and get some streaming text back.
There we go. So, that looks good. But what's really neat and and different is we can also ask it like, "Hey, could you please change the background color for on the front end?" And this is a front end tool call that then gets plumbed back to the agent, so it can uh talk back to the to the client and then execute that tool. So, that's pretty neat. You can of course call back end tools as well, and then AGUI has affordances for like rendering custom widgets when you invoke a tool. Like here, we're rendering this this widget for representing the weather when we're making a back end tool call to that weather tool.
Uh you can do human in the loop scenarios like let's say we want to work on a plan together with the agent. So, here we're getting a custom component that's being rendered where we can select like you know, which parts of this plan we like, and then we can either confirm, yep, that looks good, or we can reject it and say, no, no, agent, I've changed my mind, don't do that, and have it roll back.
So, that's how you can have like human agent interactions, and then you can also have flows that are that are long-running and generative.
Like here, if we ask the agent for a plan, and then we want it to execute it, like here, it's I think it's generating a plan for going to Mars. You can see that I'm getting streamed updates into the user interface as the agent makes progress on this particular plan, because there are specific events in the AGUI protocol that allow it to do that, and much more.
It can also, you know, you can have full state sharing between the state of the UI and the agent, so it can basically be a full collaborator in your UI experience. These are just some of the experiences that that AGUI enables, and we are also working on Blazer components specifically to make these scenarios easy to build. You can see some of these components here in this um in this sample application, like we have this agent boundary component for the the chat interface, that you point the to the agent that you want to to to drive with this interface, and then this messages component, these agent loading indicator components. Don't get too attached to the specific names here, these are still just prototype, but it shows you the direction that we're we're going.
Something to look forward to. All right, so that's how you can build agentic user interfaces using.NET and Blazer with the with AGUI.
So, let me try to stop stop this application.
Yep.
All right, finally, let's talk about how we're improving AI-assisted.NET web development.
Now, AI coding assistants like, you know, Copilot, they can be a great partner when they understand the frameworks that you're using.
But sometimes they struggle with features or scenarios that they're unfamiliar with. They might pick the wrong pattern, they might miss a new feature, or they might generate something that compiles but isn't idiomatic. So, we're investing in four areas to make AI assistants genuinely smarter about.NET.
First of all, agentic skills.
For web, we're working on a variety of ASP.NET Core and Blazor AI skills to give uh coding agents useful new capabilities and expertise. You can find and install these skills from the uh set of curated.NET plugins that are available in the.NET skills repo and marketplace.
We're also exploring custom agents, which are like specialized personas for.NET uh for.NET work. Like you might have a a a back-end ASP.NET Core developer, or a front-end Blazor developer, a tester, a doc writer, or an architect. Each can have deep framework knowledge and a focused skill set for that specific role. We're exploring which personas might matter most for.NET developers.
Uh tools, we can give uh command line tools and executables that uh give your agents new capabilities. Uh for example, the C# LSP gives agents a rich semantic engine for navigating and editing your code. Uh the.NET Inspect command line tool lets an agent query.NET APIs across NuGet packages and local projects. Other MCP servers can add useful features like integration with with Playwright. We're exploring what CLI and MCP-based tools should be included for.NET scenarios.
And then lastly, eval test suites. Uh we're building uh evaluation tests for real.NET coding tasks so that we can actually measure whether our skills, custom agents, and tools move the needle and actually improve the experience. If we can't measure it, we don't really know if it works. The eval suite helps keep us honest. Now, let me show you one of our um new Blazor skills in in action.
Hop over here.
Let's open up this project.
Actually, before we look in deeply at that project, let me show you the.NET Skills Marketplace and repo. If you go to.NET/Skills, you'll find the the.NET Skills repo and Marketplace. And in here, there's a whole bunch of different plugins that you can choose to install for different.NET scenarios. We have these two right here for ASP.NET Core and for Blazer.
You go check out the the Blazer plugin, it includes a whole bunch of brand new skills that just landed recently for authoring components, how to correctly handle user inputs, configuring auth, you know, coordinating once components, a whole bunch of stuff. One that's really interesting is this Plan UI change. This skill really helps the the agent like sort of break down the user interface into composite parts. Um we find that with Blazer, I mean, I don't know, maybe this is true with other web UI frameworks as well. Agents have a tendency to sort of create big monolithic components instead of breaking them down into subcomponents. This skill helps instruct the agent so it does a better job of that. Let me show you an example of that of a a test that I ran using this skill.
So, here I asked the agent to just create a Blazer app that is a Kanban board, you know, where you have um uh cards that you can move between different columns to to to track the progress of of work. And in the original time with the case where I ran this, I ended up with a a board implementation that looks like this. And I think it's like, I don't know, good like 3 400 lines of code all in one giant board.razor file. So, not not great factoring. It does it does work. Let me make sure I've got it selected. So, here's the the original app, you know, actually functioning.
So, here's the board and you can you know, you can see stuff that's to do, in progress, and done. You can move stuff left and right in here. You know, very basic Kanban board implementation. But, the factoring of the components isn't great. So, then I added the the Blazor plugin and asked the agent to to build a Kanban app, but this time using that the the set of Blazor skills that we've added. And it ended up with something that now looks like this. So, here's the updated version of the application. And let's look at the the board page. So, here's the refactored version and now you can see I get some nice subcomponents with component parameters where we're flowing data through throughout the application, much nice uh better factored. Now, if I run this one, you know, we get a very It's not exactly the same, you know, it's it was a different agent run, so the styling slightly different, but still just as just as functional. So, more idiomatic code leveraging the skills that that we provide in the the.NET skills repo. So, definitely check those out, you know, install the skills that are most relevant to you. Um they are added on a on on need-only basis, so you don't have to worry about them contaminating your context window. And we heavily test them using eval test suites to make sure that they have, you know, real benefits for real-world scenarios.
All right. So, that's what we're delivering for.NET web developers in.NET 11. Here's the big picture.
We're strengthening the foundation of the platform by giving you more performance, security, and observability.
These are improvements that are often driven by the some of the largest.NET services in the world, and they flow straight into your apps when you upgrade. We're investing in our modern stack, minimal APIs, SignalR, Blazor, so that you get awesome new features and innovations like support for C# unions, async validation, Open API improvements, and so on. For Blazor specifically, we're really focusing on server-side render rendering feature parity with MVC, as well as server scalability, and also the the new CoreCLR based.NET WebAssembly runtime.
We're making distributed apps easier with Aspire, including better support for Blazer WebAssembly, with service discovery, end-to-end observability, and a production-grade hosting story with the new Blazer Gateway. We're positioning.NET for the agentic web together with our friends on the Microsoft Agent Framework team, including adding support for the AGUI protocol and Blazer AI components. And we're making AI smarter about.NET with agentic skills, custom agents, tools, and eval test suites so that AI systems just love working with with.NET code.
And throughout it all, we're working with you to address those top feedback top top feedback and and pain points.
Here are some ways that you can get involved with the future of the agentic web today. You can try out our.NET 11 previews by going to get.net 11, install the SDK, try out one of our new templates, kick the tires, let us know how it goes. You can get get going with.NET AI at dot.net/ai, where you can try out Microsoft Extensions AI, Microsoft Agent Framework, the MCPC# SDK for building agentic applications. You can aspirify your your your.NET apps by going to aspire.dev. You can try installing the new.NET skills at the.NET skills repo.
And then please, you know, build something cool, share with us your experience so that we can keep making the the platform better. Thank you for listening. I hope you enjoyed learning about the the future of the agentic web with.NET. And with that, happy coding.
Related Videos
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Introduction to Problem Solving Part - 1 | Lecture 1 | Intermediate DSA
ascensionix
107 views•2026-05-29
So What's Odin Lang Even Good For
TechOverTea
131 views•2026-06-01











