langchain vs semantic-kernel: one is a provider-swap layer, the other is a .NET SDK with a named successor

What each project actually is

LangChain describes itself as a framework for building agents and LLM-powered applications, with a standard interface for models, embeddings, vector stores and more. Its README quickstart is two lines: uv add langchain, then init_chat_model("openai:gpt-5.5") followed by model.invoke. The repository is Python, MIT-licensed, and its last push was 2026-09-20. The README also points outward: Deep Agents for higher-level agent patterns, LangGraph for controllable agent workflows, LangChain.js for a JS/TS equivalent, and LangSmith for evals, observability and debugging. LangChain the framework is the middle of a larger stack, not the whole of it.

Semantic Kernel describes itself as a model-agnostic SDK to build, orchestrate and deploy AI agents and multi-agent systems. It ships for Python 3.10+, .NET 10.0+ and JDK 17+, on Windows, macOS and Linux. Its repository is C#, MIT-licensed, and its last push was 2026-09-11. The first thing in its README is not a quickstart but a notice: Semantic Kernel is now Microsoft Agent Framework, which the README calls the enterprise-ready successor, available at version 1.0 as a production-ready release with stable APIs and a commitment to long-term support. A migration guide is linked from the same notice.

That notice is the single most important fact on this page. One project is being extended in place; the other has a documented destination.

Architecture: a swap layer versus a kernel with plugins

LangChain's organising idea is provider interchangeability. The README lists model interoperability as a reason to use it: swap models in and out as your team experiments. The mechanism is a common interface over chat models, embeddings, vector stores and retrievers, with an integration catalogue underneath. The cost is the layer itself. Our earlier analysis put it plainly: LangChain is a good fit when you expect to swap providers, and a poor fit if you want a small dependency tree. That trade is the whole design. If your request path must contain only code you wrote, LangChain is working against you.

Semantic Kernel's organising idea is a kernel plus plugins. The README lists a plugin ecosystem that extends with native code functions, prompt templates, OpenAPI specs or Model Context Protocol, and a process framework that models complex business processes as structured workflows. The Python quickstart shows the shape: a ChatCompletionAgent built from AzureChatCompletion, and a MenuPlugin whose methods are decorated with @kernel_function and a description string. In .NET the same pattern appears as Kernel.CreateBuilder(), AddAzureOpenAIChatCompletion, then a ChatCompletionAgent with a Kernel property.

The practical difference is where your code sits. In LangChain your application is composed from framework components and integrations. In Semantic Kernel your functions are ordinary methods wearing annotations, and the kernel binds them to a model. Our earlier analysis noted that the plugin layer is the part most likely to survive a move to the successor framework, while the orchestration layer is the part most likely to be rewritten. Plain kernel functions are the durable asset; agent classes are the exposed one.

Getting each one running

LangChain's documented path is one package and one call. uv add langchain, then init_chat_model with a provider-prefixed string such as "openai:gpt-5.5". There is no kernel object and no builder step in the quickstart. What you must verify is coverage: our earlier analysis says to confirm that init_chat_model accepts the provider string you intend to use, and that the integration you need appears under the Integrations documentation. The README's own pointer to the Integrations providers overview is where that check happens.

Semantic Kernel's documented path is per-language and starts with credentials. You export AZURE_OPENAI_API_KEY or OPENAI_API_KEY, then install: pip install semantic-kernel for Python, or dotnet add package Microsoft.SemanticKernel plus Microsoft.SemanticKernel.Agents.Core for .NET. Java has no inline command in the README; it points to a separate semantic-kernel-java build document. The Python quickstart then constructs AzureChatCompletion, wraps it in ChatCompletionAgent with a name and instructions, and awaits agent.get_response. The .NET quickstart builds a Kernel from a builder, adds an Azure OpenAI chat completion using three environment variables (deployment, endpoint, key), and assigns that kernel to a ChatCompletionAgent.

Two setup details matter more than they look. First, Semantic Kernel's Python sample is Azure-first; the OpenAI path exists but the quickstart code shown is AzureChatCompletion. Second, the README's system requirements are version floors, not suggestions: .NET 10.0+ and JDK 17+. A team on an older .NET runtime has an upgrade to schedule before any agent work begins.

Operations, release channels and scaling

LangChain's recent releases show a stable line and an alpha line running at the same time: 1.3.18 on 2026-08-27, alongside 1.4.0a1 and 1.4.0a2 on 2026-08-27 and 2026-08-28. Our earlier analysis is explicit that you should verify the release you pin is not one of the 1.4.0 alpha builds. Alpha tags on a package index are easy to pick up by accident when a resolver takes the highest version. Pin deliberately.

Scaling and observability in LangChain are partly outside the repository. The README points to LangSmith for developing, debugging and deploying, to LangSmith Deployment for long-running stateful workflows, and to LangGraph for controllable agent workflows. None of those are in the langchain package. The README does not document rollback, nor does it describe a self-hosted control plane inside the framework itself. If you need audit trails or deployment tooling, plan for the surrounding products or build your own.

Semantic Kernel's release cadence is split by language binding: dotnet-1.80.0 on 2026-08-18, python-1.44.1 on 2026-08-06, dotnet-1.79.0 on 2026-08-06. Version numbers do not line up across bindings, so a .NET team and a Python team are on different trains and should not assume feature parity at a given moment. Our earlier analysis says to verify which package version your language binding is on and whether the connectors you need, MCP, Azure AI Search or Chroma, are present in that version. The README lists those connectors as features, but a feature list is not a per-version matrix.

The larger operational fact is the migration. Semantic Kernel's README directs readers to a migration guide for Microsoft Agent Framework. Any scaling plan on Semantic Kernel now includes a framework move, and the README does not document rollback for that move. LangChain's operational risk is dependency churn and alpha tags; Semantic Kernel's is a known destination you will eventually have to travel to.

Where each one falls short

LangChain is the wrong tool for a small job. Our earlier analysis states the case directly: do not adopt it if your application is a single prompt against a single provider, or if you have decided that every dependency in the request path must be yours. The abstraction that makes provider swaps cheap is the same abstraction that sits between you and the wire format. When a provider ships something new, you wait for the integration. When a bug crosses the boundary, you debug through the layer. The README's own framing, chaining interoperable components and third-party integrations, tells you the dependency tree is the product.

Semantic Kernel's shortfall is strategic, and it comes from its own README. A project whose README opens by naming a successor is telling you where new investment goes. Our earlier analysis says not to start a greenfield multi-agent platform on it if you have no existing investment. The README positions Microsoft Agent Framework 1.0 as the production-ready release with stable APIs and long-term support; Semantic Kernel is the thing you migrate from. That does not make existing code worthless, but it changes the default for new code.

There is a second Semantic Kernel gap: documentation depth varies by binding. The README gives Python and .NET quickstarts and leaves Java to an external build document. The system requirements and release tags are also per-language. A reader comparing the two projects on GitHub alone can easily miss that the C# repository is the primary language while the Python package carries its own version line.

Neither project is weak on licence. Both are MIT, so the choice is not a legal one.

Licence and maintenance implications

Both repositories are MIT-licensed and neither is archived. That removes the two questions that usually dominate an open-source comparison: can we ship this in a proprietary product, and is the project dead. The remaining question is direction.

LangChain's last push was 2026-09-20, one day before the date of this page, and its release list shows active versioning across a stable and an alpha channel. The repository is not archived. The maintenance caveat is not abandonment, it is surface area: a framework that spans models, embeddings, vector stores, retrievers and tools has many integration points, and the health of any single one is a separate question from the health of the core. Our earlier analysis tells you to check the Integrations documentation for the specific one you need rather than trusting the category.

Semantic Kernel's last push was 2026-09-11, and its releases span .NET and Python with separate version numbers. The repository is not archived and the code is being maintained. But the README's own notice reframes maintenance as transition: it points to Microsoft Agent Framework as the successor, at version 1.0, with a migration guide. For a reader choosing where to start, that notice outranks any push date. A repository can be actively pushed and still be the wrong place to begin, when its own documentation says so.

Neither README documents rollback. LangChain's does not describe how to revert a deployment; Semantic Kernel's does not describe how to revert the migration. Treat both as one-way operations until you have verified otherwise.

Concrete scenarios

A Python team building a retrieval agent that must run against OpenAI today and a self-hosted model next quarter: LangChain. The provider string in init_chat_model is the mechanism, and the Integrations list is the coverage check. Pin 1.3.18 rather than an alpha.

A .NET shop with an existing service layer, where agents need to call native C# functions and the runtime is already .NET 10: Semantic Kernel is the .NET-native option, and the @kernel_function-style plugin layer is the part worth writing carefully because it is the part most likely to survive. But budget for the migration the README describes, and check the connectors you need against your binding's version.

A greenfield multi-agent platform with no existing code on either project: neither, on the evidence here. LangChain points its advanced orchestration readers to LangGraph and Deep Agents rather than to the framework alone, and Semantic Kernel's README points to Microsoft Agent Framework as the successor. Starting a new multi-agent build on either core package means adopting something its own documentation treats as one layer of a larger stack or as a predecessor.

A team that has working Semantic Kernel code in production: keep it, maintain it, and read the migration guide before the next major feature. The plugin layer is portable; the orchestration layer is not.

A single prompt against a single provider: neither. LangChain's own analysis rules it out, and Semantic Kernel's setup cost, credentials, kernel builder and package set, is not repaid by one call.

Bottom line

Pick LangChain for new Python agent work where provider portability is a real requirement and you accept the abstraction layer; pick Semantic Kernel when you already run it or need .NET-native plugins and will plan the move to Microsoft Agent Framework. Before committing, verify three things on the LangChain side: that init_chat_model accepts your provider string, that your integration is listed under the Integrations documentation, and that your pinned release is not 1.4.0a1 or 1.4.0a2. On the Semantic Kernel side, verify your binding's package version, whether your connectors exist in it, and how much of your code is plain kernel functions rather than agent classes. That last split is the number that decides how expensive the migration is.

Sources

1. langchain-ai/langchain repository
2. langchain-ai/langchain README
3. microsoft/semantic-kernel repository
4. microsoft/semantic-kernel README