Microsoft Agent Framework reached general availability on April 3, 2026 as the official successor to both AutoGen and Semantic Kernel, meaning teams building on either predecessor are now the intended migration target (Microsoft Learn, "Agent Framework Overview," updated 2026-08-25). This post is about the orchestration framework itself and what its design choices mean for the team governing what gets built on it — it is not about Microsoft's separate open-source runtime-security project, the Agent Governance Toolkit, which is a different product covered in its own post.
What Microsoft Agent Framework actually is
Agent Framework is Microsoft's unified successor to AutoGen and Semantic Kernel, combining AutoGen's simple agent abstractions with Semantic Kernel's enterprise features under one API surface (Microsoft Learn, as of late August 2026).
Per Microsoft's own documentation, it was "created by the same teams" that built the two predecessor frameworks, and it merges AutoGen's lightweight agent-building patterns with Semantic Kernel's session-based state management, type safety, middleware pipeline, and telemetry — then adds graph-based workflows for explicit multi-agent orchestration on top. The framework ships in four areas:
- Agents — individual LLM-backed agents that call tools and MCP servers directly.
- Harness Agent — an opinionated, batteries-included agent for long, multi-step tasks: planning, automatic context compaction, memory, "don't-ask-again" tool approval, and built-in observability.
- Workflows — graph-based multi-agent orchestration with explicit, inspectable execution paths rather than implicit agent-to-agent handoff.
- Integrations — connectors into the broader Microsoft and third-party tooling ecosystem, including native MCP client support.
Language support currently spans .NET, Python, and Go, though Go is public preview as of late August 2026 and is missing declarative agents, RAG, and CodeAct support relative to the .NET and Python surfaces (Microsoft Learn).
| Predecessor | What it contributed to Agent Framework | Status as of late August 2026 |
|---|---|---|
| AutoGen | Simple, lightweight agent-building abstractions | Superseded; migration guide published |
| Semantic Kernel | Session-based state management, type safety, middleware, telemetry | Superseded; migration guide published |
| Agent Framework | Both of the above, plus graph-based Workflows and native MCP client support | GA since April 3, 2026 |
The practical read for a team already invested in either predecessor: Agent Framework is not a bolt-on feature, it is a merge of both codebases' design philosophies into one API, which is why Microsoft ships migration guides rather than treating the predecessors as permanently supported parallel options.
The governance-relevant design choices
Two design decisions matter more to a security or platform team than the rest of the feature list combined, because both change the default trust posture of whatever gets built on the framework.
"Don't-ask-again" tool approval, by design. The Harness Agent — the framework's opinionated, long-task agent — explicitly ships a don't-ask-again approval mode for tool calls (Microsoft Learn). That is a legitimate productivity feature for a genuinely trusted, narrow task. It is also, structurally, the same category of risk this site covers elsewhere as excessive autonomy: once a tool call class is marked "don't ask again," nothing in the framework itself re-evaluates that grant per invocation. Whether that is safe depends entirely on how narrowly the approved tool set was scoped before the grant was made, not on anything the framework enforces afterward.
Native MCP client support, with no vetting layer implied. Agent Framework connects to MCP servers as a first-class integration path (Microsoft Learn). The framework provides the plumbing to call an MCP server's tools; it does not provide MCP server vetting, tool-level scoping, or credential isolation as part of that connection — those remain the deploying team's responsibility, same as with any framework that speaks MCP.
Neither of these is a flaw in the framework's design. They are choices that trade default safety for developer velocity, which is a reasonable trade for a framework aimed at fast agent construction — but it means the governance work does not happen automatically, and a team migrating from AutoGen or Semantic Kernel should not assume it inherited more default safety than it actually did.
What Microsoft's own docs say you're responsible for
No CVE or security incident against Agent Framework surfaced in the research for this post as of late August 2026 — that is not evidence of absence, only of what has been publicly disclosed so far. The governance gap covered here is not an exploit; it is an explicit disclaimer in Microsoft's own documentation.
Microsoft's docs state that teams using the framework with "any third-party servers, agents, code, or non-Azure Direct models" do so "at your own risk," are told to review the data flowing in and out of those integrations, and are explicitly told they are "responsible for implementing your own responsible AI mitigations such as metaprompt, content filters, or other safety systems" (Microsoft Learn). In other words: Microsoft does not assume responsibility for the safety of third-party pieces the framework connects to, even though native MCP support makes connecting them one line of configuration.
Third-party commentary frames the broader migration pressure bluntly — one summary characterizes continued investment in the predecessor frameworks as building on something Microsoft has already deprioritized in favor of the successor (jangwook.net; treated here as attributed opinion, not a Microsoft-sourced claim). Migration guides exist from both AutoGen and Semantic Kernel, which is the concrete signal worth acting on regardless of how that pressure is framed.
For a compliance program already working through evidence requirements like the EU AI Act's, an explicit "at your own risk" disclaimer for third-party integrations is a useful, specific line item rather than boilerplate: it tells you precisely which of the framework's connections your own audit trail has to cover, because Microsoft's documentation is telling you plainly that its coverage stops there. Treating the disclaimer as a scoping document for your own control inventory is more useful than reading it as a liability waiver to note and move past.
Controls a platform team applies before migrating
Migrating onto Agent Framework is a reasonable engineering decision for teams already on AutoGen or Semantic Kernel. It does not remove the need for the same governance program covered in the AI governance guide — a new orchestration framework changes where controls attach, not whether they are needed. Four controls keep the migration from also inheriting the framework's permissive defaults:
- Treat "don't-ask-again" approval as a scope decision, not a convenience toggle. Before enabling it for a tool class, apply the same reasoning covered in excessive agency controls for OWASP LLM06: scope the tool to the minimum verb and resource the task needs, because nothing downstream will re-check it once granted.
- Vet every MCP server the same way regardless of how easy the framework makes connecting it. Native client support is a convenience, not a security review — apply the MCP server security checklist before any server goes into a Harness Agent's tool list.
- Design Workflows' graph orchestration with explicit delegation boundaries. Graph-based multi-agent orchestration is more inspectable than implicit handoff by default, which is a genuine governance improvement over ad hoc agent chaining — but inspectable is not the same as governed. See orchestration patterns for multi-agent systems for how to add authorization boundaries between graph nodes rather than relying on the graph's structure alone.
- Close the gap Microsoft's disclaimer leaves open. Since Microsoft explicitly does not take responsibility for third-party integrations, the deploying team needs its own audit trail across the framework and everything it connects to. A build-vs-buy evaluation is the right frame for deciding whether that trail is assembled in-house or via an independent layer; an independent control plane such as Praesidia can apply the same allow-list and audit requirements across Agent Framework and any other framework in a mixed estate, rather than re-implementing them per orchestrator.
FAQ
Is Microsoft Agent Framework the same product as the Microsoft Agent Governance Toolkit? No. Agent Framework is the orchestration successor to AutoGen and Semantic Kernel. The Agent Governance Toolkit is a separate, MIT-licensed runtime-security project that merely integrates with Agent Framework as one of several external targets. See the toolkit's own coverage.
Do I have to migrate off AutoGen or Semantic Kernel immediately? Microsoft has not published a hard deprecation date in the anchor documentation reviewed here, but migration guides exist from both frameworks, and third-party commentary frames continued investment in the predecessors as building on a deprioritized base (attributed opinion, not a Microsoft statement).
Does Agent Framework provide security or governance controls out of the box? Not for third-party integrations. Microsoft's own docs state teams connect third-party servers, agents, or non-Azure models "at your own risk" and are responsible for their own responsible-AI mitigations — the framework provides orchestration, not a governance layer.
Is Go a fully supported language for Agent Framework? As of late August 2026, Go support is public preview and is missing declarative agents, RAG, and CodeAct support that the .NET and Python surfaces have — treat it as not yet feature-complete for production governance decisions.