Azure Functions | The .NET Blog

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

Stop Hammering a Struggling Dependency: Retry Patterns for Azure Functions + Service Bus

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

Here’s how a recoverable fault becomes an outage in a Functions app: a dependency starts timing out, every Function instance retries immediately and indefinitely, the dependency gets hammered with hundreds of concurrent failed requests, and what started as a transient hiccup turns into a system-wide backpressure event.

You probably know this story. Azure Functions scale out fast — that’s the whole point. But “scale out fast” and “retry immediately” together can make failures dramatically worse.

Two patterns help. Exponential backoff and circuit breaker. Both are now natively supported for Service Bus-triggered Azure Functions.

Two Patterns, Different Roles

These patterns are complementary, not alternatives:

Exponential backoff answers: when should I try again? It increases the delay between retries so a dependency has time to recover. Message-level, pacing the retry timing.

Circuit breaker answers: should I call this dependency at all right now? It stops repeated calls to an unhealthy dependency after a failure threshold is hit, then probes carefully after a cooldown period. System-level, preventing retry storms.

You want both. Backoff handles per-message retry pacing. Circuit breaker handles aggregate health decisions.

Why This Matters Especially for Service Bus

The queue absorbs burst traffic, which is good. But without controls, the queue can grow while workers keep wasting compute on calls that will fail. Poison messages stay active longer than they should. Hot partitions or limited downstream capacity create cascading problems.

The safer design:

Detect transient failure
Delay the next attempt with exponential backoff
Stop calling the dependency when a failure threshold is reached (circuit open)
Resume carefully after a cooldown period (circuit probe)
Move irrecoverable work to dead-letter or a quarantine path

What the Native Support Looks Like

The new support integrates with the existing Azure Functions host model — no extra libraries, no custom implementations. Configuration goes in your host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

Circuit breaker configuration sets the failure threshold and reset interval so unhealthy dependencies don’t get pummeled during recovery.

Languages Covered

This isn’t .NET only. The feature covers dotnet, JavaScript, TypeScript, and Python — the full set of Service Bus trigger supported languages in Azure Functions.

Wrapping Up

Retry patterns aren’t exciting to configure until the first time a downstream outage causes your Functions to compound the problem instead of gracefully degrading. Setting these up proactively is cheap. Retrofitting them during an incident is not.

Original post: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

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.