Semantic Kernel is capable, but it is no longer Microsoft's destination
Semantic Kernel is an open-source orchestration SDK for applications that call language models, expose tools, retain memory, and coordinate agents. Its README presents 3 supported development paths: Python 3.10 or newer, .NET 10.0 or newer, and Java 17 or newer. The MIT license leaves deployment and modification choices open.
The defining context is Microsoft's notice that Semantic Kernel has become Microsoft Agent Framework, or MAF, and that MAF 1.0 is the production-ready successor with stable APIs and long-term support. Semantic Kernel itself is not portrayed as abandoned: release dotnet-1.80.1 arrived on September 3, 2026, and the repository was pushed on September 9.
Its strongest case is broad orchestration across an existing estate
The provider surface is practical. The README names OpenAI, Azure OpenAI, Hugging Face, and Nvidia, alongside local operation through Ollama, LMStudio, or ONNX. That gives 1 framework a common place to configure hosted and local model access without claiming that every backend behaves identically. Vector database integrations include Azure AI Search, Elasticsearch, and Chroma, which makes retrieval a first-class architectural option rather than an afterthought.
Agents can receive native-code functions, prompt templates, OpenAPI descriptions, and MCP tools as plugins. The same package also covers multi-agent coordination, multimodal text, vision, and audio inputs, plus a Process Framework for structured business workflows. Its 2 basic-agent quickstarts, Python and .NET, show a small chat agent; longer examples add a menu plugin and structured output.
What happened when we ran it
We cloned commit 872d29e and exercised the Python project in a fresh, unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. The checkout contained 4,844 files, about 532,529 lines of source, and occupied 47.6 MB. Installation succeeded in 43 seconds, pulling 121 packages and consuming 401 MB on disk; the build then succeeded in 9 seconds.
The test command did not pass. It exited with status 1 after 49 seconds, and the final log lines listed failures in chat-completion agent and chat-history channel tests. Each shown failure reported that async functions are not natively supported. That message is the evidence from our run; it does not prove whether the fault sits in project configuration, the selected test environment, or another missing component, so we will not manufacture a diagnosis.
pip-audit also reported 3 known vulnerabilities in the installed environment. That figure needs package-level triage before production use, because the supplied measurement does not identify affected packages or exploitability. We found 21 CI workflow files and tests, but no Dockerfile.
The quickstart is easy, while checkout validation is not
For first contact, the README is direct: export an Azure OpenAI or OpenAI key, install semantic-kernel with pip, and create an agent. The matching .NET sample uses a builder and environment variables, and Java users are routed to separate build instructions.
Our measured 43-second install supports the claim that obtaining the Python dependencies is straightforward. The 401 MB footprint and failed 49-second test run show a different reality for contributors or teams vendoring the project. Installation alone did not validate the integration.
The transition and dependency surface are the main rough edges
The successor announcement creates the largest strategic cost. A team could learn Semantic Kernel's APIs, build plugins, and encode workflows, only to carry those choices into a MAF 1.0 migration. Microsoft provides a migration guide, which is better than leaving users to infer a path, but the existence of that guide is also a strong signal that greenfield evaluation should begin with the successor.
Scope is the second cost. Model connectors, agents, multi-agent systems, vector stores, multimodal input, local runtimes, plugins, and process modeling make this a large framework, reflected in roughly 532,529 source lines. That can be appropriate for a platform team, yet excessive for a service that needs 1 model request and a few ordinary functions.
Activity is strong, although open issues still need inspection
The repository has 28,549 stars, 269 open issues, and a latest push dated September 9, 2026, one day before this review. Its latest listed release landed 6 days earlier. Taken together, those signals describe an actively maintained and widely watched project, not a repository kept alive only by historical popularity. Twenty-one workflow files further suggest serious automation investment, though file count alone says nothing about whether every job is green.
Stars and recent commits do not guarantee fast support for any particular issue. The 269-item backlog is material, and the supplied data does not reveal response times, closure rates, or maintainer distribution. The community score therefore stops at 4 out of 5: activity and adoption are visible, but issue handling quality cannot be certified from volume alone.
It belongs in the application orchestration layer
In a real stack, Semantic Kernel fits inside an application service, between product logic and model providers, tool APIs, and retrieval stores. Keep provider keys in the deployment's secret system, place authorization around sensitive plugins, and send traces to the organization's observability layer. Its 3 language paths can help shared platform teams offer similar patterns across services, but each runtime still needs independent integration and upgrade tests.
Existing Semantic Kernel users have a reasonable basis to continue while planning migration: the project is active, the feature set is substantial, and our build completed in 9 seconds. New teams should compare Microsoft Agent Framework first, then LangChain or AutoGen where their ecosystems fit better. Whichever framework wins, our failed tests and 3 audit findings are release gates to investigate, not details to wave through.