Ai | 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?

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

The Handoff Pattern: When One Agent Isn't Enough

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

At some point every multi-agent system outgrows a simple router. The first sign is usually when a specialist agent needs to ask a follow-up question, or realizes mid-turn that another agent should continue. A fixed pipeline breaks there. A one-shot router breaks there.

That’s exactly the problem the Handoff orchestration pattern in Microsoft Agent Framework is designed for.

How Handoff Works

The developer declares a graph: here are the agents, here are the edges between them. The framework does the rest — it synthesizes a handoff tool per outbound edge and injects it into each agent. When an agent decides to pass control, it calls the tool. The framework enforces the topology.

Three things make this different from just having agents call each other:

One shared transcript — the receiving agent sees the full conversation history. No starting from scratch.
Topology enforcement — an agent can only hand off to declared targets. You catch routing bugs at authoring time, not in production.
Natural termination — when the active agent finishes its turn without calling a handoff tool, the workflow yields to the user. No polling, no explicit exit conditions.

A Minimal Example

In .NET, building a handoff workflow looks like this:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage can send to either specialist. Both specialists can send back to triage. The graph is acyclic-friendly but supports back-edges when you need them (“I need more info” → back to research).

When to Use Handoff (and When Not To)

Handoff is a good fit when:

Ownership can change mid-conversation — an agent may realize it’s the wrong specialist
Back-edges matter — you might need to revisit an earlier step without restarting
Routing decisions are fuzzy — the choice to hand off is contextual and better made by the model than typed predicates

It’s not the right choice when:

Your pipeline is fixed and sequential — use the Sequential workflow for that
Each step is independent — agents sharing a transcript where only one of them needed it is just noise
You need strict processing guarantees — the non-determinism of model-driven routing isn’t what you want

Back-Edges and Human-in-the-Loop

One of the more interesting shapes Handoff enables is genuine back-edges. An agent can decide “I don’t have enough information” and route back to a research step, not with a hardcoded loop, but because the model decides it’s the right call.

Human-in-the-loop interactions also compose naturally. When a specialist needs user input, the workflow yields back to the user via the default turn loop, collects the response, and resumes with full context. The agent never lost the conversation.

Wrapping Up

Handoff is one of those patterns that sounds simple but enables a lot once you internalize it: decentralized routing, shared context, enforced topology, natural termination. It’s the right next step when your agents start saying “actually, someone else should handle this.”

Read the full walkthrough in the original post: A Tour of the Handoff Orchestration Pattern

Durable Workflows in Microsoft Agent Framework: From In-Memory to Azure Functions

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

One of the pain points with early AI agent workflows: they’re fragile. A long-running multi-step workflow tied to a single process means process restart = lost state. For simple demos this is fine. For production workloads it isn’t.

Microsoft Agent Framework’s workflow programming model now supports durable execution, backed by the Durable Task framework, with Azure Functions hosting. Here’s how the programming model works and why the durability story matters.

The Core Building Blocks

Executors are the fundamental unit of work. Each one is typed — it takes a specific input and produces a specific output:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // look up the order, return it
 return new Order(Id: message.OrderId, ...);
 }
}

Workflows wire executors into directed graphs using a fluent builder. The framework handles execution, data flow between steps, and error propagation.

You can model:

Sequential chains (step A → step B → step C)
Parallel fan-out/fan-in (run agents A, B, C in parallel, aggregate results)
Conditional branching
Human-in-the-loop approvals (pause workflow, wait for external signal)

The In-Memory Runner for Local Dev

Getting started is fast:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

The core package includes a lightweight in-process runner. No external dependencies, no database, no Azure resources. Works great for local development and unit testing.

Adding Durability with Durable Task

When a workflow needs to survive process restarts — because it’s long-running, because it has human-in-the-loop steps, because it fans out across many parallel agent calls — the in-memory runner isn’t enough.

MAF’s Durable Task integration stores workflow state in Azure Storage. If the process restarts, the workflow resumes from where it left off. The programming model stays the same; you just swap the runner.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

The same executors, the same workflow graph — backed by durable state.

Azure Functions Hosting

The third layer is Azure Functions hosting. Your workflow becomes a Function app: trigger the workflow via an HTTP endpoint, and the durable runtime handles scaling, state, and reliability.

This means a multi-agent workflow with parallel calls, conditional branches, and human approvals can scale across a serverless Functions environment without custom state management.

Why This Matters

The combination is significant for real AI systems:

Parallel agent calls — fan out to multiple specialized agents simultaneously without blocking, aggregate results when all complete
Long-running processes — workflows that involve human approval or external events can pause and resume across hours or days
Scale — Azure Functions scales the execution horizontally; the Durable Task framework handles coordinating the parallel state

If you’re building MAF workflows beyond simple local demos, this is the path to production-grade execution.

Original post: Durable Workflows in the Microsoft Agent Framework

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

Building Agents Is the Easy Part — Running Them Safely Is the Hard Part

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

There’s a pattern in AI agent development that I’ve started calling “demo regret.” The agent works great in demos. Then someone asks: what happens if it calls the wrong tool? What if it accesses data it shouldn’t? Who audited that?

Microsoft Agent Framework has your back for building and orchestrating. Agent Governance Toolkit (AGT) covers the part after that — governance, policy enforcement, and auditability at runtime.

What Each Project Actually Does

Microsoft Agent Framework (MAF) gives you the programming model: multi-agent workflows, A2A protocol interoperability, middleware hooks, memory, and managed hosting via Foundry Agent Service. It handles content safety at the model input/output level.

Agent Governance Toolkit (AGT) plugs into that same middleware pipeline to govern actions. Every tool call, resource access, and inter-agent message gets evaluated against policy before execution. Sub-millisecond overhead. No sidecars, no proxies, no prompts modified.

Agent Action --> Policy Check --> Allow / Deny --> Audit Log (< 0.1 ms)

Different layers, complete coverage, one pipeline.

Plugging In Is Just Adding Middleware

In Python, AGT adds to the same middleware parameter you’d use for logging or content filters:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

In .NET, same pattern via .Use():

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Same agent, same orchestration, same tools. AGT adds governance capabilities without touching the agent logic.

What You Get

GovernancePolicyMiddleware — evaluates every action against declarative policy rules
CapabilityGuardMiddleware — allowlists which tools an agent is permitted to call (the approve_small_loan tool isn’t in the allowed list above — deliberate)
RogueDetectionMiddleware — detects anomalous behavior patterns at runtime
AuditTrailMiddleware — Merkle-chained audit log so every action is cryptographically tamper-evident

That last one matters for compliance. A Merkle chain means if anyone modifies the log, the chain breaks. The audit is the evidence.

Five Industry Scenarios

The AGT repo ships five complete end-to-end scenarios: financial services (loan officer), healthcare (patient data), legal (contract review), government (citizen services), and manufacturing (quality control). Each one pairs real MAF agents with real AGT governance middleware.

These aren’t toy demos. They’re the kind of scenarios where you’d actually need governance in production.

Wrapping Up

If you’re building agents that touch real data, make decisions with consequences, or run unattended in production — governance isn’t optional. The combination of MAF + AGT gives you the whole stack: build it with Agent Framework, govern it with AGT.

Both projects are open source. The original article has links to the full code samples.

Original post: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

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

Azure SQL Can Generate Embeddings Now — In Pure T-SQL, No App Layer Needed

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

If you’ve ever built a RAG pipeline, you know the pipeline tax: your data lives in SQL, but to generate embeddings you need to extract it, call an embedding API, handle batching and rate limits, and store the results somewhere vector-searchable. Often in a different database entirely.

Azure SQL just removed most of that with two features that are now generally available: CREATE EXTERNAL MODEL and AI_GENERATE_EMBEDDINGS.

What They Do

These two T-SQL features work as an integrated pipeline:

CREATE EXTERNAL MODEL — registers an external AI model endpoint as a named database object. You set the location, API format, model type, and credentials once. Reuse it everywhere.

AI_GENERATE_EMBEDDINGS — a scalar T-SQL function that calls the registered model and returns a JSON array of vector values. Works in SELECT, INSERT, UPDATE, and MERGE statements.

Together they form an end-to-end embedding pipeline without leaving the SQL engine.

The Complete Workflow

-- Step 1: Register your embedding provider once
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Step 2: Generate embeddings inline in T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Step 3: Search with vector distance
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

That’s the whole pipeline: data in SQL, embeddings generated in SQL, similarity search in SQL. No orchestration layer, no ETL, no separate vector database.

Supported API Formats and Options

At GA, API_FORMAT supports Azure OpenAI and OpenAI. MODEL_TYPE is locked to EMBEDDINGS for now. The PARAMETERS JSON lets you set model-level defaults including retry count:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

Authentication uses database credentials, so secrets stay out of your application code.

What This Enables for .NET Applications

For .NET developers building AI features on top of existing SQL data, this is significant. You don’t need to:

Extract data to an intermediate store for embedding
Manage an external embedding pipeline
Set up a separate vector database (though you can use Azure AI Search if you want a full-featured vector store)
Change your application’s data access layer

You can add semantic search to existing SQL applications incrementally, using the same T-SQL tooling you already have.

Wrapping Up

RAG patterns on SQL data just got dramatically simpler. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL means your existing SQL application can gain vector search capabilities without adding new infrastructure.

Both features are GA in Azure SQL Database and Azure SQL Managed Instance today.

Original post: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

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

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.

Building an AI-Powered Conference App with .NET's Composable Stack

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

Building an AI-Powered Conference App with .NET’s Composable Stack — Microsoft built ConferencePulse, a Blazor Server app for live conference sessions, by composing five .NET extension libraries together. They used it at MVP Summit.

What ConferencePulse does

ConferencePulse runs during live sessions and provides: AI-generated polls from session content, audience Q&A with a RAG pipeline pulling from a live knowledge base, auto-generated insights, and session summaries produced by multiple concurrent AI agents. The stack is .NET 10, Blazor Server, Aspire, split across five projects: Web, Core, Ingestion, Agents, Mcp, and AppHost.

Microsoft.Extensions.AI: one abstraction for everything

IChatClient is the unified abstraction — you wire it up once and the same interface works for Azure OpenAI, OpenAI, Anthropic, or any other provider. Six lines to get a fully configured client with function invocation, OpenTelemetry tracing, and logging middleware:

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

The same IChatClient is reused later for the data ingestion enrichment step — no separate client for that.

DataIngestion pipeline

Session content flows through a pipeline: MarkdownReader → HeaderChunker (500 tokens, 50 token overlap) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). The enrichers use the same IChatClient to generate summaries and extract keywords before indexing. Audience questions, Q&A pairs, and poll results are ingested in real-time as the session progresses — the knowledge base grows during the talk.

VectorData: provider-agnostic search

VectorStoreCollection.SearchAsync() works the same whether the backing store is Qdrant or Azure AI Search. Hybrid search (vector + full-text) is supported. The RAG pipeline for audience Q&A queries this collection and gets back relevant chunks to pass as context to the chat client.

MCP: session content as tools

The session content is exposed via MCP so any MCP-compatible client can access it. Both the server and client are implemented — the server exposes session knowledge as MCP tools, and the client allows calling those tools from within the agent pipeline.

Agent Framework: parallel multi-agent summary

The session summary is generated by three agents running concurrently — PollSummaryAgent, QuestionSummaryAgent, and InsightSummaryAgent — then merged. This uses the group chat or parallel execution pattern from Microsoft Agent Framework. Each agent handles one concern; the orchestrator merges the outputs.

The design principle

The post makes a point worth keeping: use the simplest tool that fits. Direct IChatClient calls for simple generation tasks. Tool/function calling for structured data extraction. Full agents only when you need autonomous multi-step reasoning. The library layering enforces this — you can pick up Microsoft.Extensions.AI without pulling in the full Agent Framework.

See the full post for the complete project structure and source links.

Microsoft Agent Framework Part 3: From Tools to Workflows — The Building Blocks Click Into Place

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

If you’ve been following the Building Blocks for AI in .NET series, you know Part 1 gave us IChatClient (the universal model interface) and Part 2 gave us Microsoft.Extensions.VectorData (semantic search and RAG). Both are foundational, both are useful on their own. But this is where everything starts to connect.

Part 3 is about the Microsoft Agent Framework — and honestly, it’s the piece I’ve been waiting to see land in .NET. 1.0 shipped in April. The API is stable. It’s time to actually build agents.

What an Agent Actually Is (vs. a Chatbot)

Before diving into code, let’s get this distinction out of the way. A chatbot receives input, calls a model, returns output. Simple loop.

An agent has autonomy. It can reason about a task, decide which tools to use, call those tools, evaluate results, and decide what to do next — all without you writing explicit step-by-step logic for every scenario. You give it tools and instructions, and it figures out the orchestration.

Think of it this way: IChatClient is like having a conversation. An agent is like handing someone a task list.

Your First Agent in 10 Lines

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

The .AsAIAgent() extension method is the bridge. Same pattern as .AsIChatClient() from MEAI — it wraps a provider’s SDK in a stable abstraction. It works with Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry, or local models via Foundry Local or Ollama.

Streaming works too:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Giving the Agent Tools

This is where agents stop being fancy chatbots. Tools are functions the model can decide to call based on what the user asks. No routing logic needed on your part — the model figures it out.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Two things to notice here. First, AIFunctionFactory is from MEAI — same tool factory you’d use with a plain IChatClient. If you’ve already defined tools for your chat scenarios, they work here too.

Second, those Description attributes matter a lot. They’re how the model understands what a tool does and when to use it. Treat them as documentation for your AI, not for humans.

Sessions: Conversations That Actually Remember

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Without a session, each RunAsync call is stateless. With a session, the agent knows which joke you’re referring to. The AgentSession preserves conversation history between turns.

For production stateless services, sessions serialize cleanly:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... store it somewhere ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

This is critical if your agent runs in a serverless or horizontally-scaled environment.

AIContextProvider: Memory That Persists Across Sessions

Sessions preserve conversation history within a session. But what about knowing things about a user across sessions? AIContextProvider handles that.

It has two hooks:

ProvideAIContextAsync — runs before each interaction, injects context into the agent (e.g., “The user’s name is Emiliano”)
StoreAIContextAsync — runs after each interaction, lets you learn from what was said and persist it

The pattern is elegant: you can stack multiple providers — one for user preferences, one for recent interactions, one that queries your VectorData store for relevant documents. That last one is exactly the RAG pattern from Part 2, now running automatically as part of every agent call.

Multi-Agent Workflows

This is where the framework earns its name. The Agent Framework includes a graph-based workflow system where executors (agents, functions, whatever) connect via edges.

Some patterns that are natively supported:

Sequential: Agent A’s output feeds Agent B
Concurrent (fan-out/fan-in): Dispatch to multiple agents in parallel, collect results
Conditional routing: Route work to different agents based on output
Writer-critic loops: One agent writes, another evaluates, loop until approved
Sub-workflows: Compose workflows hierarchically

A writer-critic example:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Clean, readable, and the condition-based routing means you don’t write loop logic yourself. The framework drives the iteration.

Human-in-the-Loop

Not everything should run fully autonomously. For sensitive operations — database writes, financial transactions, sending communications — you want a human to approve before the agent executes.

The framework has built-in support for this via FunctionApprovalRequestContent and FunctionApprovalResponseContent. The agent proposes the tool call, your application code presents it to the user, and the response determines whether execution proceeds.

This is the right way to think about agents in enterprise settings: not fully autonomous, but autonomy-with-guardrails.

The Full Picture

If you step back for a second:

MEAI gives you a universal interface to any model
VectorData gives your agents access to your organization’s knowledge through semantic search
Agent Framework orchestrates everything — it uses IChatClient under the hood, composes with context providers, and coordinates through workflows

Each piece was designed to compose with the others. You can use any of them independently, but together they form a coherent stack for building AI applications in .NET.

Check out the original post by Jeremy Likness and the Agent Framework GitHub repo for the full samples.

Wrapping Up

The Microsoft Agent Framework Part 3 post closes the loop on the building blocks series (with MCP coming next). For .NET developers who want to build AI agents — not just chatbots, actual agents that use tools, remember things, and coordinate — this is your path forward.

The 1.0 stable release means you can build on this in production. The composition with MEAI and VectorData means you’re not learning a parallel set of abstractions. It all fits together.

If you’ve been waiting to jump into agent development in .NET, the timing is right now.

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.

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

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

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

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

What is CodeAct?

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

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

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

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

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

The safety piece: Hyperlight micro-VMs

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

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

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

Wiring it up

The minimal setup is straightforward:

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

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

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

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

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

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

Mixing CodeAct with approval-gated tools

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

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

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

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

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

When to use CodeAct (and when not to)

Reach for CodeAct when:

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

Stick with traditional tool-calling when:

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

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

Try it now

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

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

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

Wrapping up

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

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

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

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

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

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

The GPT-5 progression

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

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

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

What’s actually different

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

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

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

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

Pricing

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

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

Why Foundry matters here

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

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

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

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

Getting started

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

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

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

Wrapping up

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

The frontier is moving fast. Keep building.

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

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.

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

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

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

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

winapp run: F5 from anywhere

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

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

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

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

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

New NuGet package: dotnet run for packaged apps

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

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

# Let winapp init set it up
winapp init

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

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

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

winapp ui: UI Automation from the command line

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

What you can do:

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

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

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

Other bits worth noting

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

Get it

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

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

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

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

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

Here’s what actually matters.

Autopilot mode finally remembers your preference

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

The Agent Host supports three session configs:

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

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

Worktree and git isolation for agent sessions

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

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

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

Subagents and agent teams

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

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

Terminal output auto-included when agents send input

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

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

Self-updating Agents app on macOS

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

The smaller stuff worth knowing

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

The takeaway

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

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

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

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

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

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

Global Training for o4-mini

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

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

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

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

That trainingType: globalstandard flag is the key difference.

New Model Graders: GPT-4.1 Family

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

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

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

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

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

The RFT Data Format Gotcha

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

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

Why This Matters for .NET Developers

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

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

Global Azure Spain 2026

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

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

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

Highlights from the agenda

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

Tickets

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

Azure Tour 2026

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

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

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

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

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

Why AI workloads hit different

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

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

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

Management vs. optimization — know the difference

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

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

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

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

What actually works

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

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

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

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

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

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

The takeaway

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

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

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

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

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

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

What Docker Sandbox actually gives you

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

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

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

Why .NET developers should care

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

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

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

The security angle matters

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

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

Takeaway

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

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

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

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

The six options at a glance

Here’s how I’d summarize the landscape:

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

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

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

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

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

from azure.ai.agentserver.agentframework import from_agent_framework

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

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

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

Deploying is genuinely simple

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

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

# Init from a template
azd ai agent init

# Build, push, deploy — done
azd up

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

Built-in conversation management

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

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

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

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

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

My decision framework

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

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

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

Wrapping up

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

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

Agent Skills in .NET Just Got Seriously Flexible

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

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

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

File-based skills: the starting point

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

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

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

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

## Instructions

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

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

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

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

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

Class-based skills: ship via NuGet

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

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

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

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

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

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

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

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

Inline skills: the quick bridge

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

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

Add it to the builder just like the others:

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

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

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

Script approval: human-in-the-loop

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

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

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

Why this combination matters

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

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

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

Wrapping up

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

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

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

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

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

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

What’s Azure MCP Server?

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

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

The big deal: self-hosted remote deployments

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

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

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

For auth, you get two solid options:

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

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

Security hardening

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

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

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

Where can you use it?

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

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

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

Why this matters for .NET developers

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

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

Getting started

Pick your path:

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

Wrapping up

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

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

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

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

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

The problem is real

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

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

Aspire as agent infrastructure

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

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

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

const builder = await createBuilder();

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

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

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

await builder.build().run();

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

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

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

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

The bowling bumper analogy

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

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

Getting started

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

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

Wrapping up

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

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

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.

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

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

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

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

What are MCP Apps?

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

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

The fluent API in three steps

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

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

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

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

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

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

The API surface is well-designed

A few things I really like:

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

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

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

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

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

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Getting started

Add the preview package:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

If you’re already building MCP tools with Azure Functions, this is just a package update. The MCP Apps quickstart is the best place to start if you’re new to the concept.

Wrapping up

MCP Apps are one of the more exciting developments in the AI tooling space — tools that don’t just do things but can show things to users. The fluent API removes the protocol complexity and lets you focus on what matters: your tool’s logic and its UI.

Read the full post for the complete API reference and examples.

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

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

The monthly “What’s New in Microsoft Foundry” posts are usually a mix of incremental improvements and the occasional headline feature. The March 2026 edition? It’s basically all headline features. Foundry Agent Service goes GA, GPT-5.4 ships for production, the SDK gets a major stable release, and Fireworks AI brings open model inference to Azure. Let me break down what matters for .NET developers.

Foundry Agent Service is production-ready

This is the big one. The next-gen agent runtime is generally available — built on the OpenAI Responses API, wire-compatible with OpenAI agents, and open to models from multiple providers. If you’re building with the Responses API today, migrating to Foundry adds enterprise security, private networking, Entra RBAC, full tracing, and evaluation on top of your existing agent logic.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Key additions: end-to-end private networking, MCP auth expansion (including OAuth passthrough), Voice Live preview for speech-to-speech agents, and hosted agents in 6 new regions.

GPT-5.4 — reliability over raw intelligence

GPT-5.4 isn’t about being smarter. It’s about being more reliable. Stronger reasoning over long interactions, better instruction adherence, fewer mid-workflow failures, and integrated computer use capabilities. For production agents, that reliability matters way more than benchmark scores.

Model	Pricing (per M tokens)	Best For
GPT-5.4 (≤272K)	$2.50 / $15 output	Production agents, coding, document workflows
GPT-5.4 Pro	$30 / $180 output	Deep analysis, scientific reasoning
GPT-5.4 Mini	Cost-effective	Classification, extraction, lightweight tool calls

The smart play is a routing strategy: GPT-5.4 Mini handles high-volume, low-latency work while GPT-5.4 takes the reasoning-heavy requests.

The SDK is finally stable

azure-ai-projects SDK shipped stable releases across all languages — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, and .NET 2.0.0 (April 1). The azure-ai-agents dependency is gone — everything lives under AIProjectClient. Install with pip install azure-ai-projects and the package bundles openai and azure-identity as direct dependencies.

For .NET developers, this means a single NuGet package for the full Foundry surface. No more juggling separate agent SDKs.

Fireworks AI brings open models to Azure

Perhaps the most architecturally interesting addition: Fireworks AI processing 13+ trillion tokens daily at ~180K requests/second, now available through Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, and MiniMax M2.5 at launch.

The real story is bring-your-own-weights — upload quantized or fine-tuned weights from anywhere without changing the serving stack. Deploy via serverless pay-per-token or provisioned throughput.

Other highlights

Phi-4 Reasoning Vision 15B — multimodal reasoning for charts, diagrams, and document layouts
Evaluations GA — out-of-the-box evaluators with continuous production monitoring piped into Azure Monitor
Priority Processing (Preview) — dedicated compute lane for latency-sensitive workloads
Voice Live — speech-to-speech runtime that connects directly to Foundry agents
Tracing GA — end-to-end agent trace inspection with sort and filter
PromptFlow deprecation — migration to Microsoft Framework Workflows by January 2027

Wrapping up

March 2026 is a turning point for Foundry. The Agent Service GA, stable SDKs across all languages, GPT-5.4 for reliable production agents, and open model inference via Fireworks AI — the platform is ready for serious workloads.

Read the full roundup and build your first agent to get started.

SQL MCP Server — The Right Way to Give AI Agents Database Access

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

Let’s be honest: most database MCP servers available today are terrifying. They take a natural language query, generate SQL on the fly, and run it against your production data. What could go wrong? (Everything. Everything could go wrong.)

The Azure SQL team just introduced SQL MCP Server, and it takes a fundamentally different approach. Built as a feature of Data API builder (DAB) 2.0, it gives AI agents structured, deterministic access to database operations — without NL2SQL, without exposing your schema, and with full RBAC at every step.

Why no NL2SQL?

This is the most interesting design decision. Models aren’t deterministic, and complex queries are the most likely to produce subtle errors. The exact queries users hope AI can generate are also the ones that need the most scrutiny when produced non-deterministically.

Instead, SQL MCP Server uses an NL2DAB approach. The agent works with Data API builder’s entity abstraction layer and built-in query builder to produce accurate, well-formed T-SQL deterministically. Same result for the user, but without the risk of hallucinated JOINs or accidental data exposure.

Seven tools, not seven hundred

SQL MCP Server exposes exactly seven DML tools, regardless of database size:

describe_entities — discover available entities and operations
create_record — insert rows
read_records — query tables and views
update_record — modify rows
delete_record — remove rows
execute_entity — run stored procedures
aggregate_records — aggregation queries

This is smart because context windows are the agent’s thinking space. Flooding them with hundreds of tool definitions leaves less room for reasoning. Seven fixed tools keep the agent focused on thinking rather than navigating.

Each tool can be individually enabled or disabled:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Getting started in three commands

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

That’s a running SQL MCP Server exposing your Customers table. The entity abstraction layer means you can alias names and columns, limit fields per role, and control exactly what agents see — without exposing internal schema details.

The security story is solid

This is where Data API builder’s maturity pays off:

RBAC at every layer — each entity defines which roles can read, create, update, or delete, and which fields are visible
Azure Key Vault integration — connection strings and secrets managed securely
Microsoft Entra + custom OAuth — production-grade authentication
Content Security Policy — agents interact through a controlled contract, not raw SQL

The schema abstraction is particularly important. Your internal table and column names never get exposed to the agent. You define entities, aliases, and descriptions that make sense for the AI interaction — not your database ERD.

Multi-database and multi-protocol

SQL MCP Server supports Microsoft SQL, PostgreSQL, Azure Cosmos DB, and MySQL. And because it’s a DAB feature, you get REST, GraphQL, and MCP endpoints simultaneously from the same configuration. Same entity definitions, same RBAC rules, same security — across all three protocols.

Auto-configuration in DAB 2.0 can even inspect your database and build the configuration dynamically, if you’re comfortable with less abstraction for rapid prototyping.

My take

This is how enterprise database access for AI agents should work. Not “hey LLM, write me some SQL and YOLO it against production.” Instead: a well-defined entity layer, deterministic query generation, RBAC at every step, caching, monitoring, and telemetry. It’s boring in the best possible way.

For .NET developers, the integration story is clean — DAB is a .NET tool, the MCP Server runs as a container, and it works with Azure SQL, which most of us are already using. If you’re building AI agents that need data access, start here.

Wrapping up

SQL MCP Server is free, open-source, and runs anywhere. It’s the prescriptive approach from Microsoft for giving AI agents secure database access. Check out the full post and the documentation to get started.

VS Code 1.115 — Background Terminal Notifications, SSH Agent Mode, and More

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

VS Code 1.115 just dropped, and while it’s a lighter release in terms of headline features, the agent-related improvements are genuinely useful if you’re working with AI coding assistants daily.

Let me highlight what’s actually worth knowing.

Background terminals talk back to agents

This is the standout feature. Background terminals now automatically notify agents when commands complete, including the exit code and terminal output. Input prompts in background terminals are also detected and surfaced to the user.

Why does this matter? If you’ve used Copilot’s agent mode to run build commands or test suites in the background, you know the pain of “did that finish yet?” — background terminals were essentially fire-and-forget. Now the agent gets notified when your dotnet build or dotnet test completes, sees the output, and can react accordingly. It’s a small change that makes agent-driven workflows significantly more reliable.

There’s also a new send_to_terminal tool that lets agents send commands to background terminals with user confirmation, fixing the issue where run_in_terminal with a timeout would move terminals to the background and make them read-only.

SSH remote agent hosting

VS Code now supports connecting to remote machines over SSH, automatically installing the CLI and starting it in agent host mode. This means your AI agent sessions can target remote environments directly — useful for .NET developers who build and test on Linux servers or cloud VMs.

Edit tracking in agent sessions

File edits made during agent sessions are now tracked and restored, with diffs, undo/redo, and state restoration. If an agent makes changes to your code and something goes wrong, you can see exactly what changed and roll it back. Peace of mind for letting agents modify your codebase.

Browser tab awareness and other improvements

A few more quality-of-life additions:

Browser tab tracking — chat can now track and link to browser tabs opened during a session, so agents can reference web pages you’re looking at
File paste in terminal — paste files (including images) into the terminal with Ctrl+V, drag-and-drop, or right-click
Test coverage in minimap — test coverage indicators now show in the minimap for a quick visual overview
Pinch-to-zoom on Mac — integrated browser supports pinch-to-zoom gestures
Copilot entitlements in Sessions — status bar shows usage info in the Sessions view
Favicon in Go to File — open web pages show favicons in the quick pick list

Wrapping up

VS Code 1.115 is an incremental release, but the agent improvements — background terminal notifications, SSH agent hosting, and edit tracking — add up to a noticeably smoother experience for AI-assisted development. If you’re using Copilot’s agent mode for .NET projects, these are the kinds of quality-of-life fixes that reduce friction daily.

Check out the full release notes for every detail.

Aspire 13.2 Ships a Docs CLI — and Your AI Agent Can Use It Too

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

You know that moment when you’re deep in an Aspire AppHost, wiring up integrations, and you need to check exactly which parameters the Redis integration expects? You alt-tab to your browser, hunt through aspire.dev, squint at the API docs, then come back to your editor. Context lost. Flow broken.

Aspire 13.2 just shipped a fix for that. The aspire docs CLI lets you search, browse, and read official Aspire documentation directly from your terminal. And because it’s backed by reusable services, AI agents and skills can use the same commands to look up docs instead of hallucinating APIs that don’t exist.

The problem this actually solves

David Pine nails it in the original post: AI agents were terrible at helping developers build Aspire apps. They’d recommend dotnet run instead of aspire run, reference learn.microsoft.com for docs that live on aspire.dev, suggest outdated NuGet packages, and — my personal favorite — hallucinate APIs that don’t exist.

Why? Because Aspire was .NET-specific far longer than it’s been polyglot, and LLMs are working off training data that predates the latest features. When you give an AI agent the ability to actually look up the current docs, it stops guessing and starts being useful.

Three commands, zero browser tabs

The CLI is refreshingly simple:

List all docs

aspire docs list

Returns every documentation page available on aspire.dev. Need machine-readable output? Add --format Json.

Search for a topic

aspire docs search "redis"

Searches both titles and content with weighted relevance scoring. Same search engine that powers the documentation tooling internally. You get ranked results with titles, slugs, and relevance scores.

Read a full page (or just one section)

aspire docs get redis-integration

Streams the full page as markdown to your terminal. Need just one section?

aspire docs get redis-integration --section "Add Redis resource"

Surgical precision. No scrolling through 500 lines. Just the part you need.

The AI agent angle

Here’s where it gets interesting for us developers building with AI tooling. The same aspire docs commands work as tools for AI agents — through skills, MCP servers, or simple CLI wrappers.

Instead of your AI assistant making up Aspire APIs based on stale training data, it can call aspire docs search "postgres", find the official integration docs, read the right page, and give you the documented approach. Real-time, current documentation — not what the model memorized six months ago.

The architecture behind this is intentional. The Aspire team built reusable services (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) rather than a one-off integration. That means the same search engine works for humans in the terminal, AI agents in your editor, and automation in your CI pipeline.

Real-world scenarios

Quick terminal lookups: You’re three files deep and need Redis config parameters. Two commands, ninety seconds, back to work:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI-assisted development: Your VS Code skill wraps the CLI commands. You ask “Add a PostgreSQL database to my AppHost” and the agent looks up the real docs before answering. No hallucinations.

CI/CD validation: Your pipeline validates AppHost configurations against official documentation programmatically. --format Json output pipes cleanly to jq and other tools.

Custom knowledge bases: Building your own AI tooling? Pipe structured JSON output directly into your knowledge base:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

No web scraping. No API keys. Same structured data the docs tooling uses internally.

The documentation is always live

This is the part I appreciate most. The CLI doesn’t download a snapshot — it queries aspire.dev with ETag-based caching. The moment the docs update, your CLI and any skill built on top of it reflects that. No stale copies, no “but the wiki said…” moments.

Wrapping up

aspire docs is one of those small features that solves a real problem cleanly. Humans get terminal-native documentation access. AI agents get a way to stop guessing and start referencing actual docs. And it’s all backed by the same source of truth.

If you’re building with .NET Aspire and haven’t tried the CLI yet, run aspire docs search "your-topic-here" and see how it feels. Then consider wrapping those commands into whatever AI skill or automation setup you’re using — your agents will thank you.

Check out David Pine’s deep dive on how the docs tooling came together, and the official CLI reference for all the details.

Microsoft Agent Framework Hits 1.0 — Here's What Actually Matters for .NET Developers

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

If you’ve been following the Agent Framework journey from the early Semantic Kernel and AutoGen days, this one is significant. Microsoft Agent Framework just hit version 1.0 — production-ready, stable APIs, long-term support commitment. It’s available for both .NET and Python, and it’s genuinely ready for real workloads.

Let me cut through the announcement noise and focus on what matters if you’re building AI-powered apps with .NET.

The short version

Agent Framework 1.0 unifies what used to be Semantic Kernel and AutoGen into a single, open-source SDK. One agent abstraction. One orchestration engine. Multiple AI providers. If you’ve been bouncing between Semantic Kernel for enterprise patterns and AutoGen for research-grade multi-agent workflows, you can stop. This is the one SDK now.

Getting started is almost unfairly simple

Here’s a working agent in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

That’s it. A handful of lines and you have an AI agent running against Azure Foundry. The Python equivalent is equally concise. Add function tools, multi-turn conversations, and streaming as you go — the API surface scales up without getting weird.

Multi-agent orchestration — this is the real deal

Single agents are fine for demos, but production scenarios usually need coordination. Agent Framework 1.0 ships with battle-tested orchestration patterns straight from Microsoft Research and AutoGen:

Sequential — agents process in order (writer → reviewer → editor)
Concurrent — fan out to multiple agents in parallel, converge results
Handoff — one agent delegates to another based on intent
Group chat — multiple agents discuss and converge on a solution
Magentic-One — the research-grade multi-agent pattern from MSR

All of them support streaming, checkpointing, human-in-the-loop approvals, and pause/resume. The checkpointing part is crucial — long-running workflows survive process restarts. For us .NET developers who’ve built durable workflows with Azure Functions, this feels familiar.

The features that matter most

Here’s my shortlist of what’s worth knowing:

Middleware hooks. You know how ASP.NET Core has middleware pipelines? Same concept, but for agent execution. Intercept every stage — add content safety, logging, compliance policies — without touching agent prompts. This is how you make agents enterprise-ready.

Pluggable memory. Conversational history, persistent key-value state, vector-based retrieval. Choose your backend: Foundry Agent Service, Mem0, Redis, Neo4j, or roll your own. Memory is what turns a stateless LLM call into an agent that actually remembers context.

Declarative YAML agents. Define your agent’s instructions, tools, memory, and orchestration topology in version-controlled YAML files. Load and run with a single API call. This is a game-changer for teams that want to iterate on agent behavior without redeploying code.

A2A and MCP support. MCP (Model Context Protocol) lets agents discover and invoke external tools dynamically. A2A (Agent-to-Agent protocol) enables cross-runtime collaboration — your .NET agents can coordinate with agents running in other frameworks. A2A 1.0 support is coming soon.

The preview features worth watching

Some features shipped as preview in 1.0 — functional but APIs may evolve:

DevUI — a browser-based local debugger for visualizing agent execution, message flows, and tool calls in real time. Think Application Insights, but for agent reasoning.
GitHub Copilot SDK and Claude Code SDK — use Copilot or Claude as an agent harness directly from your orchestration code. Compose a coding-capable agent alongside your other agents in the same workflow.
Agent Harness — a customizable local runtime giving agents access to shell, file system, and messaging loops. Think coding agents and automation patterns.
Skills — reusable domain capability packages that give agents structured capabilities out of the box.

Migrating from Semantic Kernel or AutoGen

If you have existing Semantic Kernel or AutoGen code, there are dedicated migration assistants that analyze your code and generate step-by-step migration plans. The Semantic Kernel migration guide and AutoGen migration guide walk you through everything.

If you’ve been on the RC packages, upgrading to 1.0 is just a version bump.

Wrapping up

Agent Framework 1.0 is the production milestone that enterprise teams have been waiting for. Stable APIs, multi-provider support, orchestration patterns that actually work at scale, and migration paths from both Semantic Kernel and AutoGen.

The framework is fully open source on GitHub, and you can get started today with dotnet add package Microsoft.Agents.AI. Check out the quickstart guide and the samples to get your hands dirty.

If you’ve been waiting for the “safe to use in production” signal — this is it.

Aspire 13.2's Dashboard Just Got a Telemetry API — and It Changes Everything

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

If you’ve been building distributed apps with .NET Aspire, you already know the dashboard is the single best thing about the whole experience. All your traces, logs, and metrics in one place — no external Jaeger, no Seq setup, no “let me check the other terminal” moments.

Aspire 13.2 just made it significantly better. James Newton-King announced the update, and honestly? The telemetry export and API features alone are worth the upgrade.

Export telemetry like a sane person

Here’s the scenario we’ve all lived through: you’re debugging a distributed issue, you finally reproduce it after twenty minutes of setup, and now you need to share what happened with your team. Before? Screenshots. Copy-pasting trace IDs. The usual mess.

Aspire 13.2 adds a proper Manage logs and telemetry dialog where you can:

Clear all telemetry (useful before a repro attempt)
Export selected telemetry to a ZIP file in standard OTLP/JSON format
Re-import that ZIP into any Aspire dashboard later

That last part is the killer feature. You reproduce a bug, export the telemetry, attach it to your work item, and your teammate can import it into their own dashboard to see exactly what you saw. No more “can you reproduce it on your machine?”

Individual traces, spans, and logs also get an “Export JSON” option in their context menus. Need to share one specific trace? Right-click, copy JSON, paste into your PR description. Done.

The telemetry API is the real game changer

This is what I’m most excited about. The dashboard now exposes an HTTP API under /api/telemetry for querying telemetry data programmatically. Available endpoints:

GET /api/telemetry/resources — list resources with telemetry
GET /api/telemetry/spans — query spans with filters
GET /api/telemetry/logs — query logs with filters
GET /api/telemetry/traces — list traces
GET /api/telemetry/traces/{traceId} — get all spans for a specific trace

Everything comes back in OTLP JSON format. This powers the new aspire agent mcp and aspire otel CLI commands, but the real implication is bigger: you can now build tooling, scripts, and AI agent integrations that query your app’s telemetry directly.

Imagine an AI coding agent that can look at your actual distributed traces while debugging. That’s not hypothetical anymore — that’s what this API enables.

GenAI telemetry gets practical

If you’re building AI-powered apps with Semantic Kernel or Microsoft.Extensions.AI, you’ll appreciate the improved GenAI telemetry visualizer. Aspire 13.2 adds:

AI tool descriptions rendered as Markdown
A dedicated GenAI button on the traces page for quick AI trace access
Better error handling for truncated or non-standard GenAI JSON
Click-to-highlight navigation between tool definitions

The blog post mentions that VS Code Copilot chat, Copilot CLI, and OpenCode all support configuring an OTEL_EXPORTER_OTLP_ENDPOINT. Point them at the Aspire dashboard and you can literally watch your AI agents think in real time through telemetry. That’s a debugging experience you won’t find anywhere else.

Wrapping up

Aspire 13.2 takes the dashboard from “nice debugging UI” to “programmable observability platform.” The export/import workflow alone saves real time on distributed debugging, and the telemetry API opens the door to AI-assisted diagnostics.

If you’re already on Aspire, upgrade. If you’re not — this is a good reason to check out aspire.dev and see what the fuss is about.

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

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

Seven releases in one month. That’s what the Azure Developer CLI (azd) team pushed in March 2026, and the headline feature is the one I’ve been waiting for: a local run-and-debug loop for AI agents.

PC Chan published the full roundup, and while there’s a lot in there, let me filter it down to what actually matters for .NET developers building AI-powered apps.

Run and debug AI agents without deploying

This is the big one. The new azure.ai.agents extension adds a set of commands that give you a proper inner-loop experience for AI agents:

azd ai agent run — starts your agent locally
azd ai agent invoke — sends messages to it (local or deployed)
azd ai agent show — displays container status and health
azd ai agent monitor — streams container logs in real time

Before this, testing an AI agent meant deploying to Microsoft Foundry every time you made a change. Now you can iterate locally, test your agent’s behavior, and only deploy when you’re ready. If you’ve been building agents with the Microsoft Agent Framework or Semantic Kernel, this changes your daily workflow.

The invoke command works against both local and deployed agents, which means you can use the same testing workflow regardless of where the agent is running. That’s the kind of detail that saves you from maintaining two sets of test scripts.

GitHub Copilot scaffolds your azd project

azd init now offers a “Set up with GitHub Copilot (Preview)” option. Instead of manually answering prompts about your project structure, a Copilot agent scaffolds the configuration for you. It checks for a dirty working directory before modifying anything and asks for MCP server tool consent upfront.

When a command fails, azd now offers AI-assisted troubleshooting: pick a category (explain, guidance, troubleshoot, or skip), let the agent suggest a fix, and retry — all without leaving the terminal. For complex infrastructure setups, that’s a real time saver.

Container App Jobs and deployment improvements

A few deployment features worth noting:

Container App Jobs: azd now deploys Microsoft.App/jobs through the existing host: containerapp config. Your Bicep template determines whether the target is a Container App or a Job — no extra setup.
Configurable deployment timeouts: New --timeout flag on azd deploy and a deployTimeout field in azure.yaml. No more guessing the default 1200-second limit.
Remote build fallback: When remote ACR build fails, azd falls back to local Docker/Podman build automatically.
Local preflight validation: Bicep parameters get validated locally before deploying, catching missing params without a round-trip to Azure.

Developer experience polish

Some smaller improvements that add up:

Automatic pnpm/yarn detection for JS/TS projects
pyproject.toml support for Python packaging
Local template directories — azd init --template now accepts filesystem paths for offline iteration
Better error messages in --no-prompt mode — all missing values reported at once with resolution commands
Build environment variables injected into all framework build subprocesses (.NET, Node.js, Java, Python)

That last one is subtle but important: your .NET build now has access to azd environment variables, which means you can do build-time configuration injection without extra scripting.

Wrapping up

The local AI agent debugging loop is the star of this release, but the accumulation of deployment improvements and DX polish makes azd feel more mature than ever. If you’re deploying .NET apps to Azure — especially AI agents — this update is worth the install.

Check the full release notes for every detail, or get started with azd install.

Visual Studio's March Update Lets You Build Custom Copilot Agents — and the find_symbol Tool Is a Big Deal

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

Visual Studio just got its most significant Copilot update yet. Mark Downie announced the March release, and the headline is custom agents — but honestly, the find_symbol tool buried further down might be the feature that changes your workflow the most.

Let me break down what’s actually here.

Custom Copilot agents in your repo

Want Copilot to follow your team’s coding standards, run your build pipeline, or query your internal docs? Now you can build exactly that.

Custom agents are defined as .agent.md files that you drop into .github/agents/ in your repository. Each agent gets full access to workspace awareness, code understanding, tools, your preferred model, and MCP connections to external services. They show up in the agent picker alongside the built-in agents.

This is the same pattern VS Code has been supporting — and it’s great to see Visual Studio catch up. For teams that have already built agents for VS Code, your .agent.md files should work across both IDEs (though tool names can vary, so test them).

The awesome-copilot repo has community-contributed agent configurations you can use as starting points.

Agent skills: reusable instruction packs

Skills are automatically picked up from .github/skills/ in your repo or ~/.copilot/skills/ in your profile. Each skill is a SKILL.md file following the Agent Skills specification.

Think of skills as modular expertise you can mix and match. You might have a skill for your API conventions, another for your testing patterns, and another for your deployment workflow. When a skill activates, it shows up in the chat so you know it’s being applied.

If you’ve been using skills in VS Code, they work the same way in Visual Studio now.

This is where things get really interesting. The new find_symbol tool gives Copilot’s agent mode actual language-service-powered symbol navigation. Instead of searching your code as text, the agent can:

Find all references to a symbol across your project
Access type information, declarations, and scope metadata
Navigate call sites with full language awareness

What this means in practice: when you ask Copilot to refactor a method or update a parameter signature across call sites, it can actually see your code’s structure. No more “the agent changed the method but missed three call sites” situations.

Supported languages include C#, C++, Razor, TypeScript, and anything with a supported LSP extension. For .NET developers, this is a massive improvement — C# codebases with deep type hierarchies and interfaces benefit enormously from symbol-aware navigation.

Profile tests with Copilot

There’s now a Profile with Copilot command in the Test Explorer context menu. Select a test, click profile, and the Profiling Agent automatically runs it and analyzes performance — combining CPU usage and instrumentation data to deliver actionable insights.

No more manually configuring profiler sessions, running the test, exporting results, and trying to read a flame graph. The agent does the analysis and tells you what’s slow and why. Currently .NET only, which makes sense given Visual Studio’s deep .NET diagnostics integration.

Perf tips during live debugging

Performance optimization now happens while you debug, not after. As you step through code, Visual Studio shows execution time and performance signals inline. See a slow line? Click the Perf Tip and ask Copilot for optimization suggestions right there.

The Profiling Agent captures runtime data automatically — elapsed time, CPU usage, memory behavior — and Copilot uses it to pinpoint hot spots. This keeps performance work as part of your debugging flow instead of a separate task you keep postponing.

Fix NuGet vulnerabilities from Solution Explorer

When a vulnerability is detected in a NuGet package, you now see a notification with a Fix with GitHub Copilot link directly in Solution Explorer. Click through and Copilot analyzes the vulnerability, recommends the right package updates, and implements them.

For teams that struggle to keep dependencies up to date (which is basically everyone), this removes the friction of “I know there’s a vulnerability but figuring out the right update path is a project in itself.”

Wrapping up

Custom agents and skills are the headline, but find_symbol is the sleeper hit — it fundamentally changes how accurate Copilot can be when refactoring .NET code. Combined with live profiling integration and vulnerability fixes, this update makes Visual Studio’s AI features feel genuinely practical rather than demo-ready.

Download Visual Studio 2026 Insiders to try it all out.

KubeCon Europe 2026: What .NET Developers Should Actually Care About

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

You know that feeling when a massive announcement post drops and you’re scrolling through it thinking “cool, but what does this actually change for me”? That’s me every KubeCon season.

Microsoft just published their full KubeCon Europe 2026 roundup — written by Brendan Burns himself — and honestly? There’s real substance here. Not just feature checkboxes, but the kind of operational improvements that change how you run things in production.

Let me break down what actually matters for us .NET developers.

mTLS without the service mesh tax

Here’s the thing about service meshes: everyone wants the security guarantees, nobody wants the operational overhead. AKS is finally closing that gap.

Azure Kubernetes Application Network gives you mutual TLS, application-aware authorization, and traffic telemetry — without deploying a full sidecar-heavy mesh. Combined with Cilium mTLS in Advanced Container Networking Services, you get encrypted pod-to-pod communication using X.509 certificates and SPIRE for identity management.

What this means in practice: your ASP.NET Core APIs talking to background workers, your gRPC services calling each other — all encrypted and identity-verified at the network level, with zero application code changes. That’s huge.

For teams migrating off ingress-nginx, there’s also Application Routing with Meshless Istio with full Kubernetes Gateway API support. No sidecars. Standards-based. And they shipped ingress2gateway tooling for incremental migration.

GPU observability that’s not an afterthought

If you’re running AI inference alongside your .NET services (and let’s be honest, who isn’t starting to?), you’ve probably hit the GPU monitoring blind spot. You’d get great CPU/memory dashboards and then… nothing for GPUs without manual exporter plumbing.

AKS now surfaces GPU metrics natively into managed Prometheus and Grafana. Same stack, same dashboards, same alerting pipeline. No custom exporters, no third-party agents.

On the network side, they added per-flow visibility for HTTP, gRPC, and Kafka traffic with a one-click Azure Monitor experience. IPs, ports, workloads, flow direction, policy decisions — all in built-in dashboards.

And here’s the one that made me do a double-take: agentic container networking adds a web UI where you can ask natural-language questions about your cluster’s network state. “Why is pod X not reaching service Y?” → read-only diagnostics from live telemetry. That’s genuinely useful at 2 AM.

Cross-cluster networking that doesn’t require a PhD

Multi-cluster Kubernetes has historically been a “bring your own networking glue” experience. Azure Kubernetes Fleet Manager now ships cross-cluster networking through managed Cilium cluster mesh:

Unified connectivity across AKS clusters
Global service registry for cross-cluster discovery
Configuration managed centrally, not repeated per cluster

If you’re running .NET microservices across regions for resilience or compliance, this replaces a lot of fragile custom plumbing. Service A in West Europe can discover and call Service B in East US through the mesh, with consistent routing and security policies.

Upgrades that don’t require courage

Let’s be honest — Kubernetes upgrades in production are stressful. “Upgrade and hope” has been the de facto strategy for too many teams, and it’s the main reason clusters fall behind on versions.

Two new capabilities change this:

Blue-green agent pool upgrades create a parallel node pool with the new configuration. Validate behavior, shift traffic gradually, and keep a clean rollback path. No more in-place mutations on production nodes.

Agent pool rollback lets you revert a node pool to its previous Kubernetes version and node image after an upgrade goes sideways — without rebuilding the cluster.

Together, these finally give operators real control over the upgrade lifecycle. For .NET teams, this matters because platform velocity directly controls how fast you can adopt new runtimes, security patches, and networking capabilities.

AI workloads are becoming first-class Kubernetes citizens

The upstream open-source work is equally important. Dynamic Resource Allocation (DRA) just went GA in Kubernetes 1.36, making GPU scheduling a proper first-class feature instead of a workaround.

A few projects worth watching:

Project	What it does
AI Runway	Common Kubernetes API for inference — deploy models without knowing K8s, with HuggingFace discovery and cost estimates
HolmesGPT	Agentic troubleshooting for cloud-native — now a CNCF Sandbox project
Dalec	Declarative container image builds with SBOM generation — fewer CVEs at the build stage

The direction is clear: your .NET API, your Semantic Kernel orchestration layer, and your inference workloads should all run on one consistent platform model. We’re getting there.

Where I’d start this week

If you’re evaluating these changes for your team, here’s my honest priority list:

Observability first — enable GPU metrics and network flow logs in a non-prod cluster. See what you’ve been missing.
Try blue-green upgrades — test the rollback workflow before your next production cluster upgrade. Build confidence in the process.
Pilot identity-aware networking — pick one internal service path and enable mTLS with Cilium. Measure the overhead (spoiler: it’s minimal).
Evaluate Fleet Manager — if you run more than two clusters, cross-cluster networking pays for itself in reduced custom glue.

Small experiments, fast feedback. That’s always the move.

Wrapping up

KubeCon announcements can be overwhelming, but this batch genuinely moves the needle for .NET teams on AKS. Better networking security without mesh overhead, real GPU observability, safer upgrades, and stronger AI infrastructure foundations.

If you’re already on AKS, this is a great moment to tighten your operational baseline. And if you’re planning to move .NET workloads to Kubernetes — the platform just got significantly more production-ready.

SQL MCP Server, Copilot in SSMS, and a Database Hub with AI Agents: What Actually Matters from SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft just kicked off SQLCon 2026 alongside FabCon in Atlanta, and there’s a lot to unpack. The original announcement covers everything from savings plans to enterprise compliance features. I’m going to skip the enterprise pricing slides and focus on the pieces that matter if you’re a developer building things with Azure SQL and AI.

SQL MCP Server is in public preview

This is the headline for me. Azure SQL Database Hyperscale now has a SQL MCP Server in public preview that lets you securely connect your SQL data to AI agents and Copilots using the Model Context Protocol.

If you’ve been following the MCP wave — and honestly, it’s hard to miss right now — this is a big deal. Instead of building custom data pipelines to feed your AI agents context from your database, you get a standardized protocol to expose SQL data directly. Your agents can query, reason over, and act on live database information.

For those of us building AI agents with Semantic Kernel or the Microsoft Agent Framework, this opens up a clean integration path. Your agent needs to check inventory? Look up a customer record? Validate an order? MCP gives it a structured way to do that without you writing bespoke data-fetching code for every scenario.

GitHub Copilot in SSMS 22 is now GA

If you spend any time in SQL Server Management Studio — and let’s be honest, most of us still do — GitHub Copilot is now generally available in SSMS 22. Same Copilot experience you already use in VS Code and Visual Studio, but for T-SQL.

The practical value here is straightforward: chat-based assistance for writing queries, refactoring stored procedures, troubleshooting performance issues, and handling admin tasks. Nothing revolutionary in concept, but having it right there in SSMS means you don’t need to context-switch to another editor just to get AI help with your database work.

Vector indexes got a serious upgrade

Azure SQL Database now has faster, more capable vector indexes with full insert, update, and delete support. That means your vector data stays current in real time — no batch reindexing needed.

Here’s what’s new:

Quantization for smaller index sizes without losing too much accuracy
Iterative filtering for more precise results
Tighter query optimizer integration for predictable performance

If you’re doing retrieval-augmented generation (RAG) with Azure SQL as your vector store, these improvements are directly useful. You can keep your vectors alongside your relational data in the same database, which simplifies your architecture significantly compared to running a separate vector database.

The same vector enhancements are also available in SQL database in Fabric, since both run on the same SQL engine underneath.

Database Hub in Fabric: agentic management

This one is more forward-looking, but it’s interesting. Microsoft announced the Database Hub in Microsoft Fabric (early access), which gives you a single pane of glass across Azure SQL, Cosmos DB, PostgreSQL, MySQL, and SQL Server via Arc.

The interesting angle isn’t just the unified view — it’s the agentic approach to management. AI agents continuously monitor your database estate, surface what changed, explain why it matters, and suggest what to do next. It’s a human-in-the-loop model where the agent does the legwork and you make the calls.

For teams managing more than a handful of databases, this could genuinely reduce the operational noise. Instead of jumping between portals and manually checking metrics, the agent brings the signal to you.

What this means for .NET developers

The thread connecting all these announcements is clear: Microsoft is embedding AI agents at every layer of the database stack. Not as a gimmick, but as a practical tooling layer.

If you’re building .NET apps backed by Azure SQL, here’s what I’d actually do:

Try the SQL MCP Server if you’re building AI agents. It’s the cleanest way to give your agents database access without custom plumbing.
Enable Copilot in SSMS if you haven’t already — free productivity win for daily SQL work.
Look into vector indexes if you’re doing RAG and currently running a separate vector store. Consolidating to Azure SQL means one less service to manage.

Wrapping up

The full announcement has more — savings plans, migration assistants, compliance features — but the developer story is in the MCP Server, the vector improvements, and the agentic management layer. These are the pieces that change how you build, not just how you budget.

Check out the full announcement from Shireesh Thota for the complete picture, and sign up for the Database Hub early access if you want to try the new management experience.

Azure DevOps MCP Server Lands in Microsoft Foundry: What This Means for Your AI Agents

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

MCP (Model Context Protocol) has been having a moment. If you’ve been following the AI agent ecosystem, you’ve probably noticed MCP servers popping up everywhere — giving agents the ability to interact with external tools and services through a standardized protocol.

Now the Azure DevOps MCP Server is available in Microsoft Foundry, and this is one of those integrations that makes you think about the practical possibilities.

What’s actually happening here

Microsoft already released the Azure DevOps MCP Server as a public preview — that’s the MCP server itself. What’s new is the Foundry integration. You can now add the Azure DevOps MCP Server to your Foundry agents directly from the tool catalog.

For those not familiar with Foundry yet: it’s Microsoft’s unified platform for building and managing AI-powered applications and agents at scale. Model access, orchestration, evaluation, deployment — all in one place.

Setting it up

The setup is surprisingly straightforward:

In your Foundry agent, go to Add Tools > Catalog
Search for “Azure DevOps”
Select the Azure DevOps MCP Server (preview) and click Create
Enter your organization name and connect

That’s it. Your agent now has access to Azure DevOps tools.

Controlling what your agent can access

Here’s the part I appreciate: you’re not stuck with an all-or-nothing approach. You can specify which tools are available to your agent. So if you only want it to read work items but not touch pipelines, you can configure that. Principle of least privilege, applied to your AI agents.

This matters for enterprise scenarios where you don’t want an agent accidentally triggering a deployment pipeline because someone asked it to “help with the release.”

Why this is interesting for .NET teams

Think about what this enables in practice:

Sprint planning assistants — agents that can pull work items, analyze velocity data, and suggest sprint capacity
Code review bots — agents that understand your PR context because they can actually read your repos and linked work items
Incident response — agents that can create work items, query recent deployments, and correlate bugs with recent changes
Developer onboarding — “What should I work on?” gets a real answer backed by actual project data

For .NET teams already using Azure DevOps for their CI/CD pipelines and project management, having an AI agent that can actually interact with those systems directly is a significant step toward useful automation (not just chatbot-as-a-service).

The bigger MCP picture

This is part of a broader trend: MCP servers are becoming the standard way AI agents interact with the outside world. We’re seeing them for GitHub, Azure DevOps, databases, SaaS APIs — and Foundry is becoming the hub where these connections all come together.

If you’re building agents in the .NET ecosystem, MCP is worth paying attention to. The protocol is standardized, the tooling is maturing, and the Foundry integration makes it accessible without having to manually wire up server connections.

Wrapping up

The Azure DevOps MCP Server in Foundry is in preview, so expect it to evolve. But the core workflow is solid: connect, configure tool access, and let your agents work with your DevOps data. If you’re already in the Foundry ecosystem, this is a few clicks away. Give it a try and see what workflows you can build.

Check out the full announcement for the step-by-step setup and more details.

Background Responses in Microsoft Agent Framework: No More Timeout Anxiety

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

If you’ve built anything with reasoning models like o3 or GPT-5.2, you know the pain. Your agent starts thinking through a complex task, the client sits there waiting, and somewhere between “this is fine” and “did it crash?” your connection times out. All that work? Gone.

Microsoft Agent Framework just shipped background responses — and honestly, this is one of those features that should’ve existed from day one.

The problem with blocking calls

In a traditional request-response pattern, your client blocks until the agent finishes. That works fine for quick tasks. But when you’re asking a reasoning model to do deep research, multi-step analysis, or generate a 20-page report? You’re looking at minutes of wall-clock time. During that window:

HTTP connections can time out
Network blips kill the entire operation
Your user stares at a spinner wondering if anything is happening

Background responses flip this on its head.

How continuation tokens work

Instead of blocking, you kick off the agent task and get back a continuation token. Think of it like a claim ticket at a repair shop — you don’t stand at the counter waiting, you come back when it’s ready.

The flow is straightforward:

Send your request with AllowBackgroundResponses = true
If the agent supports background processing, you get a continuation token
Poll on your schedule until the token comes back null — that means the result is ready

Here’s the .NET version:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

If the agent completes immediately (simple tasks, models that don’t need background processing), no continuation token is returned. Your code just works — no special handling needed.

Streaming with resume: the real magic

Polling is fine for fire-and-forget scenarios, but what about when you want real-time progress? Background responses also support streaming with built-in resumption.

Each streamed update carries its own continuation token. If your connection drops mid-stream, you pick up exactly where you left off:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

The agent keeps processing server-side regardless of what’s happening with your client. That’s built-in fault tolerance without you writing retry logic or circuit breakers.

When to actually use this

Not every agent call needs background responses. For quick completions, you’re adding complexity for no reason. But here’s where they shine:

Complex reasoning tasks — multi-step analysis, deep research, anything that makes a reasoning model actually think
Long content generation — detailed reports, multi-part documents, extensive analysis
Unreliable networks — mobile clients, edge deployments, flaky corporate VPNs
Async UX patterns — submit a task, go do something else, come back for results

For us .NET developers building enterprise apps, that last one is particularly interesting. Think about a Blazor app where a user requests a complex report — you fire off the agent task, show them a progress indicator, and let them keep working. No WebSocket gymnastics, no custom queue infrastructure, just a token and a poll loop.

Wrapping up

Background responses are available now in both .NET and Python through Microsoft Agent Framework. If you’re building agents that do anything more complex than simple Q&A, this is worth adding to your toolkit. The continuation token pattern keeps things simple while solving a very real production problem.

Check out the full documentation for the complete API reference and more examples.

Foundry Agent Service is GA: What Actually Matters for .NET Agent Builders

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

Let’s be honest — building an AI agent prototype is the easy part. The hard part is everything after: getting it into production with proper network isolation, running evaluations that actually mean something, handling compliance requirements, and not breaking things at 2 AM.

The Foundry Agent Service just went GA, and this release is laser-focused on that “everything after” gap.

Built on the Responses API

Here’s the headline: the next-gen Foundry Agent Service is built on the OpenAI Responses API. If you’re already building with that wire protocol, migrating to Foundry is minimal code changes. What you gain: enterprise security, private networking, Entra RBAC, full tracing, and evaluation — on top of your existing agent logic.

The architecture is intentionally open. You’re not locked to one model provider or one orchestration framework. Use DeepSeek for planning, OpenAI for generation, LangGraph for orchestration — the runtime handles the consistency layer.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

If you’re coming from the azure-ai-agents package, agents are now first-class operations on AIProjectClient in azure-ai-projects. Drop the standalone pin and use get_openai_client() to drive responses.

Private networking: the enterprise blocker removed

This is the feature that unblocks enterprise adoption. Foundry now supports full end-to-end private networking with BYO VNet:

No public egress — agent traffic never touches the public internet
Container/subnet injection into your network for local communication
Tool connectivity included — MCP servers, Azure AI Search, Fabric data agents all operate over private paths

That last point is critical. It’s not just inference calls that stay private — every tool invocation and retrieval call stays inside your network boundary too. For teams operating under data classification policies that prohibit external routing, this is what was missing.

MCP authentication done right

MCP server connections now support the full spectrum of auth patterns:

Auth method	When to use
Key-based	Simple shared access for org-wide internal tools
Entra Agent Identity	Service-to-service; the agent authenticates as itself
Entra Managed Identity	Per-project isolation; no credential management
OAuth Identity Passthrough	User-delegated access; agent acts on behalf of users

OAuth Identity Passthrough is the interesting one. When users need to grant an agent access to their personal data — their OneDrive, their Salesforce org, a SaaS API scoped by user — the agent acts on their behalf with standard OAuth flows. No shared system identity pretending to be everyone.

Voice Live: speech-to-speech without the plumbing

Adding voice to an agent used to mean stitching together STT, LLM, and TTS — three services, three latency hops, three billing surfaces, all synchronized by hand. Voice Live collapses that into a single managed API with:

Semantic voice activity and end-of-turn detection (understands meaning, not just silence)
Server-side noise suppression and echo cancellation
Barge-in support (users can interrupt mid-response)

Voice interactions go through the same agent runtime as text. Same evaluators, same traces, same cost visibility. For customer support, field service, or accessibility scenarios, this replaces what previously required a custom audio pipeline.

Evaluations: from checkbox to continuous monitoring

This is where Foundry gets serious about production quality. The evaluation system now has three layers:

Out-of-the-box evaluators — coherence, relevance, groundedness, retrieval quality, safety. Connect to a dataset or live traffic and get scores back.
Custom evaluators — encode your own business logic, tone standards, and domain-specific compliance rules.
Continuous evaluation — Foundry samples live production traffic, runs your evaluator suite, and surfaces results through dashboards. Set Azure Monitor alerts for when groundedness drops or safety thresholds breach.

Everything publishes to Azure Monitor Application Insights. Agent quality, infrastructure health, cost, and app telemetry — all in one place.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Six new regions for hosted agents

Hosted agents are now available in East US, North Central US, Sweden Central, Southeast Asia, Japan East, and more. This matters for data residency requirements and for compressing latency when your agent runs close to its data sources.

Why this matters for .NET developers

Even though the code samples in the GA announcement are Python-first, the underlying infrastructure is language-agnostic — and the .NET SDK for azure-ai-projects follows the same patterns. The Responses API, the evaluation framework, the private networking, the MCP auth — all of this is available from .NET.

If you’ve been waiting for AI agents to go from “cool demo” to “I can actually ship this at work,” this GA release is the signal. Private networking, proper auth, continuous evaluation, and production monitoring are the pieces that were missing.

Wrapping up

Foundry Agent Service is available now. Install the SDK, open the portal, and start building. The quickstart guide takes you from zero to a running agent in minutes.

For the full technical deep-dive with all code samples, check the GA announcement.

From Laptop to Production: Deploying AI Agents to Microsoft Foundry with Two Commands

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

You know that gap between “it works on my machine” and “it’s deployed and serving traffic”? For AI agents, that gap has been painfully wide. You need to provision resources, deploy models, wire up identity, set up monitoring — and that’s before anyone can actually call your agent.

The Azure Developer CLI just made this a two-command affair.

The new `azd ai agent` workflow

Let me walk through what this actually looks like. You have an AI agent project — let’s say a hotel concierge agent. It works locally. You want it running on Microsoft Foundry.

azd ai agent init
azd up

That’s it. Two commands. azd ai agent init scaffolds the infrastructure-as-code in your repo, and azd up provisions everything on Azure and publishes your agent. You get a direct link to your agent in the Foundry portal.

What happens under the hood

The init command generates real, inspectable Bicep templates in your repo:

A Foundry Resource (top-level container)
A Foundry Project (where your agent lives)
Model deployment configuration (GPT-4o, etc.)
Managed identity with proper RBAC role assignments
azure.yaml for the service map
agent.yaml with agent metadata and environment variables

Here’s the key part: you own all of this. It’s versioned Bicep in your repo. You can inspect it, customize it, and commit it alongside your agent code. No magic black boxes.

The dev inner loop

What I really like is the local development story. When you’re iterating on agent logic, you don’t want to redeploy every time you change a prompt:

azd ai agent run

This starts your agent locally. Pair it with azd ai agent invoke to send test prompts, and you’ve got a tight feedback loop. Edit code, restart, invoke, repeat.

The invoke command is smart about routing too — when a local agent is running, it targets that automatically. When it’s not, it hits the remote endpoint.

Real-time monitoring

This is the feature that sold me. Once your agent is deployed:

azd ai agent monitor --follow

Every request and response flowing through your agent streams to your terminal in real time. For debugging production issues, this is invaluable. No digging through log analytics, no waiting for metrics to aggregate — you see what’s happening right now.

The full command set

Here’s the quick reference:

Command	What it does
`azd ai agent init`	Scaffold a Foundry agent project with IaC
`azd up`	Provision Azure resources and deploy the agent
`azd ai agent invoke`	Send prompts to the remote or local agent
`azd ai agent run`	Run the agent locally for development
`azd ai agent monitor`	Stream real-time logs from the published agent
`azd ai agent show`	Check agent health and status
`azd down`	Clean up all Azure resources

Why this matters for .NET developers

Even though the sample in the announcement is Python-based, the infrastructure story is language-agnostic. Your .NET agent gets the same Bicep scaffolding, the same managed identity setup, the same monitoring pipeline. And if you’re already using azd for your .NET Aspire apps or Azure deployments, this fits right into your existing workflow.

The deployment gap for AI agents has been one of the biggest friction points in the ecosystem. Going from a working prototype to a production endpoint with proper identity, networking, and monitoring shouldn’t require a week of DevOps work. Now it requires two commands and a few minutes.

Wrapping up

azd ai agent is available now. If you’ve been putting off deploying your AI agents because the infrastructure setup felt like too much work, give this a shot. Check out the full walkthrough for the complete step-by-step including frontend chat app integration.

VS Code 1.112: What .NET Developers Should Actually Care About

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

VS Code 1.112 just landed, and honestly? This one hits different if you’re spending your days in .NET land. There’s a lot in the official release notes, but let me save you some scrolling and focus on what actually matters for us.

Copilot CLI just got way more useful

The big theme this release is agent autonomy — giving Copilot more room to do its thing without you babysitting every step.

Message steering and queueing

You know that moment when Copilot CLI is halfway through a task and you realize you forgot to mention something? Before, you had to wait. Now you can just send messages while a request is still running — either to steer the current response or queue up follow-up instructions.

This is huge for those longer dotnet scaffolding tasks where you’re watching Copilot set up a project and think “oh wait, I also need MassTransit in there.”

Permission levels

This is the one I’m most excited about. Copilot CLI sessions now support three permission levels:

Default Permissions — the usual flow where tools ask for confirmation before running
Bypass Approvals — auto-approves everything and retries on errors
Autopilot — goes fully autonomous: approves tools, answers its own questions, and keeps going until the task is done

If you’re doing something like scaffolding a new ASP.NET Core API with Entity Framework, migrations, and a Docker setup — Autopilot mode means you describe what you want and go grab a coffee. It’ll figure it out.

You can enable Autopilot with the chat.autopilot.enabled setting.

Preview changes before delegation

When you delegate a task to Copilot CLI, it creates a worktree. Before, if you had uncommitted changes, you had to check Source Control to see what would be affected. Now the Chat view shows pending changes right there before you decide whether to copy, move, or ignore them.

Small thing, but it saves you from that “wait, what did I have staged?” moment.

Debug web apps without leaving VS Code

The integrated browser now supports full debugging. You can set breakpoints, step through code, and inspect variables — all inside VS Code. No more switching to Edge DevTools.

There’s a new editor-browser debug type, and if you already have existing msedge or chrome launch configurations, migrating is as simple as changing the type field in your launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

For Blazor developers, this is a game changer. You’re already running dotnet watch in the terminal — now your debugging stays in the same window too.

The browser also got independent zoom levels (finally), proper right-click context menus, and the zoom is remembered per website.

MCP server sandboxing

This one matters more than you might think. If you’re using MCP servers — maybe you’ve set up a custom one for your Azure resources or database queries — they’ve been running with the same permissions as your VS Code process. That means full access to your filesystem, network, everything.

Now you can sandbox them. In your mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

When a sandboxed server needs access to something it doesn’t have, VS Code prompts you to grant permission. Much better than the “hope nobody does anything weird” approach.

Note: Sandboxing is available on macOS and Linux for now. Windows support is coming — remote scenarios like WSL do work though.

Monorepo customizations discovery

If you’re working in a monorepo (and let’s be honest, many enterprise .NET solutions end up as one), this solves a real pain point.

Previously, if you opened a subfolder of your repo, VS Code wouldn’t find your copilot-instructions.md, AGENTS.md, or custom skills sitting at the repository root. Now with the chat.useCustomizationsInParentRepositories setting, it walks up to the .git root and discovers everything.

This means your team can share agent instructions, prompt files, and custom tools across all projects in a monorepo without everyone having to open the root folder.

/troubleshoot for agent debugging

Ever set up custom instructions or skills and wonder why they’re not being picked up? The new /troubleshoot skill reads agent debug logs and tells you what happened — which tools were used or skipped, why instructions didn’t load, and what’s causing slow responses.

Enable it with:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Then just type /troubleshoot why is my custom skill not loading? in chat.

You can also export and import these debug logs now, which is great for sharing with your team when something isn’t working as expected.

Image and binary file support

Agents can now read image files from disk and binary files natively. The binary files are presented in hexdump format, and image outputs (like screenshots from the integrated browser) show up in a carousel view.

For .NET developers, think: paste a screenshot of a UI bug into chat and have the agent understand what’s wrong, or have it analyze the output of a Blazor component rendering.

Automatic symbol references

Small quality-of-life improvement: when you copy a symbol name (a class, method, etc.) and paste it into chat, VS Code now automatically converts it to a #sym:Name reference. This gives the agent full context about that symbol without you having to manually add it.

If you want plain text instead, use Ctrl+Shift+V.

Plugins can now be enabled/disabled

Previously, disabling an MCP server or plugin meant uninstalling it. Now you can toggle them on and off — both globally and per-workspace. Right-click in the Extensions view or the Customizations view and you’re done.

Plugins from npm and pypi can also auto-update now, though they’ll ask for approval first since updates mean running new code on your machine.

Wrapping up

VS Code 1.112 is clearly pushing hard on the agent experience — more autonomy, better debugging, tighter security. For .NET developers, the integrated browser debugging and Copilot CLI improvements are the standout features.

If you haven’t tried running a full Copilot CLI session in Autopilot mode for a .NET project yet, this release is a good time to start. Just remember to set your permissions and let it cook.

Download VS Code 1.112 or update from within VS Code via Help > Check for Updates.

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.

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

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

The Handoff Pattern: When One Agent Isn't Enough

How Handoff Works

A Minimal Example

When to Use Handoff (and When Not To)

Back-Edges and Human-in-the-Loop

Wrapping Up

Durable Workflows in Microsoft Agent Framework: From In-Memory to Azure Functions

The Core Building Blocks

The In-Memory Runner for Local Dev

Adding Durability with Durable Task

Azure Functions Hosting

Why This Matters

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

Building Agents Is the Easy Part — Running Them Safely Is the Hard Part

What Each Project Actually Does

Plugging In Is Just Adding Middleware

What You Get

Five Industry Scenarios

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

Azure SQL Can Generate Embeddings Now — In Pure T-SQL, No App Layer Needed

What They Do

The Complete Workflow

Supported API Formats and Options

What This Enables for .NET Applications

Wrapping Up

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

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

Building an AI-Powered Conference App with .NET's Composable Stack

What ConferencePulse does

Microsoft.Extensions.AI: one abstraction for everything

DataIngestion pipeline

VectorData: provider-agnostic search

MCP: session content as tools

Agent Framework: parallel multi-agent summary

The design principle

Microsoft Agent Framework Part 3: From Tools to Workflows — The Building Blocks Click Into Place

What an Agent Actually Is (vs. a Chatbot)

The Deployment Flow with `azd`