The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 runs from September 14–18, 2026 at Oslo Spektrum in Oslo, Norway.

NDC Oslo is one of the largest and most respected developer conferences in Europe, covering everything from .NET and cloud to security, architecture, AI, and beyond. The 2026 edition is currently in the booking phase, with a massive lineup shaping up.

By the numbers

160 sessions (currently booking)
150 speakers (currently booking)
15 workshops (currently booking)
5 days — workshops + conference

Confirmed speakers

The speaker list is being built out, with confirmed names including:

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

Tickets

Early Bird tickets are available — the Early Bird offer ends May 22, 2026.

The CFP (Call for Papers) is also currently open.

Other NDC events in 2026

NDC Sydney — April 22–24, 2026
NDC Toronto — May 5–8, 2026
NDC Copenhagen — June 1–4, 2026
NDC AI — June 8–10, 2026
NDC TechTown — September 21–24, 2026

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 takes place on August 25, 2026 at Arena Cinemas Sihlcity (Kalanderplatz 8, 8045 Zürich).

This is an independent, non-profit community conference for developers, architects, and experts to discuss .NET, C#, ASP.NET Core, Azure, and the broader Microsoft development ecosystem. All speakers and staff volunteer their time, and any surplus from ticket sales goes to charity or the Swiss .NET community.

What you get

Top quality sessions from international subject experts
Networking with other participants
Food, snacks, and beverages during breaks, lunch, and apéro
Career opportunities through sponsor interactions
Direct discussions with speakers during breaks

Tickets

Tier	Price	Availability
Very Early Bird (Apr 1–30)	299 CHF	Max 100 tickets
Early Bird	399 CHF	Max 100 tickets
Regular	449 CHF	Until sold out

Speakers and schedule are not yet announced — the Call for Speakers is open on Sessionize.

Organizers

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 runs from May 11–15, 2026 at the Barbican Centre in London. The core 3-day conference is Tuesday through Thursday, with optional full-day workshops on Monday and Friday.

With 78 sessions and 14 workshops, this is one of the most packed developer conferences in Europe.

Topics

Architectural Thinking
Functional Code in C# 13
Serverless Design
Semantic AI
Azure Kubernetes Services
Lean DevOps Strategies
The Model Context Protocol (MCP)
Agentic AI in .NET
Refactoring the Monolith
Coding Faster with LLMs
Cryptography in a Post-Quantum World
Local First Development

Speakers

World-class lineup including Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm, and Raju Gandhi.

Tickets and info

98% of SDD 2025 attendees rated the overall experience as good, very good, or excellent.

Azure DevOps MCP Server April Update: WIQL Queries, PAT Auth, and Experimental MCP Apps

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

The Azure DevOps MCP Server keeps getting better. Dan Hellem’s April update covers both the local and remote servers, and there are some genuinely useful additions here — especially if you’ve been using Copilot to navigate boards and repos.

WIQL Query Support

The headline feature: a new wit_query_by_wiql tool that lets you run Work Item Query Language queries directly from your MCP client.

If you’ve used Azure Boards for any length of time, you know WIQL. It’s the SQL-like query syntax for work items: SELECT [System.Id], [System.Title] FROM WorkItems WHERE [System.AssignedTo] = @Me AND [System.State] = 'Active'. Having that available as an MCP tool means your Copilot sessions can now pull precise work item sets without you manually filtering or clicking through board views.

One caveat: on the remote MCP Server, this tool currently requires the Insiders feature flag while they validate query performance at scale. It’ll come to everyone once the telemetry looks good.

Personal Access Tokens on the Local Server

The local MCP Server now supports PAT authentication. This sounds like a minor quality-of-life fix, but it’s actually important for integration scenarios — specifically when you’re running the MCP server in a context where interactive authentication isn’t available, or when you’re connecting from external clients and automation.

Setup is documented in the Getting Started guide.

MCP Annotations on the Remote Server

Annotations are metadata tags on MCP tools that tell LLMs how to use them safely. The Azure DevOps MCP Server is now implementing annotations for:

Read-only tools — the LLM knows these are safe to call without user confirmation
Destructive tools — the LLM knows to be cautious and confirm before proceeding
Open-world tools — the LLM understands these may return unpredictable results

This is foundational for agent reliability. Without annotations, the LLM has to guess from the tool name whether it’s safe to call. With annotations, the behavior is explicit and the agent can make better decisions.

Wiki Tool Consolidation

The remote server is starting to consolidate related tools into fewer, more capable ones. The wiki tools are the first to get this treatment:

New Tool	Replaces
`wiki` (read-only)	`wiki_get_page`, `wiki_get_page_content`, `wiki_list_pages`, `wiki_list_wikis`, `wiki_get_wiki`
`wiki_upsert_page`	`wiki_create_or_update_page`

Fewer tools = better LLM performance. This is a consistent pattern across MCP server design — smaller, focused tool sets work better because the LLM doesn’t have to reason about which of five similarly-named tools to pick.

Experimental: MCP Apps

This is the most interesting addition, and it’s clearly experimental. MCP Apps are packaged workflows that run inside the MCP server environment:

{
 "servers": {
 "ado": {
 "type": "stdio",
 "command": "mcp-server-azuredevops",
 "args": ["contoso", "-d", "core", "work", "work-items", "mcp-apps"]
 }
 }
}

The first example is mcp_app_my_work_item — a self-contained work item experience that lets you view, filter, and edit work items assigned to you, without manually chaining multiple tool calls.

The idea is compelling: instead of your agent calling wit_get_work_item → wit_list_work_items → wit_update_work_item across multiple turns, a single MCP App provides the entire workflow as one structured, reusable unit. Reduced setup time, consistent behavior, fewer moving parts.

It’s on the mcp-apps-poc branch right now, which tells you where it stands in terms of production readiness. But the direction is right — more workflow composition at the MCP layer, less ad-hoc tool chaining in your agent prompts.

Wrapping up

The Azure DevOps MCP Server is maturing quickly. WIQL support and PAT auth are immediate wins for anyone using Copilot with Azure Boards. The annotation work makes the remote server safer for agentic use cases. And MCP Apps, while experimental, hints at where this is going: from raw tools to composable workflows.

Worth keeping an eye on the documentation as the remote server continues to evolve.

Original post by Dan Hellem: Azure DevOps MCP Server April Update.

SQL Server 2025 as Your Agent-Ready Database: Security, Backup, and MCP in One Engine

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

I’ve been following the Polyglot Tax series by Aditya Badramraju with a lot of interest. Parts 1-3 built a compelling case for SQL Server 2025 as a genuinely multi-model database — JSON, graph, vectors, and relational data all in one engine with a unified query planner. Part 4 closes the series with the parts that actually determine whether you’d trust this architecture in production.

Spoiler: the production story is solid.

One Security Model to Rule All Data Models

Here’s the thing with polyglot stacks: when an auditor asks “prove that Tenant A cannot see Tenant B’s data,” you have to answer that question for each database independently. Five databases, five security models, five proofs.

With SQL Server 2025, you define one Row-Level Security policy and it covers every data model:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

From that point, every query — relational joins, JSON path queries, graph traversals, vector similarity searches — is automatically filtered by tenant. The engine injects the predicate into the execution plan before any data leaves storage. Your calling code doesn’t need WHERE TenantID = @id everywhere. You test the policy once.

The layers compose further: Dynamic Data Masking for columns that shouldn’t show full values to certain roles, Always Encrypted for end-to-end encryption (even DBAs can’t read it), and stored procedures as the permission boundary so agents only call what you explicitly exposed.

This is the part of the architecture that matters most for compliance-heavy SaaS. One policy, one proof.

Unified Backup = Atomic Recovery

One statement, all data models, consistent point in time:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

In a polyglot stack, point-in-time recovery across five databases means coordinating five restore operations and hoping the timestamps line up within a second or two. For financial data, that two-second inconsistency is unacceptable. With one database, one transaction log, one restore — recovery is atomic by definition.

Ledger Tables for Tamper-Evident Audit Trails

For regulated industries, you need more than “we have logs.” You need cryptographic proof that those logs weren’t modified:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

Every insert, update, and delete gets cryptographically hashed into a blockchain-style structure. You can prove to an auditor — mathematically — that a row hasn’t been tampered with since it was written. In a polyglot stack, this capability doesn’t exist uniformly across all your databases.

MCP Integration: Agents Without Hand-Coded Middleware

The series built toward this: SQL Server 2025 supports the SQL MCP Server directly, which means your agents can call the database through natural language tool calls without you writing middleware for every operation.

Combine that with stored procedures as the permission boundary and Row-Level Security enforced at the engine, and you have a model where:

Agent calls a tool (e.g., “get customer context for account 12345”)
MCP translates to the stored procedure you defined
SQL engine enforces tenant isolation and column masking automatically
Agent gets exactly the data it’s allowed to see

No middleware layer. No ad-hoc query injection risk. The engine handles authorization, not the agent.

Why This Matters for .NET Developers

If you’re building .NET services with SQL Server as your primary store, the message from this series is: you don’t need to add Redis for caching, a graph DB for relationships, or a vector store for embeddings. SQL Server 2025 handles all of that — with better operational consistency than a polyglot stack and unified security that’s actually auditable.

The MCP integration means your Semantic Kernel agents or Microsoft Agent Framework workflows can interact with your data tier through the same SQL MCP Server, with the same security guarantees you’d enforce for human queries.

Wrapping up

The Polyglot Tax series is worth reading end-to-end. Parts 1-3 prove the query planner story. Part 4 proves the production story. For .NET developers building agent-first or AI-augmented applications on Azure SQL, this architecture deserves serious consideration.

Original post by Aditya Badramraju: The Polyglot Tax – Part 4.

.NET 10 Ships with Ubuntu 26.04 LTS — Here's What's New

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

It’s Ubuntu LTS day. Ubuntu 26.04 (Resolute Raccoon) launched today, and as with every Ubuntu LTS, it ships with the latest .NET LTS — in this case, .NET 10.

If you deploy .NET apps on Linux, this is the release cycle you care about. LTS on LTS — five years of support for the OS, matching .NET 10’s own long-term support window.

Install .NET 10 in two commands

sudo apt update
sudo apt install dotnet-sdk-10.0

That’s it. .NET is one of the officially supported toolchains on Ubuntu — not a third-party add-on. Microsoft and Canonical work together to make sure it works on day one.

Try it immediately

Here’s the thing I love about this: you can pull an ubuntu:resolute container image and be running C# in under a minute.

docker run --rm -it ubuntu:resolute
apt update
apt install -y dotnet-sdk-10.0
dotnet run - << 'EOF'
using System.Runtime.InteropServices;
Console.WriteLine($"Hello {RuntimeInformation.OSDescription} from .NET {RuntimeInformation.FrameworkDescription}");
EOF

That dotnet run - with a heredoc is a file-based app pattern — no project file, no directory, just C# piped to stdin. Honest, if you haven’t tried file-based apps yet, it’s worth a look.

Containers: update `-noble` to `-resolute`

The new container images use the resolute tag. Migration is a one-liner:

sed -i "s/noble/resolute/g" Dockerfile

All existing image flavors — including Chiseled — are available. The Chiseled images are still my go-to for production: minimal attack surface, no shell, no package manager, just the runtime. Update the tag and rebuild.

Native AOT: 3ms startup, 1.4MB binary

Ubuntu 26.04 ships a dedicated AOT package:

apt install -y dotnet-sdk-aot-10.0 clang

Here’s what you get when you publish a simple app:

dotnet publish app.cs
# artifacts/app/app — 1.4MB native binary

Startup time:

real 0m0.003s

3 milliseconds. For a full ASP.NET Core web service, the self-contained binary is around 13MB. That’s a completely self-contained deployable with no runtime dependency whatsoever.

For cloud-native workloads where cold-start time matters — Functions, containers, serverless — this is a legitimate game changer.

What changed in Ubuntu 26.04 that affects .NET

Three things worth knowing:

Linux 7.0 — The .NET team will start Linux 7.0 testing once they get 26.04 VMs in the lab. No breaking changes expected, but they’ll verify.
Post-quantum cryptography — Ubuntu 26.04 introduces PQC support, and .NET 10 added post-quantum cryptography APIs as well. Good alignment.
cgroup v1 removed — Ubuntu 26.04 drops cgroup v1. .NET added cgroup v2 support years ago, so this is a non-event. But if you’re on an older runtime, double-check.

Need .NET 8 or 9?

Those are available via the dotnet-backports PPA:

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0 # or dotnet-sdk-9.0

Support is “best-effort” — not the same guarantee as the LTS package in the main archive — but the packages are there and they work.

Wrapping up

Every two years, the Ubuntu LTS + .NET LTS alignment gives you a solid, long-support foundation for production workloads. Ubuntu 26.04 with .NET 10 is that foundation for the next cycle.

If you’re containerizing .NET apps, update your Dockerfiles. If you’re deploying on bare metal or VMs, apt install dotnet-sdk-10.0 and you’re done.

Read the full post from Richard Lander for the complete installation walkthrough and container details.

Azure MCP Server Is Now a .mcpb — Install It Without Any Runtime

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

You know what was annoying about setting up MCP servers? You needed a runtime. Node.js for the npm version, Python for pip/uvx, .NET SDK for the dotnet flavor, Docker if you wanted containers. Just to get a tool connected to your AI client.

The Azure MCP Server just changed that. It’s now available as an .mcpb — an MCP Bundle — and the setup is drag-and-drop.

What’s an MCP Bundle?

Think of it like a VS Code extension (.vsix) or a browser extension (.crx), but for MCP servers. A .mcpb file is a self-contained ZIP archive that includes the server binary and all its dependencies. Everything needed to run on your platform, packaged together.

The end result: you download one file, open it in a supported client, and the server runs. No runtime to install, no package.json to manage, no version conflicts.

How to install it

Three steps:

1. Download the bundle for your platform

Go to the GitHub Releases page and grab the .mcpb file for your OS and architecture. Make sure you pick the right one — osx-arm64 for Apple Silicon, osx-x64 for Intel Mac, etc.

2. Install in Claude Desktop

The easiest way: drag and drop the .mcpb file into the Claude Desktop window while you’re on the Extensions settings page (☰ → File → Settings → Extensions). Review the server details, click Install, confirm. Done.

Tip: You can also set Claude Desktop as the default app for .mcpb files and double-click to install.

3. Authenticate to Azure

az login

That’s it. The Azure MCP Server uses your existing Azure credentials.

What you can do with it

Once installed, you have access to 100+ Azure service tools directly from your AI client:

Query and manage Cosmos DB, Storage, Key Vault, App Service, Foundry
Generate az CLI commands for any task
Create Bicep and Terraform templates
Get architecture recommendations and diagnostics

Try prompts like:

“List all resource groups in my subscription”
“Generate a Bicep template for a web app with a SQL database”
“What Cosmos DB databases do I have?”
“Show me the secrets in my Key Vault named my-vault”

Which install method should you use?

Method	Best for
`.mcpb`	Claude Desktop users who want zero-config
VS Code Extension	Developers working in VS Code + GitHub Copilot
npm/npx	Developers who already have Node.js
pip/uvx	Python developers
Docker	CI/CD pipelines and containers

All methods give you the same tools. The .mcpb is just the most frictionless path for Claude Desktop users.

Why this matters

MCP servers are genuinely useful — they let AI clients interact with external systems in a structured way. But the setup friction has been a real barrier, especially for users who aren’t developers or who just don’t want to manage runtimes for every tool they install.

The .mcpb format feels like the right direction. It’s the same principle as VS Code extensions or browser extensions: one file, platform-native binary, install and go.

If the MCP ecosystem keeps moving this direction, connecting AI clients to services will get a lot simpler.

Get started

Download: GitHub Releases
Repo: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Check the full post for troubleshooting tips and a comparison of all install methods.

Azure SDK April 2026: AI Foundry 2.0 and What .NET Developers Should Know

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Monthly SDK releases are often easy to skip. This one has a few things worth paying attention to — especially if you’re building with AI Foundry, Cosmos DB in Java, or doing infrastructure provisioning from .NET code.

Azure.AI.Projects 2.0.0 — Breaking Changes That Make Sense

The Azure.AI.Projects NuGet package reaches stable 2.0.0 with some significant architectural changes. If you’re already using the preview, here’s what changed:

Namespace splits: Evaluations moved to Azure.AI.Projects.Evaluation, memory operations moved to Azure.AI.Projects.Memory. Your using statements will need updating.
Renamed types: Insights → ProjectInsights, Schedules → ProjectSchedules, Evaluators → ProjectEvaluators, Trigger → ScheduleTrigger
Naming conventions: Boolean properties now follow the Is* convention consistently

These are the kinds of breaking changes that hurt once and then feel right forever. If you’ve been building on the preview, update your imports and let the compiler point you to the rest.

The good news: it’s stable. You can actually rely on this API now.

Cosmos DB Java: Critical Security Fix (RCE)

This one is serious. The Java Cosmos DB library (azure-cosmos) version 4.79.0 includes a critical security fix for a Remote Code Execution vulnerability (CWE-502).

The issue was Java deserialization in CosmosClientMetadataCachesSnapshot, AsyncCache, and DocumentCollection. The fix replaces Java deserialization with JSON-based serialization, eliminating the entire class of deserialization attacks.

If you have any Java services using Azure Cosmos DB, update to 4.79.0 immediately. This isn’t optional.

New Provisioning Libraries for .NET

A wave of stable Provisioning libraries hit 1.0.0 this month — these are the libraries that let you define Azure infrastructure in C# code rather than ARM templates or Bicep:

Several more are in beta.1, covering API Management, Batch, Compute, Monitor, MySQL, and Security Center. If you’re doing infrastructure-as-code from .NET — particularly with Aspire deployments — these libraries are your entry point.

Azure AI Agents Java: 2.0.0 GA

The Java Azure AI Agents library also reaches general availability this month. The key breaking changes:

Several enum types converted to ExpandableStringEnum-based classes (more flexible for new values)
*Param model classes renamed to *Parameter
MCPToolConnectorId → McpToolConnectorId (consistent casing)
New convenience overload for beginUpdateMemories

Wrapping up

The headline for .NET developers this month is Azure.AI.Projects 2.0.0 hitting stable — if you’re building with AI Foundry, now’s the time to pin to stable and update your imports. For Java shops using Cosmos DB, the security update is urgent.

Full release notes at aka.ms/azsdk/releases. Original post: Azure SDK Release (April 2026).

CodeAct in Agent Framework: How to Cut Your Agent's Latency in Half

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

There’s a moment in every agent project where you look at the trace and think: “why is this taking so long?” The model is fine. The tools work. But there are seven round trips to get a result you could compute in one shot.

That’s exactly the problem CodeAct solves — and the Agent Framework team just shipped alpha support for it via a new agent-framework-hyperlight package.

What is CodeAct?

The CodeAct pattern is elegantly simple: instead of giving the model a list of tools and letting it call them one by one, you give it a single execute_code tool and let it express the entire plan as a short Python program. The agent writes the code once, the sandbox runs it, and you get back a single consolidated result.

A five-step plan that used to be five model turns becomes one execute_code turn containing a Python script that calls your tools via call_tool(...).

The benchmark in the repo makes this concrete. Eight users, dozens of orders, five tools (list users, get orders, discount rate, tax rate, compute line total). Same model, same tools, same prompt — just different wiring:

Wiring	Time	Tokens
Traditional	27.81s	6,890
CodeAct	13.23s	2,489
Improvement	52.4%	63.9%

That’s not a micro-benchmark. That’s a realistic workload with real orchestration overhead.

The safety piece: Hyperlight micro-VMs

Here’s the thing that made me actually excited about this: safety has historically been CodeAct’s Achilles heel. If you’re running model-generated code, where exactly is it running? Against your process? In a shared container?

The agent-framework-hyperlight package solves this with Hyperlight micro-VMs. Every single execute_code call gets its own freshly created micro-VM — with its own memory, no host filesystem access beyond what you explicitly mount, and no network access beyond the domains you allow. Startup is measured in milliseconds. The isolation is basically free.

Your tools still run on the host (they’re your code, with your access). The model-generated glue — the Python that decides which tools to call and in what order — runs sandboxed. That’s the right split.

Wiring it up

The minimal setup is straightforward:

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

result = await agent.run(
 "Get the weather for Seattle and Amsterdam and compare them."
)

The provider registers execute_code on every run and injects the CodeAct instructions into the system prompt automatically. You don’t need to write a custom prompt fragment.

Mixing CodeAct with approval-gated tools

This is where it gets interesting. Not every tool should run inside the sandbox without approval. You might want to gate send_email or charge_credit_card individually. The framework handles this cleanly:

@tool(approval_mode="always_require")
def send_email(to: str, subject: str, body: str) -> str:
 """Send an email. Requires approval on every call."""
 ...

agent = Agent(
 client=client,
 name="MixedToolsAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
 tools=[send_email], # invoked directly, approval-gated
)

Tools on the provider → the model reaches them via call_tool(...) inside the sandbox, cheap and chainable.
Tools on the agent directly → the model calls them as first-class tool calls, approval applies individually.

That’s a clean split: chainable data-lookup tools go through CodeAct, side-effect tools stay on the agent.

When to use CodeAct (and when not to)

Reach for CodeAct when:

The task chains many small tool calls (lookups, joins, computations, formatting)
You care about latency and token cost
You want strong per-call isolation on model-generated code by default
Tools are cheap and safe to invoke in sequence

Stick with traditional tool-calling when:

The agent only makes one or two tool calls per turn
Each tool has side effects you want approved individually
Tool descriptions are sparse or ambiguous — CodeAct relies on good docstrings

That last point matters. Because the model writes Python that calls your tools by name, docstrings and parameter annotations become part of the contract the model reasons about. Weak descriptions hurt CodeAct more than traditional tool-calling.

Try it now

pip install agent-framework-hyperlight --pre
# or
uv add --prerelease=allow agent-framework-hyperlight

Samples are under python/packages/hyperlight/samples/. The benchmark sample is the best place to start — run it against your own tools to see if the wins apply to your workload.

Worth noting: Linux and Windows are supported today. macOS support is on the way. A .NET counterpart is also coming, so if you’re on C#, keep an eye on the repo.

Wrapping up

CodeAct isn’t magic — it’s a sensible pattern that was just too risky to use without proper sandboxing. Hyperlight changes that equation. Per-call micro-VM isolation, millisecond startup, 50%+ latency improvement on the right workloads. That’s a combination worth experimenting with.

Check the full post on the Agent Framework blog for deeper coverage on filesystem mounts, network policy, and the standalone HyperlightExecuteCodeTool wiring.

GPT-5.5 Is Here and It's Coming to Azure Foundry — What .NET Developers Need to Know

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Microsoft just announced that GPT-5.5 is generally available in Microsoft Foundry. If you’ve been building agents on Azure, this is the update you’ve been waiting for.

Let me break down what actually changed and why it matters for developers building on this stack.

The GPT-5 progression

It helps to understand the arc. This isn’t just a version bump:

GPT-5: unified reasoning and speed into a single system
GPT-5.4: stronger multi-step reasoning, early agentic capabilities for enterprise use
GPT-5.5: deeper long-context reasoning, more reliable agentic execution, improved computer-use accuracy, better token efficiency

Each step has been deliberately aimed at production agentic workloads. GPT-5.5 continues that arc with a specific focus on sustained, high-stakes professional workflows — not just one-shot queries.

What’s actually different

Improved agentic coding: GPT-5.5 holds context across large codebases, can diagnose architectural-level failures, and anticipates downstream testing requirements. That last point is interesting — the model reasons about what else a fix affects before making a move. Less back-and-forth to get to a working result.

Token efficiency: Higher-quality outputs with fewer tokens and fewer retries. This translates directly to lower cost and latency for production deployments. If you’re running agents at scale, this compounds fast.

Long-context analysis: Handles extensive documents, codebases, and multi-session histories without losing the thread. For agentic workflows that maintain large working state, this matters.

There’s also a GPT-5.5 Pro variant for the most demanding enterprise workloads — deeper reasoning, higher cost.

Pricing

Model	Input ($/M tokens)	Cached Input	Output ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

GPT-5.5 is priced at the same input rate as GPT-5 but the token efficiency improvements mean you’re actually paying less per useful output. Worth running a benchmark on your specific workload before committing.

Why Foundry matters here

Access to a frontier model is just the starting point. What matters for .NET developers is how you operationalize it.

Foundry Agent Service lets you define agents in YAML or wire them up with Microsoft Agent Framework, GitHub Copilot SDK, LangGraph, or OpenAI Agents SDK — and run them as isolated hosted agents with:

A persistent filesystem
A distinct Microsoft Entra identity
Scale-to-zero pricing

One command to deploy. No infrastructure to manage. Your agents get GPT-5.5 as the model underneath.

Getting started

If you’re already using Azure AI Foundry, GPT-5.5 shows up as a new model option. Point your client at it and you’re done:

// C# — just update the model name
AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "You are a helpful assistant.", name: "MyAgent");

If you haven’t tried Foundry yet, ai.azure.com is where to start. The model catalog has a direct link to try GPT-5.5.

Wrapping up

GPT-5.5 is a real step forward for production agentic workloads. The combination of better long-context handling, improved agentic execution, and token efficiency makes it worth evaluating for anything you’re running at scale.

The frontier is moving fast. Keep building.

See the full announcement for the complete feature breakdown and enterprise details.

VS Code 1.118: Copilot CLI Gets Session Names, Model Badges, and TypeScript 7.0 Nightly Opt-In

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Visual Studio Code 1.118 is a smaller focused release — mostly Copilot CLI refinements — but there are a few things worth noting if you use the Agents app or TypeScript heavily.

Copilot CLI: sessions get real names

The Copilot CLI SDK session-title APIs are now used as the source of truth for session names. Previously you’d get auto-generated labels; now sessions surface the actual name from the SDK. Small quality-of-life improvement but it makes navigating multiple agent sessions a lot less confusing.

Switch sessions faster with keyboard shortcuts

The Agents app now has Ctrl+1, Ctrl+2, etc. bound to quickly switch between sessions. If you’re running multiple Copilot CLI sessions in parallel (which, if you’re doing agent-heavy work, you probably are), this removes a lot of mouse clicking.

Model badges in chat

Copilot CLI responses in the chat panel now show a model badge — you can see at a glance which model handled each request. Useful when you’re experimenting with different models in the same session.

Auto model selection lands in Copilot CLI

The auto model selection feature — previously available in other parts of Copilot — now works in the Copilot CLI agent too. Let the system pick the best model for the task rather than manually switching.

TypeScript 7.0 nightly opt-in

This one’s interesting if you’re on the TypeScript cutting edge: you can now opt in to testing TypeScript 7.0 nightlies directly from VS Code settings. TypeScript 7.0 is a major release with significant changes (the beta dropped a few days ago), and the opt-in path makes it easy to test without changing your global TypeScript install.

Under the hood: `node-pty` cleanup

The Copilot CLI SDK now resolves node-pty from VS Code via hostRequire instead of copying binaries into the SDK’s prebuilds folder at build time. This is an internal change but it simplifies distribution and means fewer things that can go wrong at runtime.

Wrapping up

Not a splashy release, but the Copilot CLI improvements add up — especially session management for anyone doing agent-heavy development. The TypeScript 7.0 nightly opt-in is a nice touch for those who like living on the edge.

See the full release notes for the complete change list.

Where Does Your Agent Remember Things? A Practical Guide to Chat History Storage

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

When you build an AI agent, you spend most of your energy on the model, the tools, and the prompts. The question of where the conversation history lives feels like an implementation detail — but it’s actually one of the most important architectural decisions you’ll make.

It determines whether users can branch conversations, undo responses, resume sessions after a restart, and whether your data ever leaves your infrastructure. The Agent Framework team published a deep dive on this and it’s worth understanding the full landscape.

Two fundamental patterns

Service-managed: the AI service stores the conversation state. Your app holds a reference (a thread ID, a response ID) and the service automatically includes relevant history on each request. Simpler to set up. Less control.

Client-managed: your app maintains the full history and sends relevant messages with every request. The service is stateless. You control everything — what gets sent, how it’s compressed, where it lives.

Neither is universally better. The right choice depends on what you’re building.

Service-managed: linear vs forking

Not all service-managed storage is the same. There are two distinct models:

Linear (single-threaded): messages form an ordered sequence. You can append, but you can’t branch. This is the traditional chat model — used by Foundry Prompt Agents and the now-deprecated OpenAI Assistants API. Great for chatbots and support agents. Terrible if you want “try again” or parallel exploration.

Forking-capable: each response has a unique ID, and new requests can reference any previous response as the continuation point. This is what the Responses API (Microsoft Foundry, Azure OpenAI, OpenAI) supports. Users can branch conversations, build “undo” flows, explore multiple answer paths.

If you’re building any kind of agentic workflow where multiple paths might be explored, forking is a capability you want.

Client-managed: you own the complexity

When the service doesn’t store history, your app does everything:

Context window management — you can’t send unlimited history. You need truncation, sliding windows, summarization, or tool-call collapse strategies.
Persistence — in-memory works for demos. Production needs a database, Redis, or blob storage.
Privacy — conversation data never leaves your infrastructure unless you explicitly send it.

The upside on privacy is real. For sensitive applications where you can’t have conversation history sitting on a third-party server, client-managed is the only option.

Agent Framework ships built-in compaction strategies for all the common patterns, so you don’t have to build them from scratch. But you do need to choose and configure the right one.

How Agent Framework abstracts this

The beauty of the framework is that your agent invocation code stays the same regardless of which storage model you’re using. The AgentSession handles the underlying differences.

In C#:

// Works with Chat Completions (client-managed)
// AND with Responses API (service-managed)
// The session handles the details.
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("My name is Alice.", session);
var second = await agent.RunAsync("What is my name?", session);

In Python:

session = agent.create_session()
first = await agent.run("My name is Alice.", session=session)
second = await agent.run("What is my name?", session=session)

When you switch from OpenAI Chat Completions to the Responses API, you change the client configuration — not the agent invocation code.

The Responses API is uniquely flexible

Most providers have a fixed storage model. The Responses API is the exception — it’s configurable via the store parameter:

store=true (default): service stores each response, supports forking via response IDs. Service handles compaction.
store=false: service is stateless, Agent Framework manages history client-side. You control compaction.
Conversations API: linear thread model on top of Responses. Pass a conversation ID instead of a response ID.

Here’s the client-managed mode in practice (C#):

AIAgent agent = new OpenAIClient("<your_api_key>")
 .GetResponseClient("gpt-5.4-mini")
 .AsIChatClientWithStoredOutputDisabled()
 .AsAIAgent(new ChatClientAgentOptions
 {
 ChatOptions = new() { Instructions = "You are a helpful assistant." },
 ChatHistoryProvider = new InMemoryChatHistoryProvider()
 });

And in Python:

agent = Agent(
 client=OpenAIChatClient(),
 name="StatelessAgent",
 instructions="You are a helpful assistant.",
 default_options={"store": False},
 context_providers=[InMemoryHistoryProvider("memory", load_messages=True)],
)

Swap InMemoryHistoryProvider for your DatabaseHistoryProvider when you’re ready for production persistence.

Provider quick reference

Provider	Storage	Model	Compaction
OpenAI / Azure OpenAI Chat Completions	Client	N/A	You
Foundry Agent Service	Service	Linear	Service
Responses API (default)	Service	Forking	Service
Responses API (`store=false`)	Client	N/A	You
Anthropic Claude, Ollama	Client	N/A	You

How to choose

Start with these questions:

Do you need conversation branching or “undo”? → Forking service-managed (Responses API)
Do you need full data sovereignty? → Client-managed, with a database-backed provider
Is this a simple chatbot or support flow? → Service-managed linear is fine
Do you need to migrate between providers later? → Client-managed gives you portability

The most important thing: don’t default to whatever is easiest to start with and forget to revisit it. Changing storage patterns after launch is painful.

Wrapping up

Chat history storage shapes what your agents can actually do — not just in demos but in production, under real user behavior. Agent Framework’s abstractions let you evolve your choice without rewriting your application logic, which is genuinely useful when you’re still figuring out the right model.

Read the full post for the complete decision tree, the Conversations API walkthrough, and the compaction strategy details.

Aspire 13.2 Gets Bun, Better Containers, and Less Debugging Friction

Emiliano Montesdeoca — Fri, 24 Apr 2026 00:00:00 +0000

If you’ve been building .NET backends with JavaScript frontends in Aspire, 13.2 is the kind of update that quietly makes your day better. No splashy new paradigms. Just solid improvements to things that were mildly annoying.

Let’s walk through what actually landed.

Bun is Now a First-Class Citizen

The headline feature: Bun support for Vite apps in Aspire. One fluent call, done.

// TypeScript AppHost
const builder = await createBuilder();

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

await builder.build().run();

If your team already uses Bun — which you might, given its dramatically faster install times and startup — Aspire no longer makes you fight against the grain. Previously, Aspire assumed npm and you had to work around it. Now .withBun() is a first-class option alongside .withYarn() and the default npm behavior.

Why does this matter? Because JavaScript tooling speed directly affects your inner dev loop. If your frontend takes 30 seconds to install dependencies every time you spin up a fresh environment, that adds up. Bun cuts that dramatically.

The C# AppHost equivalents are documented at aspire.dev if you prefer authoring in C# — all the same patterns apply.

Yarn Got More Reliable

Bun gets the spotlight, but Yarn users get something arguably more impactful: fewer mysterious failures. Aspire 13.2 improves reliability for withYarn() with addViteApp().

These kinds of fixes don’t sound exciting until you’ve spent 20 minutes debugging why your Yarn-backed frontend resource wouldn’t start. Consider it fixed.

Container Publishing You Can Actually Reason About

Two container improvements worth knowing:

Explicit Pull Policy

Docker Compose publishing now supports PullPolicy, including a Never option:

import { createBuilder, ImagePullPolicy } from './.modules/aspire.js';

const builder = await createBuilder();
await builder.addDockerComposeEnvironment("compose");

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

await builder.build().run();

This is the “please use the image I already built and leave the registry out of it” workflow. Super useful when iterating locally on images you’re building and publishing manually, or when your CI produces an image and you want Compose to use exactly that one without sneaking in a remote pull.

PostgreSQL 18+ Volumes Work Again

PostgreSQL 18 changed its internal data directory layout. This broke volume mapping in Aspire silently — your data volume would be set up but persistence wouldn’t actually work correctly. 13.2 fixes this.

const postgres = await builder.addPostgres("postgres")
 .withDataVolume({ isReadOnly: false });

If you’re running PostgreSQL 18 or later with a data volume, upgrade to Aspire 13.2 and don’t think about it again.

Debugging Quality-of-Life Improvements

A few things that make stepping through an AppHost session less frustrating:

DebuggerDisplayAttribute on core types — DistributedApplication, resources, endpoint expressions now show useful values in the debugger instead of requiring you to drill into object trees
Better WaitFor failure messages — when resources fail to start, the error context is actually helpful now
BeforeResourceStartedEvent fires at the right time — only when a resource is actually starting, not on unrelated state transitions
launchSettings.json is more resilient — less chance of a malformed setting corrupting your dev startup

None of these are individually earth-shattering, but collectively they remove friction from the debugging experience. If you’ve ever had to drill three levels deep into an Aspire resource object to figure out what endpoint it was using, the debugger display improvement alone is worth the update.

Wrapping up

Aspire 13.2 is a focused quality release. Bun support is the headline, but the container and debugging improvements are what will make your day-to-day work smoother. Worth updating — especially if you’re on PostgreSQL 18 with data volumes.

Full details in the original post by David Pine and the Aspire 13.2 what’s new docs.

68 Minutes a Day Re-Explaining Code to Copilot? There's a Fix for That

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

You know that moment when your Copilot session hits /compact and the agent completely forgets what you were doing? You spend the next five minutes re-explaining the file structure, the failing test, the three approaches you already tried. Then it happens again. And again.

Desi Villanueva timed it: 68 minutes per day — just on re-orientation. Not writing code. Not reviewing PRs. Just catching the AI up on things it already knew.

Turns out there’s a concrete reason this happens, and a concrete fix.

The Context Window Lie

Your agent ships with a big number on the box. 200K tokens. Sounds massive. In practice it’s a ceiling, not a guarantee.

Here’s the actual math:

200K total context
Minus ~65K for MCP tools loaded at startup (~33%)
Minus ~10K for instruction files like AGENTS.md or copilot-instructions.md

That leaves you with roughly 125K before you type a word. And it gets worse — LLMs don’t degrade gracefully as context fills up. They hit a wall at around 60% capacity. The model starts losing things mentioned 30 turns ago, contradicts earlier responses, hallucinates file names it stated confidently 10 minutes prior. The industry calls this the “lost in the middle” problem.

Effective limit: 45K tokens before quality degrades. That’s maybe 20-30 turns of active conversation before the agent starts drifting. Which is why you’re hitting /compact every 45 minutes — not because you’ve filled 200K tokens, but because the model is already rotting at 120K.

The Compaction Tax

Every /compact costs you flow state. You’re deep in a debugging session. Shared context built up over 30 minutes. The agent knows the file structure, the failing test, the hypothesis. Then the warning hits.

Ignore it → agent gets progressively dumber, hallucinates old state
Run /compact → agent has a 2-paragraph summary of a 30-minute investigation

Either way you lose. Either way you’re narrating your own project back to it like a new hire on day one.

The cruel part? The memory already exists. Copilot CLI writes every session to a local SQLite database at ~/.copilot/session-store.db — every file touched, every turn, every checkpoint. It’s all sitting on disk. The agent just can’t read it.

auto-memory: A Recall Layer, Not a Memory System

That’s the key insight behind auto-memory: don’t build a new memory system — build a read-only query layer over the one that already exists.

pip install auto-memory

~1,900 lines of Python. Zero dependencies. Installs in 30 seconds.

Instead of flooding the context with grep results, you give the agent surgical access to what actually matters:

Operation	Tokens	What you get
`grep -r "auth" src/`	~5,000–10,000	500 results, most irrelevant
`find . -name "*.py"`	~2,000	Every Python file, no context
Agent re-orientation	~2,000	You explaining what it should know
`auto-memory files --json --limit 10`	~50	The 10 files you touched yesterday

That’s a 200x improvement. The agent skips the archaeological dig and goes straight to what matters.

The recommended flow: when you’re approaching 50-70% context usage, run /clear and then prompt with “review last sessions we discussed topic X”. Instead of burning 12K tokens on blind searches, auto-memory pulls the relevant context in 50.

Why This Matters for .NET Developers

If you’re using GitHub Copilot CLI for .NET work — scaffolding services, debugging EF Core queries, iterating on Blazor components — the context rot problem hits just as hard. Complex solutions with multiple projects, shared libraries, and deep call chains are exactly the kind of codebase where the agent loses track fastest.

The install guide walks through pointing Copilot CLI at it. It’s a one-time setup.

Honestly? 68 minutes a day back in your pocket is not a minor quality-of-life tweak. That’s almost 6 hours a week.

Wrapping up

Context rot is a real architectural constraint, not a bug that will get patched. auto-memory works around it by giving your agent a cheap, precise recall mechanism instead of expensive, noisy re-exploration. If you’re doing serious AI-assisted development with GitHub Copilot CLI, it’s worth the 30-second install.

Check it out: auto-memory on GitHub. Original post by Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.

azd Hooks in Python, TypeScript, and .NET: Stop Fighting Shell Scripts

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

If you’ve ever had a fully .NET project and still found yourself writing Bash scripts just to run azd hooks, you know the pain. Why switch to shell syntax just for a pre-provision step when everything else in your project is C#?

That frustration is now officially solved. The Azure Developer CLI just shipped multi-language hook support, and it’s exactly as good as it sounds.

Hooks, quickly, if you’re not familiar

Hooks are scripts that run at key points in the azd lifecycle — before provisioning, after deployment, and more. They’re defined in azure.yaml and let you inject custom logic without forking the CLI itself.

Previously you were limited to Bash and PowerShell. Now you can use Python, JavaScript, TypeScript, or .NET — and azd handles the rest automatically.

How the detection works

You just point the hook at a file and azd infers the language from the extension:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

That’s it. No extra config. If the extension is ambiguous, you can add an explicit kind: python (or whatever) to override.

Language-specific details worth knowing

Python

Drop a requirements.txt or pyproject.toml next to your script (or anywhere up the directory tree) and azd creates a virtual environment, installs deps, and runs your script:

hooks/
├── setup.py
└── requirements.txt

No virtualenv management on your end. azd walks up from the script location to find the nearest project file.

JavaScript and TypeScript

Same pattern — put a package.json near your script and azd runs npm install first. For TypeScript, it uses npx tsx so there’s no compile step and no tsconfig.json required:

hooks/
├── seed.ts
└── package.json

Want to use pnpm or yarn? There’s a config.packageManager option for that.

.NET

Two modes here, which is nice:

Project mode: If there’s a .csproj next to the script, azd runs dotnet restore and dotnet build automatically.
Single-file mode: On .NET 10+, you can drop a standalone .cs file and it runs directly via dotnet run script.cs. No project file needed.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

If you’re already on .NET 10, single-file mode is honestly the cleanest option for simple migration or seeding scripts. No project scaffolding, no .csproj to maintain.

Executor-specific config

Each language supports an optional config block when you need to tweak the defaults:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

You can also mix formats in the same hooks: block — different languages for different lifecycle events, platform-specific overrides for Windows vs. Linux, whatever you need.

Why this matters for .NET developers

The boring answer is “consistency.” But honestly it goes deeper than that. Hooks are often the last place in an azd-based project that forces you into a different language context. Now your entire deployment pipeline — from app code to infrastructure scripts to lifecycle hooks — can live in one language.

More practically: you can now reuse your existing .NET utilities in hooks. Have a shared class library for database schema management? Just reference it in your hook project. Have a Python data-seeding script you already wrote? Drop it straight into azure.yaml.

Wrapping up

This is one of those changes that sounds small but quietly removes a lot of friction from daily azd workflows. Multi-language hook support is available now — check the official post for the full docs, and head to the azd GitHub repo to try it out on your next project.

Foundry Toolboxes: One Endpoint for All Your Agent Tools

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Here’s a problem that sounds boring until you’ve actually hit it: your organization is building multiple AI agents, each one needs tools, and every team is wiring those tools up from scratch. Same Web Search integration, same Azure AI Search config, same GitHub MCP server connection — just in a different repo, by a different team, with different credentials and no shared governance.

Microsoft Foundry just shipped Toolboxes in public preview, and it’s a direct answer to that problem.

What’s a Toolbox?

A Toolbox is a named, reusable bundle of tools that you define once in Foundry and expose through a single MCP-compatible endpoint. Any agent runtime that speaks MCP can consume it — you’re not locked to Foundry Agents.

The pitch is simple: build once, consume anywhere. Define the tools, configure auth centrally (OAuth passthrough, Entra managed identity), publish the endpoint. Every agent that needs those tools connects to the endpoint and gets them all.

No per-tool wiring. No per-agent credential management.

The four pillars (two of which ship today)

The Toolbox feature is organized around four ideas:

Pillar	Status	What it does
Discover	Coming soon	Find existing approved tools without hunting
Build	Available now	Curate tools into a named, reusable bundle
Consume	Available now	Single MCP endpoint exposes all tools
Govern	Coming soon	Centralized auth + observability across all tool calls

Today the focus is on Build and Consume. That’s enough to remove the most immediate friction.

Getting started in practice

The SDK is Python-first for now. You start by creating an AIProjectClient and then build a toolbox:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

Then you create a toolbox version with the tools you want to bundle:

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Search public and internal docs, then respond to GitHub issues.",
 tools=[
 {"type": "web_search", "description": "Search approved public documentation"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Once published, Foundry gives you a unified endpoint:

https://zava.services.ai.azure.com/api/projects/<project>/toolbox/<toolbox-name>/mcp?api-version=v1

Point any MCP-compatible agent runtime at that URL and it discovers all the tools in the bundle dynamically. One connection. All tools.

Not locked to Foundry Agents

This is worth spelling out because it’s a common concern when Microsoft ships something under the Foundry brand.

Toolboxes are created and governed in Foundry, but the consumption surface is the open MCP protocol. That means you can use them from:

Custom agents built with Microsoft Agent Framework, LangGraph, or your own code
GitHub Copilot and other MCP-enabled IDEs
Any other runtime that speaks MCP

You’re not locked in. The toolbox is Foundry-homed (that’s where you manage it) but not Foundry-bound (you can consume it from anywhere).

Why it matters now

The multi-agent wave is hitting production. Teams are building 5, 10, 20 agents — and the tool-wiring problem compounds fast. Every new agent is a new surface for duplicated config, stale credentials, and inconsistent behavior.

Toolboxes don’t solve governance and discovery yet (those are “coming soon”), but the Build + Consume foundation is enough to start centralizing. Once the Govern pillar ships, you’ll have a proper observable, centrally-controlled tool layer for your entire agent fleet.

Wrapping up

This is early — public preview, Python SDK first, with Discover and Govern still coming. But the model is sound, and the MCP-native design means it works with the tools you’re already building on. Take a look at the official announcement to get started.

Windows App Dev CLI v0.3: F5 from the Terminal and UI Automation for Agents

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Visual Studio’s F5 experience is great. But having to open VS just to launch and debug a packaged Windows app is a bit much when you’re deep in a CI pipeline, running an automated workflow, or — increasingly — when an AI agent is doing the testing.

Windows App Development CLI v0.3 just shipped, and it addresses this directly with two headline features: winapp run and winapp ui.

winapp run: F5 from anywhere

winapp run takes an unpackaged app folder and a manifest, and does everything VS does for a debug launch: registers a loose package, launches the app, and preserves your LocalState across re-deploys.

# Build your app, then run it as a packaged app
winapp run ./bin/Debug

Works for WinUI, WPF, WinForms, Console, Avalonia, and more. The modes are designed for both developers and automated workflows:

--detach: Launch and return control to the terminal immediately. Good for CI/automation where you need the app running but don’t want to block.
--unregister-on-exit: Cleans up the registered package when the app closes. Clean test runs, no leftover state.
--debug-output: Captures OutputDebugString messages and exceptions in real time. When a crash happens, a minidump is captured and analyzed in-process — managed (.NET) crashes via ClrMD, native (C++/WinRT) crashes via DbgEng. Add --symbols to pull PDBs from the Microsoft Symbol Server.

This is the kind of setup that makes headless test runs and agent-driven validation actually work. An agent can now launch your app, interact with it, verify behavior, and clean up — all without Visual Studio.

New NuGet package: dotnet run for packaged apps

For .NET developers specifically, there’s a new NuGet package: Microsoft.Windows.SDK.BuildTools.WinApp.

Add it to your project (or let winapp init do it), and dotnet run handles the entire inner loop: build, prepare a loose-layout package, register with Windows, and launch — all in one step.

# Let winapp init set it up
winapp init

# Or install directly
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

Works with WinUI, WPF, WinForms, Console, Avalonia. No manual registration, no extra commands. Just dotnet run.

This is a big quality-of-life win. If you’ve been maintaining a Makefile or PowerShell script just to wire together the build-and-register-and-launch cycle, that’s now a solved problem.

winapp ui: UI Automation from the command line

This is the one that opens up agentic scenarios. winapp ui gives you full UI Automation access to any running Windows app — WPF, WinForms, Win32, Electron, WinUI3 — all from the terminal.

What you can do:

List all top-level windows
Walk the full UI Automation tree of any window
Find elements by name, type, or automation ID
Click, invoke, and set values
Take screenshots (per-window or multi-window composites)
Wait for elements to appear — useful for test synchronization

Combine winapp ui with winapp run and you have a complete build → launch → verify workflow from the terminal. An agent can run your app, inspect the UI state, interact with it programmatically, and validate the result. No Visual Studio, no test framework bootstrapping, no manual steps.

For those building CI pipelines that do actual UI validation on Windows desktop apps, this is genuinely useful.

Other bits worth noting

winapp unregister: The cleanup counterpart to winapp run. Removes a sideloaded dev package when you’re done.
winapp manifest add-alias: Adds a uap5:AppExecutionAlias so a packaged app can be launched by name from the terminal.
Tab completion: One command to set up completions for PowerShell, then every winapp command and option is tab-completable.
Package.appxmanifest by default: winapp init now creates Package.appxmanifest (VS convention) instead of appxmanifest.xml.

Get it

winget install Microsoft.WinAppCli
# or
npm install -g @microsoft/winappcli

The CLI is in public preview. Check the GitHub repo for full docs, guides for .NET, C++, Electron, Rust, Flutter, and more — and to file issues. The original announcement has all the details.

Patch This Now: .NET 10.0.7 OOB Security Update for ASP.NET Core Data Protection

Emiliano Montesdeoca — Wed, 22 Apr 2026 00:00:00 +0000

This one is not optional. If your application uses Microsoft.AspNetCore.DataProtection, you need to update to 10.0.7.

What Happened

After the Patch Tuesday .NET 10.0.6 release, some users started reporting that decryption was failing in their applications. The issue was filed as aspnetcore#66335.

While investigating that regression, the team discovered it also exposed a security vulnerability: CVE-2026-40372.

In versions 10.0.0 through 10.0.6 of Microsoft.AspNetCore.DataProtection, the managed authenticated encryptor had a bug where it computed its HMAC validation tag over the wrong bytes of the payload and then discarded the computed hash. This could result in elevation of privilege.

In plain terms: the integrity check wasn’t doing what it was supposed to do. Data Protection uses authenticated encryption to prevent tampering — the HMAC is the “has this been modified?” check. If the HMAC is computed over the wrong data, you lose that guarantee.

Who Is Affected

Any .NET 10 application using Microsoft.AspNetCore.DataProtection — versions 10.0.0 through 10.0.6. The good news is this package is specific to .NET 10. If you’re still on .NET 8 or 9, you’re not affected by this specific CVE.

Common use cases for Data Protection: cookie encryption, antiforgery tokens, temp data in MVC, and any other use of IDataProtector in your application.

How to Fix It

Update the Microsoft.AspNetCore.DataProtection NuGet package to 10.0.7:

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

Or update your SDK/runtime: download .NET 10.0.7.

Verify you’re on the right version:

dotnet --info

Then rebuild and redeploy your application. The fix doesn’t take effect until you’re running the updated package.

The Bigger Picture

Out-of-band security releases are uncommon — they happen when a vulnerability is serious enough that it can’t wait for the next scheduled Patch Tuesday. This one is a direct consequence of a regression in 10.0.6 creating a security gap. The fact that it was discovered through bug reports is a good sign that the process worked. The fix is fast and the scope is narrow.

If you’re running .NET 10 in production with any web application framework, this is a same-day update situation.

Original announcement by Rahul Bhandari: .NET 10.0.7 Out-of-Band Security Update.

azd + GitHub Copilot: AI-Powered Project Setup and Smarter Error Fixes

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

You know that moment when you want to deploy an existing app to Azure and suddenly find yourself staring at a blank azure.yaml, trying to remember whether your Express API should use Container Apps or App Service? Yeah, that moment. It just got a whole lot shorter.

The Azure Developer CLI (azd) now integrates with GitHub Copilot in two meaningful ways: AI-assisted project scaffolding during azd init, and intelligent error troubleshooting when deployments go sideways. Both features stay entirely in your terminal, which is exactly where I want them.

Setting Up with Copilot During azd init

When you run azd init, there’s now a “Set up with GitHub Copilot (Preview)” option. Select it and Copilot analyzes your codebase to generate the azure.yaml, infrastructure templates, and Bicep modules — based on your actual code, not a template guess.

azd init
# Select: "Set up with GitHub Copilot (Preview)"

For this to work you’ll need:

azd 1.23.11 or later — check with azd version or update with azd update
An active GitHub Copilot subscription (Individual, Business, or Enterprise)
GitHub CLI (gh) — azd will prompt for login if needed

What I find genuinely useful here is that it works both ways. Building from scratch? Copilot helps you set up the right Azure services from the start. Have an existing app you’ve been putting off deploying? Point Copilot at it and it generates the configuration without you having to restructure anything.

What it actually does

Say you have a Node.js Express API with a PostgreSQL dependency. Instead of manually figuring out whether to target Container Apps or App Service, and then writing Bicep from scratch, Copilot detects your stack and generates:

An azure.yaml with the right language, host, and build settings
A Bicep module for Azure Container Apps
A Bicep module for Azure Database for PostgreSQL

And it runs preflight checks before touching anything — verifies your git working directory is clean, asks for MCP server tool consent upfront. Nothing happens without you knowing exactly what’s about to change.

Copilot-Powered Error Troubleshooting

Deployment errors are a fact of life. Missing parameters, permission issues, SKU availability problems — and the error message rarely tells you the one thing you actually need to know: how to fix it.

Without Copilot, your loop looks like: copy the error → search docs → read through three unrelated Stack Overflow answers → run some az CLI commands → try again and hope. With Copilot integrated into azd, that loop collapses. When any azd command fails, it immediately offers four options:

Explain — plain-language description of what went wrong
Guidance — step-by-step fix instructions
Diagnose and Guide — full analysis + Copilot applies the fix (with your approval) + optional retry
Skip — handle it yourself

The key thing: Copilot already has context about your project, the command that failed, and the error output. Its suggestions are specific to your situation, not generic docs.

Real examples where this shines

Resource provider not registered:

ERROR: deployment failed: MissingSubscriptionRegistration:
The subscription is not registered to use namespace 'Microsoft.App'.

This trips up anyone deploying to a fresh subscription. Copilot can register the provider and rerun the deployment automatically.

SKU not available:

ERROR: deployment failed: SkuNotAvailable:
The requested VM size 'Standard_D2s_v3' is not available in location 'westus'.

Copilot explains which VM size or region is blocked and suggests alternatives that are actually available in your subscription.

Storage account name collision:

ERROR: deployment failed: StorageAccountAlreadyTaken:
The storage account named 'myappstorage' is already taken.

Global uniqueness bites everyone at least once. Copilot suggests adding your environment name or a random suffix to your Bicep parameters.

Set a default behavior

If you always want the same option, skip the interactive prompt:

azd config set copilot.errorHandling.category troubleshoot

Options: explain, guidance, troubleshoot, fix, skip. You can also enable auto-fix and retry:

azd config set copilot.errorHandling.fix allow

Reset to interactive at any time:

azd config unset copilot.errorHandling.category

Why this matters for .NET developers

If you’re building on Azure — whether it’s a .NET Aspire app, a containerized API, or anything in between — azd has been the tool to know for a while now. This Copilot integration removes the last bit of friction that used to make it feel like you needed a cheat sheet just to get started.

The scaffolding piece is great for brownfield projects. You’ve got an ASP.NET Core app running locally, it works perfectly, but getting it onto Azure has always required a bit of infrastructure knowledge. Now Copilot bridges that gap. And the error troubleshooting feature is something I genuinely wish I’d had the last time I spent 45 minutes debugging a SkuNotAvailable error across three regions.

Wrapping up

This is exactly the kind of Copilot integration that adds real value — not AI for AI’s sake, but AI that understands your context and saves you actual time. Try it out by running azd update to get the latest version, then use azd init on your next project. The team is working on deeper features including Copilot-assisted infrastructure customization, so now’s a good time to sign up for user research if you want to influence what comes next.

Read the original announcement here.

Writing Node.js Native Addons in C# with .NET Native AOT

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Here’s a scenario I love: a team that works on .NET tooling had native Node.js addons written in C++ and compiled via node-gyp. It worked. But it required Python to be installed on every developer’s machine — an old version of Python, mind you — just to build a package that nobody on the team would ever touch directly.

So they asked a very reasonable question: we already have the .NET SDK installed, why are we writing C++ at all?

The answer was Native AOT, and the result is genuinely elegant. Drew Noakes from the C# Dev Kit team wrote up how they did it, and I think it’s worth understanding even if you’re not building VS Code extensions.

The basic idea

A Node.js native addon is a shared library (.dll on Windows, .so on Linux, .dylib on macOS) that Node.js can load at runtime. The interface is called N-API — a stable, ABI-compatible C API. N-API doesn’t care what language produced the library, only that it exports the right symbols.

.NET Native AOT can produce exactly that. It compiles your C# code ahead-of-time into a native shared library with arbitrary entry points. That’s the whole trick.

The project setup

The project file is minimal:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot is what tells the SDK to produce a shared library on dotnet publish. AllowUnsafeBlocks is needed for the N-API interop with function pointers and fixed buffers.

Exporting the entry point

Node.js expects your library to export napi_register_module_v1. In C#, [UnmanagedCallersOnly] does exactly that:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

A few things worth calling out here. nint is a native-sized integer — the managed equivalent of intptr_t. The u8 suffix produces a ReadOnlySpan<byte> with a UTF-8 string literal, passed directly to N-API without any encoding allocation. And [UnmanagedCallersOnly] exports the method with the exact entry point name Node.js is looking for.

Resolving N-API against the host process

N-API functions are exported by node.exe itself, not a separate library. So instead of linking against something, you resolve them against the running process at startup:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

With that in place, your P/Invoke declarations work cleanly:

[LibraryImport("node", EntryPoint = "napi_create_string_utf8")]
internal static partial Status CreateStringUtf8(
 nint env, ReadOnlySpan<byte> str, nuint length, out nint result);

The source-generated [LibraryImport] handles the marshalling. ReadOnlySpan<byte> maps to const char*, function pointers pass through directly, and it’s all trimming-compatible.

What an actual exported function looks like

Here’s the registry reader they built — the whole function, from reading arguments to returning a result:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Important note on the try/catch: an unhandled exception in an [UnmanagedCallersOnly] method crashes the host process. You always catch and forward to JavaScript via ThrowError.

Calling it from TypeScript

dotnet publish produces your platform-specific native library. You rename it to .node (Node.js convention for native addons) and use it with a standard require():

interface RegistryAddon {
 readStringValue(keyPath: string, valueName: string): string | undefined;
}

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;

const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

That’s it. TypeScript into C#, no Python, no C++.

What they gained

The immediate win was contributor experience: no specific Python version needed, yarn install works with just Node.js and the .NET SDK. CI pipelines got simpler too.

Performance was comparable to the C++ implementation. Native AOT produces optimized native code, and for string marshalling and registry access, the difference is negligible. The slightly larger memory footprint of the .NET runtime doesn’t matter in a long-running VS Code extension process.

But the bit that caught my attention was this: they noted that with Native AOT producing shared libraries that load directly into the Node.js process, they could potentially host more .NET logic in-process, avoiding the serialization and process-management overhead of their current pipe-based approach. That’s a longer-term exploration, but the foundation is now in place.

Why I think this is interesting beyond VS Code extensions

We often talk about Native AOT in the context of serverless cold starts or embedded scenarios. This is a different angle: using Native AOT to bridge .NET into ecosystems that traditionally required C or C++. Any environment that can load a native shared library — Electron apps, Python extensions via ctypes, Rust via FFI, Node.js via N-API — is now a potential host for C# code.

For .NET developers who’ve been eyeing some interop scenario but didn’t want to learn a C++ build system, this pattern is worth knowing. Write your logic in C#, expose it with [UnmanagedCallersOnly], compile with PublishAot, and load it from wherever you need it.

Wrapping up

The C# Dev Kit team replaced Python/C++ overhead with clean C# code that everyone on the team already knows how to write and debug. The approach is not complicated once you see it, and it’s a great example of Native AOT solving a real problem that doesn’t get talked about enough.

If you want the full walkthrough with all the string marshalling helpers, check the original post on the .NET blog. There’s also node-api-dotnet if you need a higher-level framework for more complex scenarios.

VS Code 1.117: Agents Are Getting Their Own Git Branches and I'm Here For It

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

The line between “AI assistant” and “AI teammate” keeps getting thinner. VS Code 1.117 just dropped and the full release notes are packed, but the story here is clear: agents are becoming first-class citizens in your dev workflow.

Here’s what actually matters.

Autopilot mode finally remembers your preference

Previously, you had to re-enable Autopilot every time you started a new session. Annoying. Now your permission mode persists across sessions, and you can configure the default.

The Agent Host supports three session configs:

Default — tools ask for confirmation before running
Bypass — auto-approves everything
Autopilot — fully autonomous, answers its own questions and keeps going

If you’re scaffolding a new .NET project with migrations, Docker, and CI — set it to Autopilot once and forget about it. That preference sticks.

Worktree and git isolation for agent sessions

This is the big one. Agent sessions now support full worktree and git isolation. That means when an agent works on a task, it gets its own branch and working directory. Your main branch stays untouched.

Even better — Copilot CLI generates meaningful branch names for these worktree sessions. No more agent-session-abc123. You get something that actually describes what the agent is doing.

For .NET developers running multiple feature branches or fixing bugs while a long scaffolding task runs, this is a game changer. You can have an agent building out your API controllers in one worktree while you’re debugging a service layer issue in another. No conflicts. No stashing. No mess.

Subagents and agent teams

The Agent Host Protocol now supports subagents. An agent can spin up other agents to handle parts of a task. Think of it as delegating — your main agent coordinates, and specialized agents handle the pieces.

This is early, but the potential for .NET workflows is obvious. Imagine one agent handling your EF Core migrations while another sets up your integration tests. We’re not fully there yet, but the protocol support landing now means tooling will follow fast.

Terminal output auto-included when agents send input

Small but meaningful. When an agent sends input to the terminal, the terminal output is now automatically included in the context. Before, the agent had to make an extra turn just to read what happened.

If you’ve ever watched an agent run dotnet build, fail, and then take another round-trip just to see the error — that friction is gone. It sees the output immediately and reacts.

Self-updating Agents app on macOS

The standalone Agents app on macOS now self-updates. No more manually downloading new versions. It just stays current.

The smaller stuff worth knowing

package.json hovers now show both the installed version and the latest available. Useful if you manage npm tooling alongside your .NET projects.
Images in JSDoc comments render correctly in hovers and completions.
Copilot CLI sessions now indicate whether they were created by VS Code or externally — handy when you’re jumping between terminals.
Copilot CLI, Claude Code, and Gemini CLI are recognized as shell types. The editor knows what you’re running.

The takeaway

VS Code 1.117 isn’t a flashy feature dump. It’s infrastructure. Worktree isolation, persistent permissions, subagent protocols — these are the building blocks for a workflow where agents handle real, parallel tasks without stepping on your code.

If you’re building with .NET and haven’t leaned into the agentic workflow yet, honestly, now’s the time to start.

Foundry's RFT Just Got Cheaper and Smarter — Here's What Changed

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

If you’re building .NET apps that rely on fine-tuned models, this month’s Foundry updates are worth paying attention to. Reinforcement Fine-Tuning just got more accessible and significantly cheaper.

The full details are in the official announcement, but here’s the practical breakdown.

Global Training for o4-mini

o4-mini is the go-to model for reasoning-heavy and agentic workloads. The big news: you can now launch fine-tuning jobs from 13+ Azure regions with lower per-token training rates compared to Standard training. Same infrastructure, same quality, broader reach.

If your team is spread across geographies, this matters. You’re no longer pinned to a handful of regions to train.

Here’s the REST API call to kick off a global training job:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

That trainingType: globalstandard flag is the key difference.

New Model Graders: GPT-4.1 Family

Graders define the reward signal your model optimizes against. Until now, model-based graders were limited to a smaller set of models. Now you get three new options: GPT-4.1, GPT-4.1-mini, and GPT-4.1-nano.

When should you reach for model graders instead of deterministic ones? When your task output is open-ended, when you need partial credit scoring across multiple dimensions, or when you’re building agentic workflows where tool-call correctness depends on semantic context.

Here’s the thing – the tiering strategy is practical:

GPT-4.1-nano for initial iterations. Low cost, fast feedback loops.
GPT-4.1-mini once your grading rubric is stable and you need higher fidelity.
GPT-4.1 for production grading or complex rubrics where every scoring decision counts.

You can even mix grader types in a single RFT job. Use string-match for the “correct answer” dimension and a model grader for evaluating reasoning quality. That flexibility is honestly what makes this useful for real workloads.

The RFT Data Format Gotcha

This trips people up. RFT data format is different from SFT. The last message in each row must be a User or Developer role – not Assistant. The expected answer goes in a top-level key like reference_answer that the grader references directly.

If you’ve been doing supervised fine-tuning and want to switch to RFT, you need to restructure your training data. Don’t skip this step or your jobs will fail silently.

Why This Matters for .NET Developers

If you’re calling fine-tuned models from your .NET apps through the Azure OpenAI SDK, cheaper training means you can iterate more aggressively. The model grader options mean you can fine-tune for nuanced tasks – not just exact-match scenarios. And the best practices guide on GitHub will save you real debugging time.

Start small. Ten to a hundred samples. Simple grader. Validate the loop. Then scale.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 takes place on April 18, 2026 at Kinépolis Diversia in Alcobendas, Madrid. It’s the largest community-driven Azure event in Spain, bringing together 38 speakers across 3 parallel tracks covering AI agents, Azure networking, Cosmos DB, Fabric, IoT, security, and much more.

The event runs from 08:30 to 18:30 and includes keynote, coffee breaks, lunch, and a closing Q&A session.

Highlights from the agenda

Domando Agentes de IA: governance, tools, and APIs with Azure AI Foundry and Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: multi-agent systems in action
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Tickets

Registration is a symbolic donation — the full ticket price goes directly to Plan International, supporting children’s rights and equality worldwide. Limited capacity, so grab your spot early.

Azure Tour 2026

Beyond Madrid, the Global Azure Tour 2026 also includes stops in Zaragoza, Tenerife, and Sevilla.

Your AI Experiments on Azure Are Burning Money — Here's How to Fix That

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

If you’re building AI-powered apps on Azure right now, you’ve probably noticed something: your cloud bill looks different than it used to. Not just higher — weirder. Spiky. Hard to predict.

Microsoft just published a great piece on cloud cost optimization principles that still matter, and honestly, the timing couldn’t be better. Because AI workloads have changed the game when it comes to costs.

Why AI workloads hit different

Here’s the thing. Traditional .NET workloads are relatively predictable. You know your App Service tier, you know your SQL DTUs, you can estimate monthly spend pretty accurately. AI workloads? Not so much.

You’re testing multiple models to see which one fits. You’re spinning up GPU-backed infrastructure for fine-tuning. You’re making API calls to Azure OpenAI where token consumption varies wildly depending on prompt length and user behavior. Every experiment costs real money, and you might run dozens before you land on the right approach.

That unpredictability is what makes cost optimization critical — not as an afterthought, but from day one.

Management vs. optimization — know the difference

One distinction from the article that I think developers overlook: there’s a difference between cost management and cost optimization.

Management is tracking and reporting. You set up budgets in Azure Cost Management, you get alerts, you see dashboards. That’s table stakes.

Optimization is where you actually make decisions. Do you really need that S3 tier, or would S1 handle your load? Is that always-on compute instance sitting idle on weekends? Could you use spot instances for your training jobs?

As .NET developers, we tend to focus on the code and leave the infrastructure decisions to “the ops team.” But if you’re deploying to Azure, those decisions are your decisions too.

What actually works

Based on the article and my own experience, here’s what moves the needle:

Know what you’re spending and where. Tag your resources. Seriously. If you can’t tell which project or experiment is eating your budget, you can’t optimize anything. Azure Cost Management with proper tagging is your best friend.

Set guardrails before you experiment. Use Azure Policy to restrict expensive SKUs in dev/test environments. Set spending limits on your Azure OpenAI deployments. Don’t wait until the bill arrives to realize someone left a GPU cluster running over the weekend.

Rightsize continuously. That VM you picked during prototyping? It’s probably wrong for production. Azure Advisor gives you recommendations — actually look at them. Review monthly, not yearly.

Think about lifecycle. Dev resources should spin down. Test environments don’t need to run 24/7. Use auto-shutdown policies. For AI workloads specifically, consider serverless options where you pay per execution instead of keeping compute warm.

Measure value, not just cost. This one’s easy to forget. A model that costs more but delivers significantly better results might be the right call. The goal isn’t to spend the least — it’s to spend smart.

The takeaway

Cloud cost optimization isn’t a one-time cleanup. It’s a habit. And with AI workloads making spend less predictable than ever, building that habit early saves you from painful surprises later.

If you’re a .NET developer building on Azure, start treating your cloud bill like you treat your code — review it regularly, refactor when it gets messy, and never deploy without understanding what it’s going to cost you.

Docker Sandbox Lets Copilot Agents Refactor Your Code Without Risking Your Machine

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

If you’ve used Copilot’s agent mode for anything beyond small edits, you know the pain. Every file write, every terminal command — another permission prompt. Now imagine running that across 50 projects. Not fun.

The Azure team just dropped a post about Docker Sandbox for GitHub Copilot agents, and honestly, this is one of the most practical agentic tooling improvements I’ve seen. It uses microVMs to give Copilot a fully isolated environment where it can go wild — install packages, run builds, execute tests — without touching your host system.

What Docker Sandbox actually gives you

The core idea is simple: spin up a lightweight microVM with a full Linux environment, sync your workspace into it, and let the Copilot agent operate freely inside. When it’s done, changes sync back.

Here’s what makes it more than just “run stuff in a container”:

Bidirectional workspace sync that preserves absolute paths. Your project structure looks identical inside the sandbox. No path-related build failures.
Private Docker daemon running inside the microVM. The agent can build and run containers without ever mounting your host’s Docker socket. That’s a big deal for security.
HTTP/HTTPS filtering proxies that control what the agent can reach on the network. You decide which registries and endpoints are allowed. Supply chain attacks from a rogue npm install inside the sandbox? Blocked.
YOLO mode — yes, that’s what they call it. The agent runs without permission prompts because it literally cannot damage your host. Every destructive action is contained.

Why .NET developers should care

Think about the modernization work so many teams are facing right now. You have a .NET Framework solution with 30 projects, and you need to move it to .NET 9. That’s hundreds of file changes — project files, namespace updates, API replacements, NuGet migrations.

With Docker Sandbox, you can point a Copilot agent at a project, let it refactor freely inside the microVM, run dotnet build and dotnet test to validate, and only accept the changes that actually work. No risk of it accidentally nuking your local dev environment while experimenting.

The post also describes running a fleet of parallel agents — each in its own sandbox — tackling different projects simultaneously. For large .NET solutions or microservice architectures, that’s a massive time saver. One agent per service, all running isolated, all validated independently.

The security angle matters

Here’s the thing most people skip over: when you let an AI agent execute arbitrary commands, you’re trusting it with your entire machine. Docker Sandbox flips that model. The agent gets full autonomy inside a throwaway environment. The network proxy ensures it can only pull from approved sources. Your host filesystem, Docker daemon, and credentials stay untouched.

For teams with compliance requirements — and that’s most enterprise .NET shops — this is the difference between “we can’t use agentic AI” and “we can adopt it safely.”

Takeaway

Docker Sandbox solves the fundamental tension of agentic coding: agents need freedom to be useful, but freedom on your host machine is dangerous. MicroVMs give you both. If you’re planning any large-scale .NET refactoring or modernization, this is worth setting up now. The combination of Copilot’s code intelligence with a safe execution environment is exactly what production teams have been waiting for.

Stop Babysitting Your Terminal: Aspire's Detached Mode Changes the Workflow

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Every time you run an Aspire AppHost, your terminal is gone. Locked. Occupied until you Ctrl+C out of it. Need to run a quick command? Open another tab. Want to check logs? Another tab. It’s a small friction that adds up fast.

Aspire 13.2 fixes this. James Newton-King wrote up the full details, and honestly, this is one of those features that immediately changes how you work.

Detached mode: one command, terminal back

aspire start

That’s the shorthand for aspire run --detach. Your AppHost boots up in the background and you get your terminal back immediately. No extra tabs. No terminal multiplexer. Just your prompt, ready to go.

Managing what’s running

Here’s the thing — running in the background is only useful if you can actually manage what’s out there. Aspire 13.2 ships a full set of CLI commands for exactly that:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

This turns the Aspire CLI into a proper process manager. You can start multiple AppHosts, check their status, tail their logs, and shut them down — all from a single terminal session.

Combine it with isolated mode

Detached mode pairs naturally with isolated mode. Want to run two instances of the same project in the background without port conflicts?

aspire start --isolated
aspire start --isolated

Each gets random ports, separate secrets, and its own lifecycle. Use aspire ps to see both, aspire stop to kill whichever you’re done with.

Why this is huge for coding agents

This is where it gets really interesting. A coding agent working in your terminal can now:

Start the app with aspire start
Query its state with aspire describe
Check logs with aspire logs to diagnose issues
Stop it with aspire stop when done

All without losing the terminal session. Before detached mode, an agent that ran your AppHost would lock itself out of its own terminal. Now it can start, observe, iterate, and clean up — exactly how you’d want an autonomous agent to work.

The Aspire team leaned into this. Running aspire agent init sets up an Aspire skill file that teaches agents these commands. So tools like Copilot’s coding agent can manage your Aspire workloads out of the box.

Wrapping up

Detached mode is a workflow upgrade disguised as a simple flag. You stop context-switching between terminals, agents stop blocking themselves, and the new CLI commands give you real visibility into what’s running. It’s practical, it’s clean, and it makes the daily development loop noticeably smoother.

Read the full post for all the details and grab Aspire 13.2 with aspire update --self.

Azure MCP Tools Are Now Baked Into Visual Studio 2022 — No Extension Required

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

If you’ve been using the Azure MCP tools in Visual Studio through the separate extension, you know the drill — install the VSIX, restart, hope it doesn’t break, manage version mismatches. That friction is gone.

Yun Jung Choi announced that Azure MCP tools now ship directly as part of the Azure development workload in Visual Studio 2022. No extension. No VSIX. No restart dance.

What this actually means

Starting with Visual Studio 2022 version 17.14.30, the Azure MCP Server is bundled with the Azure development workload. If you already have that workload installed, you just need to toggle it on in GitHub Copilot Chat and you’re done.

Over 230 tools across 45 Azure services — accessible directly from the chat window. List your storage accounts, deploy an ASP.NET Core app, diagnose App Service issues, query Log Analytics — all without opening a browser tab.

Why this matters more than it sounds

Here’s the thing about developer tooling: every extra step is friction, and friction kills adoption. Having MCP as a separate extension meant version mismatches, installation failures, and one more thing to keep updated. Baking it into the workload means:

Single update path through the Visual Studio Installer
No version drift between the extension and the IDE
Always current — the MCP Server updates with regular VS releases

For teams standardizing on Azure, this is a big deal. You install the workload once, enable the tools, and they’re there for every session.

What you can do with it

The tools cover the full development lifecycle through Copilot Chat:

Learn — ask about Azure services, best practices, architecture patterns
Design & develop — get service recommendations, configure app code
Deploy — provision resources and deploy directly from the IDE
Troubleshoot — query logs, check resource health, diagnose production issues

A quick example — type this in Copilot Chat:

List my storage accounts in my current subscription.

Copilot calls the Azure MCP tools behind the scenes, queries your subscriptions, and returns a formatted list with names, locations, and SKUs. No portal needed.

How to enable it

Update to Visual Studio 2022 17.14.30 or higher
Make sure the Azure development workload is installed
Open GitHub Copilot Chat
Click the Select tools button (the two wrenches icon)
Toggle Azure MCP Server on

That’s it. It stays enabled across sessions.

One caveat

The tools are disabled by default — you need to opt in. And VS 2026-specific tools aren’t available in VS 2022. Tool availability also depends on your Azure subscription permissions, same as the portal.

The bigger picture

This is part of a clear trend: MCP is becoming the standard way to surface cloud tools in developer IDEs. We’ve already seen the Azure MCP Server 2.0 stable release and MCP integrations across VS Code and other editors. Having it built into Visual Studio’s workload system is the natural progression.

For us .NET developers who live in Visual Studio, this removes yet another reason to context-switch to the Azure portal. And honestly, the less tab-switching, the better.

Pin Clustering Finally Lands in .NET MAUI Maps — One Property, Zero Pain

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

You know that moment when you load a map with a hundred pins and the whole thing turns into an unreadable blob? Yeah, that’s been the .NET MAUI Maps experience until now. No more.

David Ortinau just announced that .NET MAUI 11 Preview 3 ships pin clustering out of the box on Android and iOS/Mac Catalyst. And the best part — it’s ridiculously simple to enable.

One property to rule them all

<maps:Map IsClusteringEnabled="True" />

That’s it. Nearby pins get grouped into clusters with a count badge. Zoom in and they expand. Zoom out and they collapse. The kind of behavior users expect from any modern map — and now you get it with a single property.

Independent clustering groups

Here’s where it gets interesting. Not all pins should cluster together. Coffee shops and parks are different things, and your map should know that.

The ClusteringIdentifier property lets you separate pins into independent groups:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Pins with the same identifier cluster together. Different identifiers form independent clusters even when they’re geographically close. No identifier? Default group. Clean and predictable.

Handling cluster taps

When a user taps a cluster, you get a ClusterClicked event with everything you need:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

The event args give you Pins (the pins in the cluster), Location (the geographic center), and Handled (set to true if you want to override the default zoom). Simple, practical, exactly what you’d expect.

Platform details worth knowing

On Android, clustering uses a custom grid-based algorithm that recalculates on zoom changes — no external dependencies. On iOS and Mac Catalyst, it leverages native MKClusterAnnotation support from MapKit, which means smooth, platform-native animations.

This is one of those cases where the MAUI team made the right call — lean on the platform where it makes sense.

Why this matters

Pin clustering has been one of the most requested features in .NET MAUI (issue #11811), and for good reason. Every app that shows locations on a map — delivery tracking, store locators, real estate — needs this. Previously you had to build it yourself or pull in a third-party library. Now it’s built in.

For us .NET developers building cross-platform mobile apps, this is the kind of quality-of-life improvement that makes MAUI a genuinely practical choice for map-heavy scenarios.

Get started

Install .NET 11 Preview 3 and update the .NET MAUI workload. The Maps sample includes a new Clustering page you can play with right away.

Go build something with it — and let your maps finally breathe.

.NET April 2026 Servicing — Security Patches You Should Apply Today

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

The April 2026 servicing updates for .NET and .NET Framework are out, and this one includes security fixes you’ll want to apply soon. Six CVEs patched, including two remote code execution (RCE) vulnerabilities.

What’s patched

Here’s the quick summary:

CVE	Type	Affects
CVE-2026-26171	Security Feature Bypass	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Remote Code Execution	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Remote Code Execution	.NET 10, 9, 8
CVE-2026-32203	Denial of Service	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Denial of Service	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denial of Service	.NET Framework 2.0–4.8.1

The two RCE CVEs (CVE-2026-32178 and CVE-2026-33116) affect the broadest range of .NET versions and should be the priority.

Updated versions

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

All are available via the usual channels — dotnet.microsoft.com, container images on MCR, and Linux package managers.

What to do

Update your projects and CI/CD pipelines to the latest patch versions. If you’re running containers, pull the latest images. If you’re on .NET Framework, check the .NET Framework release notes for the corresponding patches.

For those running .NET 10 in production (it’s the current release), 10.0.6 is a mandatory update. Same for .NET 9.0.15 and .NET 8.0.26 if you’re on those LTS tracks. Two RCE vulnerabilities are not something you postpone.

Aspire 13.2 Gets MongoDB EF Core and Azure Data Lake — Two Integrations Worth Trying

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 just landed with two new database integrations that are worth your attention: MongoDB Entity Framework Core and Azure Data Lake Storage. If you’ve been wanting to use EF Core with MongoDB in an Aspire app, or need to wire up data lake workloads with proper service discovery, this release delivers both.

MongoDB meets EF Core in Aspire

This is the one I’m most excited about. Aspire has supported MongoDB for a while, but it was always the raw driver — no EF Core, no DbContext, no LINQ queries against your documents. Now you get the full EF Core experience with MongoDB, plus Aspire’s automatic health checks and service discovery.

Setting it up is the typical Aspire pattern. In your AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Then in your consuming project, add the EF Core integration:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

And register your DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

From there, it’s standard EF Core. Define your entities, use your DbContext like you would with any other provider. The integration handles connection pooling, OpenTelemetry traces, and health checks behind the scenes.

For .NET developers who’ve been using MongoDB with the raw driver and manually wiring up connection strings, this is a nice quality-of-life upgrade. You get the full EF Core abstraction without losing Aspire’s service discovery.

Azure Data Lake Storage joins the party

The second big addition is an Azure Data Lake Storage (ADLS) integration. If you’re building data pipelines, ETL processes, or analytics platforms, you can now wire up Data Lake resources the same way you’d wire up any other Aspire dependency.

In the AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

In the consuming project:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

No manual connection string management, no credential hunting. Aspire provisions resources and injects them. For those of us building cloud-native .NET apps that touch both operational data and analytics workloads, this makes the data lake feel like a first-class citizen in the Aspire model.

The small fixes that matter

Beyond the headline features, there are a few quality-of-life improvements worth noting:

MongoDB connection string fix — the forward slash before the database name is now handled correctly. If you’ve been working around this, you can remove that workaround
SQL Server exports — Aspire.Hosting.SqlServer now exports additional server configuration options for finer-grained control
Emulator updates — ServiceBus emulator 2.0.0, App Configuration emulator 1.0.2, and CosmosDB’s preview emulator now includes a readiness check
Azure Managed Redis — now defaults to rediss:// (Redis Secure), so connections are encrypted out of the box

That last one is subtle but important — encrypted Redis by default means one less thing to configure in production.

Wrapping up

Aspire 13.2 is an incremental release, but the MongoDB EF Core and Data Lake integrations fill real gaps. If you’ve been waiting for proper EF Core support with MongoDB in Aspire, or needed Data Lake to be a first-class dependency, upgrade to 13.2 and give them a spin. The aspire add command scaffolds everything you need.

Read the full release notes for more details, and check out the integration gallery for the complete list.

azd update — One Command to Rule All Your Package Managers

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

You know that “A new version of azd is available” message that pops up every few weeks? The one you dismiss because you can’t remember whether you installed azd via winget, Homebrew, or that curl script you ran six months ago? Yeah, that’s finally fixed.

Microsoft just shipped azd update — a single command that updates the Azure Developer CLI to the latest version regardless of how you originally installed it. Windows, macOS, Linux — doesn’t matter. One command.

How it works

azd update

That’s it. If you want early access to new features, you can switch to the daily insiders build:

azd update --channel daily
azd update --channel stable

The command detects your current installation method and uses the appropriate update mechanism under the hood. No more “wait, did I use winget or choco on this machine?”

The small catch

azd update ships starting with version 1.23.x. If you’re on an older version, you’ll need to do one last manual update using your original installation method. After that, azd update handles everything going forward.

Check your current version with azd version. If you need a fresh install, the install docs have you covered.

Why it matters

This is a small quality-of-life improvement, but for those of us who use azd daily for deploying AI agents and Aspire apps to Azure, staying current means fewer “this bug was already fixed in the latest version” moments. One less thing to think about.

Read the full announcement and Jon Gallant’s deeper dive for more context.

Azure DevOps Server April 2026 Patch — PR Completion Fix and Security Updates

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Quick heads-up for teams running self-hosted Azure DevOps Server: Microsoft released Patch 3 for April 2026 with three targeted fixes.

What’s fixed

Pull request completion failures — a null reference exception during work item auto-completion could cause PR merges to fail. If you’ve hit random PR completion errors, this is likely the cause
Sign-out redirect validation — improved validation during sign-out to prevent potential malicious redirects. This is a security fix worth applying promptly
GitHub Enterprise Server PAT connections — creating Personal Access Token connections to GitHub Enterprise Server was broken, now it’s restored

How to update

Download Patch 3 and run the installer. To verify the patch is applied:

<patch-installer>.exe CheckInstall

If you’re running Azure DevOps Server on-premises, Microsoft strongly recommends staying on the latest patch for both security and reliability. Check the release notes for full details.

Azure Smart Tier Is GA — Automatic Blob Storage Cost Optimization Without Lifecycle Rules

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

If you’ve ever spent time tuning Azure Blob Storage lifecycle policies and then watched them fall apart when access patterns shifted, this one’s for you. Microsoft just announced the general availability of smart tier for Azure Blob and Data Lake Storage — a fully managed tiering capability that automatically moves objects between hot, cool, and cold tiers based on real usage.

What smart tier actually does

The concept is straightforward: smart tier continuously evaluates the last access time of each object in your storage account. Frequently accessed data stays in hot, inactive data moves to cool after 30 days, and then to cold after another 60 days. When data is accessed again, it’s promoted back to hot immediately. The cycle restarts.

No lifecycle rules to configure. No access pattern predictions. No manual tuning.

During the preview, Microsoft reported that over 50% of smart-tier-managed capacity automatically shifted to cooler tiers based on actual access patterns. That’s a meaningful cost reduction for large storage accounts.

Why this matters for .NET developers

If you’re building applications that generate logs, telemetry, analytics data, or any kind of growing data estate — and honestly, who isn’t — storage costs add up fast. The traditional approach was writing lifecycle management policies, testing them, and then re-tuning when your app’s access patterns changed. Smart tier removes that entire workflow.

Some practical scenarios where this helps:

Application telemetry and logs — hot when debugging, rarely accessed after a few weeks
Data pipelines and ETL outputs — accessed heavily during processing, then mostly cold
User-generated content — recent uploads are hot, older content gradually cools
Backup and archival data — accessed occasionally for compliance, mostly idle

Setting it up

Enabling smart tier is a one-time configuration:

New accounts: Select smart tier as the default access tier during storage account creation (zonal redundancy required)
Existing accounts: Switch the blob access tier from your current default to smart tier

Objects smaller than 128 KiB stay in hot and don’t incur the monitoring fee. For everything else, you pay standard hot/cool/cold capacity rates with no tier transition charges, no early deletion fees, and no data retrieval costs. A monthly monitoring fee per object covers the orchestration.

The tradeoff to know about

Smart tier’s tiering rules are static (30 days → cool, 90 days → cold). If you need custom thresholds — say, moving to cool after 7 days for a specific workload — lifecycle rules are still the way to go. And don’t mix both: avoid using lifecycle rules on smart-tier-managed objects, as they can conflict.

Wrapping up

This isn’t revolutionary, but it solves a real operational headache. If you manage growing blob storage accounts and you’re tired of maintaining lifecycle policies, enable smart tier and let Azure handle it. It’s available today in nearly all zonal public cloud regions.

Where Should You Host Your AI Agents on Azure? A Practical Decision Guide

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

If you’re building AI agents with .NET right now, you’ve probably noticed something: there are a lot of ways to host them on Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — and they all sound reasonable until you actually need to pick one. Microsoft just published a comprehensive guide to Azure AI agent hosting that clears this up, and I want to break it down from a practical .NET developer perspective.

The six options at a glance

Here’s how I’d summarize the landscape:

Option	Best for	You manage
Container Apps	Full container control without K8s complexity	Observability, state, lifecycle
AKS	Enterprise compliance, multi-cluster, custom networking	Everything (that’s the point)
Azure Functions	Event-driven, short-running agent tasks	Not much — true serverless
App Service	Simple HTTP agents, predictable traffic	Deployment, scaling config
Foundry Agents	Code-optional agents via portal/SDK	Almost nothing
Foundry Hosted Agents	Custom framework agents with managed infra	Your agent code only

The first four are general-purpose compute — you can run agents on them, but they weren’t designed for it. The last two are agent-native: they understand conversations, tool calls, and agent lifecycles as first-class concepts.

Foundry Hosted Agents — the sweet spot for .NET agent developers

Here’s what caught my attention. Foundry Hosted Agents sit right in the middle: you get the flexibility of running your own code (Semantic Kernel, Agent Framework, LangGraph — whatever) but the platform handles infrastructure, observability, and conversation management.

The key piece is the Hosting Adapter — a thin abstraction layer that bridges your agent framework to the Foundry platform. For Microsoft Agent Framework, it looks like this:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

That’s your entire hosting story. The adapter handles protocol translation, streaming via server-sent events, conversation history, and OpenTelemetry tracing — all automatically. No custom middleware, no manual plumbing.

Deploying is genuinely simple

I’ve deployed agents to Container Apps before and it works, but you end up writing a lot of glue code for state management and observability. With Hosted Agents and azd, the deployment is:

# Install the AI agent extension
azd ext install azure.ai.agents

# Init from a template
azd ai agent init

# Build, push, deploy — done
azd up

That single azd up builds your container, pushes it to ACR, provisions the Foundry project, deploys model endpoints, and starts your agent. Five steps collapsed into one command.

Built-in conversation management

This is the part that saves the most time in production. Instead of building your own conversation state store, Hosted Agents handle it natively:

# Create a persistent conversation
conversation = openai_client.conversations.create()

# First turn
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Second turn — context is preserved
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

No Redis. No Cosmos DB session store. No custom middleware for message serialization. The platform just handles it.

My decision framework

After going through all six options, here’s my quick mental model:

Do you need zero infrastructure? → Foundry Agents (portal/SDK, no containers)
Do you have custom agent code but want managed hosting? → Foundry Hosted Agents
Do you need event-driven, short-lived agent tasks? → Azure Functions
Do you need maximum container control without K8s? → Container Apps
Do you need strict compliance and multi-cluster? → AKS
Do you have a simple HTTP agent with predictable traffic? → App Service

For most .NET developers building with Semantic Kernel or Microsoft Agent Framework, Hosted Agents is likely the right starting point. You get scale-to-zero, built-in OpenTelemetry, conversation management, and framework flexibility — without managing Kubernetes or wiring up your own observability stack.

Wrapping up

The agent hosting landscape on Azure is maturing fast. If you’re starting a new AI agent project today, I’d seriously consider Foundry Hosted Agents before reaching for Container Apps or AKS out of habit. The managed infrastructure saves real time, and the hosting adapter pattern lets you keep your framework choice.

Check out the full guide from Microsoft and the Foundry Samples repo for working examples.

Agent Skills in .NET Just Got Seriously Flexible

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

If you’ve been building agents with the Microsoft Agent Framework, you know the drill: you define skills, wire them into a provider, and let the agent figure out which one to invoke. What’s new is how you author those skills — and the flexibility jump is significant.

The latest update introduces three distinct authoring patterns for agent skills: file-based, class-based, and inline code-defined. All three plug into a single AgentSkillsProviderBuilder, meaning you can mix and match without any routing logic or special glue code. Let me walk you through each one and when you’d reach for it.

File-based skills: the starting point

File-based skills are exactly what they sound like — a directory on disk with a SKILL.md file, optional scripts, and reference documents. Think of it as the most straightforward way to give your agent new capabilities:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

The SKILL.md frontmatter declares the skill name and description, and the instructions section tells the agent how to use the scripts and references:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Then you wire it up with SubprocessScriptRunner.RunAsync for script execution:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

The agent discovers the skill automatically and invokes the provisioning script when it needs to check account status. Clean and simple.

Class-based skills: ship via NuGet

Here’s where it gets interesting for teams. Class-based skills derive from AgentClassSkill<T> and use attributes like [AgentSkillResource] and [AgentSkillScript] so the framework discovers everything via reflection:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

The beauty here is that a team can package this as a NuGet package. You add it to your project, drop it into the builder, and it works alongside your file-based skills with zero coordination:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Both skills show up in the agent’s system prompt. The agent decides which one to use based on the conversation — no routing code needed.

Inline skills: the quick bridge

You know that moment when another team is building exactly the skill you need, but it won’t ship for a sprint? AgentInlineSkill is your bridge:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Add it to the builder just like the others:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

When the NuGet package eventually ships, you swap out the inline skill for the class-based one. The agent doesn’t know the difference.

But inline skills aren’t just for bridges. They’re also the right choice when you need to generate skills dynamically at runtime — think one skill per business unit loaded from config — or when a script needs to close over local state that doesn’t belong in a DI container.

Script approval: human-in-the-loop

For us .NET developers building production agents, this is the part that actually unblocks deployment conversations. Some scripts have real consequences — enrolling someone in benefits, querying production infra. Flip on UseScriptApproval and the agent pauses before executing any script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

When the agent wants to run a script, it returns an approval request instead. Your app collects the decision — approve or reject — and the agent continues accordingly. In regulated environments, this is the difference between “we can deploy this” and “legal says no.”

Why this combination matters

The real power isn’t any single authoring pattern — it’s the composition. You can:

Start small with a file-based skill, iterate on the instructions, and ship it without writing C#
Ship reusable skills as NuGet packages that other teams can add with one line
Bridge gaps with inline skills when you need something now
Filter shared skill directories with predicates so your agent only loads what it should
Add human oversight for scripts that touch production systems

All of these compose through AgentSkillsProviderBuilder. No special routing, no conditional logic, no skill type checks.

Wrapping up

Agent skills in .NET now have a genuinely flexible authoring model. Whether you’re a solo developer sketching out a prototype with file-based skills or an enterprise team shipping packaged capabilities via NuGet, the patterns fit. And the script approval mechanism makes it production-ready for environments where you need that human checkpoint.

Check out the original announcement for the full walkthrough, the Agent Skills documentation on Microsoft Learn, and the .NET samples on GitHub to get hands-on.

Azure MCP Server 2.0 Just Dropped — Self-Hosted Agentic Cloud Automation Is Here

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

If you’ve been building anything with MCP and Azure lately, you probably already know the local experience works well. Plug in an MCP server, let your AI agent talk to Azure resources, move on. But the moment you need to share that setup across a team? That’s where things got complicated.

Not anymore. Azure MCP Server just hit 2.0 stable, and the headline feature is exactly what enterprise teams have been asking for: self-hosted remote MCP server support.

What’s Azure MCP Server?

Quick refresher. Azure MCP Server implements the Model Context Protocol specification and exposes Azure capabilities as structured, discoverable tools that AI agents can invoke. Think of it as a standardized bridge between your agent and Azure — provisioning, deployment, monitoring, diagnostics, all through one consistent interface.

The numbers speak for themselves: 276 MCP tools across 57 Azure services. That’s serious coverage.

The big deal: self-hosted remote deployments

Here’s the thing. Running MCP locally on your machine is fine for dev and experiments. But in a real team scenario, you need:

Shared access for developers and internal agent systems
Centralized configuration (tenant context, subscription defaults, telemetry)
Enterprise network and policy boundaries
Integration into CI/CD pipelines

Azure MCP Server 2.0 addresses all of this. You can deploy it as a centrally managed internal service with HTTP-based transport, proper authentication, and consistent governance.

For auth, you get two solid options:

Managed Identity — when running alongside Microsoft Foundry
On-Behalf-Of (OBO) flow — OpenID Connect delegation that calls Azure APIs using the signed-in user’s context

That OBO flow is particularly interesting for us .NET developers. It means your agentic workflows can operate with the user’s actual permissions, not some over-privileged service account. Principle of least privilege, built right in.

Security hardening

This isn’t just a feature release — it’s a security one too. The 2.0 release adds:

Stronger endpoint validation
Protections against injection patterns in query-oriented tools
Tighter isolation controls for dev environments

If you’re going to expose MCP as a shared service, these safeguards matter. A lot.

Where can you use it?

The client compatibility story is broad. Azure MCP Server 2.0 works with:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agents: GitHub Copilot CLI, Claude Code
Standalone: local server for simple setups
Self-hosted remote: the new star of 2.0

Plus there’s sovereign cloud support for Azure US Government and Azure operated by 21Vianet, which is critical for regulated deployments.

Why this matters for .NET developers

If you’re building agentic applications with .NET — whether that’s Semantic Kernel, Microsoft Agent Framework, or your own orchestration — Azure MCP Server 2.0 gives you a production-ready way to let your agents interact with Azure infrastructure. No custom REST wrappers. No service-specific integration patterns. Just MCP.

Combined with the fluent API for MCP Apps that dropped a few days ago, the .NET MCP ecosystem is maturing fast.

Getting started

Pick your path:

GitHub Repo — source code, docs, everything
Docker Image — containerized deployment
VS Code Extension — IDE integration
Self-hosting guide — the 2.0 flagship feature

Wrapping up

Azure MCP Server 2.0 is exactly the kind of infrastructure upgrade that doesn’t look flashy in a demo but changes everything in practice. Self-hosted remote MCP with proper auth, security hardening, and sovereign cloud support means MCP is ready for real teams building real agentic workflows on Azure. If you’ve been waiting for the “enterprise-ready” signal — this is it.

.NET Aspire 13.2 Wants to Be Your AI Agent's Best Friend

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

You know that moment when your AI coding agent writes some solid code, you get excited, and then it completely falls apart trying to actually run the thing? Port conflicts, phantom processes, wrong environment variables — suddenly your agent is burning tokens troubleshooting startup issues instead of building features.

The Aspire team just dropped a really thoughtful post about exactly this problem, and their answer is compelling: Aspire 13.2 is designed not just for humans, but for AI agents.

The problem is real

AI agents are incredible at writing code. But shipping a working full-stack app involves way more than generating files. You need to start services in the right order, manage ports, set environment variables, connect databases, and get feedback when things break. Right now, most agents handle all of this through trial-and-error — running commands, reading error output, trying again.

We layer on Markdown instructions, custom skills, and prompts to try to guide them, but those are unpredictable, can’t be compiled, and cost tokens just to parse. The Aspire team nailed the core insight: agents need compilers and structured APIs, not more Markdown.

Aspire as agent infrastructure

Here’s what Aspire 13.2 brings to the agentic development table:

Your entire stack in typed code. The AppHost defines your full topology — API, frontend, database, cache — in compilable TypeScript or C#:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

An agent can read this to understand app topology, add resources, wire up connections, and build to verify. The compiler tells it immediately if something is wrong. No guessing, no trial-and-error with config files.

One command to rule them all. Instead of agents juggling docker compose up, npm run dev, and database startup scripts, everything is just aspire start. All resources launch in the right order, on the right ports, with the right configuration. Long-running processes don’t hang the agent either — Aspire manages them.

Isolated mode for parallel agents. With --isolated, each Aspire run gets its own random ports and separate user secrets. Got multiple agents working across git worktrees? They won’t collide. This is huge for tools like VS Code’s background agents that spin up parallel environments.

Agent eyes through telemetry. Here’s where it gets really powerful. The Aspire CLI exposes full OpenTelemetry data during development — traces, metrics, structured logs. Your agent isn’t just reading console output and hoping for the best. It can trace a failing request across services, profile slow endpoints, and pinpoint exactly where things break. That’s production-grade observability in the development loop.

The bowling bumper analogy

The Aspire team uses a great analogy: think of Aspire as bowling lane bumpers for AI agents. If the agent isn’t perfect (and it won’t be), the bumpers keep it from throwing gutter balls. The stack definition prevents misconfiguration, the compiler catches errors, the CLI handles process management, and the telemetry provides the feedback loop.

Pair this with something like Playwright CLI, and your agent can actually use your app — clicking through flows, checking the DOM, seeing broken things in telemetry, fixing the code, restarting, and testing again. Build, run, observe, fix. That’s the autonomous development loop we’ve been chasing.

Getting started

New to Aspire? Install the CLI from get.aspire.dev and follow the getting started guide.

Already using Aspire? Run aspire update --self to get 13.2, then point your favorite coding agent at your repo. You might be surprised how much further it gets with Aspire’s guardrails in place.

Wrapping up

Aspire 13.2 isn’t just a distributed app framework anymore — it’s becoming essential agent infrastructure. Structured stack definitions, one-command startup, isolated parallel runs, and real-time telemetry give AI agents exactly what they need to go from writing code to shipping apps.

Read the full post from the Aspire team for all the details and demo videos.

Agentic Platform Engineering Is Getting Real — Git-APE Shows How

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Platform engineering has been one of those terms that sounds great in conference talks but usually means “we built an internal portal and a Terraform wrapper.” The real promise — self-service infrastructure that’s actually safe, governed, and fast — has always been a few steps away.

The Azure team just published Part 2 of their agentic platform engineering series, and this one is all about the hands-on implementation. They call it Git-APE (yes, the acronym is intentional), and it’s an open-source project that uses GitHub Copilot agents plus Azure MCP servers to turn natural-language requests into validated, deployed infrastructure.

What Git-APE actually does

The core idea: instead of developers learning Terraform modules, navigating portal UIs, or filing tickets to a platform team, they talk to a Copilot agent. The agent interprets the intent, generates Infrastructure-as-Code, validates it against policies, and deploys — all within VS Code.

Here’s the setup:

git clone https://github.com/Azure/git-ape
cd git-ape

Open the workspace in VS Code, and the agent configuration files are auto-discovered by GitHub Copilot. You interact with the agent directly:

@git-ape deploy a function app with storage in West Europe

The agent uses Azure MCP Server under the hood to interact with Azure services. The MCP configuration in VS Code settings enables specific capabilities:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Why this matters

For those of us building on Azure, this shifts the platform engineering conversation from “how do we build a portal” to “how do we describe our guardrails as APIs.” When your platform’s interface is an AI agent, the quality of your constraints and policies becomes the product.

The Part 1 blog laid out the theory: well-described APIs, control schemas, and explicit guardrails make platforms agent-ready. Part 2 proves it works by shipping actual tooling. The agent doesn’t just blindly generate resources — it validates against best practices, respects naming conventions, and applies your organization’s policies.

Clean-up is just as easy:

@git-ape destroy my-resource-group

My take

I’ll be honest — this one is more about the pattern than the specific tool. Git-APE itself is a demo/reference architecture. But the underlying idea — agents as the interface to your platform, MCP as the protocol, GitHub Copilot as the host — is where enterprise developer experience is heading.

If you’re a platform team looking at how to make your internal tooling agent-friendly, there’s no better starting point. And if you’re a .NET developer wondering how this connects to your world: the Azure MCP Server and GitHub Copilot agents work with any Azure workload. Your ASP.NET Core API, your .NET Aspire stack, your containerized microservices — all of it can be the target of an agentic deployment flow.

Wrapping up

Git-APE is an early but concrete look at agentic platform engineering in practice. Clone the repo, try the demo, and start thinking about how your platform’s APIs and policies would need to look for an agent to safely use them.

Read the full post for the walkthrough and video demos.

Aspire's Isolated Mode Fixes the Port Conflict Nightmare for Parallel Development

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

If you’ve ever tried running two instances of the same project at the same time, you know the pain. Port 8080 is already in use. Port 17370 is taken. Kill something, restart, juggle environment variables — it’s a productivity killer.

This problem is getting worse, not better. AI agents create git worktrees to work independently. Background agents spin up separate environments. Developers checkout the same repo twice for feature branches. Every one of these scenarios hits the same wall: two instances of the same app fighting over the same ports.

Aspire 13.2 fixes this with a single flag. James Newton-King from the Aspire team wrote up the full details, and it’s one of those “why didn’t we have this sooner” features.

The fix: `--isolated`

aspire run --isolated

That’s it. Each run gets:

Random ports — no more collisions between instances
Isolated user secrets — connection strings and API keys stay separate per instance

No manual port reassignment. No environment variable juggling. Each run gets a fresh, collision-free environment automatically.

Real scenarios where this shines

Multiple checkouts. You’ve got a feature branch in one directory and a bugfix in another:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Both run without conflicts. The dashboard shows what’s running and where.

Background agents in VS Code. When Copilot Chat’s background agent creates a git worktree to work on your code independently, it may need to run your Aspire AppHost. Without --isolated, that’s a port collision with your primary worktree. With it, both instances just work.

The Aspire skill that ships with aspire agent init automatically instructs agents to use --isolated when working in worktrees. So Copilot’s background agent should handle this out of the box.

Integration tests alongside development. Need to run tests against a live AppHost while continuing to build features? Isolated mode gives each context its own ports and config.

How it works under the hood

When you pass --isolated, the CLI generates a unique instance ID for the run. This drives two behaviors:

Port randomization — instead of binding to predictable ports defined in your AppHost config, isolated mode picks random available ports for everything — the dashboard, service endpoints, all of it. Service discovery adjusts automatically, so services find each other regardless of which ports they land on.
Secret isolation — each isolated run gets its own user secrets store, keyed by the instance ID. Connection strings and API keys from one run don’t leak into another.

Your code doesn’t need any changes. Aspire’s service discovery resolves endpoints at runtime, so everything connects correctly regardless of port assignment.

When to use it

Use --isolated when running multiple instances of the same AppHost simultaneously — whether that’s parallel development, automated tests, AI agents, or git worktrees. For single-instance development where you prefer predictable ports, regular aspire run still works fine.

Wrapping up

Isolated mode is a small feature that solves a real, increasingly common problem. As AI-assisted development pushes us toward more parallel workflows — multiple agents, multiple worktrees, multiple contexts — the ability to just spin up another instance without fighting over ports is essential.

Read the full post for all the technical details and try it out with aspire update --self to get 13.2.

Building Real-Time Multi-Agent UIs That Don't Feel Like a Black Box

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Here’s the thing about multi-agent systems: they look incredible in demos. Three agents passing work around, solving problems, making decisions. Then you try to put it in front of actual users and… silence. A spinning indicator. No idea which agent is doing what or why the system is paused. That’s not a product — that’s a trust problem.

The Microsoft Agent Framework team just published a fantastic walkthrough on pairing MAF workflows with AG-UI, an open protocol for streaming agent execution events to a frontend over Server-Sent Events. And honestly? This is the kind of bridge we’ve been missing.

Why this matters for .NET developers

If you’re building AI-powered apps, you’ve probably hit this wall. Your backend orchestration works great — agents hand off to each other, tools fire, decisions get made. But the frontend has no clue what’s happening behind the scenes. AG-UI fixes that by defining a standard protocol for streaming agent events (think RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) directly to your UI layer over SSE.

The demo they built is a customer support workflow with three agents: a triage agent that routes requests, a refund agent that handles money stuff, and an order agent that manages replacements. Each agent has its own tools, and the handoff topology is explicitly defined — no “figure it out from the prompt” vibes.

The handoff topology is the real star

What caught my eye is how HandoffBuilder lets you declare a directed routing graph between agents:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Each add_handoff creates a directed edge with a natural-language description. The framework generates handoff tools for each agent based on this topology. So routing decisions are grounded in your orchestration structure, not just whatever the LLM feels like doing. That’s a huge deal for production reliability.

Human-in-the-loop that actually works

The demo showcases two interrupt patterns that any real-world agent app needs:

Tool approval interrupts — when an agent calls a tool marked with approval_mode="always_require", the workflow pauses and emits an event. The frontend renders an approval modal with the tool name and arguments. No token-burning retry loops — just a clean pause-approve-resume flow.

Information request interrupts — when an agent needs more context from the user (like an order ID), it pauses and asks. The frontend shows the question, the user responds, and execution resumes from exactly where it stopped.

Both patterns stream as standard AG-UI events, so your frontend doesn’t need custom logic per agent — it just renders whatever event comes through the SSE connection.

Wiring it up is surprisingly simple

The integration between MAF and AG-UI is a single function call:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

The workflow_factory creates a fresh workflow per thread, so each conversation gets isolated state. The endpoint handles all the SSE plumbing automatically. If you’re already using FastAPI (or can add it as a lightweight layer), this is almost zero friction.

My take

For us .NET developers, the immediate question is: “Can I do this in C#?” The Agent Framework is available for both .NET and Python, and the AG-UI protocol is language-agnostic (it’s just SSE). So while this specific demo uses Python and FastAPI, the pattern translates directly. You could wire up an ASP.NET Core minimal API with SSE endpoints following the same AG-UI event schema.

The bigger takeaway is that multi-agent UIs are becoming a first-class concern, not an afterthought. If you’re building anything where agents interact with humans — customer support, approval workflows, document processing — this combination of MAF orchestration and AG-UI transparency is the pattern to follow.

Wrapping up

AG-UI + Microsoft Agent Framework gives you the best of both worlds: robust multi-agent orchestration on the backend and real-time visibility on the frontend. No more black-box agent interactions.

Check out the full walkthrough and the AG-UI protocol repo to dig deeper.

Connect Your MCP Servers on Azure Functions to Foundry Agents — Here's How

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Here’s something I love about the MCP ecosystem: you build your server once, and it works everywhere. VS Code, Visual Studio, Cursor, ChatGPT — every MCP client can discover and use your tools. Now, Microsoft is adding another consumer to that list: Foundry agents.

Lily Ma from the Azure SDK team published a practical guide on connecting MCP servers deployed to Azure Functions with Microsoft Foundry agents. If you already have an MCP server, this is pure value-add — no rebuilding required.

Why this combination makes sense

Azure Functions gives you scalable infrastructure, built-in auth, and serverless billing for hosting MCP servers. Microsoft Foundry gives you AI agents that can reason, plan, and take actions. Connecting the two means your custom tools — querying a database, calling a business API, running validation logic — become capabilities that enterprise AI agents can discover and use autonomously.

The key point: your MCP server stays the same. You’re just adding Foundry as another consumer. The same tools that work in your VS Code setup now power an AI agent your team or customers interact with.

Authentication options

This is where the post really adds value. Four auth methods depending on your scenario:

Method	Use Case
Key-based (default)	Development or servers without Entra auth
Microsoft Entra	Production with managed identities
OAuth identity passthrough	Production where each user authenticates individually
Unauthenticated	Dev/testing or public data only

For production, Microsoft Entra with agent identity is the recommended path. OAuth identity passthrough is for when user context matters — the agent prompts users to sign in, and each request carries the user’s own token.

Setting it up

The high-level flow:

Deploy your MCP server to Azure Functions — samples available for .NET, Python, TypeScript, and Java
Enable built-in MCP authentication on your function app
Get your endpoint URL — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Add the MCP server as a tool in Foundry — navigate to your agent in the portal, add a new MCP tool, provide endpoint and credentials

Then test it in the Agent Builder playground by sending a prompt that would trigger one of your tools.

My take

The composability story here is getting really strong. Build your MCP server once in .NET (or Python, TypeScript, Java), deploy to Azure Functions, and every MCP-compatible client can use it — coding tools, chat apps, and now enterprise AI agents. That’s a “write once, use everywhere” pattern that actually works.

For .NET developers specifically, the Azure Functions MCP extension makes this straightforward. You define your tools as Azure Functions, deploy, and you’ve got a production-grade MCP server with all the security and scaling Azure Functions provides.

Wrapping up

If you have MCP tools running on Azure Functions, connecting them to Foundry agents is a quick win — your custom tools become enterprise AI capabilities with proper auth and no code changes to the server itself.

Read the full guide for step-by-step instructions on each authentication method, and check the detailed docs for production setups.

GitHub Copilot's Modernization Assessment Is the Best Migration Tool You're Not Using Yet

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Migrating a legacy .NET Framework app to modern .NET is one of those tasks everyone knows they should do but nobody wants to start. It’s never just “change the target framework.” It’s APIs that disappeared, packages that don’t exist anymore, hosting models that work completely differently, and a million small decisions about what to containerize, what to rewrite, and what to leave alone.

Jeffrey Fritz just published a deep dive into GitHub Copilot’s modernization assessment, and honestly? This is the best migration tooling I’ve seen for .NET. Not because of the code generation — that’s table stakes now. Because of the assessment document it produces.

It’s not just a code suggestion engine

The VS Code extension follows an Assess → Plan → Execute model. The assessment phase analyzes your entire codebase and produces a structured document that captures everything: what needs to change, what Azure resources to provision, what deployment model to use. Everything downstream — infrastructure-as-code, containerization, deployment manifests — flows from what the assessment finds.

The assessment is stored under .github/modernize/assessment/ in your project. Each run produces an independent report, so you build up a history and can track how your migration posture evolves as you fix issues.

Two ways to start

Recommended Assessment — the fast path. Pick from curated domains (Java/.NET Upgrade, Cloud Readiness, Security) and get meaningful results without touching configuration. Great for a first look at where your app stands.

Custom Assessment — the targeted path. Configure exactly what to analyze: target compute (App Service, AKS, Container Apps), target OS, containerization analysis. Pick multiple Azure targets to compare migration approaches side-by-side.

That comparison view is genuinely useful. An app with 3 mandatory issues for App Service might have 7 for AKS. Seeing both helps drive the hosting decision before you commit to a migration path.

The issue breakdown is actionable

Each issue comes with a criticality level:

Mandatory — must fix or migration fails
Potential — might impact migration, needs human judgment
Optional — recommended improvements, won’t block migration

And each issue links to affected files and line numbers, provides a detailed description of what’s wrong and why it matters for your target platform, gives concrete remediation steps (not just “fix this”), and includes links to official documentation.

You can hand individual issues to developers and they have everything they need to act. That’s the difference between a tool that tells you “there’s a problem” and one that tells you how to solve it.

The upgrade paths covered

For .NET specifically:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Each upgrade path has detection rules that know which APIs were removed, which patterns have no direct equivalent, and what security issues need attention.

For teams managing multiple apps, there’s also a CLI that supports multi-repo batch assessments — clone all repos, assess them all, get per-app reports plus an aggregated portfolio view.

My take

If you’re sitting on legacy .NET Framework apps (and let’s be real, most enterprise teams are), this is the tool to start with. The assessment document alone is worth the time — it turns a vague “we should modernize” into a concrete, prioritized list of work items with clear paths forward.

The collaborative workflow is smart too: export assessments, share with your team, import them without re-running. Architecture reviews where the decision-makers aren’t the ones running the tools? Covered.

Wrapping up

GitHub Copilot’s modernization assessment transforms .NET migration from a scary, undefined project into a structured, trackable process. Start with a recommended assessment to see where you stand, then use custom assessments to compare Azure targets and build your migration plan.

Read the full walkthrough and grab the VS Code extension to try it on your own codebase.

MCP Apps Get a Fluent API — Build Rich AI Tool UIs in .NET with Three Steps

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP tools are great for giving AI agents capabilities. But what if your tool needs to show something to the user — a dashboard, a form, an interactive visualization? That’s where MCP Apps come in, and they just got a lot easier to build.

Lilian Kasem from the Azure SDK team introduced the new fluent configuration API for MCP Apps on .NET Azure Functions, and it’s the kind of developer experience improvement that makes you wonder why it wasn’t always this simple.

What are MCP Apps?

MCP Apps extend the Model Context Protocol by letting tools carry their own UI views, static assets, and security controls. Instead of just returning text, your MCP tool can render full HTML experiences — interactive dashboards, data visualizations, configuration forms — all invocable by AI agents and presented to users by MCP clients.

The catch was that wiring all this up manually required knowing the MCP spec intimately: ui:// URIs, special mime types, metadata coordination between tools and resources. Not hard, but fiddly.

The fluent API in three steps

Step 1: Define your function. Just a standard Azure Functions MCP tool:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Step 2: Promote it to an MCP App. In your program startup:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Step 3: Add your HTML view. Create assets/hello-app.html with whatever UI you need.

That’s it. The fluent API handles all the MCP spec plumbing — generating the synthetic resource function, setting the correct mime type, injecting the metadata that connects your tool to its view.

The API surface is well-designed

A few things I really like:

View sources are flexible. You can serve HTML from files on disk, or embed resources directly in your assembly for self-contained deployments:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP is composable. You explicitly allowlist origins your app needs, following least-privilege principles. Call WithCsp multiple times and origins accumulate:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Visibility control. You can make a tool visible to the LLM only, the host UI only, or both. Want a tool that only renders UI and shouldn’t be called by the model? Easy:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Getting started

Add the preview package:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

If you’re already building MCP tools with Azure Functions, this is just a package update. The MCP Apps quickstart is the best place to start if you’re new to the concept.

Wrapping up

MCP Apps are one of the more exciting developments in the AI tooling space — tools that don’t just do things but can show things to users. The fluent API removes the protocol complexity and lets you focus on what matters: your tool’s logic and its UI.

Read the full post for the complete API reference and examples.

Microsoft Foundry March 2026 — GPT-5.4, Agent Service GA, and the SDK Refresh That Changes Everything

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

The monthly “What’s New in Microsoft Foundry” posts are usually a mix of incremental improvements and the occasional headline feature. The March 2026 edition? It’s basically all headline features. Foundry Agent Service goes GA, GPT-5.4 ships for production, the SDK gets a major stable release, and Fireworks AI brings open model inference to Azure. Let me break down what matters for .NET developers.

Foundry Agent Service is production-ready

This is the big one. The next-gen agent runtime is generally available — built on the OpenAI Responses API, wire-compatible with OpenAI agents, and open to models from multiple providers. If you’re building with the Responses API today, migrating to Foundry adds enterprise security, private networking, Entra RBAC, full tracing, and evaluation on top of your existing agent logic.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Key additions: end-to-end private networking, MCP auth expansion (including OAuth passthrough), Voice Live preview for speech-to-speech agents, and hosted agents in 6 new regions.

GPT-5.4 — reliability over raw intelligence

GPT-5.4 isn’t about being smarter. It’s about being more reliable. Stronger reasoning over long interactions, better instruction adherence, fewer mid-workflow failures, and integrated computer use capabilities. For production agents, that reliability matters way more than benchmark scores.

Model	Pricing (per M tokens)	Best For
GPT-5.4 (≤272K)	$2.50 / $15 output	Production agents, coding, document workflows
GPT-5.4 Pro	$30 / $180 output	Deep analysis, scientific reasoning
GPT-5.4 Mini	Cost-effective	Classification, extraction, lightweight tool calls

The smart play is a routing strategy: GPT-5.4 Mini handles high-volume, low-latency work while GPT-5.4 takes the reasoning-heavy requests.

The SDK is finally stable

azure-ai-projects SDK shipped stable releases across all languages — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, and .NET 2.0.0 (April 1). The azure-ai-agents dependency is gone — everything lives under AIProjectClient. Install with pip install azure-ai-projects and the package bundles openai and azure-identity as direct dependencies.

For .NET developers, this means a single NuGet package for the full Foundry surface. No more juggling separate agent SDKs.

Fireworks AI brings open models to Azure

Perhaps the most architecturally interesting addition: Fireworks AI processing 13+ trillion tokens daily at ~180K requests/second, now available through Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, and MiniMax M2.5 at launch.

The real story is bring-your-own-weights — upload quantized or fine-tuned weights from anywhere without changing the serving stack. Deploy via serverless pay-per-token or provisioned throughput.

Other highlights

Phi-4 Reasoning Vision 15B — multimodal reasoning for charts, diagrams, and document layouts
Evaluations GA — out-of-the-box evaluators with continuous production monitoring piped into Azure Monitor
Priority Processing (Preview) — dedicated compute lane for latency-sensitive workloads
Voice Live — speech-to-speech runtime that connects directly to Foundry agents
Tracing GA — end-to-end agent trace inspection with sort and filter
PromptFlow deprecation — migration to Microsoft Framework Workflows by January 2027

Wrapping up

March 2026 is a turning point for Foundry. The Agent Service GA, stable SDKs across all languages, GPT-5.4 for reliable production agents, and open model inference via Fireworks AI — the platform is ready for serious workloads.

Read the full roundup and build your first agent to get started.

SQL MCP Server — The Right Way to Give AI Agents Database Access

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Let’s be honest: most database MCP servers available today are terrifying. They take a natural language query, generate SQL on the fly, and run it against your production data. What could go wrong? (Everything. Everything could go wrong.)

The Azure SQL team just introduced SQL MCP Server, and it takes a fundamentally different approach. Built as a feature of Data API builder (DAB) 2.0, it gives AI agents structured, deterministic access to database operations — without NL2SQL, without exposing your schema, and with full RBAC at every step.

Why no NL2SQL?

This is the most interesting design decision. Models aren’t deterministic, and complex queries are the most likely to produce subtle errors. The exact queries users hope AI can generate are also the ones that need the most scrutiny when produced non-deterministically.

Instead, SQL MCP Server uses an NL2DAB approach. The agent works with Data API builder’s entity abstraction layer and built-in query builder to produce accurate, well-formed T-SQL deterministically. Same result for the user, but without the risk of hallucinated JOINs or accidental data exposure.

Seven tools, not seven hundred

SQL MCP Server exposes exactly seven DML tools, regardless of database size:

describe_entities — discover available entities and operations
create_record — insert rows
read_records — query tables and views
update_record — modify rows
delete_record — remove rows
execute_entity — run stored procedures
aggregate_records — aggregation queries

This is smart because context windows are the agent’s thinking space. Flooding them with hundreds of tool definitions leaves less room for reasoning. Seven fixed tools keep the agent focused on thinking rather than navigating.

Each tool can be individually enabled or disabled:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Getting started in three commands

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

That’s a running SQL MCP Server exposing your Customers table. The entity abstraction layer means you can alias names and columns, limit fields per role, and control exactly what agents see — without exposing internal schema details.

The security story is solid

This is where Data API builder’s maturity pays off:

RBAC at every layer — each entity defines which roles can read, create, update, or delete, and which fields are visible
Azure Key Vault integration — connection strings and secrets managed securely
Microsoft Entra + custom OAuth — production-grade authentication
Content Security Policy — agents interact through a controlled contract, not raw SQL

The schema abstraction is particularly important. Your internal table and column names never get exposed to the agent. You define entities, aliases, and descriptions that make sense for the AI interaction — not your database ERD.

Multi-database and multi-protocol

SQL MCP Server supports Microsoft SQL, PostgreSQL, Azure Cosmos DB, and MySQL. And because it’s a DAB feature, you get REST, GraphQL, and MCP endpoints simultaneously from the same configuration. Same entity definitions, same RBAC rules, same security — across all three protocols.

Auto-configuration in DAB 2.0 can even inspect your database and build the configuration dynamically, if you’re comfortable with less abstraction for rapid prototyping.

My take

This is how enterprise database access for AI agents should work. Not “hey LLM, write me some SQL and YOLO it against production.” Instead: a well-defined entity layer, deterministic query generation, RBAC at every step, caching, monitoring, and telemetry. It’s boring in the best possible way.

For .NET developers, the integration story is clean — DAB is a .NET tool, the MCP Server runs as a container, and it works with Azure SQL, which most of us are already using. If you’re building AI agents that need data access, start here.

Wrapping up

SQL MCP Server is free, open-source, and runs anywhere. It’s the prescriptive approach from Microsoft for giving AI agents secure database access. Check out the full post and the documentation to get started.

That Visual Studio Floating Windows Setting You Didn't Know About (But Should)

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

If you use multiple monitors with Visual Studio (and honestly, who doesn’t these days), you’ve probably experienced the annoyance: floating tool windows disappear when you minimize the main IDE, they always stay on top of everything else, and they don’t show up as separate taskbar buttons. It works for some workflows, but for multi-monitor setups it’s frustrating.

Mads Kristensen from the Visual Studio team shared a little-known setting that completely changes how floating windows behave. One dropdown. That’s it.

The setting

Tools > Options > Environment > Windows > Floating Windows

The dropdown “These floating windows are owned by the main window” has three options:

None — full independence. Every floating window gets its own taskbar entry and behaves like a normal Windows window.
Tool Windows (default) — documents float freely, tool windows stay tied to the IDE.
Documents and Tool Windows — classic Visual Studio behavior, everything tied to the main window.

Why “None” is the move for multi-monitor setups

Set it to None and suddenly all your floating tool windows and documents behave like real Windows applications. They appear in the taskbar, stay visible when you minimize the main Visual Studio window, and stop forcing themselves to the front of everything.

Combine this with PowerToys FancyZones and it’s a game changer. Create custom layouts across your monitors, snap your Solution Explorer to one zone, debugger to another, and code files wherever you want. Everything stays put, everything is independently accessible, and your workspace feels organized instead of chaotic.

Quick recommendations

Multi-monitor power users: Set to None, pair with FancyZones
Occasional floaters: Tool Windows (default) is a solid middle ground
Traditional workflow: Documents and Tool Windows keeps everything classic

Pro tip: Ctrl + double-click on any tool window title bar to instantly float or dock it. No restart needed after changing the setting.

Wrapping up

It’s one of those “I can’t believe I didn’t know about this” settings. If floating windows in Visual Studio have ever annoyed you, go change this right now.

Read the full post for the details and screenshots.

VS Code 1.116 — Agents App Gets Keyboard Navigation and File Context Completions

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

VS Code 1.116 is the April 2026 release, and while it’s lighter than some recent updates, the changes are focused and meaningful — especially if you’re using the Agents app daily.

Here’s what landed, based on the official release notes.

Agents app improvements

The Agents app continues to mature with usability polish that makes a real difference in daily workflows:

Dedicated keybindings — you can now focus the Changes view, the files tree within Changes, and the Chat Customizations view with dedicated commands and keyboard shortcuts. If you’ve been clicking around the Agents app to navigate, this brings full keyboard-driven workflows.

Accessibility help dialog — pressing Alt+F1 in the chat input box now opens an accessibility help dialog showing available commands and keybindings. Screen reader users can also control announcement verbosity. Good accessibility benefits everyone.

File-context completions — type # in the Agents app chat to trigger file-context completions scoped to your current workspace. This is one of those small quality-of-life improvements that speeds up every interaction — no more typing full file paths when referencing code.

CSS `@import` link resolution

A nice one for frontend developers: VS Code now resolves CSS @import references that use node_modules paths. You can Ctrl+click through imports like @import "some-module/style.css" when using bundlers. Small but eliminates a friction point in CSS workflows.

Wrapping up

VS Code 1.116 is about refinement — making the Agents app more navigable, more accessible, and more keyboard-friendly. If you’re spending significant time in the Agents app (and I suspect many of us are), these changes add up.

Check the full release notes for the complete list.

VS Code 1.115 — Background Terminal Notifications, SSH Agent Mode, and More

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 just dropped, and while it’s a lighter release in terms of headline features, the agent-related improvements are genuinely useful if you’re working with AI coding assistants daily.

Let me highlight what’s actually worth knowing.

Background terminals talk back to agents

This is the standout feature. Background terminals now automatically notify agents when commands complete, including the exit code and terminal output. Input prompts in background terminals are also detected and surfaced to the user.

Why does this matter? If you’ve used Copilot’s agent mode to run build commands or test suites in the background, you know the pain of “did that finish yet?” — background terminals were essentially fire-and-forget. Now the agent gets notified when your dotnet build or dotnet test completes, sees the output, and can react accordingly. It’s a small change that makes agent-driven workflows significantly more reliable.

There’s also a new send_to_terminal tool that lets agents send commands to background terminals with user confirmation, fixing the issue where run_in_terminal with a timeout would move terminals to the background and make them read-only.

SSH remote agent hosting

VS Code now supports connecting to remote machines over SSH, automatically installing the CLI and starting it in agent host mode. This means your AI agent sessions can target remote environments directly — useful for .NET developers who build and test on Linux servers or cloud VMs.

Edit tracking in agent sessions

File edits made during agent sessions are now tracked and restored, with diffs, undo/redo, and state restoration. If an agent makes changes to your code and something goes wrong, you can see exactly what changed and roll it back. Peace of mind for letting agents modify your codebase.

Browser tab awareness and other improvements

A few more quality-of-life additions:

Browser tab tracking — chat can now track and link to browser tabs opened during a session, so agents can reference web pages you’re looking at
File paste in terminal — paste files (including images) into the terminal with Ctrl+V, drag-and-drop, or right-click
Test coverage in minimap — test coverage indicators now show in the minimap for a quick visual overview
Pinch-to-zoom on Mac — integrated browser supports pinch-to-zoom gestures
Copilot entitlements in Sessions — status bar shows usage info in the Sessions view
Favicon in Go to File — open web pages show favicons in the quick pick list

Wrapping up

VS Code 1.115 is an incremental release, but the agent improvements — background terminal notifications, SSH agent hosting, and edit tracking — add up to a noticeably smoother experience for AI-assisted development. If you’re using Copilot’s agent mode for .NET projects, these are the kinds of quality-of-life fixes that reduce friction daily.

Check out the full release notes for every detail.

C# 15 Gets Union Types — and They're Exactly What We've Been Asking For

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

This is the one I’ve been waiting for. C# 15 introduces the union keyword — proper discriminated unions with compiler-enforced exhaustive pattern matching. If you’ve ever envied F#’s discriminated unions or Rust’s enums, you know exactly why this matters.

Bill Wagner published the deep dive on the .NET blog, and honestly? The design is clean, practical, and very C#. Let me walk you through what’s actually here and why it’s a bigger deal than it might seem at first glance.

The problem unions solve

Before C# 15, returning “one of several possible types” from a method was always a compromise:

object — no constraints, no compiler help, defensive casting everywhere
Marker interfaces — better, but anyone can implement them. The compiler can never consider the set complete
Abstract base classes — same issue, plus the types need a common ancestor

None of these give you what you actually want: a closed set of types where the compiler guarantees you’ve handled every case. That’s what union types do.

The syntax is beautifully simple

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

One line. Pet can hold a Cat, a Dog, or a Bird. Implicit conversions are generated automatically:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

And here’s the magic — the compiler enforces exhaustive matching:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

No discard _ needed. The compiler knows this switch covers every possible case. If you later add a fourth type to the union, every switch expression that doesn’t handle it produces a warning. Missing cases caught at build time, not at runtime.

Where this gets practical

The Pet example is cute, but here’s where unions actually shine in real code.

API responses that return different shapes

public union ApiResult<T>(T, ApiError, ValidationFailure);

Now every consumer is forced to handle success, error, and validation failure. No more “I forgot to check the error case” bugs.

Single value or collection

The OneOrMore<T> pattern shows how unions can have a body with helper methods:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Callers pass whichever form is convenient:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Composing unrelated types

This is the killer feature over traditional hierarchies. You can union types that have nothing in common — string and Exception, int and IEnumerable<T>. No common ancestor needed.

Custom unions for existing libraries

Here’s a smart design choice: any class or struct with a [Union] attribute is recognized as a union type, as long as it follows the basic pattern (public constructors for case types and a Value property). Libraries like OneOf that already provide union-like types can opt into compiler support without rewriting their internals.

For performance-sensitive scenarios with value types, libraries can implement a non-boxing access pattern with HasValue and TryGetValue methods.

The bigger picture

Union types are part of a broader exhaustiveness story coming to C#:

Union types — exhaustive matching over a closed set of types (available now in preview)
Closed hierarchies — closed modifier prevents derived classes outside the defining assembly (proposed)
Closed enums — prevents creation of values other than declared members (proposed)

Together, these three features will give C# one of the most comprehensive type-safe pattern matching systems in any mainstream language.

Try it today

Union types are available in .NET 11 Preview 2:

Install the .NET 11 Preview SDK
Target net11.0 in your project
Set <LangVersion>preview</LangVersion>

One caveat: in Preview 2, you’ll need to declare UnionAttribute and IUnion in your project since they’re not in the runtime yet. Grab RuntimePolyfill.cs from the docs repo, or add this:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Wrapping up

Union types are one of those features that make you wonder how we got by without them. Compiler-enforced exhaustive matching, clean syntax, generic support, and integration with existing pattern matching — it’s everything we’ve been asking for, done the C# way.

Try them in .NET 11 Preview 2, break things, and share your feedback on GitHub. This is preview, and the C# team is actively listening. Your edge cases and design feedback will shape the final release.

For the full language reference, check out the union types docs and the feature specification.

Aspire 13.2 Ships a Docs CLI — and Your AI Agent Can Use It Too

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

You know that moment when you’re deep in an Aspire AppHost, wiring up integrations, and you need to check exactly which parameters the Redis integration expects? You alt-tab to your browser, hunt through aspire.dev, squint at the API docs, then come back to your editor. Context lost. Flow broken.

Aspire 13.2 just shipped a fix for that. The aspire docs CLI lets you search, browse, and read official Aspire documentation directly from your terminal. And because it’s backed by reusable services, AI agents and skills can use the same commands to look up docs instead of hallucinating APIs that don’t exist.

The problem this actually solves

David Pine nails it in the original post: AI agents were terrible at helping developers build Aspire apps. They’d recommend dotnet run instead of aspire run, reference learn.microsoft.com for docs that live on aspire.dev, suggest outdated NuGet packages, and — my personal favorite — hallucinate APIs that don’t exist.

Why? Because Aspire was .NET-specific far longer than it’s been polyglot, and LLMs are working off training data that predates the latest features. When you give an AI agent the ability to actually look up the current docs, it stops guessing and starts being useful.

Three commands, zero browser tabs

The CLI is refreshingly simple:

List all docs

aspire docs list

Returns every documentation page available on aspire.dev. Need machine-readable output? Add --format Json.

Search for a topic

aspire docs search "redis"

Searches both titles and content with weighted relevance scoring. Same search engine that powers the documentation tooling internally. You get ranked results with titles, slugs, and relevance scores.

Read a full page (or just one section)

aspire docs get redis-integration

Streams the full page as markdown to your terminal. Need just one section?

aspire docs get redis-integration --section "Add Redis resource"

Surgical precision. No scrolling through 500 lines. Just the part you need.

The AI agent angle

Here’s where it gets interesting for us developers building with AI tooling. The same aspire docs commands work as tools for AI agents — through skills, MCP servers, or simple CLI wrappers.

Instead of your AI assistant making up Aspire APIs based on stale training data, it can call aspire docs search "postgres", find the official integration docs, read the right page, and give you the documented approach. Real-time, current documentation — not what the model memorized six months ago.

The architecture behind this is intentional. The Aspire team built reusable services (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) rather than a one-off integration. That means the same search engine works for humans in the terminal, AI agents in your editor, and automation in your CI pipeline.

Real-world scenarios

Quick terminal lookups: You’re three files deep and need Redis config parameters. Two commands, ninety seconds, back to work:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI-assisted development: Your VS Code skill wraps the CLI commands. You ask “Add a PostgreSQL database to my AppHost” and the agent looks up the real docs before answering. No hallucinations.

CI/CD validation: Your pipeline validates AppHost configurations against official documentation programmatically. --format Json output pipes cleanly to jq and other tools.

Custom knowledge bases: Building your own AI tooling? Pipe structured JSON output directly into your knowledge base:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

No web scraping. No API keys. Same structured data the docs tooling uses internally.

The documentation is always live

This is the part I appreciate most. The CLI doesn’t download a snapshot — it queries aspire.dev with ETag-based caching. The moment the docs update, your CLI and any skill built on top of it reflects that. No stale copies, no “but the wiki said…” moments.

Wrapping up

aspire docs is one of those small features that solves a real problem cleanly. Humans get terminal-native documentation access. AI agents get a way to stop guessing and start referencing actual docs. And it’s all backed by the same source of truth.

If you’re building with .NET Aspire and haven’t tried the CLI yet, run aspire docs search "your-topic-here" and see how it feels. Then consider wrapping those commands into whatever AI skill or automation setup you’re using — your agents will thank you.

Check out David Pine’s deep dive on how the docs tooling came together, and the official CLI reference for all the details.

Microsoft Agent Framework Hits 1.0 — Here's What Actually Matters for .NET Developers

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

If you’ve been following the Agent Framework journey from the early Semantic Kernel and AutoGen days, this one is significant. Microsoft Agent Framework just hit version 1.0 — production-ready, stable APIs, long-term support commitment. It’s available for both .NET and Python, and it’s genuinely ready for real workloads.

Let me cut through the announcement noise and focus on what matters if you’re building AI-powered apps with .NET.

The short version

Agent Framework 1.0 unifies what used to be Semantic Kernel and AutoGen into a single, open-source SDK. One agent abstraction. One orchestration engine. Multiple AI providers. If you’ve been bouncing between Semantic Kernel for enterprise patterns and AutoGen for research-grade multi-agent workflows, you can stop. This is the one SDK now.

Getting started is almost unfairly simple

Here’s a working agent in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

That’s it. A handful of lines and you have an AI agent running against Azure Foundry. The Python equivalent is equally concise. Add function tools, multi-turn conversations, and streaming as you go — the API surface scales up without getting weird.

Multi-agent orchestration — this is the real deal

Single agents are fine for demos, but production scenarios usually need coordination. Agent Framework 1.0 ships with battle-tested orchestration patterns straight from Microsoft Research and AutoGen:

Sequential — agents process in order (writer → reviewer → editor)
Concurrent — fan out to multiple agents in parallel, converge results
Handoff — one agent delegates to another based on intent
Group chat — multiple agents discuss and converge on a solution
Magentic-One — the research-grade multi-agent pattern from MSR

All of them support streaming, checkpointing, human-in-the-loop approvals, and pause/resume. The checkpointing part is crucial — long-running workflows survive process restarts. For us .NET developers who’ve built durable workflows with Azure Functions, this feels familiar.

The features that matter most

Here’s my shortlist of what’s worth knowing:

Middleware hooks. You know how ASP.NET Core has middleware pipelines? Same concept, but for agent execution. Intercept every stage — add content safety, logging, compliance policies — without touching agent prompts. This is how you make agents enterprise-ready.

Pluggable memory. Conversational history, persistent key-value state, vector-based retrieval. Choose your backend: Foundry Agent Service, Mem0, Redis, Neo4j, or roll your own. Memory is what turns a stateless LLM call into an agent that actually remembers context.

Declarative YAML agents. Define your agent’s instructions, tools, memory, and orchestration topology in version-controlled YAML files. Load and run with a single API call. This is a game-changer for teams that want to iterate on agent behavior without redeploying code.

A2A and MCP support. MCP (Model Context Protocol) lets agents discover and invoke external tools dynamically. A2A (Agent-to-Agent protocol) enables cross-runtime collaboration — your .NET agents can coordinate with agents running in other frameworks. A2A 1.0 support is coming soon.

The preview features worth watching

Some features shipped as preview in 1.0 — functional but APIs may evolve:

DevUI — a browser-based local debugger for visualizing agent execution, message flows, and tool calls in real time. Think Application Insights, but for agent reasoning.
GitHub Copilot SDK and Claude Code SDK — use Copilot or Claude as an agent harness directly from your orchestration code. Compose a coding-capable agent alongside your other agents in the same workflow.
Agent Harness — a customizable local runtime giving agents access to shell, file system, and messaging loops. Think coding agents and automation patterns.
Skills — reusable domain capability packages that give agents structured capabilities out of the box.

Migrating from Semantic Kernel or AutoGen

If you have existing Semantic Kernel or AutoGen code, there are dedicated migration assistants that analyze your code and generate step-by-step migration plans. The Semantic Kernel migration guide and AutoGen migration guide walk you through everything.

If you’ve been on the RC packages, upgrading to 1.0 is just a version bump.

Wrapping up

Agent Framework 1.0 is the production milestone that enterprise teams have been waiting for. Stable APIs, multi-provider support, orchestration patterns that actually work at scale, and migration paths from both Semantic Kernel and AutoGen.

The framework is fully open source on GitHub, and you can get started today with dotnet add package Microsoft.Agents.AI. Check out the quickstart guide and the samples to get your hands dirty.

If you’ve been waiting for the “safe to use in production” signal — this is it.

Aspire 13.2's Dashboard Just Got a Telemetry API — and It Changes Everything

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

If you’ve been building distributed apps with .NET Aspire, you already know the dashboard is the single best thing about the whole experience. All your traces, logs, and metrics in one place — no external Jaeger, no Seq setup, no “let me check the other terminal” moments.

Aspire 13.2 just made it significantly better. James Newton-King announced the update, and honestly? The telemetry export and API features alone are worth the upgrade.

Export telemetry like a sane person

Here’s the scenario we’ve all lived through: you’re debugging a distributed issue, you finally reproduce it after twenty minutes of setup, and now you need to share what happened with your team. Before? Screenshots. Copy-pasting trace IDs. The usual mess.

Aspire 13.2 adds a proper Manage logs and telemetry dialog where you can:

Clear all telemetry (useful before a repro attempt)
Export selected telemetry to a ZIP file in standard OTLP/JSON format
Re-import that ZIP into any Aspire dashboard later

That last part is the killer feature. You reproduce a bug, export the telemetry, attach it to your work item, and your teammate can import it into their own dashboard to see exactly what you saw. No more “can you reproduce it on your machine?”

Individual traces, spans, and logs also get an “Export JSON” option in their context menus. Need to share one specific trace? Right-click, copy JSON, paste into your PR description. Done.

The telemetry API is the real game changer

This is what I’m most excited about. The dashboard now exposes an HTTP API under /api/telemetry for querying telemetry data programmatically. Available endpoints:

GET /api/telemetry/resources — list resources with telemetry
GET /api/telemetry/spans — query spans with filters
GET /api/telemetry/logs — query logs with filters
GET /api/telemetry/traces — list traces
GET /api/telemetry/traces/{traceId} — get all spans for a specific trace

Everything comes back in OTLP JSON format. This powers the new aspire agent mcp and aspire otel CLI commands, but the real implication is bigger: you can now build tooling, scripts, and AI agent integrations that query your app’s telemetry directly.

Imagine an AI coding agent that can look at your actual distributed traces while debugging. That’s not hypothetical anymore — that’s what this API enables.

GenAI telemetry gets practical

If you’re building AI-powered apps with Semantic Kernel or Microsoft.Extensions.AI, you’ll appreciate the improved GenAI telemetry visualizer. Aspire 13.2 adds:

AI tool descriptions rendered as Markdown
A dedicated GenAI button on the traces page for quick AI trace access
Better error handling for truncated or non-standard GenAI JSON
Click-to-highlight navigation between tool definitions

The blog post mentions that VS Code Copilot chat, Copilot CLI, and OpenCode all support configuring an OTEL_EXPORTER_OTLP_ENDPOINT. Point them at the Aspire dashboard and you can literally watch your AI agents think in real time through telemetry. That’s a debugging experience you won’t find anywhere else.

Wrapping up

Aspire 13.2 takes the dashboard from “nice debugging UI” to “programmable observability platform.” The export/import workflow alone saves real time on distributed debugging, and the telemetry API opens the door to AI-assisted diagnostics.

If you’re already on Aspire, upgrade. If you’re not — this is a good reason to check out aspire.dev and see what the fuss is about.

azd Now Lets You Run and Debug AI Agents Locally — Here's What Changed in March 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Seven releases in one month. That’s what the Azure Developer CLI (azd) team pushed in March 2026, and the headline feature is the one I’ve been waiting for: a local run-and-debug loop for AI agents.

PC Chan published the full roundup, and while there’s a lot in there, let me filter it down to what actually matters for .NET developers building AI-powered apps.

Run and debug AI agents without deploying

This is the big one. The new azure.ai.agents extension adds a set of commands that give you a proper inner-loop experience for AI agents:

azd ai agent run — starts your agent locally
azd ai agent invoke — sends messages to it (local or deployed)
azd ai agent show — displays container status and health
azd ai agent monitor — streams container logs in real time

Before this, testing an AI agent meant deploying to Microsoft Foundry every time you made a change. Now you can iterate locally, test your agent’s behavior, and only deploy when you’re ready. If you’ve been building agents with the Microsoft Agent Framework or Semantic Kernel, this changes your daily workflow.

The invoke command works against both local and deployed agents, which means you can use the same testing workflow regardless of where the agent is running. That’s the kind of detail that saves you from maintaining two sets of test scripts.

GitHub Copilot scaffolds your azd project

azd init now offers a “Set up with GitHub Copilot (Preview)” option. Instead of manually answering prompts about your project structure, a Copilot agent scaffolds the configuration for you. It checks for a dirty working directory before modifying anything and asks for MCP server tool consent upfront.

When a command fails, azd now offers AI-assisted troubleshooting: pick a category (explain, guidance, troubleshoot, or skip), let the agent suggest a fix, and retry — all without leaving the terminal. For complex infrastructure setups, that’s a real time saver.

Container App Jobs and deployment improvements

A few deployment features worth noting:

Container App Jobs: azd now deploys Microsoft.App/jobs through the existing host: containerapp config. Your Bicep template determines whether the target is a Container App or a Job — no extra setup.
Configurable deployment timeouts: New --timeout flag on azd deploy and a deployTimeout field in azure.yaml. No more guessing the default 1200-second limit.
Remote build fallback: When remote ACR build fails, azd falls back to local Docker/Podman build automatically.
Local preflight validation: Bicep parameters get validated locally before deploying, catching missing params without a round-trip to Azure.

Developer experience polish

Some smaller improvements that add up:

Automatic pnpm/yarn detection for JS/TS projects
pyproject.toml support for Python packaging
Local template directories — azd init --template now accepts filesystem paths for offline iteration
Better error messages in --no-prompt mode — all missing values reported at once with resolution commands
Build environment variables injected into all framework build subprocesses (.NET, Node.js, Java, Python)

That last one is subtle but important: your .NET build now has access to azd environment variables, which means you can do build-time configuration injection without extra scripting.

Wrapping up

The local AI agent debugging loop is the star of this release, but the accumulation of deployment improvements and DX polish makes azd feel more mature than ever. If you’re deploying .NET apps to Azure — especially AI agents — this update is worth the install.

Check the full release notes for every detail, or get started with azd install.

Azure DevOps Finally Fixes the Markdown Editor UX Everyone Complained About

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

If you use Azure Boards, you’ve probably experienced this: you’re reading through a work item description, maybe reviewing acceptance criteria, and you accidentally double-click. Boom — you’re in edit mode. You didn’t want to edit anything. You were just reading.

Dan Hellem announced the fix, and it’s one of those changes that sounds tiny but actually removes real friction from your daily workflow.

What changed

The Markdown editor for work item text fields now opens in preview mode by default. You can read and interact with the content — follow links, review formatting — without worrying about accidentally entering edit mode.

When you actually want to edit, you click the edit icon at the top of the field. When you’re done, you exit back to preview mode explicitly. Simple, intentional, predictable.

That’s it. That’s the change.

Why this matters more than it sounds

The community feedback thread on this was long. The double-click-to-edit behavior was introduced with the Markdown editor back in July 2025, and the complaints started almost immediately. The problem wasn’t just accidental edits — it was that the whole interaction felt unpredictable. You never knew if clicking would read or edit.

For teams that do sprint planning, backlog grooming, or code review with Azure Boards, this kind of micro-friction compounds. Every accidental edit mode entry is a context switch. Every “wait, did I change something?” moment is wasted attention.

The new default respects the most common interaction pattern: you read work items far more often than you edit them.

Rollout status

This is already rolling out to a subset of customers and expanding to everyone over the next two to three weeks. If you’re not seeing it yet, you will soon.

Wrapping up

Not every improvement needs to be a headline feature. Sometimes the best update is just removing something annoying. This is one of those — a small UX fix that makes Azure Boards feel less hostile to people who just want to read their work items in peace.

Bookmark Studio Brings Slot-Based Navigation and Sharing to Visual Studio Bookmarks

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Bookmarks in Visual Studio have always been… fine. You set one, you navigate to the next, you forget which bookmark is which. They work, but they’ve never been the kind of feature you’d call powerful.

Mads Kristensen just released Bookmark Studio, an experimental extension that fills in exactly the gaps you’ve probably run into if you use bookmarks regularly.

The core addition: bookmarks can now be assigned to slots 1–9 and jumped to directly with Alt+Shift+1 through Alt+Shift+9. New bookmarks automatically get the next available slot, so in most cases, fast navigation works without any setup.

This sounds simple, but it changes bookmarks from “I have some bookmarks somewhere” to “Slot 3 is my API controller, Slot 5 is the service layer, Slot 7 is the test.” That kind of spatial memory makes navigation nearly instant during focused work sessions.

The Bookmark Manager

A new tool window shows all your bookmarks in one place with filtering by name, file, location, color, or slot. Double-click or keyboard-navigate to jump to any bookmark.

If you’ve ever had more than five or six bookmarks and lost track of which was which, this alone is worth installing the extension.

Organization with labels, colors, and folders

Bookmarks can optionally have labels, colors, and be grouped into folders. None of it is required — your current bookmark workflow keeps working. But when you’re debugging a complex issue or exploring an unfamiliar codebase, being able to color-code and label your bookmarks adds useful context.

All metadata is stored per solution, so your bookmark organization persists across sessions.

This is the feature I didn’t know I wanted. Bookmark Studio lets you export bookmarks as plain text, Markdown, or CSV. That means you can:

Include bookmark paths in pull request descriptions
Share investigation breadcrumbs with teammates
Move bookmark sets between repos or branches

Bookmarks stop being a solo navigation tool and start being a way to communicate “here’s the path through this code.”

Bookmarks that track code movement

Bookmark Studio tracks bookmarks relative to the text they’re anchored to, so they don’t drift to wrong lines as you edit. If you’ve ever set bookmarks during a debugging session and had them all point to the wrong lines after a refactor — this fixes that.

Wrapping up

Bookmark Studio doesn’t reinvent anything. It takes a feature that’s been “good enough” for years and makes it genuinely useful for focused development. Slot navigation, the Bookmark Manager, and export capabilities are the highlights.

Grab it from the Visual Studio Marketplace and give it a try.

Visual Studio's March Update Lets You Build Custom Copilot Agents — and the find_symbol Tool Is a Big Deal

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio just got its most significant Copilot update yet. Mark Downie announced the March release, and the headline is custom agents — but honestly, the find_symbol tool buried further down might be the feature that changes your workflow the most.

Let me break down what’s actually here.

Custom Copilot agents in your repo

Want Copilot to follow your team’s coding standards, run your build pipeline, or query your internal docs? Now you can build exactly that.

Custom agents are defined as .agent.md files that you drop into .github/agents/ in your repository. Each agent gets full access to workspace awareness, code understanding, tools, your preferred model, and MCP connections to external services. They show up in the agent picker alongside the built-in agents.

This is the same pattern VS Code has been supporting — and it’s great to see Visual Studio catch up. For teams that have already built agents for VS Code, your .agent.md files should work across both IDEs (though tool names can vary, so test them).

The awesome-copilot repo has community-contributed agent configurations you can use as starting points.

Agent skills: reusable instruction packs

Skills are automatically picked up from .github/skills/ in your repo or ~/.copilot/skills/ in your profile. Each skill is a SKILL.md file following the Agent Skills specification.

Think of skills as modular expertise you can mix and match. You might have a skill for your API conventions, another for your testing patterns, and another for your deployment workflow. When a skill activates, it shows up in the chat so you know it’s being applied.

If you’ve been using skills in VS Code, they work the same way in Visual Studio now.

This is where things get really interesting. The new find_symbol tool gives Copilot’s agent mode actual language-service-powered symbol navigation. Instead of searching your code as text, the agent can:

Find all references to a symbol across your project
Access type information, declarations, and scope metadata
Navigate call sites with full language awareness

What this means in practice: when you ask Copilot to refactor a method or update a parameter signature across call sites, it can actually see your code’s structure. No more “the agent changed the method but missed three call sites” situations.

Supported languages include C#, C++, Razor, TypeScript, and anything with a supported LSP extension. For .NET developers, this is a massive improvement — C# codebases with deep type hierarchies and interfaces benefit enormously from symbol-aware navigation.

Profile tests with Copilot

There’s now a Profile with Copilot command in the Test Explorer context menu. Select a test, click profile, and the Profiling Agent automatically runs it and analyzes performance — combining CPU usage and instrumentation data to deliver actionable insights.

No more manually configuring profiler sessions, running the test, exporting results, and trying to read a flame graph. The agent does the analysis and tells you what’s slow and why. Currently .NET only, which makes sense given Visual Studio’s deep .NET diagnostics integration.

Perf tips during live debugging

Performance optimization now happens while you debug, not after. As you step through code, Visual Studio shows execution time and performance signals inline. See a slow line? Click the Perf Tip and ask Copilot for optimization suggestions right there.

The Profiling Agent captures runtime data automatically — elapsed time, CPU usage, memory behavior — and Copilot uses it to pinpoint hot spots. This keeps performance work as part of your debugging flow instead of a separate task you keep postponing.

Fix NuGet vulnerabilities from Solution Explorer

When a vulnerability is detected in a NuGet package, you now see a notification with a Fix with GitHub Copilot link directly in Solution Explorer. Click through and Copilot analyzes the vulnerability, recommends the right package updates, and implements them.

For teams that struggle to keep dependencies up to date (which is basically everyone), this removes the friction of “I know there’s a vulnerability but figuring out the right update path is a project in itself.”

Wrapping up

Custom agents and skills are the headline, but find_symbol is the sleeper hit — it fundamentally changes how accurate Copilot can be when refactoring .NET code. Combined with live profiling integration and vulnerability fixes, this update makes Visual Studio’s AI features feel genuinely practical rather than demo-ready.

Download Visual Studio 2026 Insiders to try it all out.

KubeCon Europe 2026: What .NET Developers Should Actually Care About

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

You know that feeling when a massive announcement post drops and you’re scrolling through it thinking “cool, but what does this actually change for me”? That’s me every KubeCon season.

Microsoft just published their full KubeCon Europe 2026 roundup — written by Brendan Burns himself — and honestly? There’s real substance here. Not just feature checkboxes, but the kind of operational improvements that change how you run things in production.

Let me break down what actually matters for us .NET developers.

mTLS without the service mesh tax

Here’s the thing about service meshes: everyone wants the security guarantees, nobody wants the operational overhead. AKS is finally closing that gap.

Azure Kubernetes Application Network gives you mutual TLS, application-aware authorization, and traffic telemetry — without deploying a full sidecar-heavy mesh. Combined with Cilium mTLS in Advanced Container Networking Services, you get encrypted pod-to-pod communication using X.509 certificates and SPIRE for identity management.

What this means in practice: your ASP.NET Core APIs talking to background workers, your gRPC services calling each other — all encrypted and identity-verified at the network level, with zero application code changes. That’s huge.

For teams migrating off ingress-nginx, there’s also Application Routing with Meshless Istio with full Kubernetes Gateway API support. No sidecars. Standards-based. And they shipped ingress2gateway tooling for incremental migration.

GPU observability that’s not an afterthought

If you’re running AI inference alongside your .NET services (and let’s be honest, who isn’t starting to?), you’ve probably hit the GPU monitoring blind spot. You’d get great CPU/memory dashboards and then… nothing for GPUs without manual exporter plumbing.

AKS now surfaces GPU metrics natively into managed Prometheus and Grafana. Same stack, same dashboards, same alerting pipeline. No custom exporters, no third-party agents.

On the network side, they added per-flow visibility for HTTP, gRPC, and Kafka traffic with a one-click Azure Monitor experience. IPs, ports, workloads, flow direction, policy decisions — all in built-in dashboards.

And here’s the one that made me do a double-take: agentic container networking adds a web UI where you can ask natural-language questions about your cluster’s network state. “Why is pod X not reaching service Y?” → read-only diagnostics from live telemetry. That’s genuinely useful at 2 AM.

Cross-cluster networking that doesn’t require a PhD

Multi-cluster Kubernetes has historically been a “bring your own networking glue” experience. Azure Kubernetes Fleet Manager now ships cross-cluster networking through managed Cilium cluster mesh:

Unified connectivity across AKS clusters
Global service registry for cross-cluster discovery
Configuration managed centrally, not repeated per cluster

If you’re running .NET microservices across regions for resilience or compliance, this replaces a lot of fragile custom plumbing. Service A in West Europe can discover and call Service B in East US through the mesh, with consistent routing and security policies.

Upgrades that don’t require courage

Let’s be honest — Kubernetes upgrades in production are stressful. “Upgrade and hope” has been the de facto strategy for too many teams, and it’s the main reason clusters fall behind on versions.

Two new capabilities change this:

Blue-green agent pool upgrades create a parallel node pool with the new configuration. Validate behavior, shift traffic gradually, and keep a clean rollback path. No more in-place mutations on production nodes.

Agent pool rollback lets you revert a node pool to its previous Kubernetes version and node image after an upgrade goes sideways — without rebuilding the cluster.

Together, these finally give operators real control over the upgrade lifecycle. For .NET teams, this matters because platform velocity directly controls how fast you can adopt new runtimes, security patches, and networking capabilities.

AI workloads are becoming first-class Kubernetes citizens

The upstream open-source work is equally important. Dynamic Resource Allocation (DRA) just went GA in Kubernetes 1.36, making GPU scheduling a proper first-class feature instead of a workaround.

A few projects worth watching:

Project	What it does
AI Runway	Common Kubernetes API for inference — deploy models without knowing K8s, with HuggingFace discovery and cost estimates
HolmesGPT	Agentic troubleshooting for cloud-native — now a CNCF Sandbox project
Dalec	Declarative container image builds with SBOM generation — fewer CVEs at the build stage

The direction is clear: your .NET API, your Semantic Kernel orchestration layer, and your inference workloads should all run on one consistent platform model. We’re getting there.

Where I’d start this week

If you’re evaluating these changes for your team, here’s my honest priority list:

Observability first — enable GPU metrics and network flow logs in a non-prod cluster. See what you’ve been missing.
Try blue-green upgrades — test the rollback workflow before your next production cluster upgrade. Build confidence in the process.
Pilot identity-aware networking — pick one internal service path and enable mTLS with Cilium. Measure the overhead (spoiler: it’s minimal).
Evaluate Fleet Manager — if you run more than two clusters, cross-cluster networking pays for itself in reduced custom glue.

Small experiments, fast feedback. That’s always the move.

Wrapping up

KubeCon announcements can be overwhelming, but this batch genuinely moves the needle for .NET teams on AKS. Better networking security without mesh overhead, real GPU observability, safer upgrades, and stronger AI infrastructure foundations.

If you’re already on AKS, this is a great moment to tighten your operational baseline. And if you’re planning to move .NET workloads to Kubernetes — the platform just got significantly more production-ready.

SQL MCP Server, Copilot in SSMS, and a Database Hub with AI Agents: What Actually Matters from SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft just kicked off SQLCon 2026 alongside FabCon in Atlanta, and there’s a lot to unpack. The original announcement covers everything from savings plans to enterprise compliance features. I’m going to skip the enterprise pricing slides and focus on the pieces that matter if you’re a developer building things with Azure SQL and AI.

SQL MCP Server is in public preview

This is the headline for me. Azure SQL Database Hyperscale now has a SQL MCP Server in public preview that lets you securely connect your SQL data to AI agents and Copilots using the Model Context Protocol.

If you’ve been following the MCP wave — and honestly, it’s hard to miss right now — this is a big deal. Instead of building custom data pipelines to feed your AI agents context from your database, you get a standardized protocol to expose SQL data directly. Your agents can query, reason over, and act on live database information.

For those of us building AI agents with Semantic Kernel or the Microsoft Agent Framework, this opens up a clean integration path. Your agent needs to check inventory? Look up a customer record? Validate an order? MCP gives it a structured way to do that without you writing bespoke data-fetching code for every scenario.

GitHub Copilot in SSMS 22 is now GA

If you spend any time in SQL Server Management Studio — and let’s be honest, most of us still do — GitHub Copilot is now generally available in SSMS 22. Same Copilot experience you already use in VS Code and Visual Studio, but for T-SQL.

The practical value here is straightforward: chat-based assistance for writing queries, refactoring stored procedures, troubleshooting performance issues, and handling admin tasks. Nothing revolutionary in concept, but having it right there in SSMS means you don’t need to context-switch to another editor just to get AI help with your database work.

Vector indexes got a serious upgrade

Azure SQL Database now has faster, more capable vector indexes with full insert, update, and delete support. That means your vector data stays current in real time — no batch reindexing needed.

Here’s what’s new:

Quantization for smaller index sizes without losing too much accuracy
Iterative filtering for more precise results
Tighter query optimizer integration for predictable performance

If you’re doing retrieval-augmented generation (RAG) with Azure SQL as your vector store, these improvements are directly useful. You can keep your vectors alongside your relational data in the same database, which simplifies your architecture significantly compared to running a separate vector database.

The same vector enhancements are also available in SQL database in Fabric, since both run on the same SQL engine underneath.

Database Hub in Fabric: agentic management

This one is more forward-looking, but it’s interesting. Microsoft announced the Database Hub in Microsoft Fabric (early access), which gives you a single pane of glass across Azure SQL, Cosmos DB, PostgreSQL, MySQL, and SQL Server via Arc.

The interesting angle isn’t just the unified view — it’s the agentic approach to management. AI agents continuously monitor your database estate, surface what changed, explain why it matters, and suggest what to do next. It’s a human-in-the-loop model where the agent does the legwork and you make the calls.

For teams managing more than a handful of databases, this could genuinely reduce the operational noise. Instead of jumping between portals and manually checking metrics, the agent brings the signal to you.

What this means for .NET developers

The thread connecting all these announcements is clear: Microsoft is embedding AI agents at every layer of the database stack. Not as a gimmick, but as a practical tooling layer.

If you’re building .NET apps backed by Azure SQL, here’s what I’d actually do:

Try the SQL MCP Server if you’re building AI agents. It’s the cleanest way to give your agents database access without custom plumbing.
Enable Copilot in SSMS if you haven’t already — free productivity win for daily SQL work.
Look into vector indexes if you’re doing RAG and currently running a separate vector store. Consolidating to Azure SQL means one less service to manage.

Wrapping up

The full announcement has more — savings plans, migration assistants, compliance features — but the developer story is in the MCP Server, the vector improvements, and the agentic management layer. These are the pieces that change how you build, not just how you budget.

Check out the full announcement from Shireesh Thota for the complete picture, and sign up for the Database Hub early access if you want to try the new management experience.

Azure DevOps MCP Server Lands in Microsoft Foundry: What This Means for Your AI Agents

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) has been having a moment. If you’ve been following the AI agent ecosystem, you’ve probably noticed MCP servers popping up everywhere — giving agents the ability to interact with external tools and services through a standardized protocol.

Now the Azure DevOps MCP Server is available in Microsoft Foundry, and this is one of those integrations that makes you think about the practical possibilities.

What’s actually happening here

Microsoft already released the Azure DevOps MCP Server as a public preview — that’s the MCP server itself. What’s new is the Foundry integration. You can now add the Azure DevOps MCP Server to your Foundry agents directly from the tool catalog.

For those not familiar with Foundry yet: it’s Microsoft’s unified platform for building and managing AI-powered applications and agents at scale. Model access, orchestration, evaluation, deployment — all in one place.

Setting it up

The setup is surprisingly straightforward:

In your Foundry agent, go to Add Tools > Catalog
Search for “Azure DevOps”
Select the Azure DevOps MCP Server (preview) and click Create
Enter your organization name and connect

That’s it. Your agent now has access to Azure DevOps tools.

Controlling what your agent can access

Here’s the part I appreciate: you’re not stuck with an all-or-nothing approach. You can specify which tools are available to your agent. So if you only want it to read work items but not touch pipelines, you can configure that. Principle of least privilege, applied to your AI agents.

This matters for enterprise scenarios where you don’t want an agent accidentally triggering a deployment pipeline because someone asked it to “help with the release.”

Why this is interesting for .NET teams

Think about what this enables in practice:

Sprint planning assistants — agents that can pull work items, analyze velocity data, and suggest sprint capacity
Code review bots — agents that understand your PR context because they can actually read your repos and linked work items
Incident response — agents that can create work items, query recent deployments, and correlate bugs with recent changes
Developer onboarding — “What should I work on?” gets a real answer backed by actual project data

For .NET teams already using Azure DevOps for their CI/CD pipelines and project management, having an AI agent that can actually interact with those systems directly is a significant step toward useful automation (not just chatbot-as-a-service).

The bigger MCP picture

This is part of a broader trend: MCP servers are becoming the standard way AI agents interact with the outside world. We’re seeing them for GitHub, Azure DevOps, databases, SaaS APIs — and Foundry is becoming the hub where these connections all come together.

If you’re building agents in the .NET ecosystem, MCP is worth paying attention to. The protocol is standardized, the tooling is maturing, and the Foundry integration makes it accessible without having to manually wire up server connections.

Wrapping up

The Azure DevOps MCP Server in Foundry is in preview, so expect it to evolve. But the core workflow is solid: connect, configure tool access, and let your agents work with your DevOps data. If you’re already in the Foundry ecosystem, this is a few clicks away. Give it a try and see what workflows you can build.

Check out the full announcement for the step-by-step setup and more details.

Background Responses in Microsoft Agent Framework: No More Timeout Anxiety

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

If you’ve built anything with reasoning models like o3 or GPT-5.2, you know the pain. Your agent starts thinking through a complex task, the client sits there waiting, and somewhere between “this is fine” and “did it crash?” your connection times out. All that work? Gone.

Microsoft Agent Framework just shipped background responses — and honestly, this is one of those features that should’ve existed from day one.

The problem with blocking calls

In a traditional request-response pattern, your client blocks until the agent finishes. That works fine for quick tasks. But when you’re asking a reasoning model to do deep research, multi-step analysis, or generate a 20-page report? You’re looking at minutes of wall-clock time. During that window:

HTTP connections can time out
Network blips kill the entire operation
Your user stares at a spinner wondering if anything is happening

Background responses flip this on its head.

How continuation tokens work

Instead of blocking, you kick off the agent task and get back a continuation token. Think of it like a claim ticket at a repair shop — you don’t stand at the counter waiting, you come back when it’s ready.

The flow is straightforward:

Send your request with AllowBackgroundResponses = true
If the agent supports background processing, you get a continuation token
Poll on your schedule until the token comes back null — that means the result is ready

Here’s the .NET version:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

If the agent completes immediately (simple tasks, models that don’t need background processing), no continuation token is returned. Your code just works — no special handling needed.

Streaming with resume: the real magic

Polling is fine for fire-and-forget scenarios, but what about when you want real-time progress? Background responses also support streaming with built-in resumption.

Each streamed update carries its own continuation token. If your connection drops mid-stream, you pick up exactly where you left off:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

The agent keeps processing server-side regardless of what’s happening with your client. That’s built-in fault tolerance without you writing retry logic or circuit breakers.

When to actually use this

Not every agent call needs background responses. For quick completions, you’re adding complexity for no reason. But here’s where they shine:

Complex reasoning tasks — multi-step analysis, deep research, anything that makes a reasoning model actually think
Long content generation — detailed reports, multi-part documents, extensive analysis
Unreliable networks — mobile clients, edge deployments, flaky corporate VPNs
Async UX patterns — submit a task, go do something else, come back for results

For us .NET developers building enterprise apps, that last one is particularly interesting. Think about a Blazor app where a user requests a complex report — you fire off the agent task, show them a progress indicator, and let them keep working. No WebSocket gymnastics, no custom queue infrastructure, just a token and a poll loop.

Wrapping up

Background responses are available now in both .NET and Python through Microsoft Agent Framework. If you’re building agents that do anything more complex than simple Q&A, this is worth adding to your toolkit. The continuation token pattern keeps things simple while solving a very real production problem.

Check out the full documentation for the complete API reference and more examples.

Foundry Agent Service is GA: What Actually Matters for .NET Agent Builders

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Let’s be honest — building an AI agent prototype is the easy part. The hard part is everything after: getting it into production with proper network isolation, running evaluations that actually mean something, handling compliance requirements, and not breaking things at 2 AM.

The Foundry Agent Service just went GA, and this release is laser-focused on that “everything after” gap.

Built on the Responses API

Here’s the headline: the next-gen Foundry Agent Service is built on the OpenAI Responses API. If you’re already building with that wire protocol, migrating to Foundry is minimal code changes. What you gain: enterprise security, private networking, Entra RBAC, full tracing, and evaluation — on top of your existing agent logic.

The architecture is intentionally open. You’re not locked to one model provider or one orchestration framework. Use DeepSeek for planning, OpenAI for generation, LangGraph for orchestration — the runtime handles the consistency layer.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

If you’re coming from the azure-ai-agents package, agents are now first-class operations on AIProjectClient in azure-ai-projects. Drop the standalone pin and use get_openai_client() to drive responses.

Private networking: the enterprise blocker removed

This is the feature that unblocks enterprise adoption. Foundry now supports full end-to-end private networking with BYO VNet:

No public egress — agent traffic never touches the public internet
Container/subnet injection into your network for local communication
Tool connectivity included — MCP servers, Azure AI Search, Fabric data agents all operate over private paths

That last point is critical. It’s not just inference calls that stay private — every tool invocation and retrieval call stays inside your network boundary too. For teams operating under data classification policies that prohibit external routing, this is what was missing.

MCP authentication done right

MCP server connections now support the full spectrum of auth patterns:

Auth method	When to use
Key-based	Simple shared access for org-wide internal tools
Entra Agent Identity	Service-to-service; the agent authenticates as itself
Entra Managed Identity	Per-project isolation; no credential management
OAuth Identity Passthrough	User-delegated access; agent acts on behalf of users

OAuth Identity Passthrough is the interesting one. When users need to grant an agent access to their personal data — their OneDrive, their Salesforce org, a SaaS API scoped by user — the agent acts on their behalf with standard OAuth flows. No shared system identity pretending to be everyone.

Voice Live: speech-to-speech without the plumbing

Adding voice to an agent used to mean stitching together STT, LLM, and TTS — three services, three latency hops, three billing surfaces, all synchronized by hand. Voice Live collapses that into a single managed API with:

Semantic voice activity and end-of-turn detection (understands meaning, not just silence)
Server-side noise suppression and echo cancellation
Barge-in support (users can interrupt mid-response)

Voice interactions go through the same agent runtime as text. Same evaluators, same traces, same cost visibility. For customer support, field service, or accessibility scenarios, this replaces what previously required a custom audio pipeline.

Evaluations: from checkbox to continuous monitoring

This is where Foundry gets serious about production quality. The evaluation system now has three layers:

Out-of-the-box evaluators — coherence, relevance, groundedness, retrieval quality, safety. Connect to a dataset or live traffic and get scores back.
Custom evaluators — encode your own business logic, tone standards, and domain-specific compliance rules.
Continuous evaluation — Foundry samples live production traffic, runs your evaluator suite, and surfaces results through dashboards. Set Azure Monitor alerts for when groundedness drops or safety thresholds breach.

Everything publishes to Azure Monitor Application Insights. Agent quality, infrastructure health, cost, and app telemetry — all in one place.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Six new regions for hosted agents

Hosted agents are now available in East US, North Central US, Sweden Central, Southeast Asia, Japan East, and more. This matters for data residency requirements and for compressing latency when your agent runs close to its data sources.

Why this matters for .NET developers

Even though the code samples in the GA announcement are Python-first, the underlying infrastructure is language-agnostic — and the .NET SDK for azure-ai-projects follows the same patterns. The Responses API, the evaluation framework, the private networking, the MCP auth — all of this is available from .NET.

If you’ve been waiting for AI agents to go from “cool demo” to “I can actually ship this at work,” this GA release is the signal. Private networking, proper auth, continuous evaluation, and production monitoring are the pieces that were missing.

Wrapping up

Foundry Agent Service is available now. Install the SDK, open the portal, and start building. The quickstart guide takes you from zero to a running agent in minutes.

For the full technical deep-dive with all code samples, check the GA announcement.

From Laptop to Production: Deploying AI Agents to Microsoft Foundry with Two Commands

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

You know that gap between “it works on my machine” and “it’s deployed and serving traffic”? For AI agents, that gap has been painfully wide. You need to provision resources, deploy models, wire up identity, set up monitoring — and that’s before anyone can actually call your agent.

The Azure Developer CLI just made this a two-command affair.

The new `azd ai agent` workflow

Let me walk through what this actually looks like. You have an AI agent project — let’s say a hotel concierge agent. It works locally. You want it running on Microsoft Foundry.

azd ai agent init
azd up

That’s it. Two commands. azd ai agent init scaffolds the infrastructure-as-code in your repo, and azd up provisions everything on Azure and publishes your agent. You get a direct link to your agent in the Foundry portal.

What happens under the hood

The init command generates real, inspectable Bicep templates in your repo:

A Foundry Resource (top-level container)
A Foundry Project (where your agent lives)
Model deployment configuration (GPT-4o, etc.)
Managed identity with proper RBAC role assignments
azure.yaml for the service map
agent.yaml with agent metadata and environment variables

Here’s the key part: you own all of this. It’s versioned Bicep in your repo. You can inspect it, customize it, and commit it alongside your agent code. No magic black boxes.

The dev inner loop

What I really like is the local development story. When you’re iterating on agent logic, you don’t want to redeploy every time you change a prompt:

azd ai agent run

This starts your agent locally. Pair it with azd ai agent invoke to send test prompts, and you’ve got a tight feedback loop. Edit code, restart, invoke, repeat.

The invoke command is smart about routing too — when a local agent is running, it targets that automatically. When it’s not, it hits the remote endpoint.

Real-time monitoring

This is the feature that sold me. Once your agent is deployed:

azd ai agent monitor --follow

Every request and response flowing through your agent streams to your terminal in real time. For debugging production issues, this is invaluable. No digging through log analytics, no waiting for metrics to aggregate — you see what’s happening right now.

The full command set

Here’s the quick reference:

Command	What it does
`azd ai agent init`	Scaffold a Foundry agent project with IaC
`azd up`	Provision Azure resources and deploy the agent
`azd ai agent invoke`	Send prompts to the remote or local agent
`azd ai agent run`	Run the agent locally for development
`azd ai agent monitor`	Stream real-time logs from the published agent
`azd ai agent show`	Check agent health and status
`azd down`	Clean up all Azure resources

Why this matters for .NET developers

Even though the sample in the announcement is Python-based, the infrastructure story is language-agnostic. Your .NET agent gets the same Bicep scaffolding, the same managed identity setup, the same monitoring pipeline. And if you’re already using azd for your .NET Aspire apps or Azure deployments, this fits right into your existing workflow.

The deployment gap for AI agents has been one of the biggest friction points in the ecosystem. Going from a working prototype to a production endpoint with proper identity, networking, and monitoring shouldn’t require a week of DevOps work. Now it requires two commands and a few minutes.

Wrapping up

azd ai agent is available now. If you’ve been putting off deploying your AI agents because the infrastructure setup felt like too much work, give this a shot. Check out the full walkthrough for the complete step-by-step including frontend chat app integration.

VS Code 1.112: What .NET Developers Should Actually Care About

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 just landed, and honestly? This one hits different if you’re spending your days in .NET land. There’s a lot in the official release notes, but let me save you some scrolling and focus on what actually matters for us.

Copilot CLI just got way more useful

The big theme this release is agent autonomy — giving Copilot more room to do its thing without you babysitting every step.

Message steering and queueing

You know that moment when Copilot CLI is halfway through a task and you realize you forgot to mention something? Before, you had to wait. Now you can just send messages while a request is still running — either to steer the current response or queue up follow-up instructions.

This is huge for those longer dotnet scaffolding tasks where you’re watching Copilot set up a project and think “oh wait, I also need MassTransit in there.”

Permission levels

This is the one I’m most excited about. Copilot CLI sessions now support three permission levels:

Default Permissions — the usual flow where tools ask for confirmation before running
Bypass Approvals — auto-approves everything and retries on errors
Autopilot — goes fully autonomous: approves tools, answers its own questions, and keeps going until the task is done

If you’re doing something like scaffolding a new ASP.NET Core API with Entity Framework, migrations, and a Docker setup — Autopilot mode means you describe what you want and go grab a coffee. It’ll figure it out.

You can enable Autopilot with the chat.autopilot.enabled setting.

Preview changes before delegation

When you delegate a task to Copilot CLI, it creates a worktree. Before, if you had uncommitted changes, you had to check Source Control to see what would be affected. Now the Chat view shows pending changes right there before you decide whether to copy, move, or ignore them.

Small thing, but it saves you from that “wait, what did I have staged?” moment.

Debug web apps without leaving VS Code

The integrated browser now supports full debugging. You can set breakpoints, step through code, and inspect variables — all inside VS Code. No more switching to Edge DevTools.

There’s a new editor-browser debug type, and if you already have existing msedge or chrome launch configurations, migrating is as simple as changing the type field in your launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

For Blazor developers, this is a game changer. You’re already running dotnet watch in the terminal — now your debugging stays in the same window too.

The browser also got independent zoom levels (finally), proper right-click context menus, and the zoom is remembered per website.

MCP server sandboxing

This one matters more than you might think. If you’re using MCP servers — maybe you’ve set up a custom one for your Azure resources or database queries — they’ve been running with the same permissions as your VS Code process. That means full access to your filesystem, network, everything.

Now you can sandbox them. In your mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

When a sandboxed server needs access to something it doesn’t have, VS Code prompts you to grant permission. Much better than the “hope nobody does anything weird” approach.

Note: Sandboxing is available on macOS and Linux for now. Windows support is coming — remote scenarios like WSL do work though.

Monorepo customizations discovery

If you’re working in a monorepo (and let’s be honest, many enterprise .NET solutions end up as one), this solves a real pain point.

Previously, if you opened a subfolder of your repo, VS Code wouldn’t find your copilot-instructions.md, AGENTS.md, or custom skills sitting at the repository root. Now with the chat.useCustomizationsInParentRepositories setting, it walks up to the .git root and discovers everything.

This means your team can share agent instructions, prompt files, and custom tools across all projects in a monorepo without everyone having to open the root folder.

/troubleshoot for agent debugging

Ever set up custom instructions or skills and wonder why they’re not being picked up? The new /troubleshoot skill reads agent debug logs and tells you what happened — which tools were used or skipped, why instructions didn’t load, and what’s causing slow responses.

Enable it with:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Then just type /troubleshoot why is my custom skill not loading? in chat.

You can also export and import these debug logs now, which is great for sharing with your team when something isn’t working as expected.

Image and binary file support

Agents can now read image files from disk and binary files natively. The binary files are presented in hexdump format, and image outputs (like screenshots from the integrated browser) show up in a carousel view.

For .NET developers, think: paste a screenshot of a UI bug into chat and have the agent understand what’s wrong, or have it analyze the output of a Blazor component rendering.

Automatic symbol references

Small quality-of-life improvement: when you copy a symbol name (a class, method, etc.) and paste it into chat, VS Code now automatically converts it to a #sym:Name reference. This gives the agent full context about that symbol without you having to manually add it.

If you want plain text instead, use Ctrl+Shift+V.

Plugins can now be enabled/disabled

Previously, disabling an MCP server or plugin meant uninstalling it. Now you can toggle them on and off — both globally and per-workspace. Right-click in the Extensions view or the Customizations view and you’re done.

Plugins from npm and pypi can also auto-update now, though they’ll ask for approval first since updates mean running new code on your machine.

Wrapping up

VS Code 1.112 is clearly pushing hard on the agent experience — more autonomy, better debugging, tighter security. For .NET developers, the integrated browser debugging and Copilot CLI improvements are the standout features.

If you haven’t tried running a full Copilot CLI session in Autopilot mode for a .NET project yet, this release is a good time to start. Just remember to set your permissions and let it cook.

Download VS Code 1.112 or update from within VS Code via Help > Check for Updates.

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

Write for The .NET Blog

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog is a community-driven publication where developers share insights, tutorials, and stories about .NET, Azure, AI, and cloud-native development. We welcome contributions from developers of all levels — whether you’re writing your first technical post or you’re a seasoned speaker.

How to Join

Everything lives on GitHub and follows a pull-request workflow. Here’s how to get started:

1. Fork the Repository

Head to github.com/thedotnetblog/blog and fork it to your GitHub account.

2. Create Your Author Profile

If this is your first contribution, add yourself as an author by creating a folder at content/authors/your-username/ with an index.md file:

---
title: "Your Name"
id: "your-username"
role: "Your role or title"
bio: "A short bio about yourself."
avatar: "/img/authors/your-avatar.jpg"
socials:
 - platform: "GitHub"
 url: "https://github.com/your-username"
 - platform: "Twitter"
 url: "https://x.com/your-username"
---

Add your avatar image (square, at least 200×200px) to static/img/authors/.

3. Write Your Post

Create a new folder at content/posts/your-username/your-post-slug/ and add an index.md file:

---
title: "Your Post Title"
date: 2025-01-01
author: "your-username"
description: "A one-sentence description of your post."
tags: ["dotnet", "azure"]
---

Your post content in Markdown...

4. Open a Pull Request

Push your changes to your fork and open a pull request against the main branch. Our team will review it and provide feedback within a few days.

What We’re Looking For

Tutorials — step-by-step guides on .NET, Azure, AI, Blazor, Aspire, and more
Deep dives — in-depth explorations of a technology, pattern, or architecture
Community stories — your experience building with .NET in production
Event recaps — summaries of conferences, meetups, or webinars

Guidelines

Content should be technical and relevant to the .NET ecosystem
Code examples must be accurate and tested against a real project
Include a meaningful description and at least one relevant tag
Posts are automatically translated into all supported languages

Get in Touch

Open an issue on GitHub or reach out on X / Twitter. We’d love to have you as part of the community!

The .NET Blog

NDC Oslo 2026

By the numbers

Confirmed speakers

Tickets

Other NDC events in 2026

Links

.NET Day Switzerland 2026

What you get

Tickets

Organizers

Links

SDD Conference 2026

Topics

Speakers

Tickets and info

Azure DevOps MCP Server April Update: WIQL Queries, PAT Auth, and Experimental MCP Apps

WIQL Query Support

Personal Access Tokens on the Local Server

MCP Annotations on the Remote Server

Wiki Tool Consolidation

Experimental: MCP Apps

Wrapping up

SQL Server 2025 as Your Agent-Ready Database: Security, Backup, and MCP in One Engine

One Security Model to Rule All Data Models

Unified Backup = Atomic Recovery

Ledger Tables for Tamper-Evident Audit Trails

MCP Integration: Agents Without Hand-Coded Middleware

Why This Matters for .NET Developers

Wrapping up

.NET 10 Ships with Ubuntu 26.04 LTS — Here's What's New

Install .NET 10 in two commands

Try it immediately

Containers: update -noble to -resolute

Native AOT: 3ms startup, 1.4MB binary

What changed in Ubuntu 26.04 that affects .NET

Need .NET 8 or 9?

Wrapping up

Azure MCP Server Is Now a .mcpb — Install It Without Any Runtime

What’s an MCP Bundle?

How to install it

What you can do with it

Which install method should you use?

Why this matters

Get started

Azure SDK April 2026: AI Foundry 2.0 and What .NET Developers Should Know

Azure.AI.Projects 2.0.0 — Breaking Changes That Make Sense

Cosmos DB Java: Critical Security Fix (RCE)

New Provisioning Libraries for .NET

Azure AI Agents Java: 2.0.0 GA

Wrapping up

CodeAct in Agent Framework: How to Cut Your Agent's Latency in Half

What is CodeAct?

The safety piece: Hyperlight micro-VMs

Wiring it up

Mixing CodeAct with approval-gated tools

When to use CodeAct (and when not to)

Try it now

Wrapping up

GPT-5.5 Is Here and It's Coming to Azure Foundry — What .NET Developers Need to Know

The GPT-5 progression

What’s actually different

Pricing

Why Foundry matters here

Getting started

Wrapping up

VS Code 1.118: Copilot CLI Gets Session Names, Model Badges, and TypeScript 7.0 Nightly Opt-In

Copilot CLI: sessions get real names

Switch sessions faster with keyboard shortcuts

Model badges in chat

Auto model selection lands in Copilot CLI

TypeScript 7.0 nightly opt-in

Under the hood: node-pty cleanup

Wrapping up

Where Does Your Agent Remember Things? A Practical Guide to Chat History Storage

Two fundamental patterns

Service-managed: linear vs forking

Client-managed: you own the complexity

How Agent Framework abstracts this

The Responses API is uniquely flexible

Containers: update `-noble` to `-resolute`

Under the hood: `node-pty` cleanup