* .NET: Add Microsoft Fabric sample #3674 (#4230) Co-authored-by: Chris <66376200+crickman@users.noreply.github.com> * Python: Phase 2: Embedding clients for Ollama, Bedrock, and Azure AI Inference (#4207) * Phase 2: Embedding clients for Ollama, Bedrock, and Azure AI Inference Add embedding client implementations to existing provider packages: - OllamaEmbeddingClient: Text embeddings via Ollama's embed API - BedrockEmbeddingClient: Text embeddings via Amazon Titan on Bedrock - AzureAIInferenceEmbeddingClient: Text and image embeddings via Azure AI Inference, supporting Content | str input with separate model IDs for text (AZURE_AI_INFERENCE_EMBEDDING_MODEL_ID) and image (AZURE_AI_INFERENCE_IMAGE_EMBEDDING_MODEL_ID) endpoints Additional changes: - Rename EmbeddingCoT -> EmbeddingT, EmbeddingOptionsCoT -> EmbeddingOptionsT - Add otel_provider_name passthrough to all embedding clients - Register integration pytest marker in all packages - Add lazy-loading namespace exports for Ollama and Bedrock embeddings - Add image embedding sample using Cohere-embed-v3-english - Add azure-ai-inference dependency to azure-ai package Part of #1188 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix mypy duplicate name and ruff lint issues - Rename second 'vector' variable to 'img_vector' in image embedding loop - Combine nested with statements in tests - Remove unused result assignments in tests Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * updates from feedback * Fix CI failures in embedding usage handling - Fix Azure AI embedding mypy issues by normalizing vectors to list[float], safely accumulating optional usage token fields, and filtering None entries before constructing GeneratedEmbeddings - Avoid Bandit false positive by initializing usage details as an empty dict - Update OpenAI embedding tests to assert canonical usage keys (input_token_count/total_token_count) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [Purview] Mark responses as responses and fix epoch bug for python long overflow (#4225) * .NET: Support InvokeMcpTool for declarative workflows (#4204) * Initial implementation of InvokeMcpTool in declarative workflow * Cleaned up sample implementation * Updated sample comments. * Added missing executor routing attribute * Fix PR comments. * Updated based on PR comments. * Updated based on PR comments. * Removed unnecessary using statement. * Update Python package versions to rc2 (#4258) - Bump core and azure-ai to 1.0.0rc2 - Bump preview packages to 1.0.0b260225 - Update dependencies to >=1.0.0rc2 - Add CHANGELOG entries for changes since rc1 - Update uv.lock Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * .NET: Fixing issue where OpenTelemetry span is never exported in .NET in-process workflow execution (#4196) * 1. Add reproduction test for issue #4155: workflow.run Activity never stopped in streaming OffThread path The WorkflowRunActivity_IsStopped_Streaming_OffThread test demonstrates that the workflow.run OpenTelemetry Activity created in StreamingRunEventStream.RunLoopAsync is started but never stopped when using the OffThread/Default streaming execution. The background run loop keeps running after event consumption completes, so the using Activity? declaration never disposes until explicit StopAsync() is called. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> 2. Fix workflow.run Activity never stopped in streaming OffThread execution (#4155) The workflow.run OpenTelemetry Activity in StreamingRunEventStream.RunLoopAsync was scoped to the method lifetime via 'using'. Since the run loop only exits on cancellation, the Activity was never stopped/exported until explicit disposal. Fix: Remove 'using' and explicitly dispose the Activity when the workflow reaches Idle status (all supersteps complete). A safety-net disposal in the finally block handles cancellation and error paths. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add root-level workflow.session activity spanning run loop lifetime\n\nImplements two-level telemetry hierarchy per PR feedback from lokitoth:\n- workflow.session: spans the entire run loop / stream lifetime\n- workflow_invoke: per input-to-halt cycle, nested within the session\n\nThis ensures the session activity stays open across multiple turns,\nwhile individual run activities are created and disposed per cycle.\n\nAlso fixes linkedSource CancellationTokenSource disposal leak in\nStreamingRunEventStream (added using declaration)." * Address Copilot review: fix Activity/CTS disposal, rename activity, add error tag\n\n1. LockstepRunEventStream: Remove 'using' from Activity in async iterator\n and manually dispose in finally block (fixes #4155 pattern). Also dispose\n linkedSource CTS in finally to prevent leak.\n2. Tags.cs: Add ErrorMessage (\"error.message\") tag for runtime errors,\n distinct from BuildErrorMessage (\"build.error.message\").\n3. ActivityNames: Rename WorkflowRun from \"workflow_invoke\" to \"workflow.run\"\n for cross-language consistency.\n4. WorkflowTelemetryContext: Fix XML doc to say \"outer/parent span\" instead\n of \"root-level span\".\n5. ObservabilityTests: Assert WorkflowSession absence when DisableWorkflowRun\n is true.\n6. WorkflowRunActivityStopTests: Fix streaming test race by disposing\n StreamingRun before asserting activities are stopped.\n7. StreamingRunEventStream/LockstepRunEventStream: Use Tags.ErrorMessage\n instead of Tags.BuildErrorMessage for runtime error events." * Review fixes: revert workflow_invoke rename, use 'using' for linkedSource, move SessionStarted earlier\n\n- Revert ActivityNames.WorkflowRun back to \"workflow_invoke\" (OTEL semantic convention contract)\n- Use 'using' declaration for linkedSource CTS in LockstepRunEventStream (no timing sensitivity)\n- Move SessionStarted event before WaitForInputAsync in StreamingRunEventStream to match Lockstep behavior" * Improve naming and comments in WorkflowRunActivityStopTests" * Prevent session Activity.Current leak in lockstep mode, add nesting test Save and restore Activity.Current in LockstepRunEventStream.Start() so the session activity doesn't leak into caller code via AsyncLocal. Re-establish Activity.Current = sessionActivity before creating the run activity in TakeEventStreamAsync to preserve parent-child nesting. Add test verifying app activities after RunAsync are not parented under the session, and that the workflow_invoke activity nests under the session." * Fix stale XML doc: WorkflowRun -> WorkflowInvoke in ObservabilityTests --------- Co-authored-by: alliscode <bentho@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Python / .NET Samples - Restructure and Improve Samples (Feature Branc… (#4092) * Python: .NET Samples - Restructure and Improve Samples (Feature Branch) (#4091) * Moved by agent (#4094) * Fix readme links * .NET Samples - Create `04-hosting` learning path step (#4098) * Agent move * Agent reorderd * Remove A2A section from README Removed A2A section from the Getting Started README. * Agent fixed links * Fix broken sample links in durable-agents README (#4101) * Initial plan * Fix broken internal links in documentation Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Revert template link changes; keep only durable-agents README fix Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * .NET Samples - Create `03-workflows` learning path step (#4102) * Fix solution project path * Python: Fix broken markdown links to repo resources (outside /docs) (#4105) * Initial plan * Fix broken markdown links to repo resources Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Update README to rename .NET Workflows Samples section --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * .NET Samples - Create `02-agents` learning path step (#4107) * .NET: Fix broken relative link in GroupChatToolApproval README (#4108) * Initial plan * Fix broken link in GroupChatToolApproval README Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Update labeler configuration for workflow samples * .NET - Reorder Agents samples to start from Step01 instead of Step04 (#4110) * Fix solution * Resolve new sample paths * Move new AgentSkills and AgentWithMemory_Step04 samples * Fix link * Fix readme path * fix: update stale dotnet/samples/Durable path reference in AGENTS.md Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Moved new sample * Update solution * Resolve merge (new sample) * Sync to new sample - FoundryAgents_Step21_BingCustomSearch * Updated README * .NET Samples - Configuration Naming Update (#4149) * .NET: Restore AzureFunctions index parity with ConsoleApps under DurableAgents samples (#4221) * Clean-up `05_host_your_agent` * Config setting consistency * Refine samples * AGENTS.md * Move new samples * Re-order samples * Move new project and fixup solution * Fixup model config * Fix up new UT project --------- Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> * Python: Fix Bedrock embedding test stub missing meta attribute (#4287) * Fix Bedrock embedding test stub missing meta attribute * Increase test coverage so gate passes * Python: (ag-ui): fix approval payloads being re-processed on subsequent conversation turns (#4232) * Fix ag-ui tool call issue * Safe json fix * Python: Update workflow orchestration samples to use AzureOpenAIResponsesClient (#4285) * Update workflow orchestration samples to use AzureOpenAIResponsesClient * Fix broken link * Move scripts to scripts folder --------- Co-authored-by: Roger Barreto <19890735+rogerbarreto@users.noreply.github.com> Co-authored-by: Chris <66376200+crickman@users.noreply.github.com> Co-authored-by: Eduard van Valkenburg <eavanvalkenburg@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Rishabh Chawla <rishabhchawla1995@gmail.com> Co-authored-by: Peter Ibekwe <109177538+peibekwe@users.noreply.github.com> Co-authored-by: Dmytro Struk <13853051+dmytrostruk@users.noreply.github.com> Co-authored-by: Ben Thomas <ben.thomas@microsoft.com> Co-authored-by: alliscode <bentho@microsoft.com> Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: Evan Mattson <35585003+moonbox3@users.noreply.github.com>
Durable agents
Overview
Durable agents extend the standard Microsoft Agent Framework with durable state management powered by the Durable Task framework. An ordinary Agent Framework agent runs in-process: its conversation history lives in memory and is lost when the process ends. A durable agent persists conversation history and execution state in external storage so that sessions survive process restarts, failures, and scale-out events.
| Capability | Ordinary agent | Durable agent |
|---|---|---|
| Conversation history | In-memory only | Durably persisted |
| Failure recovery | State lost on crash | Automatically resumed |
| Multi-instance scale-out | Not supported | Any worker can resume a session |
| Multi-agent orchestrations | Manual coordination | Deterministic, checkpointed workflows |
| Human-in-the-loop | Must keep process alive | Can wait days/weeks with zero compute |
| Hosting | Any process | Console app, Azure Functions, or any Durable Task–compatible host |
Note
For a step-by-step tutorial and deployment guidance, see Azure Functions (Durable) on Microsoft Learn.
How durable agents work
Durable agents are implemented on top of Durable Entities (also called "virtual actors"). Each agent session maps to one entity instance whose state contains the full conversation history. When you send a message to a durable agent, the following happens:
- The message is dispatched to the entity identified by an
AgentSessionId(a composite of the agent name and a unique session key). - The entity loads its persisted
DurableAgentState, which includes the complete conversation history. - The entity invokes the underlying
AIAgentwith the full conversation history, collects the response, and appends both the request and the response to the state. - The updated state is persisted back to durable storage automatically.
Because the entity framework serializes access to each entity instance, concurrent messages to the same session are processed one at a time, eliminating race conditions.
Agent session identity
Every durable agent session is identified by an AgentSessionId, which has two components:
- Name – the registered name of the agent (case-insensitive).
- Key – a unique session key (case-sensitive), typically a GUID.
The session ID is mapped to an underlying Durable Task entity ID with a dafx- prefix (e.g., dafx-joker). This naming convention is consistent across both .NET and Python implementations.
Architecture
.NET
The .NET implementation consists of two NuGet packages:
| Package | Purpose |
|---|---|
Microsoft.Agents.AI.DurableTask |
Core durable agent types: DurableAIAgent, AgentEntity, DurableAgentSession, AgentSessionId, DurableAgentsOptions, and the state model. |
Microsoft.Agents.AI.Hosting.AzureFunctions |
Azure Functions hosting integration: auto-generated HTTP endpoints, MCP tool triggers, entity function triggers, and the ConfigureDurableAgents extension method on FunctionsApplicationBuilder. |
Key types:
DurableAIAgent– A subclass ofAIAgentused inside orchestrations. Obtained viacontext.GetAgent("agentName"), it routesRunAsynccalls through the orchestration's entity APIs so that each call is checkpointed.DurableAIAgentProxy– A subclass ofAIAgentused outside orchestrations (e.g., from HTTP triggers or console apps). It signals the entity viaDurableTaskClientand polls for the response.AgentEntity– TheTaskEntity<DurableAgentState>that hosts the real agent. It loads the registeredAIAgentby name, wraps it in anEntityAgentWrapper, feeds it the full conversation history, and persists the result.DurableAgentSession– AnAgentSessionsubclass that carries theAgentSessionId.DurableAgentsOptions– Builder for registering agents and configuring TTL.
Python
The core Python implementation is in the agent-framework-durabletask package (python/packages/durabletask). Azure Functions hosting (including AgentFunctionApp) is in the separate agent-framework-azurefunctions package (python/packages/azurefunctions).
Key types:
DurableAIAgent– A generic proxy (DurableAIAgent[TaskT]) implementingSupportsAgentRun. Returns aTaskTfromrun()— either anAgentResponse(client context) or aDurableAgentTask(orchestration context, must beyielded).DurableAIAgentWorker– Wraps aTaskHubGrpcWorkerand registers agents as durable entities viaadd_agent().DurableAIAgentClient– Wraps aTaskHubGrpcClientfor external callers.get_agent()returns aDurableAIAgent[AgentResponse].DurableAIAgentOrchestrationContext– Wraps anOrchestrationContextfor use inside orchestrations.get_agent()returns aDurableAIAgent[DurableAgentTask].AgentEntity– Platform-agnostic agent execution logic that manages state, invokes the agent, handles streaming, and calls response callbacks.
Hosting models
Azure Functions
The recommended production hosting model. A single call to ConfigureDurableAgents (C#) or AgentFunctionApp (Python) automatically:
- Registers agent entities with the Durable Task worker.
- Generates HTTP endpoints at
/api/agents/{agentName}/runfor each registered agent. - Supports
thread_idquery parameter / JSON field and thex-ms-thread-idresponse header for session continuity. - Supports fire-and-forget via the
x-ms-wait-for-response: falseheader (returns HTTP 202). - Optionally exposes agents as MCP tools.
C# example:
using IHost app = FunctionsApplication
.CreateBuilder(args)
.ConfigureFunctionsWebApplication()
.ConfigureDurableAgents(options => options.AddAIAgent(agent))
.Build();
app.Run();
Python example:
app = AgentFunctionApp(agents=[agent])
Console apps / generic hosts
For self-hosted or non-serverless scenarios, register durable agents via IServiceCollection.ConfigureDurableAgents (.NET) or DurableAIAgentWorker (Python) with explicit Durable Task worker and client configuration.
C# example:
IHost host = Host.CreateDefaultBuilder(args)
.ConfigureServices(services =>
{
services.ConfigureDurableAgents(
options => options.AddAIAgent(agent),
workerBuilder: b => b.UseDurableTaskScheduler(connectionString),
clientBuilder: b => b.UseDurableTaskScheduler(connectionString));
})
.Build();
Python example:
worker = DurableAIAgentWorker(TaskHubGrpcWorker(host_address="localhost:4001"))
worker.add_agent(agent)
worker.start()
Deterministic multi-agent orchestrations
Durable agents can be composed into deterministic, checkpointed workflows using Durable Task orchestrations. The orchestration framework replays orchestrator code on failure, so completed agent calls are not re-executed.
Patterns
| Pattern | Description |
|---|---|
| Sequential (chaining) | Call agents one after another, passing outputs forward. |
| Parallel (fan-out/fan-in) | Run multiple agents concurrently and aggregate results. |
| Conditional | Branch orchestration logic based on structured agent output. |
| Human-in-the-loop | Pause for external events (approvals, feedback) with optional timeouts. |
Using agents in orchestrations
Inside an orchestration function, obtain a DurableAIAgent via the orchestration context. Each agent gets its own session (created with CreateSessionAsync / create_session), and you can call the same agent multiple times on the same session to maintain conversation context across sequential invocations.
C#:
static async Task<string> WritingOrchestration(TaskOrchestrationContext context)
{
// Get a durable agent reference — works in any host (console app, Azure Functions, etc.)
DurableAIAgent writer = context.GetAgent("WriterAgent");
// Create a session to maintain conversation context across multiple calls
AgentSession session = await writer.CreateSessionAsync();
// First call: generate an initial draft
AgentResponse<TextResponse> draft = await writer.RunAsync<TextResponse>(
message: "Write a concise inspirational sentence about learning.",
session: session);
// Second call: refine the draft — the agent sees the full conversation history
AgentResponse<TextResponse> refined = await writer.RunAsync<TextResponse>(
message: $"Improve this further while keeping it under 25 words: {draft.Result.Text}",
session: session);
return refined.Result.Text;
}
Python:
def writing_orchestration(context, _):
agent_ctx = DurableAIAgentOrchestrationContext(context)
# Get a durable agent reference — works in any host (standalone worker, Azure Functions, etc.)
writer = agent_ctx.get_agent("WriterAgent")
# Create a session to maintain conversation context across multiple calls
session = writer.create_session()
# First call: generate an initial draft
draft = yield writer.run(
messages="Write a concise inspirational sentence about learning.",
session=session,
)
# Second call: refine the draft — the agent sees the full conversation history
refined = yield writer.run(
messages=f"Improve this further while keeping it under 25 words: {draft.text}",
session=session,
)
return refined.text
Important
In .NET,
DurableAIAgent.RunAsync<T>deliberately avoidsConfigureAwait(false)because the Durable Task Framework uses a custom synchronization context — all continuations must run on the orchestration thread.
Streaming and response callbacks
Durable agents do not support true end-to-end streaming because entity operations are request/response. However, reliable streaming is supported via response callbacks:
IAgentResponseHandler(.NET) orAgentResponseCallbackProtocol(Python) – Implement this interface to receive streaming updates as the underlying agent generates them (e.g., push tokens to a Redis Stream for client consumption).- The entity still returns the complete
AgentResponseafter the stream is fully consumed. - Clients can reconnect and resume reading from a cursor-based stream (e.g., Redis Streams) without losing messages.
See the Reliable Streaming samples for a complete implementation using Redis Streams.
Session TTL (Time-To-Live)
Durable agent sessions support automatic cleanup via configurable TTL. See Session TTL for details on configuration, behavior, and best practices.
Observability
When using the Durable Task Scheduler as the durable backend, you get built-in observability through its dashboard:
- Conversation history – View complete chat history for each agent session.
- Orchestration visualization – See multi-agent execution flows, including parallel branches and conditional logic.
- Performance metrics – Monitor agent response times, token usage, and orchestration duration.
- Debugging – Trace tool invocations and external event handling.
Samples
- .NET – Console app samples and Azure Functions samples covering single-agent, chaining, concurrency, conditionals, human-in-the-loop, long-running tools, MCP tool exposure, and reliable streaming.
- Python – Durable Task samples covering single-agent, multi-agent, streaming, chaining, concurrency, conditionals, and human-in-the-loop.
Packages
| Language | Package | Source |
|---|---|---|
| .NET | Microsoft.Agents.AI.DurableTask |
dotnet/src/Microsoft.Agents.AI.DurableTask |
| .NET | Microsoft.Agents.AI.Hosting.AzureFunctions |
dotnet/src/Microsoft.Agents.AI.Hosting.AzureFunctions |
| Python | agent-framework-durabletask |
python/packages/durabletask |
| Python | agent-framework-azurefunctions |
python/packages/azurefunctions |