Chatbot Development Frameworks Compared (2026)

Short answer: there are two families, and picking the wrong one costs months. Intent-based frameworks — Rasa, Dialogflow CX, Amazon Lex, Microsoft Bot Framework — enumerate what the bot can understand. LLM-native orchestration — LangGraph, Semantic Kernel, the Vercel AI SDK, or a plain tool-calling loop — composes answers from retrieval and tools. For anything new, start in the second family. The first still wins where determinism is a hard requirement or a working investment is too large to rewrite.

The frameworks, and what each is actually for

Framework	Family	Language	Runs	Best fit
Rasa	Intent, with LLM dialogue in Rasa Pro	Python	Self-hosted	Regulated or on-premise work where the transcript must be defensible
Dialogflow CX	Intent, explicit state machine	Config first	Managed, Google Cloud	Large scripted flows, strong telephony and voice
Amazon Lex	Intent	Config first	Managed, AWS	Contact-centre work already inside AWS Connect
Microsoft Bot Framework	Intent, SDK	C#, JavaScript	Either	Teams and Microsoft 365 surfaces
Copilot Studio	Low-code, LLM-assisted	Visual	Managed	Business users building internal assistants
Botpress	Hybrid, visual and LLM	TypeScript	Either	Small teams wanting a builder without going low-code
LangChain	LLM-native library	Python, JS	Yours	Prototyping, and the integration surface
LangGraph	LLM-native orchestration	Python, JS	Yours	Multi-step flows, human checkpoints, replay after failure
Semantic Kernel	LLM-native SDK	C#, Python, Java	Yours	.NET shops wanting plugins and planners in-process
Vercel AI SDK	LLM-native, front-end first	TypeScript	Yours	Streaming chat UI wired to tool calls
Plain tool-calling loop	None	Anything	Yours	Most single-corpus assistants

That last row is not a joke, and it is the one we reach for most in chatbot development work. Most assistants answer from one corpus and call two or three tools, and that does not need a framework.

The intent family

Rasa is the one to reach for when the answer has to be defensible. It runs entirely inside your infrastructure, the dialogue policy is inspectable, and you can point at exactly why the bot said what it said. Rasa Pro’s newer dialogue understanding uses a language model to decide what the user wants while keeping the business logic in code, which is a sensible middle position. The cost is that you own the deployment, the training pipeline and the ops.

Dialogflow CX models conversation as an explicit state machine, which is genuinely better than its predecessor for anything with more than a handful of paths. It is strongest where voice matters. If your bot is going to answer a phone, the telephony integration here represents real work you would otherwise redo badly.

Amazon Lex is the same shape with a different owner. The reason to pick it is almost always that your contact centre is already on AWS Connect and you want one vendor.

Microsoft Bot Framework is an SDK rather than a console, so it suits engineers, and its reason to exist is reach into Teams and Microsoft 365. Copilot Studio is the low-code sibling aimed at business users. Both are the right answer mainly when the surface is Microsoft’s.

The LLM-native family

LangChain is the library everyone starts with and many later regret. The integration catalogue is genuinely useful and the abstractions are heavy enough that, when behaviour surprises you, you are debugging the framework rather than your system. Fine for a prototype, harder to live with.

LangGraph, from the same team, is the one we default to for real work. State is explicit and typed, a run can be checkpointed and resumed, and “what happens when step seven fails” has an answer you can write a test for. The trade is a steeper start: you have to model the flow before you can run it, which feels slow right up until the first production failure.

Semantic Kernel is the natural choice in a .NET shop. Plugins and planners run in-process alongside existing services, and that beats standing up a Python sidecar for the sake of a framework.

Vercel AI SDK solves a different problem from the rest: streaming a conversation into a web interface, with tool calls and generative UI. It is a front-end library that happens to talk to models, and pairing it with your own backend logic is a perfectly good architecture.

Botpress sits across both families, offering a visual builder that has moved steadily toward LLM-native behaviour. It suits a small team that wants structure without writing orchestration code.

What changed

Intent frameworks exist because older systems could not compose language. You enumerated intents, mapped utterances to them, extracted entities, and scripted responses. Everything the bot could say, someone wrote.

That approach has a hard ceiling. Anything outside the enumerated intents falls through to a fallback, users learn the phrasebook is narrow, and a mature bot becomes hundreds of intents nobody can safely modify — adding one risks shadowing another.

Retrieval plus generation removes the enumeration problem entirely. You are no longer predicting phrasings; you are making sure the answer exists in retrievable form and constraining what the model may assert. That is a better problem to have.

Where the old frameworks still win

Hard determinism. If a regulator requires that a specific question always produces a specific approved sentence, an intent match into a scripted response is the honest way to guarantee it. You can achieve this in a modern stack with a deterministic route, but if most of your surface needs it, an intent framework is not the wrong tool.

Sunk investment that still works. A Dialogflow bot handling 60% of contacts is not a rewrite candidate just because the architecture is dated. The upgrade worth costing is usually replacing the fallback path with grounded retrieval — keep the intents that work, and let retrieval handle everything that currently dead-ends.

Voice and telephony. The mature IVR integrations, barge-in handling and telephony plumbing in these platforms represent real work you would otherwise redo.

What a modern stack looks like

There is no single framework, which is why the question feels unsatisfying. The pieces:

Layer	What it does	Common choices
Retrieval	Finds the passages that answer the question	pgvector, BM25 hybrid, a managed index
Grounding	Threshold, citations, refusal when nothing matches	Yours
Orchestration	Routing, tool calls, multi-step flows	LangGraph, a plain tool-calling loop
Tools	Actions against your systems of record	Yours, typed and validated
Guardrails	What it may assert, permission-aware retrieval	Yours
Observability	Traces, resolution metrics, unanswered questions	Langfuse, LangSmith

Notice how much of that column says “yours”. The frameworks handle orchestration; the parts that decide whether the assistant is any good — retrieval quality, grounding, permissions — are not framework features. That is the honest answer to “which framework should we use”: it matters less than the layers around it.

Orchestration: framework or loop

For a chatbot that answers from a corpus and occasionally calls a tool, a structured tool-calling loop with your own control flow is usually clearer than any framework. Fewer abstractions between you and the behaviour you are debugging.

A framework earns its place when you have genuine multi-agent routing, long-running flows with human checkpoints, or a need to inspect and replay state after a failure. LangGraph is our default there because explicit graph state makes behaviour testable and “what happens when step 7 fails” has a real answer. We compared the options in LangGraph vs LangChain and went deeper in AI agent platforms vs building your own.

The failure mode we see most is a framework adopted for a problem that did not need one, where the abstraction now obscures the thing you are trying to fix.

The platform question is separate

“Framework” and “platform” get conflated. Intercom, Zendesk and the rest are platforms — hosted products with connectors, analytics and a UI. Frameworks are libraries you build with.

Use a platform when your content is public-facing, permissions are uniform, and nothing the bot does writes to a system of record. Build when retrieval must respect per-user permissions, when the assistant must act in systems the platform does not reach, when data cannot leave your infrastructure, or when per-seat pricing dominates at your scale. We laid out the economics in AI chatbot development: cost and timeline.

Choosing, concretely

Is any part of your surface required to be deterministic? If most of it is, intent frameworks are still reasonable. If a little is, route those cases deterministically inside a modern stack.
Does the assistant act, or only answer? Acting means tool contracts, authorisation and idempotency, and pushes you toward an orchestration framework.
Is retrieval permission-sensitive? If yes, that constraint reaches back into ingestion and rules out most turnkey options.
Who maintains it? A plain loop is easier for an engineer; a platform is easier for everyone else.

Question three catches teams out most often, because it is discovered late and is expensive to retrofit.

The takeaway

The framework choice is a smaller decision than it looks. Retrieval quality, grounding discipline and permission handling decide whether a chatbot works, and none of them are framework features. Pick the smallest orchestration layer that expresses your flow — often a plain tool-calling loop — and spend the saved effort on the corpus.

EpochC builds AI chatbots and domain-grounded assistants on production RAG and retrieval, plus AI agents where the assistant needs to act. See four sub-agents behind one conversational API, or start a project.

Chatbot development frameworks: what to use in 2026