Daily Edition Sources +5

Microsoft Agent Framework: the successor built from AutoGen and Semantic Kernel

Microsoft's new framework has migration paths for AutoGen and Semantic Kernel, but its freshest source work makes a more practical promise: carry a caller's intent across an agent boundary without letting it overrule the host that operates the run.

A torn-paper marker diagram shows AutoGen and Semantic Kernel migration cards feeding an A2A adapter, where caller configuration crosses to an agent while a host-policy gate remains in control; a BYOK provider card and a red samples-not-production stamp sit beside the flow.
Diagram Punkmigration promises only matter when the hand-off keeps its boundaries.
repo microsoft/agent-framework evidence
5 source signals 1 repo 2 linked commits
Evidence: 2 linked commits / July 29, 2026 / Daily Edition
Open Edition Evidence below

Calling a framework a successor is easy. The hard work begins when an application has old agent shapes, its own model-provider commitments, and an operator who still needs the final say over how a run behaves. Microsoft Agent Framework's public README makes the transition explicit: it links migration guides for both Semantic Kernel and AutoGen, alongside a claim to support production-grade agent and workflow systems in Python and .NET.

The repository gives that claim more substance than a landing-page line. Its AutoGen migration samples cover single-agent and orchestration patterns; the Semantic Kernel set reaches from chat completion to orchestration, OpenAI Responses, and Copilot Studio. That is a useful map for a team deciding what must be translated. It is not a promise that a running system can be lifted across unchanged.

The useful seam is where a request becomes a run

The fresher clue is a small A2A adapter change. It carries a caller's MessageSendParams.configuration into the hosted agent's run options under the named a2a.configuration key. The accompanying tests exercise that forwarding for ordinary and streaming calls. More important, another test makes the boundary visible: a request asking to return immediately does not override a server run mode that has disallowed background responses.

That is a less glamorous kind of interoperability than a new model connector, but it is where an agent framework earns trust. A caller can state an output mode or history preference and the host can still keep responsibility for its own scheduling policy. The code is preserving context without silently transferring authority.

Provider choice has the same shape

A second new .NET sample takes a GitHub Copilot client and routes a session through an explicitly configured OpenAI, Azure, Anthropic, or compatible endpoint. The sample calls this BYOK, but its useful reporting detail is the warning: the key is static, automatic refresh is absent, and usage is accounted for by the chosen provider rather than GitHub.

Put beside the A2A change, that sample reads as a design choice. Microsoft Agent Framework is not claiming that one abstraction removes the difficult questions inherited from two earlier frameworks. It is trying to make those questions legible at the interface: whose configuration crossed the boundary, whose policy remains in force, and whose credentials and bill now carry the work.

The evidence has a sharp limit. Migration samples and focused adapter tests do not establish release status, provider parity, or a painless upgrade for an application with its own state, tools, and deployment constraints. The next useful public signal is a real migration report or an end-to-end test that follows one existing workflow across its provider, host-policy, and recovery boundaries—not another claim that the frameworks have simply become one.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateJuly 29, 2026
LaneDaily Edition
Confidence78%
Sources5
Reposmicrosoft/agent-framework

Primary Evidence

Evidence Limits

  • These public sources establish source and sample behavior, not that a release contains every change or that existing AutoGen and Semantic Kernel applications migrate unchanged.
  • The A2A test proves a tested policy boundary; it does not prove production interoperability with every A2A peer.
  • Watch for public release notes, migration issue reports, and end-to-end tests that show how these boundaries behave across a real existing application.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.