Weekly .NET Roundup: Agents, MCP, and .NET 11 Performance

by TechHub

Welcome to this week's Weekly .NET Roundup, where the center of gravity kept shifting from chat-based assistance to agentic workflows you can host, secure, and observe in real apps. Azure Functions gained richer MCP building blocks (including Entra ID auth and structured responses), Blazor demos showed agents triggering UI actions through components, and Microsoft Agent Framework pushed the “agent harness” idea as a practical control plane for approvals and telemetry. On the platform side, .NET 11 preview 5 introduced StringBuilder.MoveChunks() to reduce allocations in hot text pipelines, while Azure tooling and IDE updates (azd, Azure SDK, VS Code, and Visual Studio) focused on tightening day-to-day loops for provisioning, AI-assisted development, and cost/usage visibility.

This Week's Overview

Agentic AI and MCP show up in more .NET workflows

Microsoft's agent story kept expanding this week, building directly on last week's Build 2026 throughline that agentic workflows are moving from demos into day-to-day .NET delivery, with updates that connect “agentic” patterns (plan, tool calling, memory, approvals) to concrete developer surfaces like Azure Functions and Blazor. The common thread is moving from chat-only assistants to agents that can trigger actions, return structured outputs, and integrate with identity and tooling in a way that fits real apps.

For .NET teams, the practical question is no longer “can an LLM answer my question?” but “how do I host, secure, observe, and control an agent that can do work in my system?” This week's posts and demos filled in those pieces: MCP (Model Context Protocol) extensions for Functions, UI-triggered actions in Blazor via WebMCP, and the Microsoft Agent Framework's “agent harness” approach for production concerns like approvals and telemetry.

Azure Functions MCP Extension adds triggers, UI apps, and Entra ID auth

The Azure Functions MCP extension update (as shown at Build 2026) added multiple building blocks that make MCP servers feel more like first-class apps, following last week's focus on MCP-style integrations as the “plumbing” that turns agent plans into governed tool calls. New resource and prompt triggers let you activate behavior based on resources or prompts, and MCP Apps introduce an interactive UI layer instead of treating everything as headless tool calls.

On the response side, the extension now supports structured and rich content responses, which matters if you're returning JSON payloads, cards, or content that downstream clients need to parse reliably. Built-in MCP authentication with Microsoft Entra ID (plus On-Behalf-Of (OBO) flow samples) is a big step toward running MCP endpoints in enterprise environments where delegated identity and least-privilege access are required. The roadmap callouts (Foundry Toolbox integration, plus planned streaming output and pagination) hint at the next set of developer ergonomics and scalability features.

Blazor + WebMCP: letting agents trigger UI actions through components

A Blazor Community Standup demo showed WebMCP exposing Blazor component actions so an AI agent can drive UI interactions from natural language, extending last week's theme of treating agents as app components (not just chat surfaces) by putting tool-calling directly against UI behavior. The key idea is that UI components can become “tools” an agent can call, bridging the gap between an agent's plan and an app's actual interaction model.

For Blazor developers, this points to a pattern where you keep domain logic in components/services but add a controlled surface that maps user intent to specific actions. The hard parts to watch are the usual ones for tool-enabled agents: permissioning, validation, and making sure agent-triggered UI actions stay predictable (and testable) as the app evolves.

Microsoft Agent Framework formalizes the “agent harness” pattern

Wes Steyn's posts introduced (and then started a series on) Microsoft Agent Framework with a focus on the “agent harness” pattern, which reads like a direct continuation of last week's Aspire + MAF guidance on making multi-agent apps observable, debuggable workloads rather than black boxes. Instead of treating the agent as a single black box, the harness framing encourages you to design the control plane that decides when the agent can act, which tools it can use, and how you measure and debug behavior.

The runnable .NET and Python samples walk through plan/execute modes, structured output (JSON Schema), and tool calling against hosted web search, which is useful if you're standardizing agent behavior across a polyglot stack. The follow-up “claw” post makes the production path explicit: start with a minimal CLI-style coding agent, then layer in governance, telemetry (including OpenTelemetry), and enterprise controls (like Purview) as you move toward real deployments.

Spec-driven development tries to reduce “prompt iteration” debt

An On .NET Live session argued for spec-driven development as a way to make LLM-assisted building less guessy, and it fits neatly with last week's “golden repos” idea of grounding assistants in explicit, versioned standards rather than ad hoc prompt tweaks. The idea is to shift effort from repeated prompt tweaks to a clearer spec that tools can follow, with GitHub Spec Kit used as the example workflow.

For teams adopting agents in real repositories, this is a reminder that “better prompting” often hits diminishing returns. Tightening inputs (specs, constraints, acceptance criteria) can improve repeatability, code review quality, and the agent's ability to generate changes that match intent, especially when multiple contributors or multiple agents are involved.

Explainers: agentic AI concepts and multi-agent orchestration with Semantic Kernel

Two deep technical explainers focused on how goal-driven agents plan tasks, call tools, and maintain context in the Microsoft ecosystem using Azure AI Foundry, Semantic Kernel, and Microsoft Graph, continuing last week's Build-era framing that Foundry + agent frameworks are becoming the default stack for “agentic” .NET work. A separate post extended that framing to multi-agent systems, covering orchestration, delegation, agent communication, and shared memory, plus the operational challenges that show up quickly (observability and cost control in particular).

If you're evaluating Semantic Kernel beyond “single copilot” scenarios, the multi-agent discussion is a useful checklist for architecture decisions. It reinforces that as you add agents, the integration work shifts from “how do I call an LLM?” to “how do I coordinate workloads, track decisions, and keep tool access and spend under control?”

.NET performance and low-allocation APIs: StringBuilder.MoveChunks in .NET 11 preview 5

The .NET 11 preview 5 work on StringBuilder.MoveChunks() targets a specific but common performance pain: allocations caused by calling ToString() just to hand text to another API. MoveChunks() transfers StringBuilder's internal chunks without copying, enabling APIs to accept StringBuilder data more directly.

Andrew Lock's walkthrough connects the feature to a real compiler/tooling scenario: creating Roslyn SourceText for source generators without forcing a large intermediate string allocation. For developers writing analyzers, generators, or other high-churn text pipelines, this is a reminder to watch upcoming framework APIs that let you keep data in builder-like structures longer, especially in hot paths.

Azure developer tooling updates for .NET teams

This week tied together Azure tooling changes that affect day-to-day developer loops: provisioning and CI flows with azd, and SDK-level updates that bring new GA libraries and preview AI agent hosting components. The theme is reducing glue code and making repeatable environments easier to stand up and secure.

Azure Developer CLI (azd) 1.24.3 through 1.26.0: new commands and safer provisioning

The Azure Developer CLI recap covered versions 1.24.3 through 1.26.0, highlighting new azd tool and azd exec commands along with improvements around provisioning safety and extensions, which complements last week's “build and operate” agent focus by tightening the repeatable environment side of the loop. The post also calls out fixes across deployments, concurrency, authentication, and CI/pipeline scenarios, which are the areas that tend to cause “works locally, fails in automation” friction.

For .NET app teams using azure.yaml, Bicep, and GitHub OIDC, these changes are worth scanning for behavior shifts, especially if you rely on federated credentials in pipelines. If you maintain internal templates, consider retesting provisioning flows with the newer azd versions to catch auth or concurrency regressions early.

Azure SDK (May 2026): Azure Batch for .NET GA and more AI building blocks

The May 2026 Azure SDK roundup highlighted GA for the .NET Azure Batch client library (Azure.Compute.Batch 1.0.0) and also noted GA for the Azure SDK for Rust. On the AI side, it called out Azure AI Search “knowledge-base retrieval” features (including KnowledgeBaseRetrievalClient) plus preview Azure AI Agent Server hosting libraries, reinforcing last week's Build storyline that agent hosting is getting packaged into more standard Azure components.

For .NET developers, the Batch GA update is a concrete milestone if you're running large-scale job orchestration, while the AI items point toward more standardized patterns for retrieval and agent hosting. If you're building RAG (retrieval-augmented generation) features, the knowledge-base retrieval additions may be a better fit than rolling custom query + prompt assembly in application code.

VS Code and Visual Studio: AI-assisted workflows keep expanding

Microsoft's editor and IDE updates this week leaned into two threads: more capable in-editor experiences (including the integrated browser) and more AI-forward workflows (Copilot, agents, and even AI-assisted feature discovery), which follows naturally from last week's Build watchlists pointing .NET teams at IDE surfaces designed around end-to-end agent workflows. For .NET developers who split time between Visual Studio and VS Code, the signal is that both environments are converging on “assistive” building blocks, but in different ways.

VS Code June recap: editor improvements plus Copilot updates

A VS Code Live session recapped the June releases with demos of recent improvements and GitHub Copilot updates, along with community Q&A. Even if you do not catch every monthly release note, the recap format is useful for spotting workflow changes that are easy to miss when they ship incrementally (especially around Copilot behaviors and UX).

If your team standardizes on specific extensions or Copilot settings, these release recaps are a good trigger to revisit configuration docs and onboarding notes. Small UI or behavior shifts can have outsized impact on training, internal screenshots, and “follow these steps” runbooks.

Integrated browser improvements land in VS Code

A separate update focused on the VS Code integrated browser, adding practical features like history, search, bookmarks, and screenshots, plus device emulation. The same roundup mentioned Mermaid diagram support and improved issue reporting, along with a preview of new VS Code Learn content.

For .NET web developers, the device emulation angle is a straightforward win when you're iterating on responsive UI and want fewer context switches. Mermaid support is also a small but useful addition if you keep architecture diagrams close to code (for example, in markdown docs in the repo).

Visual Studio 2022 gets AI-powered feature search (17.14.35)

A short demo showed an AI-powered workflow in Visual Studio 2022 17.14.35 for searching IDE features, aimed at helping developers discover capabilities faster. This is less about code generation and more about reducing “where is that setting/menu?” friction.

If you're supporting a team with mixed experience levels in Visual Studio, this kind of feature can reduce the overhead of internal support pings. It is also a reminder to validate what AI-assisted search surfaces in your environment if extensions or policies disable certain features.

Designing AI coding tools: skills vs agents, plus security and accessibility checks

Rohan Malpani's videos discussed how Visual Studio and VS Code are approaching AI integration, contrasting reusable “skills” with agent-based workflows (including the VS Code Agents window), a framing that lines up with last week's push to treat agentic workflows as shippable software with controls and checks. The focus stayed on how teams iterate in real repositories while maintaining quality, with explicit mention of security and accessibility checks as part of shipping production-ready code.

For .NET teams, this is a useful framing for adoption: start with narrow, repeatable skills for common tasks, then move toward agents when you need multi-step work across files and tools. Pairing AI assistance with security and accessibility checks is a practical guardrail, especially when AI suggestions can introduce subtle vulnerabilities or regressions in UI semantics.

MAI-Code-1-Flash in VS Code: end-to-end feature work via Copilot Chat

A demo walked through using MAI-Code-1-Flash in VS Code with Copilot Chat to explore a codebase and complete an end-to-end feature workflow (build, run, test), echoing last week's theme that Copilot surfaces are increasingly about multi-step execution (not just answers) inside the tools teams already use. The video also discusses cost considerations, which matters if you are choosing models for heavy daily coding usage.

For developers evaluating multiple models behind Copilot-like experiences, the takeaway is to test on your actual repo workflows: navigation, refactors, and test writing tend to reveal differences quickly. Cost only becomes meaningful once you understand which steps still require human iteration and which can be delegated safely.

VS Code 1.127: token pricing normalization tweak

VS Code 1.127 included a change to token pricing normalization to handle a legacy flat pricing payload returned by some endpoints. It is a small note, but it hints at ongoing work to make pricing/usage reporting more robust across different backends.

If you track AI usage costs via editor integrations, keep an eye on subtle release note items like this since they can affect how usage data is displayed or calculated. For teams doing chargeback or budgeting, even “normalization” fixes can change month-over-month numbers.

Running LLMs on Windows with .NET apps: Qwen3 on an NPU via WinML CLI

A detailed tutorial explored running Qwen3-0.6B on a Windows NPU using WinML CLI, framing the work around “token economics” (latency and cost tradeoffs when inference moves to the edge). The walkthrough covers ONNX export, quantization and calibration, compilation, and benchmarking NPU vs CPU, then connects it to real app shapes with a WinUI 3/.NET 10 chat app and a FastAPI backend exposing OpenAI-compatible streaming.

For .NET developers, the practical value is seeing the full pipeline, not just “it runs”: model prep, performance measurement, and integration patterns that match how teams build internal tools. The post also includes a pragmatic fix (a quantization patch for Qwen3's composite decoder), which is the kind of detail that often determines whether an edge deployment is a quick experiment or a repeatable approach.

Data and integration patterns for .NET on Azure and Fabric

Two posts focused on “unblocking the messy middle” work that .NET teams spend a lot of time on: ingesting data efficiently and migrating legacy integration logic, continuing last week's modernization thread by staying grounded in the real migration and operations details.

Fabric Data Warehouse Bulk Copy API (preview): faster ingestion without staging files

Microsoft Fabric Data Warehouse introduced a Bulk Copy API in preview as a client-side alternative to row-by-row INSERTs when staging files for COPY INTO is not possible. The post includes examples in C# (including SqlBulkCopy), Java, and bcp.exe, plus orchestration guidance for tools like Azure Data Factory and SSIS.

If you're loading data into Fabric from applications or pipelines where file staging is awkward, bulk copy can simplify the path while still improving throughput. Treat it like other bulk-load APIs: validate error handling, schema drift behavior, and retry semantics before you rely on it in production, especially while it's still in preview.

BizTalk-to-Azure migration: dynamic code-table mapping with Functions

A migration write-up described replacing BizTalk map-style code-table (value) mappings with an Azure Function that applies XPath-scoped rules to XML stored in Blob Storage, then enriches via SQL lookups with caching. This pattern is aimed at integration workloads where mappings change over time and you want to avoid hardcoding transformations into compiled artifacts.

For teams modernizing BizTalk or similar ESB-style solutions, it is a useful example of decomposing “mapping” into a service that can evolve with rules and data tables. The design choice to cache SQL lookups is important because mapping functions often sit on throughput-sensitive paths, and database round-trips can dominate latency if you're not careful.

Other .NET News

Several smaller items are still worth bookmarking if they map directly to your day-to-day work, especially around app packaging and migration.

Rick Strahl broke down why Windows subsystem selection (WinExe vs Exe) makes dual GUI/CLI apps awkward, then walked through three implementation strategies (console attachment with AttachConsole/FreeConsole via P/Invoke, launching GUI from CLI, or splitting executables and sharing code). If you ship tooling that sometimes needs a UI and sometimes needs scripting-friendly output, the tradeoff analysis is practical and includes implementation details like ILRepack.

Two short videos touched on modernizing .NET developer workflows in VS Code: one on migrating from .NET Framework 4.8 to .NET 10 (with a pointer to an AwesomeCopilot repo), and another on using VS Code and Copilot-era tooling to move faster through feature work. Even as quick hits, they are useful prompts to check whether your repo templates and extension recommendations match where Microsoft is steering .NET in VS Code.