Microsoft Agent Framework

Agents act in outside systems through tools the developer gives them. Any function becomes a tool with typed parameters, hosted MCP servers run on the provider's side and local MCP servers run beside the agent, and the Foundry Toolbox and shell tools add more. Code interpreter, file search and web search come from the model providers that offer them, and developers control which tools are available on each run. Agents can also call other agents through A2A, Copilot Studio, GitHub Copilot or Foundry agent services.

Sourcelearn.microsoft.com/en-us/agent-framework/agents/toolsread 2026-11-09

Graph based workflows connect agents and functions through executors and edges with conditional routing, shared state, events and sub workflows, alongside a functional workflow API and declarative workflows in YAML. Ready orchestration patterns cover sequential, concurrent, handoff, group chat and Magentic coordination, where a manager agent plans and assigns work to specialists. A workflow can itself be wrapped as an agent, and background agents let a parent delegate tasks to named child agents that run concurrently.

Sourcelearn.microsoft.com/en-us/agent-framework/workflows/orchestrationsread 2026-11-09

Retrieval runs through context providers and vector stores. The RAG guide grounds an agent in documents indexed in a vector store with embeddings, an Azure AI Search provider searches an existing index before each run, Azure Content Understanding turns files into searchable content, and a Neo4j provider brings in a knowledge graph. Provider file search searches files uploaded to a model service. The indexes live in the customer's own search service or database and persist across runs.

Sourcelearn.microsoft.com/en-us/agent-framework/agents/ragread 2026-11-09

Any function tool can be marked as needing approval, so the agent's run stops with an approval request and the tool runs only after a person says yes in a new run. Workflows pause on human in the loop requests and resume from the answer, and the Harness adds standing approvals a user can grant once for a tool. Termination and guardrail middleware can stop a run or rewrite its result, and FIDES blocks sensitive tools from acting on untrusted content before they run.

Sourcelearn.microsoft.com/en-us/agent-framework/agents/tools/tool-approvalread 2026-11-09

As a library, the framework has no user accounts, roles or sign in of its own; identity comes from the Azure credentials or provider keys the application passes in. Its governance controls act on content and tools: FIDES labels every piece of content for integrity and confidentiality and enforces policy before a sensitive tool runs, and Microsoft Purview middleware blocks prompts and responses under data loss prevention policies. The open source framework carries no compliance attestation of its own.

Sourcelearn.microsoft.com/en-us/agent-framework/agents/securityread 2026-11-09

Agents and workflows emit OpenTelemetry traces, logs and metrics under the GenAI semantic conventions, covering each model call, tool call and workflow executor, to any OpenTelemetry backend, with the Aspire dashboard suggested for local viewing and DevUI showing traces beside a test chat. Workflows raise events as each executor runs, and Purview middleware logs AI interactions for audit and compliance review in Microsoft Purview.

Sourcelearn.microsoft.com/en-us/agent-framework/agents/observabilityread 2026-11-09

Sessions carry an agent's conversation, storage providers persist it, and compaction keeps long histories within the model's context. For memory across sessions, context providers write and read back what the agent should remember, from Mem0, Redis, Valkey, Azure Cosmos DB, a semantic chat history memory provider, or a file store that shares memory files across sessions when given a stable scope such as a user ID. Each store is the customer's own, so the team sets how long memory lives and can delete one user's memory.

Sourcelearn.microsoft.com/en-us/agent-framework/concepts/agents/conversations/context-providersread 2026-11-09

The framework runs wherever the customer runs Python or .NET, on its own servers, containers or Kubernetes, and agents can be served from the customer's infrastructure behind Responses, OpenAI compatible, A2A or MCP endpoints. The Durable Extension runs durable agents and workflows on Azure Functions or on the customer's own compute against a Durable Task Scheduler, and hosted agents can deploy to Microsoft Foundry Agent Service instead. Local models through Ollama, Foundry Local or ONNX keep model calls on the customer's machines.

Sourcelearn.microsoft.com/en-us/agent-framework/hostingread 2026-11-09

Starting points are building blocks rather than finished agents. The Harness is an opinionated agent setup for research, coding and data analysis that the developer configures with a chat client and the capabilities it needs, declarative agents and workflows are written in YAML, and orchestration patterns are ready to fill with the team's own agents. Samples in the repository and a Microsoft maintained skill help coding agents build Agent Framework apps.

Sourcelearn.microsoft.com/en-us/agent-framework/concepts/harnessread 2026-11-09

With the Durable Extension on Azure Functions, agents and workflows run from Functions triggers and bindings such as timers, queues, webhooks and HTTP endpoints the Functions model generates, and an MCP server trigger hosts an agent as an MCP server without trigger glue. Self hosted agents answer OpenAI Responses, OpenAI compatible, A2A and MCP requests, and Telegram helpers turn bot updates into agent runs. Anywhere else, the application decides when to call the agent.

Sourcelearn.microsoft.com/en-us/agent-framework/hosting/durable-extensionread 2026-11-09

The developer picks the model client for each agent from Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini, Mistral, NVIDIA NIM, Ollama, Foundry Local, ONNX or Dapr, and agents in one workflow can each use a different provider. Runtime model routing can send a run to a different model based on the request, and a custom chat client adds any other service.

Sourcelearn.microsoft.com/en-us/agent-framework/concepts/agents/runtime-model-routingread 2026-11-09

The framework is itself the SDK, with published API references for .NET and Python and a Go version in preview. Agents built with it can be exposed to outside callers as OpenAI Responses or OpenAI compatible endpoints, as A2A servers with agent cards, or as MCP servers, and the Durable Extension generates REST APIs for sending messages, checking status and managing sessions. Custom agents, chat clients, middleware and context providers extend it.

Sourcelearn.microsoft.com/en-us/agent-framework/hosting/self-hostingread 2026-11-09

A built in evaluation framework scores an agent's quality, safety and correctness. Evaluation items wrap whole conversations, evaluators range from fast local checks during development to Microsoft Foundry's cloud evaluators, or any custom one, and a run returns pass and fail counts with per item detail. In .NET it builds on Microsoft.Extensions.AI.Evaluation. DevUI gives a local test chat with traces, and AG-UI apps can be tested in Dojo.

Sourcelearn.microsoft.com/en-us/agent-framework/agents/evaluationread 2026-11-09

Computer use passes through from the model provider. OpenAI and Foundry clients expose a native computer tool with which a Responses model asks for ordered desktop or browser actions, but the application owns the execution environment, presents safety checks for approval, performs the actions and returns screenshots. The framework itself ships no browser, desktop session or runner for an agent to drive.

Sourcelearn.microsoft.com/en-us/agent-framework/agents/tools/computer-useread 2026-11-09