Agents | The .NET Blog

NL2SQL Is the SQL Injection of the Agentic Age

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

There’s a version of the NL2SQL pitch that sounds perfect: users ask questions in natural language, agents generate SQL, data comes back. Fewer screens, fewer queries, less code. Simple.

Then you think about it for five more minutes.

The Problems Nobody Talks About in the Demo

Schemas weren’t designed to explain things. Cryptic table names, inconsistent column names, technically valid relationships that are semantically invalid without additional predicates — these are normal for enterprise databases. They’re not bugs, they’re just the accumulated history of business changes. But when you ask a model to infer intent from a schema that wasn’t designed to communicate intent, the model will try anyway. It won’t give up. It’ll generate its best-effort query and return results with confidence.

Models are not deterministic. Ask the same question about the same database twice and you might get different SQL. The model is calculating probabilities, and slight variations in context drive different outputs. You cannot test your way to a guarantee that the agent always generates the right query.

User review doesn’t scale. “Just review every query before execution” sounds safe. But it assumes users are experts in both the data model and SQL — exactly the people who didn’t need the natural language interface. It also introduces cognitive overload and a new class of confirmation bias, where users overwhelmed by query complexity approve invalid queries rather than investigate them.

And then there’s injection. In traditional SQL development, parameterization solved injection because user input filled parameters, not SQL structure. With NL2SQL, the model is generating the SQL itself. The prompt, schema context, conversation history, and retrieved data all influence what gets executed. If someone crafts a prompt that changes what the model generates, that’s injection — not at the parameter level, but at the query generation level. And unlike dropping a table (obvious, recoverable), NL2SQL injection produces queries that return incorrect results with no visible error. Business decisions get made on wrong data.

What SQL MCP Server Actually Solves

This is where the article makes its most useful practical point. Instead of giving an agent arbitrary schema access and hoping for the best, SQL MCP Server exposes a curated API surface built on top of Data API builder.

The difference matters: the agent doesn’t generate SQL. It calls named endpoints that return predefined result shapes. The SQL is written once, by a developer, and is deterministic. The agent’s nondeterminism is limited to choosing which endpoint to call, not constructing arbitrary queries.

This is analogous to what parameterization did for SQL injection in the traditional app model — you remove the ability to construct arbitrary queries from untrusted input.

The Right Question

The article doesn’t say “never use NL2SQL.” It says: be deliberate about where you apply it and what you expose. For exploratory analysis in a controlled environment, with a scoped schema and read-only access, NL2SQL might be fine. For production systems where business decisions depend on the results, a curated API layer is significantly safer.

Honesty: some problems are genuinely better solved with structured queries behind named endpoints than with natural language to SQL. SQL MCP Server gives you that option without abandoning the agentic interface entirely.

Original post: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

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

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

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

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

What is CodeAct?

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

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

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

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

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

The safety piece: Hyperlight micro-VMs

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

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

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

Wiring it up

The minimal setup is straightforward:

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

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

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

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

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

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

Mixing CodeAct with approval-gated tools

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

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

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

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

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

When to use CodeAct (and when not to)

Reach for CodeAct when:

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

Stick with traditional tool-calling when:

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

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

Try it now

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

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

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

Wrapping up

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

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

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

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

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

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

Two fundamental patterns

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

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

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

Service-managed: linear vs forking

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

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

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

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

Client-managed: you own the complexity

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

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

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

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

How Agent Framework abstracts this

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

In C#:

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

In Python:

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

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

The Responses API is uniquely flexible

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

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

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

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

And in Python:

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

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

Provider quick reference

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

How to choose

Start with these questions:

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

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

Wrapping up

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

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

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.

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

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

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

Here’s what actually matters.

Autopilot mode finally remembers your preference

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

The Agent Host supports three session configs:

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

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

Worktree and git isolation for agent sessions

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

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

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

Subagents and agent teams

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

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

Terminal output auto-included when agents send input

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

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

Self-updating Agents app on macOS

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

The smaller stuff worth knowing

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

The takeaway

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

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

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.

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.

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.

VS Code 1.116 — Agents App Gets Keyboard Navigation and File Context Completions

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

VS Code 1.116 is the April 2026 release, and while it’s lighter than some recent updates, the changes are focused and meaningful — especially if you’re using the Agents app daily.

Here’s what landed, based on the official release notes.

Agents app improvements

The Agents app continues to mature with usability polish that makes a real difference in daily workflows:

Dedicated keybindings — you can now focus the Changes view, the files tree within Changes, and the Chat Customizations view with dedicated commands and keyboard shortcuts. If you’ve been clicking around the Agents app to navigate, this brings full keyboard-driven workflows.

Accessibility help dialog — pressing Alt+F1 in the chat input box now opens an accessibility help dialog showing available commands and keybindings. Screen reader users can also control announcement verbosity. Good accessibility benefits everyone.

File-context completions — type # in the Agents app chat to trigger file-context completions scoped to your current workspace. This is one of those small quality-of-life improvements that speeds up every interaction — no more typing full file paths when referencing code.

CSS `@import` link resolution

A nice one for frontend developers: VS Code now resolves CSS @import references that use node_modules paths. You can Ctrl+click through imports like @import "some-module/style.css" when using bundlers. Small but eliminates a friction point in CSS workflows.

Wrapping up

VS Code 1.116 is about refinement — making the Agents app more navigable, more accessible, and more keyboard-friendly. If you’re spending significant time in the Agents app (and I suspect many of us are), these changes add up.

Check the full release notes for the complete list.

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.

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.

Agents | The .NET Blog

NL2SQL Is the SQL Injection of the Agentic Age

The Problems Nobody Talks About in the Demo

What SQL MCP Server Actually Solves

The Right Question

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

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

What is CodeAct?

The safety piece: Hyperlight micro-VMs

Wiring it up

Mixing CodeAct with approval-gated tools

When to use CodeAct (and when not to)

Try it now

Wrapping up

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

Two fundamental patterns

Service-managed: linear vs forking

Client-managed: you own the complexity

How Agent Framework abstracts this

The Responses API is uniquely flexible

Provider quick reference

How to choose

Wrapping up

Foundry Toolboxes: One Endpoint for All Your Agent Tools

What’s a Toolbox?

The four pillars (two of which ship today)

Getting started in practice

Not locked to Foundry Agents

Why it matters now

Wrapping up

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

Autopilot mode finally remembers your preference

Worktree and git isolation for agent sessions

Subagents and agent teams

Terminal output auto-included when agents send input

Self-updating Agents app on macOS

The smaller stuff worth knowing

The takeaway

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

The six options at a glance

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

Deploying is genuinely simple

Built-in conversation management

My decision framework

Wrapping up

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

What’s Azure MCP Server?

The big deal: self-hosted remote deployments

Security hardening

Where can you use it?

Why this matters for .NET developers

Getting started

Wrapping up

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

What Git-APE actually does

Why this matters

My take

Wrapping up

Microsoft Foundry March 2026 — GPT-5.4, Agent Service GA, and the SDK Refresh That Changes Everything

Foundry Agent Service is production-ready

GPT-5.4 — reliability over raw intelligence

The SDK is finally stable

Fireworks AI brings open models to Azure

Other highlights

Wrapping up

VS Code 1.116 — Agents App Gets Keyboard Navigation and File Context Completions

Agents app improvements

CSS @import link resolution

Wrapping up

azd Now Lets You Run and Debug AI Agents Locally — Here's What Changed in March 2026

Run and debug AI agents without deploying

GitHub Copilot scaffolds your azd project

Container App Jobs and deployment improvements

Developer experience polish

Wrapping up

CSS `@import` link resolution