Wiki · Concept · Last reviewed June 25, 2026

Microsoft Agent Framework

Microsoft Agent Framework is Microsoft's open, multi-language framework for building production-grade AI agents and multi-agent workflows in .NET and Python, positioned as the successor to Semantic Kernel and AutoGen.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Microsoft Agent Framework, AutoGen, Semantic Kernel, AI agents, workflows, agent governance

Snapshot

Type: open-source agent application framework and workflow runtime, not a model and not a safety certification.
Languages: .NET and Python, with first-party Microsoft documentation and packages for both ecosystems.
Lineage: Microsoft's stated successor to Semantic Kernel and AutoGen for agent and multi-agent application development.
Core surfaces: agents, model clients, tools, MCP clients, context providers, memory, middleware, telemetry, workflows, checkpoints, and provider integrations.
Governance question: which model, tool, workflow, credential, middleware, log, third-party system, and human-approval boundary was active in the deployed run?
Source rule: distinguish Microsoft Learn documentation, GitHub repository state, release posts, migration guidance, and a customer's deployed configuration.

Definition

Microsoft Agent Framework is an open framework for building AI agents and multi-agent workflows across .NET and Python. The official Microsoft Learn overview describes it as the next generation of both Semantic Kernel and AutoGen, created by the same teams and combining AutoGen's agent abstractions with Semantic Kernel's enterprise features.

The official GitHub repository describes the project as a framework for teams taking agents from prototype to production. Its stated ecosystem includes Microsoft Foundry, Azure OpenAI, OpenAI, and the GitHub Copilot SDK, with samples and hosting patterns for local and cloud deployment.

Microsoft's Agent Framework 1.0 announcement, published April 3, 2026, says the project reached version 1.0 for both .NET and Python, with stable APIs and long-term-support commitments. That makes the framework a current production-oriented Microsoft agent stack, not only a research experiment.

The framework should be defined by its role in application architecture. It wraps model calls with state, tools, middleware, workflows, telemetry, and provider connectors. It does not make the underlying model truthful, safe, authorized, or suitable for a regulated workflow by itself.

Boundary Tests

Not a model provider. Agent Framework can connect to Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Ollama, and other providers, but the framework is the orchestration layer around model access rather than the model itself.

Not the same as Semantic Kernel. Semantic Kernel remains a Microsoft SDK and ecosystem, but Microsoft Learn positions Agent Framework as the next generation of both Semantic Kernel and AutoGen. Migration claims should cite the specific migration guide and version involved.

Not the same as MCP or A2A. Model Context Protocol is a tool and context-access protocol. Agent2Agent Protocol is an agent-to-agent collaboration protocol. Agent Framework can integrate with such protocols, but it is a developer framework for building and orchestrating agents.

Not a governance control by itself. Middleware, telemetry, workflows, and FIDES can support governance. They do not replace least privilege, identity, authorization, privacy review, evaluation, incident response, and human oversight.

Current Context

As of June 25, 2026, Microsoft Agent Framework is part of Microsoft's broader agent platform strategy alongside Microsoft Foundry, Copilot Studio, GitHub Copilot, Agent 365, Entra agent identity work, Purview, and other enterprise controls described on the Microsoft AI page. It is the code-first SDK layer for teams building custom agents and workflows, not the whole Microsoft agent stack.

Microsoft Learn's overview divides the framework into two primary categories: agents that use language models to process inputs, call tools and MCP servers, and generate responses; and graph-based workflows that connect agents and functions for multi-step tasks with type-safe routing, checkpointing, and human-in-the-loop support. It also names foundational building blocks such as model clients, agent sessions, context providers, middleware, and MCP clients.

The April 2026 version 1.0 announcement framed the release as production-ready, while still listing several preview or evolving areas such as hosted-agent integration, frontend adapters, skills, and coding-agent harness patterns. That means a review should separate stable framework primitives from preview features and provider-specific integrations.

The GitHub repository is active and open source. That is useful for source inspection and issue tracking, but an active repository is not evidence that a customer's deployed agent is correctly permissioned, evaluated, or monitored. The relevant unit for governance is the concrete application and versioned dependency set.

The documentation itself contains a strong shared-responsibility warning. Microsoft says customers using third-party servers, agents, code, or non-Azure Direct models are responsible for reviewing data shared with and received from those systems, managing whether data leaves Azure compliance or geographic boundaries, and implementing responsible AI mitigations appropriate to their use case.

Architecture

The framework organizes agent applications around agents, context providers, model clients, function invocation, middleware, telemetry, and storage. Microsoft Learn's agent-pipeline page describes a request path where middleware and telemetry run around the agent, context providers load history or add tools and instructions, and function middleware handles tool-calling loops.

Middleware is a central governance surface. Microsoft Learn describes middleware as reusable behavior that can intercept, inspect, and modify requests and responses at defined points. That makes it a natural place for logging, security checks, policy enforcement, redaction, and operational controls.

Agent Framework also exposes provider-specific agent types. The documentation names local chat-client agents as well as remote-service agents and integrations such as A2A, GitHub Copilot, and Copilot Studio agents. The practical point is that a single framework can wrap very different execution and trust boundaries.

GitHub Copilot-backed agents are a good example of why the framework boundary matters. Microsoft Learn says GitHub Copilot agents can involve shell command execution, file operations, URL fetching, and MCP server integration, and recommends containerized environments for agents with shell or file permissions. That is an operational security claim about a provider integration, not a blanket permission to run coding agents on a developer's host.

Workflows

Workflows are the framework's explicit orchestration layer. Microsoft Learn distinguishes agents from workflows by saying that a workflow has a predefined sequence of operations, can include AI agents as components, and is designed for business processes involving agents, human interactions, and external systems.

The workflow documentation describes directed graphs of executors and edges, checkpoints for saving and resuming state, and observability spans, logs, and metrics. The orchestration documentation lists built-in multi-agent patterns including sequential, concurrent, handoff, group chat, and Magentic orchestrations.

This is why the framework matters for AI governance. It is not merely a chat wrapper. It gives developers a way to make multi-agent execution paths more explicit, while still leaving policy, data classification, authorization, safety testing, and incident response to the application owner.

A workflow graph can become de facto policy. If it decides which agent receives a task, which function runs after approval, which checkpoint resumes after failure, or which human step is bypassed, then the graph belongs in AI Change Management, AI System Inventory, and incident review records.

Governance and Safety

Microsoft's own overview includes a third-party-systems warning: applications that operate with third-party servers, agents, code, or non-Azure Direct models do so under those third parties' terms, and customers are responsible for reviewing data shared with and received from those systems. That warning is central, not boilerplate.

Agent Framework's safety documentation also cautions about logs and telemetry. It says trace-level logging can include full chat messages and personally identifiable information, and that telemetry configured with sensitive data can include chat messages, function calls, and results. Those settings should not be treated as ordinary debug toggles in production.

The security documentation describes FIDES, an information-flow-control middleware where content carries integrity and confidentiality labels and policies are enforced before sensitive tools run. That is a useful signal about where agent frameworks are heading: from orchestration toward policy-aware execution. It does not remove the need for threat modeling, least privilege, or human review.

For governance, Agent Framework should be reviewed as agent infrastructure under AI Agent Identity, AI Agent Observability, AI Audit Trails, Data Minimization, and Secure AI System Development. The review should cover not only prompts and model choice, but also tool authority, workflow checkpoints, middleware order, telemetry configuration, provider routing, and secrets exposure.

Security review should treat FIDES as a promising deterministic layer for prompt-injection and data-flow problems, but also as an experimental or configuration-sensitive control where the exact language runtime, package version, tool annotations, policy settings, and enforcement mode matter. A deployment that only mentions FIDES without showing labels, blocked sinks, approval behavior, and audit logs is not yet reviewable.

Minimum Review Record

A serious Microsoft Agent Framework deployment should leave enough evidence to reconstruct both application behavior and governance posture.

Framework identity: .NET or Python SDK, package versions, repository commit or release, runtime environment, hosting target, and owner.
Model and provider route: Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Ollama, GitHub Copilot, Copilot Studio, A2A, MCP, or other providers, plus region and data-processing boundary where relevant.
Agent surface: agent names, instructions, context providers, memory stores, tools, MCP servers, skills, shell or file access, URL access, and credential source.
Workflow surface: workflow graph, orchestration pattern, checkpoint store, resume policy, human-in-the-loop steps, branching rules, and timeout or cancellation behavior.
Policy surface: middleware order, FIDES or other security labels, tool-approval rules, content filters, authorization checks, sandbox boundary, and kill-switch behavior.
Evidence surface: telemetry level, sensitive-data setting, redaction policy, trace identifiers, retention period, access control, incident link, and tested replay or reconstruction procedure.

Defense Pattern

Inventory the runtime. Record framework version, language runtime, agent types, providers, model routes, tools, middleware, workflows, and hosting environment.
Separate agents and workflows. Treat a workflow graph, checkpoint, or orchestration pattern as deployed policy, not just glue code.
Gate tool use outside the model. Middleware and called functions should enforce authorization even when the model selects the tool.
Label trust boundaries. Treat webpages, issue bodies, emails, tool outputs, and third-party agent messages as untrusted data unless provenance and policy say otherwise.
Protect traces. Disable production trace settings that expose full prompts, private documents, function arguments, or returned data unless formally approved.
Sandbox coding agents. Put shell, file, package-installation, browser, and URL-fetching capabilities behind container, network, filesystem, and credential limits.
Pin and review dependencies. Track package versions, migration-assistant output, preview APIs, provider SDKs, MCP server dependencies, and workflow schema changes.
Review migrations. Moving from AutoGen or Semantic Kernel should trigger evaluation and change management, not only import changes.

Source Discipline

Claims about Microsoft Agent Framework should cite current Microsoft Learn pages, the official GitHub repository, and Microsoft devblog release posts. Avoid treating third-party framework comparisons as proof of support, security, or production readiness.

When describing an implementation, name the Agent Framework version, SDK language, provider, agent type, workflow pattern, middleware stack, logging settings, and connected third-party systems. "Built with Agent Framework" is too broad to audit.

Separate release status from deployment status. A Microsoft 1.0 announcement can establish that a framework release exists; it does not prove that an enterprise agent built on it is reliable, safe, compliant, or correctly configured. For security claims, preserve the exact documentation page, package version, runtime language, feature status, and date reviewed.

Spiralist Reading

Spiralism reads Microsoft Agent Framework as a sign that agents are moving from improvisation into architecture. The agent is no longer only a prompt and a tool list. It is a pipeline, workflow, middleware stack, trace, checkpoint, and policy boundary.

That is progress only if the institution uses the architecture honestly. A framework can make delegation visible, or it can make unsafe delegation look professionally packaged.

Open Questions

Which Semantic Kernel and AutoGen deployments should migrate, and which should remain stable?
How should workflow checkpoints be logged without preserving excessive private context?
Which tool calls should require middleware-based policy checks even after model selection?
How should organizations compare Microsoft Agent Framework with model-provider-native agent SDKs and independent frameworks?

Sources

Microsoft Learn, Microsoft Agent Framework overview, reviewed June 25, 2026.
GitHub, microsoft/agent-framework, official repository, reviewed June 25, 2026.
Microsoft Agent Framework Blog, Microsoft Agent Framework Version 1.0, reviewed June 25, 2026.
Microsoft Learn, Agent Pipeline Architecture, reviewed June 25, 2026.
Microsoft Learn, Microsoft Agent Framework Workflows, reviewed June 25, 2026.
Microsoft Learn, Workflow orchestrations in Agent Framework, reviewed June 25, 2026.
Microsoft Learn, Agent Safety, reviewed June 25, 2026.
Microsoft Learn, Agent Security with FIDES, reviewed June 25, 2026.
Microsoft Learn, Observability in Agent Framework, reviewed June 25, 2026.
Microsoft Learn, GitHub Copilot agents in Agent Framework, reviewed June 25, 2026.
Microsoft Learn, Semantic Kernel to Microsoft Agent Framework Migration Guide, reviewed June 25, 2026.
Microsoft Learn, AutoGen to Microsoft Agent Framework Migration Guide, reviewed June 25, 2026.

Return to Wiki