Chatbot development frameworks: what to use in 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.
Best chatbot development frameworks in 2026 by use case
There is no single best chatbot development framework in 2026. The useful answer depends on the boundary the assistant has to operate inside:
| Use case | Strong starting point | Why |
|---|---|---|
| Grounded assistant over one knowledge base | Plain tool-calling loop | Small surface, clear traces, no orchestration tax |
| Multi-step assistant with approvals | LangGraph | Explicit state, checkpoints and resumable runs |
| .NET product with existing services | Semantic Kernel | Fits the language, deployment and plugin model already in use |
| Streaming web chat interface | Vercel AI SDK plus a backend service | Handles UI streaming while business rules stay server-side |
| Regulated scripted dialogue | Rasa | Inspectable policies and self-hosted operation |
| Google Cloud voice or contact centre | Dialogflow CX | Mature telephony and explicit conversational state |
| AWS Connect contact centre | Amazon Lex | Native integration usually matters more than framework features |
| Microsoft 365 internal assistant | Copilot Studio or Bot Framework | Identity and distribution align with the existing environment |
Use this as a shortlist, then test the hardest real conversations before committing. The proof should include an ambiguous request, a missing answer, a permission-sensitive lookup, a tool timeout and a human handoff. Compare the resulting traces and failure behaviour, not the quality of the happy-path demo. If two options perform similarly, choose the one your team can debug and operate with the fewest new moving parts.
The framework is also separate from the model provider. A useful evaluation keeps the same test set and retrieval corpus while swapping orchestration, then keeps the orchestration fixed while testing models. Changing both at once makes it impossible to know which decision improved the result.
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.
Chatbot development framework questions
What is a chatbot development framework?
A chatbot development framework supplies components for dialogue state, model calls, retrieval, tools and channel integrations. It reduces setup work, but your application still owns permissions, policy and evaluation.
What is the best chatbot development framework in 2026?
For a simple grounded assistant, start with a plain tool-calling loop. Use LangGraph for resumable multi-step workflows, Rasa for deterministic self-hosted dialogue, or a cloud-native framework when its channel integration saves substantial work.
Is LangGraph better than LangChain for chatbots?
LangGraph is stronger when a conversation has explicit state, branches, approvals or recovery after failure. LangChain offers a broad integration library. A simple assistant may need neither abstraction.
Should a chatbot use Rasa or an LLM framework?
Choose Rasa when dialogue must follow inspectable paths and run inside your boundary. Choose an LLM-oriented stack when questions are open-ended and answers must combine retrieval with tools.
Can I build a chatbot without a framework?
Yes. One model call, retrieval over an approved corpus and a small set of typed tools often need only a clear application loop. This can be easier to test and operate.
Which framework is best for an enterprise chatbot?
The answer depends on identity, deployment and systems of record. Enterprise teams should prioritize permission-aware retrieval, audit trails, reliable integrations and staff expertise over the longest framework feature list.
Which chatbot framework is best for voice?
Dialogflow CX is a strong starting point for Google Cloud telephony, while Amazon Lex fits AWS Connect. Evaluate transcription latency, interruption handling and escalation alongside dialogue features.
How should teams compare chatbot frameworks?
Run the same difficult conversations through each candidate. Include missing information, restricted content, tool failures and human handoff. Compare traces, recovery behavior, operating effort and total integration work.
Does the chatbot framework determine answer accuracy?
Only partly. Corpus quality, retrieval, grounding rules and evaluation usually matter more. A sophisticated framework cannot repair contradictory source material or permissions applied after retrieval.
When should a team change chatbot frameworks?
Change when the current framework blocks a required control, integration or recovery pattern and the migration cost is justified. Poor answers alone usually call for content and retrieval work first.
EpochC builds AI chatbot development services on custom RAG development services, plus custom AI agent development where the assistant needs to act. See four sub-agents behind one conversational API, or start a project.