Semantic Kernel: The Enterprise Agent Framework Nobody Writes About
The framework AI Twitter ignored and Fortune 500 platform teams quietly shipped.
Nobody on AI Twitter writes about Semantic Kernel. The Fortune 500 platform teams I talk to keep shipping it. That gap is the most interesting thing about this framework, and it explains why Semantic Kernel has outlasted three full hype cycles while LangChain forks burn through their welcome.
Microsoft’s Semantic Kernel started life in 2023 as a Microsoft Research project for stitching LLMs into existing application code. Three years later, it has C#, Python, and Java SDKs, a stable plugin model, a process orchestration framework, and an Agent abstraction that finally landed properly in the 1.x line. None of that gets attention because none of it ships with a personality: the release notes read like release notes, the docs read like Microsoft Docs, and the samples are written in C#, which is the kiss of death for any AI library hoping to trend.
That’s the marketing problem. The engineering reality is that Semantic Kernel quietly does the things enterprise platform teams need a framework to do, in the languages they already write, with the auth providers they already use. The plugin model is the cleanest separation of capability-from-orchestration in any framework I’ve evaluated: a plugin is a class, a function on that plugin is a method, type safety carries through to the model’s tool-use payload, and dependency injection works the way DI works everywhere else in the same codebase. None of this is exciting, which is precisely why it survives integration with a fifteen-year-old monolith.
The C# story matters more than people give it credit for. I have worked inside healthcare and insurance environments where the entire backend is .NET, audit logs are tied to Entra ID identities, and the security team will not approve a Python service for production because nobody on staff can read it. In those shops, “use LangChain” is not a decision the platform team can make. Semantic Kernel slots into the existing build pipeline, the existing observability stack, and the existing service mesh without anyone needing to argue about Python packaging. That alone is enough to ship it.
The Python SDK has caught up enough to matter. It trailed C# for the first eighteen months, which earned Semantic Kernel a reputation as the .NET one that has been hard to shake. As of the 1.x series, the Python feature parity is close enough that you can pick the language based on team preference instead of capability gaps. The Java SDK is further behind, though it exists, which is more than most agent frameworks can say about anything outside Python.
Where it gets interesting is the Process Framework. Semantic Kernel’s process model is a graph of steps with explicit event-driven transitions, close to what LangGraph offers but expressed in a way that does not feel like a research artifact. Each step is a regular class. State flows through events. The execution model is observable through the same telemetry pipeline as the rest of your application. If you have built workflows in Azure Durable Functions or AWS Step Functions, the mental model maps directly, and that conceptual continuity is what makes the framework palatable to platform engineers who have spent careers building systems that survive on-call rotations.
The Agent framework is the newer piece, and it shows the tradeoffs of Microsoft’s ship-slowly-break-less cadence. Compared to AutoGen 0.4 or CrewAI, the agent abstractions feel deliberately conservative. You get ChatCompletionAgent, OpenAIAssistantAgent, and an AgentGroupChat coordinator for multi-agent scenarios. There is no orchestrator-of-orchestrators pattern, no exotic delegation primitives, no team-of-specialists DSL. It does the basic thing well and leaves the unusual stuff to your own code. For production work, that’s usually what you actually want. For a hackathon, it’s underwhelming.
The places it falls short are predictable. Documentation sprawls across three language tracks and reads like reference material rather than narrative, which is fine when you know what you are looking for and brutal when you are learning. The community plugin ecosystem is a fraction of LangChain’s, so you will end up writing wrappers around vendor SDKs that someone in the LangChain orbit already wrote. The release cadence is slower than the rest of the field, which is a feature in production and a liability when a new model API drops and you are waiting on the official binding.
The vendor-lock question deserves a direct answer. Semantic Kernel is not Azure-only. It supports OpenAI, Azure OpenAI, Hugging Face, ONNX, Ollama, Mistral, Anthropic, and Google models through first-party or community connectors. It runs anywhere .NET, Python, or Java runs. The Microsoft incentive shows up in subtler ways: the path of least resistance for memory and embeddings points at Azure AI Search, the auth examples assume Entra ID, the deployment patterns lean on Azure Container Apps. None of that is a lock. It is gravity, and most teams who choose Semantic Kernel have already chosen to live inside that gravity for unrelated reasons.
The honest comparison runs like this. If your team writes Python and lives on AI Twitter, you will hate Semantic Kernel and pick something with more momentum. If your team writes C# or Java, ships to enterprise customers, and answers to a procurement org that wants Microsoft on the receipt, Semantic Kernel is the only serious option in the agent space. If your team writes Python inside an enterprise that has standardized on Azure, the Python SDK gets you the same compliance posture without forcing a language switch. Picking the wrong one of these three modes is how teams end up with frameworks they cannot defend in a security review six months later.
The Fortune 500 platform teams that quietly ship Semantic Kernel are not making a hype-resistant statement. They are picking the tool that fits the rest of their stack, that their security team will approve, and that has Microsoft’s name on the support contract. Those criteria do not generate Twitter threads. They do generate production systems that ship and stay shipped. Most of the AI tooling conversation is calibrated for the first hour of building something. Semantic Kernel is calibrated for the third year of operating it. That gap, more than anything, is why the framework nobody writes about keeps showing up in the systems that actually matter.
If this was useful, forward it to one engineer who needs less noise in their feed.