DIE AGENTINNICOLENDERS.COM
DEEN
← Dispatches

AnalysisTHE HANDLERTHE TECHNICIAN

Semantic Kernel and AutoGen are now one

Published

Two differently machined metal shafts joined in the middle into a single continuous shaft.AI generated
microsoft/agent-frameworkGitHub

There was a time when you had to choose between two Microsoft agent libraries without anyone being able to answer the question cleanly. Semantic Kernel was the enterprise foundation, AutoGen the playground for multi-agent patterns. If you wanted both, you glued.

That is over. The Microsoft Agent Framework brings both together, is open source and stable for Python and .NET.

What was merged

The framework takes the enterprise foundations of Semantic Kernel and the multi-agent orchestration of AutoGen and turns them into one SDK. You no longer have to choose.

For .NET people this matters more than it sounds. Semantic Kernel was always the more mature path in .NET, AutoGen was heavily Python-leaning. The multi-agent patterns that impressed everyone in Python demos were either missing in C# or hand-rolled. That asymmetry is gone.

Stable since Build 2026:

  • The agent harness with skills, memory and middleware. The same notion of a skill as in Copilot Studio, the same Markdown format.
  • Integrations with the GitHub Copilot SDK and the Claude Agent SDK. A Microsoft framework treating foreign agent SDKs as equals was not on the cards two years ago.
  • Multi-agent orchestration patterns including Magentic-One.

File system tools, memory tools and a deep research agent are in public preview.

Middleware is the part nobody talks about

Of those three building blocks, middleware is the one I need most often in projects and see least often in talks.

Middleware sits between agent and model, or between agent and tool. That is exactly where everything belongs that is missing from demos and mandatory in production: logging of what actually went out. Redaction of personal data before it leaves the system boundary. Call limiting. Traceability of model version and prompt state per call.

Build this as a cross-cutting layer or you will build it into every single call later. I have watched that happen more than once, and it is always more expensive than the version where somebody thought about it for ten minutes first.

Incidentally it is also part of the answer to the record-keeping the EU AI Act expects. Timestamp, model and version, prompt template and its version, parameters, calling system: that either falls out of middleware as a by-product or it does not exist at all.

Memory, with a number attached

The Foundry Agent Service knows three kinds of memory in public preview:

  • Session memory holds context within one thread.
  • User memory remembers preferences and facts across sessions.
  • Procedural memory is the new part and the interesting one: agents learn how work gets done, not just what was said.

Microsoft cites early Tau-bench results for procedural memory of 7 to 14 percentage points better success rate at roughly the same cost. The example in the Microsoft blog: a PR review agent is told once to check test coverage first, then flag new dependencies, then look for breaking changes. Weeks later, on an unrelated PR, it runs the same three checks in the same order without being told again.

I find the idea convincing and the number worth taking carefully. Tau-bench is a benchmark, not a customer project, and a vendor's figures about a vendor's own feature are not independent evidence. The direction is right regardless: an agent that retains the way of working you explained once solves precisely the problem instructions fail at in practice.

And the flip side belongs in the same paragraph: persistent per-user memory is a data question. Before you switch it on, you should be able to say what gets stored, for how long, and what happens on a deletion request.

The development path

The Foundry Toolkit for VS Code is GA. Create agents from templates or with GitHub Copilot, run and debug them locally with trace visualisation, inspect them step by step, connect them to toolboxes and deploy straight into the Foundry Agent Service, all inside the editor.

This is the point where agent development finally feels like software development rather than configuration in a portal. Being able to debug locally is not a convenience, it is the precondition for someone understanding a problem instead of guessing around it.

For operations the other half comes with it: tracing and evaluation for hosted agents through an OpenTelemetry pipeline, where every model call, every tool invocation and every sub-agent hop lands. Evaluations point back to the trace that triggered them.

When I reach for code and when I do not

My line is simple and has nothing to do with preference.

Code, when the agent is part of a product, borders an existing codebase, needs its own orchestration patterns, or when call-level traceability is a requirement rather than a wish.

Low code, when the process belongs to a business department and changes often. A C# project only the IT team can change is the more expensive solution for a process that gets adjusted monthly, even if it is technically the cleaner one.

And the uncomfortable third option: no agent at all. If a procedure runs identically every time, it does not need a runtime that reasons about it afresh each time.

Why there is no code sample here

I would have liked to include one. I am leaving it out on purpose.

API signatures in the Agent Framework move between package versions, and a sample somebody copies that does not compile is worse than none. A text with a date stamp ages worse than documentation that gets maintained. If you want to get started, begin with the repository and the quickstart documentation, check the current package version and write your first agent locally in the Foundry Toolkit.

If it helps, I will turn this into a reference piece later with a verified state. A reference I can maintain. An analysis I cannot.

Sources

Microsoft Foundry · Development