AI Agents | The .NET Blog

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.

SQL MCP Server on Azure App Service — No Containers Required

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

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

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

What’s SQL MCP Server, Again?

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

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

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

The Container Problem (and the Solution)

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

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

Here’s the local setup flow in a nutshell:

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

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

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

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

# Start the server
dab start

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

Authentication That Doesn’t Involve Shared API Keys

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

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

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

Deploying to App Service

The actual deployment is straightforward Azure CLI work:

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

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

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

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

Why This Matters for .NET Developers

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

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

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

Wrapping Up

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

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

Governing MCP Tool Calls in .NET with the Agent Governance Toolkit

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

Governing MCP Tool Calls in .NET with the Agent Governance Toolkit is worth a close look if you are building or operating .NET systems at scale.

From my perspective, the important part is not the headline feature but how quickly a team can convert it into a safer, repeatable engineering workflow.

Why it matters for .NET teams

Most teams are balancing delivery speed, platform consistency, and governance. This update is useful because it gives you a more concrete path to improve one of those constraints without rewriting everything.

Practical next steps

Validate the feature in a small .NET pilot with production-like data.
Add clear rollback and observability checkpoints before broader rollout.
Capture the implementation pattern in your internal templates so other teams can reuse it.

Source

Original article: https://devblogs.microsoft.com/dotnet/governing-mcp-tool-calls-in-dotnet-with-the-agent-governance-toolkit/

Visual Studio April Update: Cloud Agent Integration for .NET Workflows

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

Visual Studio April Update: Cloud Agent Integration for .NET Workflows is worth a close look if you are building or operating .NET systems at scale.

From my perspective, the important part is not the headline feature but how quickly a team can convert it into a safer, repeatable engineering workflow.

Why it matters for .NET teams

Practical next steps

Validate the feature in a small .NET pilot with production-like data.
Add clear rollback and observability checkpoints before broader rollout.
Capture the implementation pattern in your internal templates so other teams can reuse it.

Source

Original article: https://devblogs.microsoft.com/visualstudio/visual-studio-april-update-cloud-agent-integration/