Semantic Kernel and Microsoft Agent Framework: What Matters in 2026

If you learnt Microsoft’s agent stack through Semantic Kernel, the naming in 2026 can be confusing. The short version is this:

Microsoft Agent Framework is the production successor to Semantic Kernel and AutoGen for new agent and multi-agent applications.

Semantic Kernel has not suddenly become useless. Existing applications can still use its model connectors, plugins, and agent APIs. But for new work, I would evaluate Agent Framework first, especially when I need explicit workflows, durable state, human approval, or multi-agent orchestration.

If you are still deciding whether the problem needs a function, workflow, or agent, start with Agent Architectures in Practice.

What Semantic Kernel gave us

Semantic Kernel made it easier to connect model calls with ordinary application code. Its main ideas remain sound:

• register one or more model services;
• expose code as tools or plugins;
• let a model select a tool through function calling;
• keep orchestration inside the application;
• add filters, telemetry, and validation around model behaviour.

That is still a useful architecture. The model does not replace the application; it chooses from capabilities the application provides.

The difficult part was never creating a Kernel object. It was managing longer processes: resuming after failure, coordinating several workers, controlling state, and understanding what happened across many calls.

What Agent Framework changes

Agent Framework brings the agent work from Semantic Kernel and AutoGen into one framework across .NET and Python, with Go support developing separately. It keeps single-agent development, then adds workflows with explicit execution paths.

The distinction I find useful is:

• Agent: open-ended work where a model may choose tools and decide the next step.
• Workflow: controlled work where the application defines how agents and functions connect.

That separation matters. Many business processes need some model judgement, but they do not need unlimited autonomy. A workflow can keep approvals, retries, branching, and completion rules explicit while an agent handles a bounded step.

flowchart LR
  U[Request] --> W[Workflow]
  W --> A[Agent step]
  A --> T[Approved tools]
  T --> V[Validation]
  V --> H[Human approval]
  H --> O[Business action]

Agent Framework also provides middleware, session-based state, observability, provider integrations, and graph-based patterns such as sequential, concurrent, and hand-off workflows. Those features are useful, but I would still start with one agent and a small number of tools.

Where Microsoft Foundry fits

Agent Framework is code. Microsoft Foundry is a platform.

I use the framework to define agent behaviour and workflows in the repository. Foundry can provide model deployments, managed agent hosting, identity, knowledge services, tracing, evaluation, networking, and governance.

They can be used together, but they are not the same layer. Keeping that boundary clear prevents platform configuration from leaking into domain logic.

Should an existing Semantic Kernel app migrate?

Not automatically.

If the application is stable, supported, and mostly uses model connectors and plugins, a migration may create work without user value. I would first record the current behaviour with tests and evaluation examples.

Migration becomes more attractive when the team needs:

• supported workflow orchestration rather than custom loops;
• clearer state and checkpoint handling;
• shared patterns across existing SK and AutoGen projects;
• new Agent Framework integrations or hosting options;
• a long-term framework direction for a growing agent platform.

I would migrate one path at a time. Start with a low-risk workflow, keep tool contracts stable, and compare outcomes against the existing implementation.

Tools need ordinary engineering discipline

Whether I use Semantic Kernel or Agent Framework, I treat model-callable tools as security boundaries.

Each tool should have a narrow purpose, typed inputs, validated outputs, timeouts, and least-privilege access. Authentication and authorisation stay in code. The prompt can explain a policy, but it cannot enforce one.

I also separate reads from writes. Read-only tools are easier to introduce. Actions that change records, send messages, spend money, or alter access should have idempotency and an approval step.

What I would choose now

For a new agent or workflow in the Microsoft ecosystem, I would start with Agent Framework and use Foundry services only where they solve a clear operations need.

For an existing Semantic Kernel application, I would keep it running while I evaluate migration against real requirements. “New framework available” is not enough reason to rewrite a working system.

The lasting idea is more important than the SDK name: keep model behaviour bounded by explicit tools, application rules, observable state, and repeatable evaluation.

References

• Microsoft Agent Framework overview
• Migration guide from Semantic Kernel
• Semantic Kernel on GitHub