Azure | The .NET Blog

Microsoft Foundry April 2026: Foundry Local GA, GPT-5.5, CodeAct with Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

A busy month for Microsoft Foundry. Here are the announcements that matter most.

Foundry Local Is Generally Available

Foundry Local — Microsoft’s cross-platform local AI runtime — graduates from preview to GA on Windows, macOS (Apple Silicon), and Linux x64. Production-ready local model inference with a developer-friendly SDK. The 1.1 release (detailed in a separate post) adds transcription, embeddings, and Responses API support.

GPT-5.5

The latest GPT-5 family model is now available in Foundry. Default quota for Tier 5 and Tier 6 subscriptions. If you’ve been working with earlier GPT-5 variants, this is worth evaluating for your use cases.

Agent Framework Tracing in Foundry

Two tracing features ship in preview this month:

Microsoft Agent Framework tracing — MAF agents can now emit OpenTelemetry traces into Foundry. Debug agent behavior, trace multi-step execution, surface latency and errors across tool calls. This fills a real gap: knowing what your agent actually did in production, not just what it returned.

Hosted-agent tracing — Sessions, tool calls, and run steps from hosted agents also surface in Foundry traces. Same observability story extended to the hosted tier.

CodeAct with Hyperlight (Alpha)

This is the most technically interesting addition: Agent Framework can now execute Python code inside Hyperlight micro-virtual machines.

CodeAct is the pattern where an agent generates and executes Python code as a tool. The obvious concern is security — you’re running model-generated code. Hyperlight’s micro-VMs provide process-level isolation with near-native startup time, making sandboxed code execution practical without the overhead of full containers or VMs.

For agentic workflows where code execution is necessary, this is a significant safety improvement over running code in the host process.

Agent Monitoring Dashboard (Preview)

A unified operations dashboard combining token usage, latency, run success rate, and evaluator scores in one view. The distinction from regular observability dashboards: it includes evaluation results alongside operational metrics, so you can correlate “the agent is slower” with “evaluator scores dropped” — or confirm they’re unrelated.

Continuous Evaluation Custom Evaluators (Preview)

You can now bring your own code-based or prompt-based evaluators into continuous evaluation pipelines. Previously, continuous eval was limited to built-in evaluators. Custom evaluators let you enforce team-specific quality criteria in your production monitoring loop.

Agent Inventory in Control Plane

The Foundry Control Plane Operate view now shows all supported agents across a subscription: Foundry agents, Azure SRE Agent, Logic Apps agent loops, and registered custom agents. One view to understand what’s deployed and where.

Original post: What’s new in Microsoft Foundry | April 2026

Your Local MAF Agent Just Got a Production Home

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Getting an agent to work locally is the fun part. The tricky part is everything that comes after: deploying it without losing your mind, managing sessions, setting up identity, wiring observability. Usually that means a lot of custom infrastructure glue.

Foundry Hosted Agents just removed most of that glue for Microsoft Agent Framework (MAF) users.

What Foundry Hosted Agents Actually Does

When you deploy a MAF agent to Foundry Hosted Agents, the platform handles a surprisingly long list of things you’d otherwise build yourself:

Scale to zero — your agent costs nothing while idle and spins back up automatically
Per-session VM-isolated sandboxes — every user session gets its own sandbox with filesystem persistence that survives scale-down events
Built-in Entra ID — each agent gets its own identity so it can call Foundry models, Toolbox, and Azure services without secrets baked into the image
Versioned deployments — every deployment is an immutable snapshot, with blue/green and canary rollout support
Zero-config observability — APPLICATIONINSIGHTS_CONNECTION_STRING is injected at runtime so MAF’s OpenTelemetry traces flow into App Insights automatically

That last one is genuinely nice. No extra wiring, no additional config. Traces just show up.

The Code Difference Is Tiny

This is what I appreciate most about this integration. You don’t rewrite your agent. You just wrap it:

In .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

In Python:

server = ResponsesHostServer(agent)
server.run()

That’s it. The same logic you tested locally is what runs in production. The platform wraps it in the session management, identity, and scaling infrastructure.

Two Protocols, One Agent

Hosted Agents support two endpoint styles:

Responses (/responses) — OpenAI-compatible, manages conversation history and streaming. Good default for chat-shaped agents.
Invocations (/invocations) — you define the request/response schema. Good for non-conversational workflows.

If you’re building something that looks like a conversation, start with Responses. If you’re building an API-shaped agent that takes structured input and returns structured output, Invocations gives you the flexibility.

The Deployment Flow with `azd`

When you run azd up with a MAF agent:

Optionally creates a Foundry project and deploys a model
Packages your code and pushes an image to Azure Container Registry
Provisions compute from the ACR image
Assigns a dedicated Entra ID to the agent
Exposes a stable endpoint (https://{project_endpoint}/agents/{agent_name})
Handles everything else from that point on

Sessions persist for up to 30 days. Idle compute is deprovisioned after 15 minutes and restored transparently on the next request. From the agent’s perspective, nothing changed.

Wrapping Up

The distance between “working locally” and “running in production” has historically been long and painful for AI agents. Foundry Hosted Agents + MAF closes that gap significantly. If you already have a local agent built with Agent Framework, this is worth trying today.

The team says GA is coming soon — this is currently in preview. Check the MAF Hosted Agent Integration docs and the .NET samples to get started.

Original article: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1: Real-Time Transcription, Embeddings, and the Responses API

Emiliano Montesdeoca — Thu, 28 May 2026 00:00:00 +0000

Foundry Local 1.0 proved the concept: run AI models locally on Windows, macOS (Apple Silicon), and Linux x64 with a developer-friendly SDK. Version 1.1 adds three capabilities that cover a lot of real production use cases.

Live Audio Transcription

The most significant new feature: real-time speech-to-text streaming directly from the microphone. Captions, voice UIs, meeting transcription, accessibility tooling — all running locally with zero cloud dependency.

The API is session-based and streams results as they arrive, with is_final markers to distinguish interim from finalized text. Available across all language bindings: JavaScript, C#, Python, and Rust.

Load a streaming speech model from the catalog, create a session with audio settings (sample rate, channels, language), start it, push raw PCM audio chunks, and consume the async stream of results. The post has full Python and C# examples.

Text Embeddings

Semantic search, RAG pipelines, clustering, similarity matching — these all require embeddings. Foundry Local 1.1 adds embedding model support so you can generate vectors locally from the same SDK, without sending data to a cloud endpoint.

For applications where data residency matters or where you’re processing sensitive content, local embedding generation is a meaningful capability.

Responses API

Foundry Local now supports the Responses API — the structured interface designed for agentic interactions. This adds:

Tool calling — let locally-running models invoke tools you define
Multimodal vision-language input — pass image + text to vision-capable models
Compatible with the standard API shape, so existing agents targeting OpenAI’s Responses API work against local models

Package Size Improvements

Two changes reduce the JavaScript package size:

The koffi FFI layer has been replaced with a custom Node-API C addon
WebGPU execution provider ships as a separate plugin, so applications that don’t need GPU acceleration don’t pay the size cost

The C# SDK now targets lower framework versions for broader .NET compatibility.

Why This Matters

The three capabilities together — transcription, embeddings, tool calling — cover the core building blocks of many AI applications. Running them locally means:

No internet required
No per-token costs
No data leaving the machine
Consistent latency regardless of network conditions

Foundry Local is the right choice for edge scenarios, privacy-sensitive workloads, offline applications, or anything where you want to avoid cloud dependency during development.

Original post: Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell Is in Public Preview — And It Has an MCP Server Built In

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

If you’ve ever had to bounce between a portal tab, an SDK sample, and a half-finished script just to answer one Cosmos DB question, you already know the friction this project is designed to remove.

Azure Cosmos DB Shell just entered public preview. It’s an open-source CLI with bash-like syntax and — the part that makes this interesting — an integrated MCP server.

What Makes This Different From Other Database CLIs

The CLI itself is useful: familiar commands, scripting support, CI/CD integration. That part is table stakes for a developer-focused database tool.

The interesting part is the MCP server integration. Every command the CLI exposes becomes available as an MCP tool that your AI agents can call. There’s no custom API layer, no integration code to write. Your agent can:

Navigate database hierarchies with cd, ls, pwd
Run SQL queries with query and get structured results back
Create and modify items with create item, update, rm
Manage databases and containers with mkdb, mkcon, rmdb, rmcon
Inspect current context with endpoint, pwd

The key shift: your agent isn’t talking to a Cosmos DB API — it’s talking to the same shell interface you use. The commands are deterministic, auditable, and open source so you can inspect exactly what’s happening.

The Open-Source Foundation Matters

This isn’t a black-box managed service. The shell is open source, which means:

Security teams can audit the implementation
Platform teams can fork and extend it for their specific standards
Developers can contribute improvements that benefit everyone

For enterprise teams adopting AI tooling, “can we see exactly how it works” is increasingly not an optional requirement. Open source here is a meaningful differentiator.

Three Scenarios That Become Easier

Intelligent data analysis — connect an agent to the shell, ask natural language questions, get structured query results. The agent handles the query construction; the shell handles execution.

Autonomous data management — workflows that need to create, update, or remove data in Cosmos DB can do so through the MCP tools without needing a custom integration.

Real-time monitoring and alerts — an agent can periodically query containers, compare results, and surface anomalies through whatever notification channel makes sense.

The MCP interface makes these scenarios composable with any AI platform that speaks MCP — not just Microsoft’s tooling.

Getting Started

The shell is in public preview. Install it, configure your Cosmos DB connection, and enable the MCP server. From there, any MCP-compatible agent host can discover and use the tools.

Original post: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Your AI Agent Has an Identity Problem (And Here's the Template That Solves It)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

There’s a moment in every AI agent project that goes something like this: the demo works perfectly, the agent interprets natural language, calls the right APIs, returns the right data. Then you start thinking about real users.

What stops one user’s agent session from seeing another user’s data? What if the agent is tricked through prompt injection? What if it calls a tool in an unexpected way?

These aren’t edge cases. They’re design decisions you need to make before shipping.

A new azd template from Curity and Microsoft gives you a working reference for exactly this problem.

The Core Problem: Authentication ≠ Authorization

Most agent samples handle user authentication well. They handle authorization poorly. Knowing who the user is doesn’t tell you what data they should see.

A traditional client app makes predictable API calls. An AI agent is nondeterministic — it interprets natural language and decides what to call. It can be creative. It can also be wrong. And if it’s manipulated through prompt injection, you need rules that don’t depend on the AI being well-behaved.

The solution this template demonstrates: short-lived tokens that carry exactly the right information for each hop.

How the Token Chain Works

The template uses OAuth 2.0 access tokens with token exchange to narrow permissions at each step. A user token gets exchanged twice before it reaches the MCP server:

First exchange — narrows the scope and converts the opaque token to a JWT
Second exchange — adds the agent identity and a new audience for the MCP server hop

What the MCP server token looks like:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

The customer_id is baked into the token by the authorization server, not passed as a parameter the agent controls. The API checks the token, not the agent’s instructions.

This means: even if someone tricks the agent into trying to fetch another customer’s data, the token won’t authorize it.

What the Template Deploys

With a few azd commands you get:

A backend agent on Microsoft Foundry (C#, Microsoft A2A and MCP SDKs)
An MCP server exposing a sample portfolio API
Curity Identity Server as the authorization server, alongside Entra ID for authentication
External and internal API gateways handling token exchange and audit logging
Bicep for all the Azure infrastructure: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, storage

The whole pattern is inspectable and customizable.

The Design Principle Worth Borrowing

Even if you don’t use Curity, the pattern is transferable: agents should never hold permanent API access. Every action should use a short-lived token with the minimum scope needed for that specific call, issued to the specific agent identity, carrying the claims the API needs to make authorization decisions.

This holds up against creative agents, mistakes, and prompt injection in ways that “just make sure the agent doesn’t do bad things” never will.

Wrapping Up

Security patterns for AI agents are still being worked out across the industry. This template is one of the more complete reference implementations I’ve seen — it covers the actual authorization flow, not just authentication.

Original post: Least privilege AI agents: A new azd template from Curity and Microsoft

Private Endpoints, VNets, NSGs — Aspire Handles the Networking Now

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Here’s a scenario I’ve seen too many times. The app is done. The demo is great. Then the security checklist shows up: take storage off the public internet, run inside a VNet, provide outbound IPs for the partner allowlist, prove that only the right subnets talk to the right services.

At that point the application model and the infrastructure model start drifting apart in ways that are painful to maintain.

Aspire’s new Azure enterprise networking support addresses this directly. You describe the network shape next to the resources that use it, in your AppHost.

The Building Blocks

Here’s what each Azure networking concept is for, distilled:

Feature	Use it when	Why it matters
Virtual network	You need a private address space	The network boundary for subnets, private endpoints, and routing
Subnet	You need to separate workloads inside the VNet	Each part of the system gets its own address range and policy surface
Delegated subnet	A platform service (like ACA) needs to manage a subnet	Lets the service place managed infrastructure in your VNet safely
NAT gateway	You need predictable outbound public IPs	Stable address for allowlists and auditing
Private endpoint	You want a PaaS resource reachable privately	Puts a private IP for that service inside your VNet, removes public exposure
NSG	You need subnet-level traffic rules	Explicit allow/deny for inbound and outbound traffic per subnet

Describing It in Your AppHost

The key shift here is that you’re modeling the network alongside the resources that use it, not in a separate Bicep file that drifts away from the app model over time.

From the AppHost, you can:

Create VNets and subnets with AddVirtualNetwork() and AddSubnet()
Attach a NAT gateway to subnets for stable outbound IPs
Create private endpoints for storage, Key Vault, SQL, and other PaaS services
Define NSGs with inbound and outbound security rules
Configure Network Security Perimeters for cross-resource policies

The result is that when you run azd up, the infrastructure matches what the app model says it needs. Not what a manually maintained template says.

Why This Matters for Real Applications

A few things that become significantly easier once the network is modeled in Aspire:

Private endpoints for Key Vault and storage — you describe WithPrivateEndpoint() on those resources, and Aspire handles the DNS zone configuration and endpoint attachment. The app never changes.

Consistent outbound IPs — add a NAT gateway to the relevant subnet and every outbound request from your app goes through a known, stable IP. Partners can allowlist it. Auditors can trace it.

NSG rules from code — instead of clicking through the portal or maintaining a Bicep snippet, your security rules live in the AppHost alongside the resources they protect.

This is the kind of integration that doesn’t make demos exciting but makes production systems maintainable.

Wrapping Up

Network security showing up late in the project lifecycle is a solved problem if you model it alongside the app from the start. Aspire’s enterprise networking support makes that possible without requiring a separate infrastructure track.

Full details in the original post: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Kubernetes Support, Browser Logs, and the Aspireify Skill

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Five weeks is not a long time for a release, but Aspire 13.3 doesn’t feel like it. The headline items are meaningful: first-class Kubernetes and AKS deployment with Helm, an agent-assisted onboarding skill called Aspireify, browser log capture directly in the dashboard, and structured command results. Plus 45 new features, 134 improvements, and 93 bug fixes.

Let’s hit the highlights.

Aspireify: Agent-Assisted Onboarding

Adding Aspire to an existing project sounds simple — drop an AppHost in, done. In practice it involves a lot of archaeology: which ports matter, which environment variables are real dependencies, which Docker Compose services should map to Aspire integrations.

The new Aspireify skill gives your coding agent a guided workflow for exactly this. When aspire init drops a skeleton AppHost, the Aspireify skill helps the agent inspect the repo, understand how it already runs, and wire the AppHost to fit the app — not the other way around.

The default stance is “minimize changes to your code.” If your app already reads DATABASE_URL, the agent maps that with WithEnvironment() instead of asking you to rewrite your configuration. If a port is hardcoded, the skill tells the agent when to preserve it.

This is the kind of AI tooling that actually saves time rather than generating more work to review.

First-Class Kubernetes and AKS Deployment

This one has been on the wishlist for a while. Aspire 13.3 ships first-class Kubernetes and AKS deployment support with Helm. You can now target AKS as a deployment target directly from the Aspire tooling.

For teams already running production workloads on AKS, this closes a significant gap. Your Aspire app model now has a clean path from local dev to Kubernetes without manual Helm chart authoring.

Browser Logs in the Dashboard

This is one of those features that sounds small until you’re debugging a frontend issue.

The new WithBrowserLogs() API attaches a tracked browser resource to any endpoint-capable resource. Aspire launches Chromium using a private CDP pipe and streams console logs, network requests, and errors directly into the resource log stream:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost supports the same:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Console errors, failed network requests, client-side exceptions — all visible in the same dashboard where you’re already watching traces and metrics. No more tab-switching to browser DevTools for the basic stuff.

Structured Command Results

Resource commands got a meaningful upgrade. Until now, commands returned success/failure. Now they return structured results: text, JSON, or markdown that flows through the model, dashboard UI, CLI, and MCP tools.

The dashboard ties this together with a new notification center in the header. Command results show up as timestamped notifications with markdown rendering and a “View response” action.

This makes resource commands genuinely composable. An integration can now expose a command that returns meaningful output — like a tunnel URL — rather than just changing state somewhere.

Wrapping Up

Aspire 13.3 is worth the upgrade even just for the Kubernetes support. The browser logs and structured command results feel like the kind of quality-of-life improvements that accumulate quickly in a day-to-day development workflow.

Full release notes: What’s New in Aspire 13.3

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.

Removing the Monkey Work of Migration with Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Removing the Monkey Work of Migration with Agentic Platform Engineering — a walkthrough of Git-Ape (git agentic platform engineering tool) migrating a real AWS Terraform repo to Azure, focusing on intent extraction rather than line-by-line conversion.

The input: contoso-migration

The source is a real Terraform project (contoso-migration) that deploys a Next.js app on AWS — EC2 for compute, ALB for load balancing, S3 for artifacts, and IAM keys for identity. Cost: ~$34/month. The goal isn’t to reproduce the same infrastructure on Azure; it’s to figure out what the deployment is actually trying to do and rebuild that on Azure-native services.

Step 1: Validation and auth

Git-Ape starts by validating all required CLI tools — az, aws, gh, jq, git — and confirming active auth sessions before touching anything. No partial runs.

Step 2: Intent extraction

The agent reads the entire source repo through the GitHub API and extracts the deployment intent: runtime (Node.js), compute type, ingress pattern, artifact handling, identity model, networking, and monitoring. This is the key step — it’s building a semantic model of what the deployment does, not what Terraform keywords it uses.

Step 3: Service mapping

AWS services get mapped to Azure equivalents:

EC2 → App Service (Linux, Node 20 LTS)
ALB → App Service built-in load balancing
IAM roles/keys → Managed Identity
Terraform → Bicep + GitHub Actions

Step 4: Critique agent

Before generating output, a critique agent runs and catches two blocking issues:

Build-on-startup anti-pattern — the original Terraform was running npm install && npm run build on EC2 at startup. Fix: build in CI, deploy a ready artifact.
Unnecessary Blob Storage — S3 was used for artifact staging that could be eliminated with proper CI/CD. The critique agent dropped it entirely.

Step 5: Generated output

The result is ~80 lines of Bicep instead of the original 200+ lines of Terraform. The agent created a new GitHub repo with infra/main.bicep and .github/workflows/deploy.yml and removed all AWS-specific files.

Security posture comparison

The migration also produced a meaningful security upgrade:

AWS original	Azure output
HTTP only	HTTPS only, TLS 1.2
SSH open to 0.0.0.0/0	No SSH exposure
IAM access keys	OIDC + Managed Identity
No monitoring	Application Insights

Cost: ~$13/month vs the original $34/month.

What makes this different from a syntax converter

The critique agent step is what separates this from a mechanical translation. It caught patterns that would have worked on AWS but would be wrong on Azure — and fixed them instead of replicating them. The output isn’t “AWS in Azure syntax”; it’s an Azure-native deployment that achieves the same goal more cleanly.

See the full walkthrough for the complete agent trace and generated files.

SQL MCP Server on Azure App Service — No Containers Required

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Let me be honest with you: every time I see “requires a container” in a tutorial, a little part of me sighs. Containers are great — until your team doesn’t have a container strategy, and suddenly a feature that looked simple is blocked behind orchestration overhead you didn’t plan for.

That’s why this one caught my eye. The SQL MCP Server can now run on Azure App Service — no Docker, no Kubernetes, just the same Data API builder (DAB) configuration that exposes your SQL database through MCP, REST, and GraphQL.

What’s SQL MCP Server, Again?

Quick context if you haven’t run into it yet. SQL MCP Server sits between your AI agent and your SQL database. Instead of giving your agent direct database access (which is a terrible idea), it exposes your tables and views as an abstraction layer — entities with defined permissions.

It’s built on top of Data API builder, which means one configuration file drives MCP and REST and GraphQL simultaneously. Your agent talks to the MCP endpoint. Your traditional app talks to REST or GraphQL. Same config, same runtime, different surfaces.

That’s genuinely useful. You’re not maintaining two separate API layers.

The Container Problem (and the Solution)

The original deployment model for SQL MCP Server was containers. That works well in many shops — but not all. Plenty of .NET teams standardize on Azure App Service or VMs. Requiring a container runtime just to expose a SQL endpoint adds friction nobody asked for.

The new walkthrough shows you how to skip the container entirely. The whole thing runs with a dab start command, hosted on App Service as a standard .NET 8 web process.

Here’s the local setup flow in a nutshell:

# Install Data API builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Initialize the configuration
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Add an entity
dab add products --source dbo.products --permissions "authenticated:*"

# Configure App Service auth provider
dab configure --runtime.host.authentication.provider AppService

# Start the server
dab start

At this point you have MCP at /mcp, REST and GraphQL from the same process, and nothing running in a container.

Authentication That Doesn’t Involve Shared API Keys

This is the part I appreciate most. When you deploy to App Service, you configure Microsoft Entra ID as the authentication provider. No shared secrets embedded in config files, no API keys to rotate.

The connection string stays in an App Service environment variable (not in dab-config.json), and the MCP endpoint is protected by platform authentication. If you’re already aligned to Entra ID across your Azure workloads — which you probably are if you’re using Azure AI Foundry agents — this fits naturally.

For local development, you switch to Simulator mode and STDIO transport. Flip back to AppService mode when deploying. Clean and explicit.

Deploying to App Service

The actual deployment is straightforward Azure CLI work:

# Create the App Service plan
az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

# Create the web app (.NET 8 runtime)
az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

# Set the startup command
az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Then deploy your DAB project using whatever code deployment path your team already uses — VS Code, GitHub Actions, Zip Deploy. The key detail: it’s a code deployment, not a container deployment. No image to build, push, or manage.

Why This Matters for .NET Developers

If you’re building AI agents in .NET — whether with the Microsoft Agent Framework, Semantic Kernel, or Azure AI Foundry hosted agents — eventually your agent needs to talk to a database. SQL MCP Server gives you a structured way to do that without exposing raw connection strings or writing a custom API layer.

Running it on App Service closes the gap for teams that aren’t running containers. It’s the same DAB config, the same Entra auth, the same MCP protocol — just on infrastructure you already know.

Check out the full walkthrough in the original blog post and the sample repo on GitHub.

Wrapping Up

The SQL MCP Server on App Service is a solid pragmatic option for .NET teams that want to give their agents structured access to SQL data without a container strategy. The combination of DAB’s entity model, App Service’s built-in Entra auth, and the dab start startup command makes for a deployment that’s simple to explain and easy to operate.

Give it a try. Your agents will appreciate the clean API surface. Your ops team will appreciate not having to deal with container registries.

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.

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).

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

Getting Started with Microsoft Agent Framework

Emiliano Montesdeoca — Thu, 05 Mar 2026 00:00:00 +0000

The Microsoft Agent Framework (MAF) is a .NET SDK for building multi-agent AI systems. Rather than a single “do everything” prompt, you compose specialized agents — each with their own tools and instructions — and let them hand off work to each other.

This tutorial walks you through building a simple two-agent system: a triage agent that routes requests and a resolver agent that handles them.

Prerequisites

.NET 8 or later
NuGet: Microsoft.AI.Agents.Core
An Azure OpenAI or OpenAI API key

Step 1: Install packages

dotnet new console -n AgentDemo
cd AgentDemo
dotnet add package Microsoft.AI.Agents.Core
dotnet add package Microsoft.SemanticKernel

Step 2: Define your first agent

Agents are defined with a name, instructions, and a set of tools (Semantic Kernel plugins):

using Microsoft.AI.Agents.Core;
using Microsoft.SemanticKernel;

var kernel = Kernel.CreateBuilder()
 .AddAzureOpenAIChatCompletion(
 deploymentName: "gpt-4o",
 endpoint: Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")!,
 apiKey: Environment.GetEnvironmentVariable("AZURE_OPENAI_KEY")!
 )
 .Build();

var triageAgent = new ChatCompletionAgent
{
 Name = "TriageAgent",
 Instructions = """
 You are a triage agent. Classify incoming requests as either:
 - 'billing' — questions about invoices, payments, or subscriptions
 - 'technical' — questions about bugs, features, or how the product works
 Then hand off to the appropriate agent.
 """,
 Kernel = kernel
};

Step 3: Define the resolver agent

var resolverAgent = new ChatCompletionAgent
{
 Name = "ResolverAgent",
 Instructions = """
 You are a support resolver. You receive pre-triaged requests and provide
 clear, concise answers. Always end with a confirmation question.
 """,
 Kernel = kernel
};

Step 4: Set up handoff topology

MAF’s HandoffBuilder lets you declare a routing graph between agents:

var chat = new AgentGroupChat(triageAgent, resolverAgent)
{
 ExecutionSettings = new AgentGroupChatSettings
 {
 TerminationStrategy = new ApprovalTerminationStrategy()
 }
};

Step 5: Run the workflow

chat.AddChatMessage(new ChatMessageContent(
 AuthorRole.User,
 "My invoice from last month looks wrong — I was charged twice."
));

await foreach (var response in chat.InvokeAsync())
{
 Console.WriteLine($"[{response.AuthorName}]: {response.Content}");
}

MAF will call the triage agent first, which classifies the issue as “billing” and hands off to the resolver agent. You’ll see each agent’s turn in the output.

What to explore next

Tool calling — give agents access to APIs, databases, or file systems via SK plugins
Human-in-the-loop — use ApprovalTerminationStrategy to pause for human confirmation before high-risk actions
AG-UI integration — stream agent events to a frontend using the AG-UI protocol for real-time visibility
Observability — connect to Azure Monitor or OpenTelemetry to trace agent decisions

The MAF documentation and samples on GitHub cover production patterns including state persistence and long-running workflows.

Getting Started with Semantic Kernel

Emiliano Montesdeoca — Tue, 10 Feb 2026 00:00:00 +0000

Semantic Kernel (SK) is Microsoft’s open-source SDK for building AI orchestration into .NET (and Python/Java) applications. It’s the layer between your app code and LLMs: it handles prompts, plugins, memory, and multi-step planning so you don’t have to wire everything together manually.

This tutorial gets you from zero to a working SK-powered console app that calls an LLM and uses a plugin.

Prerequisites

.NET 8 or later
An OpenAI API key or an Azure OpenAI deployment

Step 1: Install the SDK

dotnet new console -n SkDemo
cd SkDemo
dotnet add package Microsoft.SemanticKernel

Step 2: Set up the kernel

The Kernel is the central object in SK. You configure it with an AI service (OpenAI, Azure OpenAI, or a local model):

using Microsoft.SemanticKernel;

var builder = Kernel.CreateBuilder();

builder.AddOpenAIChatCompletion(
 modelId: "gpt-4o-mini",
 apiKey: Environment.GetEnvironmentVariable("OPENAI_API_KEY")!
);

Kernel kernel = builder.Build();

Step 3: Invoke a prompt

The simplest thing SK does: send a prompt to the LLM and get a response.

var result = await kernel.InvokePromptAsync(
 "Summarize the key features of .NET 10 in three bullet points."
);

Console.WriteLine(result);

That’s it for the basics. But SK’s real power is in plugins.

Step 4: Create a plugin

A plugin is a C# class whose methods SK can call as tools. Here’s a simple one:

using System.ComponentModel;
using Microsoft.SemanticKernel;

public class DatePlugin
{
 [KernelFunction, Description("Returns the current date and time.")]
 public string GetCurrentDate() => DateTime.UtcNow.ToString("R");
}

kernel.ImportPluginFromObject(new DatePlugin());

Step 5: Let the kernel call the plugin

Enable automatic function calling so the LLM can invoke plugins when needed:

var settings = new OpenAIPromptExecutionSettings
{
 ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions
};

var result = await kernel.InvokePromptAsync(
 "What is today's date? Format it nicely.",
 new KernelArguments(settings)
);

Console.WriteLine(result);

The model will call GetCurrentDate() automatically and incorporate the result into its response.

What to explore next

Planners — have SK break a complex task into steps and execute them
Memory — add semantic search over your documents using embeddings
Agents — build multi-agent workflows using the AgentGroupChat API

The Semantic Kernel repo on GitHub has a rich set of samples in dotnet/samples/ covering all of these scenarios.

Azure | The .NET Blog

Microsoft Foundry April 2026: Foundry Local GA, GPT-5.5, CodeAct with Hyperlight

Foundry Local Is Generally Available

GPT-5.5

Agent Framework Tracing in Foundry

CodeAct with Hyperlight (Alpha)

Agent Monitoring Dashboard (Preview)

Continuous Evaluation Custom Evaluators (Preview)

Agent Inventory in Control Plane

Your Local MAF Agent Just Got a Production Home

What Foundry Hosted Agents Actually Does

The Code Difference Is Tiny

Two Protocols, One Agent

The Deployment Flow with azd

Wrapping Up

Foundry Local 1.1: Real-Time Transcription, Embeddings, and the Responses API

Live Audio Transcription

Text Embeddings

Responses API

Package Size Improvements

Why This Matters

Cosmos DB Shell Is in Public Preview — And It Has an MCP Server Built In

What Makes This Different From Other Database CLIs

The Open-Source Foundation Matters

Three Scenarios That Become Easier

Getting Started

Your AI Agent Has an Identity Problem (And Here's the Template That Solves It)

The Core Problem: Authentication ≠ Authorization

How the Token Chain Works

What the Template Deploys

The Design Principle Worth Borrowing

Wrapping Up

Private Endpoints, VNets, NSGs — Aspire Handles the Networking Now

The Building Blocks

Describing It in Your AppHost

Why This Matters for Real Applications

Wrapping Up

Aspire 13.3: Kubernetes Support, Browser Logs, and the Aspireify Skill

Aspireify: Agent-Assisted Onboarding

First-Class Kubernetes and AKS Deployment

Browser Logs in the Dashboard

Structured Command Results

Wrapping Up

SDD Conference 2026

Topics

Speakers

Tickets and info

Removing the Monkey Work of Migration with Agentic Platform Engineering

The input: contoso-migration

Step 1: Validation and auth

Step 2: Intent extraction

Step 3: Service mapping

Step 4: Critique agent

Step 5: Generated output

Security posture comparison

What makes this different from a syntax converter

SQL MCP Server on Azure App Service — No Containers Required

What’s SQL MCP Server, Again?

The Container Problem (and the Solution)

Authentication That Doesn’t Involve Shared API Keys

Deploying to App Service

Why This Matters for .NET Developers

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

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)

The Deployment Flow with `azd`