Microsoft Agent Framework is an open-source framework for building AI agents. Its distinguishing
feature, as described in Microsoft’s AI Agents for Beginners course, is how little ceremony it
requires to expose a function to a model: tools are defined as Python functions carrying a @tool
decorator, and the framework serializes the function and its parameters into the schema sent to the
model, then handles the back-and-forth between the model and the application’s code. This is what the framework
contributes to a direct implementation of the Function calling: the schema is
generated rather than written by hand, and the exchange with the model is the framework’s
responsibility rather than the application’s.
Capabilities
An existing function is converted into a tool by decorating it, with an approval mode specified on the decorator. Agents are created from a chat client configured with a project endpoint, model deployment and credential, and are given a name, instructions and the tools they may use; the agent is then run against a natural-language request.
Beyond functions the developer writes, the framework provides access to prebuilt tools — File
Search and Code Interpreter are the two the course names — through its FoundryChatClient.
Above individual agents the framework has a workflow system, in which units of work called executors are wired together with edges through a builder. Microsoft’s documentation describes Human-in-the-loop in that system as a consequence of a more general capability rather than a feature of its own: an executor can send a request out of the workflow and wait for the answer, which covers a human operator as one case of an external system among others. The channel for this is a typed request port. When a request reaches it the workflow pauses and emits an event carrying the request’s details; an external system subscribes to those events, produces a response, and hands it back, and the framework routes it to the executor that asked. The same mechanism is offered in the framework’s C#, Python and Go surfaces, with Python letting an executor issue the request directly and register a response handler whose type annotations the framework matches incoming responses against.
Tool approval reuses that machinery rather than adding another. Where agents run under one of the prebuilt orchestrations, a tool marked as needing approval pauses the workflow and emits the same event, differing only in that the payload is an approval request rather than a request type the developer defined. The documentation is explicit about the limits of this: sequential, concurrent and group-chat orchestrations do not stop for free-form user input on their own, so a workflow that needs a conversation between steps has to pair them with a request port in a custom workflow. The handoff orchestration is the exception, being interactive by default — when an agent answers without handing off to another agent, control returns to the user for the next input.
Waiting also survives being checkpointed. Pending requests are stored as part of a checkpoint’s state and re-emitted when it is restored, and a run can be resumed from a checkpoint with the responses supplied in the same call, so Checkpoint-and-Resume and an outstanding approval do not have to be handled as separate concerns.
Adoption & Ecosystem
The project also develops in the open through architecture decision records kept in its repository, which is where a second source describes parts of the framework not covered by the course.
The record read here, ADR-0024, proposes FIDES (Flow Integrity Deterministic Enforcement System), a label-based information-flow-control defence against Prompt injection; it carries the status proposed rather than accepted. It also shows how those records relate to one another, naming two earlier ones as its own lineage: an agent-filtering-middleware record it says established the middleware patterns it builds on, and a user-approval record it says it references for the human-in-the-loop pattern. Neither of those records was read here, so what stands above is how ADR-0024 describes them.
What that record incidentally documents about the framework itself is its extension surface. There
is a FunctionMiddleware base class through which behaviour can be inserted around tool calls, and
the record’s stated reason for its choice is that the option it picked was the only one giving
deterministic, formally verifiable guarantees while integrating non-invasively with that existing
pipeline and staying backwards compatible. Labels and similar metadata can be attached to content through an
additional_properties field without schema changes, and a SerializationMixin persists them.
Remote MCP connections belong to the proposal rather than to that existing surface: the design
would secure a connection made by tool or by URL by mapping MCP ToolAnnotations such as
readOnlyHint and openWorldHint onto its own labels, and by reading a server’s _meta.ifc
result metadata (see Model Context Protocol).
The framework appears in the course as one of two Microsoft routes to implementing tool use, the other being Microsoft Foundry Agent Service; the course provides worked samples in both Python and .NET.
Where the framework came from is recorded by a fourth source. A chapter of Jimmy Song’s online handbook 智能体构建指南 states that Microsoft merged AutoGen with Semantic Kernel into Microsoft Agent Framework in 2025, ending the period in which the company maintained two parallel multi-agent frameworks. That chapter reads the merger as a marker of a wider consolidation: the field moving from competing on features to converging on a small number of projects teams are willing to depend on, rather than migrating repeatedly between experimental ones. In its 2026 summary of the ecosystem it lists Microsoft Agent Framework as Microsoft’s unified multi-agent framework and the product of that merger, alongside LangGraph, OpenAI Agents SDK, CrewAI and OpenHands. Nothing in the sources held here states what happened to AutoGen’s or Semantic Kernel’s own APIs in the merge.