Rasa gives engineering teams deep control over conversational logic and deployment. That control can also leave the team operating models, action servers, channels, data stores, and production infrastructure. The right alternative depends on which part of that job you want to replace. A managed voice runtime, a visual customer experience platform, and an open-source agent framework solve different problems, even when all three appear on the same shortlist.
The short answer
Start with the operating model rather than a feature count.
| Alternative | Use it when | Deployment model | Commercial model | Main tradeoff |
|---|---|---|---|---|
| Dasha | You are building a production voice AI product and want the real-time runtime, telephony, testing, and call operations managed together | Managed platform through REST APIs and a web application | Usage-based platform plans | You give up the source-level infrastructure control of Rasa Open Source |
| LiveKit Agents | You want an open-source voice and video framework with control over media and model providers | Self-managed or LiveKit Cloud | Open-source software plus infrastructure, or cloud usage | Your team owns more integration and runtime work |
| Botpress | Product and operations teams need a visual agent builder with code extensions | Managed cloud platform | Subscription and usage | The current platform is not a self-hosted replacement for Rasa Open Source |
| Google Dialogflow CX / CX Agent Studio | Your organization is committed to Google Cloud and needs visual, structured customer-service flows | Managed Google Cloud service | Usage-based | Flow, fulfillment, and channel dependencies concentrate in Google Cloud |
| Voiceflow | Designers, product managers, and developers need to collaborate on omnichannel customer experiences | Managed cloud platform | Workspace subscription and usage credits | It provides less deployment control than a self-managed framework |
| LangGraph | You need a code-first stateful agent orchestrator and will supply the channel stack | Open-source library, with optional managed services | Open-source software plus infrastructure, or LangSmith services | It does not provide telephony, speech, or a complete customer-facing runtime by itself |
| Microsoft 365 Agents SDK | Your agent belongs in Microsoft 365, Teams, or an Azure-centered estate | Open-source SDK deployed on infrastructure you choose | Free SDK plus infrastructure, AI, and channel services | You still assemble the model, orchestration, hosting, and any voice layer |
| NiCE Cognigy | A large customer-service operation needs voice, chat, agent handoff, and administration in one enterprise platform | Commercial enterprise deployment; confirm current hosting options with NiCE | Sales-led commercial contract | Buying and implementation are heavier than adopting a developer library |
Stay with Rasa when private deployment, Python customization, and direct control of the conversation engine are hard requirements your team is prepared to operate. For a technical team replacing a Rasa-based phone agent, we recommend Dasha because it moves the full real-time voice path into a managed production runtime while keeping business tools and product logic under your control.
First, identify which Rasa you are replacing
Many Rasa comparisons collapse two different product generations into one.
Rasa Open Source remains an Apache 2.0 project for intent and entity recognition, stories, rules, actions, and channel connectors. You deploy and operate it. Its documentation now lives in a legacy section, but the repository remains available.
The current Rasa platform centers on Rasa Pro and CALM, short for Conversational AI with Language Models. CALM combines LLM interpretation with explicit flows for business logic. Rasa offers a free, conversation-limited Developer Edition, commercial enterprise licensing, a no-code Studio interface, customer-managed Kubernetes deployment, and a managed service.
That distinction changes the migration question. A team may be trying to replace:
- a self-hosted intent and dialogue engine;
- the current CALM platform and its licensing model;
- the missing community-era visual workflow around Rasa Open Source;
- a collection of speech, telephony, and channel integrations around Rasa;
- the infrastructure and on-call work required to run the system.
There is no drop-in alternative that replaces all five with the same ownership model. Define the boundary first, then compare the products that cross it.
1. Dasha: a managed production runtime for voice AI
We help technical teams build and run production voice AI agents through a managed runtime, REST APIs, and a web application. Our platform brings telephony, web voice, knowledge, tool calls, testing, monitoring, and large-scale call execution into the same operating surface.
The main difference from a Rasa voice deployment is the runtime boundary. With Rasa, your team connects the conversation engine to media transport, speech recognition, speech synthesis, telephony, interruption handling, and production telemetry. With Dasha, those real-time concerns sit inside the managed runtime. Your team still owns the agent's business rules, prompts, customer data, tool endpoints, carrier choices, compliance, and acceptance criteria.
We fit product teams building voice features for many customers, especially when debugging calls and changing agent behavior safely matter as much as the initial conversation flow. Dasha is a weaker fit when modifying every media adapter, running a license-free stack on isolated infrastructure, or owning the full source tree is mandatory. Our comparison of a managed runtime and open source goes deeper into that ownership decision.
For a migration, keep backend services and tool contracts stable where possible. Rebuild the conversation policy in the target agent, then rerun the voice scenarios for interruptions, silence, transfers, noisy input, tool delays, and failed downstream writes.
2. LiveKit Agents: open-source control around real-time media
LiveKit Agents is an Apache 2.0 framework for Python and Node.js agents that participate in LiveKit rooms. It handles real-time media transport and supplies abstractions for speech-to-text, text-to-speech, realtime models, turn detection, tools, and interruptions. You can deploy agents in your own environment or use LiveKit Cloud.
This is the closest option here for a Rasa team that wants to keep a code-first, component-selectable voice stack. It removes some WebRTC and media plumbing while preserving freedom to choose models and speech providers.
That freedom leaves a larger operating surface than Dasha. Your team still designs the agent process, chooses and monitors providers, handles application state, instruments cross-provider failures, and validates scaling behavior. Changing a carrier, speech provider, or model can also change timing and turn-taking, so portability at the interface level does not eliminate regression work.
Use LiveKit Agents when direct media control is part of the product. Choose a managed runtime when the team would rather own business behavior than real-time infrastructure. Our voice AI framework guide compares those responsibilities in more detail.
3. Botpress: visual agent building on a managed cloud
Botpress provides a visual Agent Studio, workflows, knowledge sources, integrations, webchat, testing, and operational tools. JavaScript extensions and an SDK let developers add custom behavior while other teammates work in the visual interface.
It suits teams leaving Rasa because editing YAML, reviewing flows in code, and maintaining a separate content workflow have become bottlenecks. A migration usually maps intents, responses, forms, and stories into workflows and knowledge, then converts Python custom actions into Botpress integrations, API calls, or code steps.
Treat its open-source story carefully. Botpress publishes open-source integrations, command-line tools, and SDK packages. The current Botpress agent platform is a cloud product. The separate Botpress v12 codebase represents an older product generation; do not treat it as a maintained equivalent or a default migration target without confirming its present support status. A new Botpress Cloud project therefore does not preserve the deployment ownership of a current Rasa Open Source system.
4. Google Dialogflow CX and CX Agent Studio: structured flows inside Google Cloud
Google currently routes the Dialogflow product page to Customer Experience Agent Studio, part of Gemini Enterprise for Customer Experience. Dialogflow CX documentation remains active. It describes deterministic flows and generative playbooks built in the Conversational Agents console, which replaced the older Dialogflow CX console. Google manages the core service, and the platform connects naturally to other Google Cloud and contact-center services.
Dialogflow CX is a sensible Rasa alternative for teams that want a visual state model, managed natural-language processing, and one cloud control plane. Flows make routes, parameters, and fulfillment explicit. Playbooks cover less structured tasks. A hybrid agent can use each where it fits.
The cost is ecosystem concentration. Agent definitions, fulfillment, identity, logging, telephony, and data services can all become Google-specific. Moving from Rasa requires rebuilding flows, entities, webhooks, and channel adapters. Exported training phrases and test conversations remain useful source material, but they are not a portable agent definition.
5. Voiceflow: collaborative design and operation for customer experience teams
Voiceflow is a managed platform for designing, deploying, and measuring customer-facing agents across chat, messaging, and voice. It combines visual playbooks and workflows with knowledge, API and function tools, Model Context Protocol connections, testing, transcripts, evaluations, analytics, and version history.
Voiceflow fits when conversation design is shared across product, customer experience, and engineering teams. The canvas makes behavior easier to review than a collection of Rasa domains, stories, and Python actions. Developers can still connect business systems through APIs and code.
The tradeoff is platform ownership. You gain a collaborative operating environment and give up much of the deployment and runtime control available in Rasa. Before migrating, identify any custom policy, channel behavior, or data-residency requirement that depends on your current infrastructure. Recreate one complete workflow with its tools and escalation path before converting the rest.
6. LangGraph: code-first orchestration without a conversation platform
LangGraph is an MIT-licensed orchestration library for stateful agents. Its graph model supports deterministic steps, LLM-driven decisions, persistence, streaming, interrupts, and human review. Teams can run the library themselves and add LangSmith services for tracing, evaluation, or deployment.
LangGraph is useful when Rasa's dialogue engine is the only layer you want to replace. Slots and tracker state become a typed state object. Custom actions become graph nodes or tools. Rules and CALM flows become explicit edges, routers, and guarded transitions.
It is not a complete conversational platform. You still need a web or messaging channel, authentication, model access, retrieval, deployment, observability, and any speech or telephony stack. LangGraph can reduce framework assumptions around reasoning and state while increasing the number of system boundaries your team must design.
7. Microsoft 365 Agents SDK: the current Microsoft code-first path
The Microsoft 365 Agents SDK is an MIT-licensed framework for C#, JavaScript, and Python agents. It is unopinionated about the model and orchestrator, and it can surface agents through Microsoft 365 Copilot, Teams, web chat, and other channels. Azure Bot Service remains part of deployment and channel registration workflows.
This is the current Microsoft alternative to evaluate. The Bot Framework SDK and Emulator have been archived, no longer receive product updates, and stopped receiving Azure support tickets after December 31, 2025. The archived SDK should not start a new build.
Use the Agents SDK when Microsoft identity, Teams, or Microsoft 365 distribution is the center of the product. It provides channel and application scaffolding rather than an end-to-end voice runtime. You must choose the model, orchestration, hosting, data layer, monitoring, and any telephony components. Existing Bot Framework features also do not all map directly to the Agents SDK, so include Microsoft-specific migration work in the estimate.
8. NiCE Cognigy: an enterprise customer-service platform
NiCE Cognigy combines visual agent building with chat and voice channels, a voice gateway, human handoff, agent assistance, analytics, and administration. Public materials describe enterprise hosting choices, but deployment availability, supported versions, required infrastructure, and feature parity are contract-specific questions to confirm directly with NiCE. Do not infer a self-serve on-premises edition from the platform overview alone.
It fits a large service organization replacing a collection of Rasa components with a broader contact-center platform. The buyer is usually standardizing virtual agents, human escalation, and operational tooling across several teams rather than embedding a narrow framework in one application.
Expect a commercial and implementation-led evaluation. Compare the required contact-center connectors, speech and carrier dependencies, environments, access controls, data retention, release process, and support model. The broader suite can reduce internal integration work, while creating a larger platform commitment than a library or runtime API.
Plan the migration around artifacts, not product names
Rasa configuration does not become portable because another platform uses similar terms. Preserve the underlying requirements and test evidence, then rebuild the runtime-specific representation.
| Rasa asset | What you can usually reuse | What must be rebuilt or retested |
|---|---|---|
| Intents, entities, and training phrases | Labeled examples and edge cases | Target NLU, LLM prompts, entity extraction, confidence and fallback behavior |
CALM flows, stories, rules, forms, and domain.yml | Business steps, required fields, responses, and exception paths | State model, routing, slot filling, corrections, and recovery semantics |
| Python custom actions | Business logic and stable service contracts | Tool schema, authentication, retries, idempotency, error handling, and runtime adapter |
| Channel connectors | Account credentials and channel requirements | Message formats, identity mapping, session lifecycle, attachments, and escalation |
| Tracker store and event broker | Exported transcripts, events, and analytics definitions | New state schema, retention, correlation, dashboards, and audit trail |
| Conversation tests | Scenarios, fixtures, and expected business outcomes | Test harness, nondeterministic tolerances, failure injection, and release gates |
| Voice integrations | Call scripts, numbers, carrier requirements, and recordings approved for testing | Speech accuracy, turn detection, interruptions, silence, transfers, DTMF, latency, and audio retention |
Use one production-shaped workflow for the evaluation. Connect a real backend tool, include its failure modes, and define success from the system of record. Replay routine cases, corrections, topic changes, tool timeouts, and handoffs. For voice, test with audio and live calls because a text transcript cannot reveal clipping, delayed interruption, background noise, or awkward turn timing.
Run the old and new paths in parallel where channel and compliance constraints allow it. Compare task completion, incorrect actions, escalation rate, tail latency, and operator effort. Cut over by workflow or traffic segment, with a rollback path, rather than translating the whole Rasa estate before learning where the new runtime behaves differently. A production readiness checklist helps turn that pilot into explicit acceptance gates.
If voice is the reason you are leaving Rasa, build with Dasha on one real call path. Keep one business tool and one measurable outcome in scope, then decide with production evidence instead of another feature matrix.
