/microsoft-agent-framework

name: microsoft-agent-framework
description: "Build .NET AI agents, harnesses, and multi-agent workflows with Microsoft Agent Framework using the right agent type, sessions, tools, workflows, hosting protocols, and enterprise guardrails. USE FOR: building or reviewing .NET code that uses Microsoft.Agents.*, Microsoft.Extensions.AI, AIAgent, HarnessAgent, AgentSession, or Agent Framework hosting packages; choosing agent, harness, workflow, and hosting shapes. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made."
compatibility: "Requires current Microsoft Agent Framework packages and a .NET application that truly needs agentic or workflow orchestration; declarative, hosting, and advanced Harness surfaces may remain preview or experimental."

Microsoft Agent Framework

Trigger On

• building or reviewing `.NET` code that uses `Microsoft.Agents.*`, `Microsoft.Extensions.AI`, `AIAgent`, `HarnessAgent`, `AgentSession`, or Agent Framework hosting packages
• choosing between `ChatClientAgent`, Responses agents, hosted agents, custom agents, Anthropic agents, workflows, or durable agents
• adding the batteries-included `Microsoft.Agents.AI.Harness` surface for planning, todos, compaction, file memory/access, tool approvals, skills, shell execution, or background agents
• authoring preview-era `Microsoft.Agents.AI.Workflows.Declarative*` packages or wrapping a workflow with `workflow.AsAIAgent()`
• adding tools, MCP, A2A, OpenAI-compatible hosting, AG-UI, DevUI, background responses, or OpenTelemetry
• migrating from Semantic Kernel agent APIs or aligning AutoGen-style multi-agent patterns to Agent Framework
• using Anthropic Claude models (haiku, sonnet, opus) via `AnthropicClient` or through Azure Foundry with `AnthropicFoundryClient`

Workflow

1. Decide whether the problem should stay deterministic. If plain code or a typed workflow without LLM autonomy is enough, do that instead of adding an agent. 2. Choose the execution shape first: single `AIAgent`, batteries-included `HarnessAgent`, explicit programmatic `Workflow`, workflow-as-agent wrapper, declarative workflow when YAML portability is explicitly required, Azure Functions durable agent, ASP.NET Core hosted agent, AG-UI remote UI, or DevUI local debugging. 3. Choose the agent type and provider intentionally. Prefer the simplest agent that satisfies the threading, tooling, and hosting requirements. 4. Keep agents stateless and keep conversation or long-lived state in `AgentSession`. Treat the session as opaque provider-owned state, serialize it through the owning agent, and never accept a raw service conversation ID as an end-user authorization boundary. 5. Add only the tools and middleware that the scenario needs. Narrow the tool surface, require approval for side effects, and treat MCP, A2A, and third-party services as trust boundaries. 6. For workflows, model executors, edges, typed `RequestPort` boundaries, checkpoints, shared state, and human-in-the-loop explicitly rather than hiding control flow in prompts. 7. Prefer Responses-based protocols for new remote/OpenAI-compatible integrations unless you specifically need Chat Completions compatibility. 8. Use durable agents only when you truly need Azure Functions serverless hosting, durable thread storage, or deterministic long-running orchestrations. 9. Verify preview status, package maturity, docs recency, and provider-specific limitations before locking a production architecture.

Current Upstream Notes

• [`.NET 1.20.0`](https://github.com/microsoft/agent-framework/releases/tag/dotnet-1.20.0) fixes Foundry-hosted workflow cancellation and duplicate AgentHost port binding, preserves Responses logprobs, and adds a timeout for background-agent wait-for-first-completion. Re-test cancellation, timeout, recovery, and streamed metadata with the selected provider.
• Current AG-UI hosted web-search samples use Responses. Update the Cosmos connector name from `CommunityToolkit.VectorData.CosmosNoSql` to `CommunityToolkit.VectorData.AzureCosmosDB` when following the migrated sample. Retired OpenAI Assistants integration tests were removed; choose an active provider API for new work.

• `dotnet-1.19.0` adds persisted routing and sessions, resilient/steerable hosted agents, AG-UI forwarding, and experimental agent hooks. It makes a breaking move to the MCP `2026-07-28` Tasks extension; update both peers and resume tests together.
• Current AG-UI hosting uses `Microsoft.Agents.AI.Hosting.AGUI.AspNetCore` with `AddAGUIServer()` and `MapAGUIServer(...)`; the client uses `AGUI.Client`, and conversation state flows through `AgentSession`. Do not copy older `AddAGUI`/`MapAGUI` or `AgentThread` hosting examples into current applications.
• The bundled August 2026 snapshot contains 172 pages. Start with the September review for current checkpoint and AG-UI guidance, then load only the relevant topic reference. Verify language and package maturity against the linked live page.

Architecture

flowchart LR
  A["Task"] --> B{"Deterministic code is enough?"}
  B -->|Yes| C["Write normal .NET code or a plain workflow"]
  B -->|No| D{"One dynamic decision-maker is enough?"}
  D -->|Yes| O{"Needs a packaged long-task runtime?"}
  O -->|No| E["Use an `AIAgent` / `ChatClientAgent`"]
  O -->|Yes| P["Use `HarnessAgent` with scoped capabilities"]
  D -->|No| F["Use a typed `Workflow`"]
  F --> G{"Needs durable Azure hosting or week-long execution?"}
  G -->|Yes| H["Use durable agents on Azure Functions"]
  G -->|No| I["Use in-process workflows"]
  E --> J{"Need a remote protocol or UI?"}
  P --> J
  F --> J
  J -->|OpenAI-compatible HTTP| K["ASP.NET Core Hosting.OpenAI"]
  J -->|Agent-to-agent protocol| L["A2A hosting"]
  J -->|Web UI protocol| M["AG-UI"]
  J -->|Local debug shell| N["DevUI (dev only)"]