Agent-Framework | The .NET Blog

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

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

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

Foundry Local Is Generally Available

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

GPT-5.5

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

Agent Framework Tracing in Foundry

Two tracing features ship in preview this month:

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

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

CodeAct with Hyperlight (Alpha)

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

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

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

Agent Monitoring Dashboard (Preview)

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

Continuous Evaluation Custom Evaluators (Preview)

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

Agent Inventory in Control Plane

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

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

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

A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET

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

A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET — the A2A Protocol just hit v1.0, and both the A2A Agent (client) and A2A Hosting (server) packages for .NET are updated to match.

What A2A v1 actually is

A2A is an open interoperability protocol for AI agents backed by a technical steering committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. The v1 label means it is now a stable, production-ready standard — not a moving target. The SDK and Agent Framework packages that implement it are still in preview, but the protocol itself is locked.

v1 improves on v0.3 with multi-tenancy support, signed Agent Cards for cryptographic identity, improved security flows, and a web-aligned architecture overall.

Connecting to a remote A2A agent

A remote A2A agent is just an AIAgent in your code — same RunAsync, same streaming, same session handling. Two ways to get one:

using A2A;
using Microsoft.Agents.AI;

// Discovery via well-known URI
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// Direct configuration
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// Streaming works the same way
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

The A2ACardResolver approach does automatic discovery via the /.well-known/agent-card.json endpoint. The direct A2AClient path gives you explicit control over the name and description surfaced to your orchestration layer.

Exposing your agent as an A2A endpoint

Any AIAgent you’ve already built — on Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, or AWS Bedrock — can be exposed as an A2A endpoint with two lines in ASP.NET Core:

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");
// agent card auto-discovered at /.well-known/agent-card.json

The agent card is served automatically at the well-known URI, so any A2A-compliant client can discover and call your agent without extra configuration.

What this means in practice

The stable v1 protocol means you can wire your .NET agents to agents built in Python, Java, or any other language without worrying about breaking changes. The cryptographic identity in signed Agent Cards also gives you a foundation for trust verification between agents — useful once you’re operating more than a handful of them.

See the full post for the complete changelog and migration notes from v0.3.

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.

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.

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.

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.

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.

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.

Agent-Framework | The .NET Blog

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

Foundry Local Is Generally Available

GPT-5.5

Agent Framework Tracing in Foundry

CodeAct with Hyperlight (Alpha)

Agent Monitoring Dashboard (Preview)

Continuous Evaluation Custom Evaluators (Preview)

Agent Inventory in Control Plane

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

A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET

What A2A v1 actually is

Connecting to a remote A2A agent

Exposing your agent as an A2A endpoint

What this means in practice

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

What is CodeAct?

The safety piece: Hyperlight micro-VMs

Wiring it up

Mixing CodeAct with approval-gated tools

When to use CodeAct (and when not to)

Try it now

Wrapping up

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

The GPT-5 progression

What’s actually different

Pricing

Why Foundry matters here

Getting started

Wrapping up

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

Two fundamental patterns

Service-managed: linear vs forking

Client-managed: you own the complexity

How Agent Framework abstracts this

The Responses API is uniquely flexible

Provider quick reference

How to choose

Wrapping up

Agent Skills in .NET Just Got Seriously Flexible

File-based skills: the starting point

Class-based skills: ship via NuGet

Inline skills: the quick bridge

Script approval: human-in-the-loop

Why this combination matters

Wrapping up

Building Real-Time Multi-Agent UIs That Don't Feel Like a Black Box

Why this matters for .NET developers

The handoff topology is the real star

Human-in-the-loop that actually works

Wiring it up is surprisingly simple

My take

Wrapping up

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

The short version

Getting started is almost unfairly simple

Multi-agent orchestration — this is the real deal

The Deployment Flow with `azd`