Rasa has evolved considerably from the earlier chatbot architecture commonly described as separate “Rasa NLU” and “Rasa Core” components. In 2026, Rasa positions its technology around scalable, high-trust conversational AI agents that can combine large language models with explicit business logic and controlled dialogue execution.
A central part of the current approach is CALM (Conversational AI with Language Models). CALM uses an LLM to understand what the user wants and translate that intent into structured commands, while predefined flows and policies determine how the business process is actually executed. This aims to preserve the flexibility of natural language without allowing an LLM to invent critical workflow steps.
Rasa is designed for teams that want more control over conversational behavior than a purely prompt-driven agent may provide. Instead of asking a model to reason freely through every business process, developers can define flows for important tasks and let language models help interpret the conversation and move users through those flows.
CALM: Rasa's controlled LLM framework separates language understanding from business-process execution. The model interprets user input, while structured logic governs what the assistant is allowed to do next.
Flows: Flows describe business processes as clear steps, such as collecting information, calling an action, checking a condition, confirming a choice, or transferring to another flow.
Command Generators: LLM-based command generators analyze the conversation and produce commands that represent how the user wants to progress, such as starting a relevant flow or setting information needed by that flow.
Flow Policy: Once a flow is active, Rasa's dialogue management executes the defined business logic rather than asking the LLM to improvise each operational step.
Classic NLU Coexistence: Intent classification and entity extraction have not simply disappeared. Rasa can support classic NLU patterns and coexistence strategies where deterministic NLU and newer LLM-based dialogue understanding are used together.
Older Rasa tutorials frequently divide the product into “Rasa NLU” for intents and entities and “Rasa Core” for dialogue management. Those concepts are historically important, but they no longer describe the full modern platform.
Classic intent-based assistants can still be appropriate for tightly bounded applications. However, current Rasa documentation places greater emphasis on flows, LLM-based command generation, controlled agent behavior, knowledge search, and enterprise deployment capabilities. When maintaining an older Rasa project, teams should assess which existing NLU, stories, rules, policies, and custom actions remain valuable and where a staged migration to newer flow-based patterns makes sense.
Begin with the processes the agent must complete reliably. A flow might handle a refund request, appointment change, account update, order inquiry, or support escalation. Each flow should define the required information, actions, conditions, and completion criteria.
For CALM-based assistants, an LLM-based command generator can interpret user language and determine which structured commands should move the conversation forward. Clear flow names, descriptions, and boundaries are important because the model uses that context when deciding what the user is trying to accomplish.
For applications where classic NLU is more appropriate, Rasa can still use intent classification and entity extraction. Hybrid designs can route between newer LLM-based behavior and traditional NLU-based logic.
Custom actions allow the assistant to interact with external APIs, databases, CRMs, scheduling systems, order platforms, and other services. Sensitive or irreversible operations should be validated by backend code and authorization rules rather than trusting model output alone.
Rasa's enterprise-search capabilities can support knowledge-grounded answers using retrieval and, where configured, retrieval-augmented generation (RAG). This can help answer questions from approved documentation while keeping transactional workflows separate from open-ended knowledge responses.
A Rasa agent can be connected to supported messaging or voice channels and custom front ends. Deployment planning should include infrastructure, model/provider dependencies, latency, scaling, observability, privacy, secrets management, and the availability requirements of connected business systems.
Rasa is often considered for business-critical assistants precisely because conversational quality is only one part of production reliability. Testing should cover both language behavior and workflow correctness.
Flow tests: Verify that required steps occur in the correct order and that users can correct, interrupt, or change their requests appropriately.
Language variation: Test different ways of asking for the same task, incomplete requests, ambiguous phrasing, typos, and multilingual or domain-specific terminology where relevant.
Tool and API failures: Confirm that the assistant handles timeouts, invalid data, authorization failures, and unavailable backend services safely.
Knowledge quality: Evaluate whether retrieved information is current, relevant, and sufficiently grounded to support the generated answer.
Escalation: Define when the assistant should hand off to a person or stop attempting a task it cannot complete reliably.
It is no longer accurate to describe every current Rasa capability simply as a fully open-source package. Rasa has an open-source history and continues to support classic Rasa concepts, while current Rasa Pro and Rasa Platform capabilities use licensing. Rasa also offers a Developer Edition for getting started with modern features.
Before selecting an architecture, verify the current license, conversation limits, deployment options, support model, and which features require Rasa Pro or other commercial components. These details can change over time.
Customer Service: Combine flexible language understanding with controlled support flows, backend actions, knowledge search, and human escalation.
Regulated or High-Trust Processes: Use predefined business logic where the assistant must follow approved steps and should not invent procedures.
Transactional Assistants: Connect conversational interfaces to APIs for scheduling, account servicing, order management, or other structured tasks.
Internal Enterprise Agents: Help employees navigate procedures, retrieve approved knowledge, and initiate controlled internal workflows.
Rasa is particularly worth evaluating when a team needs conversational flexibility but also wants explicit control over business logic, deployment, integrations, testing, and observability. It can be more engineering-intensive than a simple no-code chatbot builder, so the tradeoff is usually greater control in exchange for more implementation responsibility.
For small marketing automations or straightforward FAQ bots, a lighter platform may be sufficient. For complex, multi-step or mission-critical conversational systems, Rasa's flow-oriented approach can provide a useful separation between what an LLM understands and what the business application is permitted to execute.
Rasa in 2026 should not be evaluated solely through the older “NLU plus Core” mental model. Its modern direction combines LLM-based dialogue understanding with CALM, structured flows, deterministic execution, custom actions, knowledge retrieval, and enterprise-oriented controls.
The key idea is controlled flexibility: let language models help understand natural conversation while keeping critical business processes explicit, testable, observable, and governed. That makes Rasa especially relevant for teams that need AI agents to do real work without surrendering operational control to a free-form prompt.