We're a .NET shop that ran a pilot with LangGraph for a customer support automation project. After three months, we switched to Semantic Kernel. The decision wasn't about one being "better," but about what fit our ecosystem.
The main learning: LangGraph's Python-first nature created a friction point for our entire team. While the concepts are transferable, debugging and extending Python-based graphs within our predominantly .NET/C# codebase added overhead. Semantic Kernel, being native to .NET, allowed for tighter integration and let our existing developers move faster with familiar tooling.
Key takeaways:
* LangGraph's stateful orchestration is powerful for complex, looping workflows. For our more linear support ticket classification and routing, it was overkill.
* Semantic Kernel's planning capabilities were sufficient and more approachable for our use case.
* The integration with Azure AI Services and existing .NET libraries was nearly seamless with Semantic Kernel, reducing custom glue code.
For a mixed stack, LangGraph might still be the answer. For a shop like ours, built on Microsoft technologies, the switch reduced complexity. Always evaluate against your team's core competencies and where the bulk of your application lives.
I'm a lead developer at a mid-sized fintech company running mostly on .NET Core and Azure. We've evaluated both frameworks for internal document processing agents and have Semantic Kernel handling live classification workflows.
* **Team Efficiency and Tooling**: For a dedicated .NET team, Semantic Kernel cuts initial setup by half, maybe more. LangGraph requires bridging Python/.NET (like with gRPC), adding at least a week of integration overhead and ongoing debug complexity. With Semantic Kernel, our devs work entirely in Visual Studio with native debugging.
* **Cost Model and Scaling**: Semantic Kernel's core is open-source with costs tied to your chosen LLM (Azure OpenAI, etc.). LangGraph's commercial cloud offering starts around $0.10 per 1k "state transitions" in my last review, which can add up fast for high-volume workflows. For low-to-medium throughput linear tasks, Semantic Kernel on our own infra was predictably cheaper.
* **State Management and Complexity**: LangGraph's built-in state persistence and conditional loops excel for multi-step, recursive processes (like negotiation bots). Semantic Kernel's planner is more linear; for a straightforward support ticket flow (classify -> route -> log), that's actually a benefit. We found LangGraph's power came with a learning curve our team didn't need.
* **Azure Ecosystem Integration**: Semantic Kernel has first-class connectors for Azure AI Search, Azure OpenAI, and Microsoft Entra ID. Implementing equivalent security and data retrieval with LangGraph meant writing custom middleware, which introduced a minor security review bottleneck for us.
Given your description of a linear support ticket flow and a pure .NET shop, I'd stick with Semantic Kernel. The fit is just cleaner. If your workflows start needing complex human-in-the-loop branching or stateful multi-session conversations, then reevaluate LangGraph. Tell us more about your projected request volume and whether you need to integrate with any non-Microsoft services.
Your point about LangGraph's cost per state transition is interesting. We saw similar behavior in a prototype, but the actual latency from those cloud-based transitions was the real bottleneck for us. Each state hop added 80-120ms on average, which killed our target for sub-second response on classification tasks.
That's where the linear planner in Semantic Kernel shined for us. It kept the operation mostly within a single service boundary. Have you measured the end-to-end latency difference between the two approaches for your document workflows? I'd be curious if the cost correlates with the time penalty.
ms matters