Skip to main content
This page contains information about changes between major versions and how you can migrate from one version to another.

Rasa Pro 3.16 to Rasa Pro 3.17

Native A2A sub-agent server

Migration Impact: If an external orchestrator currently calls your Rasa assistant via REST webhooks, custom connectors, or bespoke HTTP integrations, you can migrate to the native a2a_server mode for a standard Agent-to-Agent contract with structured task output. Rasa Pro 3.17 adds native A2A sub-agent server support. With an a2a_server block in endpoints.yml, rasa run exposes the Agent-to-Agent protocol on the same Sanic port as REST and channel webhooks.

Before (custom integration)

  • External orchestrators called Rasa via REST webhooks (/webhooks/rest/webhook) or custom channel connectors.
  • No standard AgentCard for capability discovery.
  • No A2A task lifecycle (working, input_required, completed, etc.).
  • Structured flow/slot results had to be parsed from custom action payloads or tracker APIs.
  • Session continuity (sender_id) was managed manually by the orchestrator.

After (native a2a_server)

  • Standard A2A JSON-RPC on POST / with message/send and message/stream.
  • Auto-generated AgentCard from user-facing flows at startup (GET /.well-known/agent-card.json).
  • Structured DataPart in task status with state, active_flow, slots, and persisted_slots.
  • message/stream SSE with working status and artifact deltas during streaming custom actions.
  • Proper tasks/cancel, messageId idempotency, and orchestrator slot pre-seeding via metadata or DataPart.
  • Optional bearer JWT auth for orchestrators and opt-in HTTP push notifications.

Migration steps

  1. Add a2a_server to endpoints.yml (only description is required):
  1. Set start_session_after_expiry: false in domain.yml — required when A2A is enabled. Resumed orchestrator contextId values reuse the same Rasa sender_id; auto session restart would reset slots silently.
  1. Run with a single Sanic worker per replica until Redis-backed A2A stores ship:
  1. Update your orchestrator to use an A2A client (for example a2a-sdk) against POST / instead of REST webhooks. Fetch GET /.well-known/agent-card.json for capability discovery.
  2. Read task status.message DataPart for structured results instead of parsing raw REST response bodies.
  3. Optionally enable JWT auth and push notifications.
No Action Required: If you do not expose Rasa to external orchestrators, or you only use Rasa as an orchestrator calling external A2A agents (via sub_agents/), no changes are needed.
Not tested for V1Running Rasa as an A2A sub-agent while also invoking external sub-agents (sub_agents/ with protocol: a2a) is not tested for V1.
See also:

Custom voice channel connector changes

Migration Impact: If you maintain a custom voice channel connector, update it for the Rasa Pro 3.17 voice channel runtime changes before upgrading. Built-in voice channels are updated in Rasa Pro 3.17. Rasa Pro 3.17 changes how voice channels register their Sanic routes and run audio streaming. Existing custom voice channels that use the older voice connector APIs can fail at startup or during a call until they are updated. Update custom voice channels as follows:
  • Use conversation_blueprint instead of blueprint. It takes a agent object of type rasa.core.channels.channel.RuntimeAgent.
  • Update calls to self.run_audio_streaming to pass the agent object instead of on_new_message callback.
  • Remove calls to self._register_listeners(blueprint).
After updating the connector, run a call through the channel and verify that call start, audio streaming, interruption handling, and call end events still reach Rasa.

Migrating to Rasa Pro 3.17 — Docker image and Python 3.12

Starting with Rasa Pro 3.17, the official Docker image changes: This follows Python 3.10 end-of-life in October 2026. Rasa Pro continues to support Python 3.10–3.13 when installed outside the official image, but the official 3.17 Docker image ships Python 3.12 only.
Breaking change: TensorFlow-based components are not supported in the 3.17 Docker imageBecause the 3.17 image uses Python 3.12, TensorFlow and its dependencies are not installed and not supported. TensorFlow does not publish compatible wheels for Python ≥ 3.12, so Rasa cannot bundle the TensorFlow stack in this image.The following components cannot be trained or run in the official Rasa Pro 3.17 Docker image:
  • DIETClassifier
  • TEDPolicy
  • UnexpecTEDIntentPolicy
  • ResponseSelector
  • ConveRTFeaturizer
  • LanguageModelFeaturizer
If your config.yml or a trained model archive (.tar.gz) depends on any of these, you cannot deploy it unchanged on the 3.17 image.

FAQ

Does this affect all NLU assistants? No. This is a breaking change for assistants that use TensorFlow-based NLU or policies (the list above). It is not a blanket removal of NLU. Assistants using non-TensorFlow NLU components continue to work on the 3.17 image, for example:
  • LogisticRegressionClassifier / SklearnIntentClassifier
  • CRFEntityExtractor
  • EntitySynonymMapper
  • CountVectorsFeaturizer, RegexFeaturizer, FallbackClassifier
  • SpaCy- or MITIE-based components (with rasa-pro[nlu])
Real-world example: A production bot migrated with LogisticRegressionClassifier, CRFEntityExtractor, and EntitySynonymMapper (no DIET/TED) is not affected by this change. Is the impact limited to DIET and TED? No. The full set of unavailable components is: DIETClassifier, TEDPolicy, UnexpecTEDIntentPolicy, ResponseSelector, ConveRTFeaturizer, and LanguageModelFeaturizer. UnexpecTEDIntentPolicy and ResponseSelector also depend on TensorFlow even though they are not always grouped with DIET/TED in older docs. Does this affect flow-based assistants? No, if they do not reference TensorFlow components. Rasa agents using FlowPolicy, CompactLLMCommandGenerator, etc. are the intended target runtime for the 3.17 image. Can I stay on Python 3.10? Yes, but not with the official 3.17 image. You must build and maintain a custom Docker image pinned to Python 3.10 (or 3.11 if you need TensorFlow). Plan to migrate before Python 3.10 EOL (October 2026).

Who is affected?

Migration options

Custom Docker image on Python 3.10 or 3.11
  • Build your own image if you must keep TensorFlow components in the near term.
  • Python 3.11 is the last version that supports the full TensorFlow NLU stack (pip install 'rasa-pro[nlu]').
  • You are responsible for base image updates, security patches, and compatibility testing.
For bots moving to CALM (long-term recommended):
  • Adopt flows + FlowPolicy / CompactLLMCommandGenerator etc
  • Remove the TensorFlow NLU pipeline entirely.
  • Retrain and validate end-to-end.

Pre-upgrade checklist

Before moving to the Rasa Pro 3.17 Docker image:
  1. Audit config.yml — search for: DIETClassifier, TEDPolicy, UnexpecTEDIntentPolicy, ResponseSelector, ConveRTFeaturizer, LanguageModelFeaturizer.
  2. Audit trained models — inspect the model’s packaged config or your deployment manifest; archived models embed the pipeline/policies used at train time.
  3. Decide per deployment:
    • Cannot migrate yet → build custom 3.10/3.11 image
  4. Re-create virtualenv / image — do not reuse a Python 3.10 venv; reinstall with pip install 'rasa-pro[nlu]' only if you need non-TF NLU extras.
  5. Update CI/CD — pipeline tests that train DIET/TED must run on Python 3.11 or earlier, not the 3.17 image defaults.

Rasa Pro 3.15 to Rasa Pro 3.16

Default Models for LLM-based Components

Migration Impact: If you rely on previous implicit defaults for built-in LLM-based components, pin model names explicitly in endpoints.yml to preserve prior behavior. The default model mapping changed in 3.16.0:

Changes to Default Command-Generator Prompt Templates

Migration Impact: If you use custom prompt_template files, compare them with the updated shipped templates and include the relevant changes. The shipped defaults for command generators changed:
  • CompactLLMCommandGenerator defaults now use:
    • command_prompt_v2_gpt_5_1_2025_11_13_template.jinja2
    • agent_command_prompt_v2_gpt_5_1_2025_11_13_template.jinja2
  • SearchReadyLLMCommandGenerator defaults now use:
    • command_prompt_v3_gpt_5_1_2025_11_13_template.jinja2
    • agent_command_prompt_v3_gpt_5_1_2025_11_13_template.jinja2
See the full shipped templates in the reference docs: If you already provide a custom prompt_template, that custom file is still used.

Changes to Default ReAct Sub-agent Prompt Templates

Migration Impact: If you use configuration.prompt_template for ReAct sub agents or custom completion behavior, align your customizations with the updated defaults. The shipped ReAct defaults changed for:
  • Task-specific prompt template: mcp_task_agent_prompt_template.jinja2
  • General-purpose prompt template: mcp_open_agent_prompt_template.jinja2
  • Built-in task_completed completion guidance/tool instructions
See the reference sections:

Changes to Agent Protocol and Custom Tool Interface

Migration Impact: If you maintain custom A2A/ReAct agent implementations or custom MCP tools, update method signatures and hook usage as described below.

process_output removal and replacement hooks

process_output was removed from the shared agent protocol. Use protocol-specific hooks:

run signature changed

run now supports cooperative cancellation via an optional cancellation_token:

Custom tool callable signature changed

  • Before: Callable[[Dict[str, Any]], AgentToolResult]
  • After: Callable[[Dict[str, Any], AgentToolContext], AgentToolResult]
Import AgentToolContext with:

Support for user_id in DialogueStateTracker

As part of the changes to support session management and user tracking across multiple conversation sessions, the DialogueStateTracker now includes an optional user_id field. This field is automatically handled by Rasa’s built-in tracker stores, but custom tracker store implementations must be updated to support it. If you have a custom tracker store implementation, you need to:

1. Update retrieve() Methods

Ensure your retrieve() and retrieve_full_tracker() methods pass user_id to DialogueStateTracker.from_dict():

2. Update save() and update() Methods

If your custom tracker store uses the mixin inheritance pattern with SerializedTrackerAsText or SerializedTrackerAsDict, then no changes are needed. The mixin classes have been updated to include user_id in serialization automatically. However, if your tracker store implements its own serialise_tracker() method without using the mixins, you must manually include user_id:
Both save() and update() methods preserve user_id:
  • save() uses serialise_tracker() which automatically includes user_id (via mixins)
  • update() typically receives tracker.current_state() which includes user_id

3. Update Deserialization (If Custom)

If you override deserialise_tracker(), ensure you extract and pass user_id:

4. Implement get_serialized_trackers_by_user_id() Method

The GET /users/{user_id}/trackers endpoint now calls get_serialized_trackers_by_user_id() to return conversation data directly from storage, without replaying events through DialogueStateTracker.from_dict() and current_state(). You must implement this method in your custom tracker store to power the endpoint efficiently.
Each returned dict must include at minimum the sender_id, events, and any top-level metadata fields (such as user_id and current_session_id) expected by the API response schema. The current_session_id field should be derived from the metadata of the last event in the tracker’s event list, and must be null when the last event is ConversationInactive.

Removal of the HumanHandoff / hand over command

The HumanHandoffCommand class was removed from the codebase, and the corresponding hand over command was removed from all default prompt templates. If you’re using a custom prompt template that includes the hand over command, please make sure to remove it. If you want to continue using human handoff functionality, you can implement a custom command for that. Please see customization guide for more details: Customizing the Command Set.

Rasa Pro 3.14 to Rasa Pro 3.15

Changes to invoke_llm Method Signature

As part of the Langfuse integration for tracing LLM calls, the invoke_llm method signature has been updated to use LLMInput instead of a plain prompt string. This change enables passing metadata (such as session ID, component name, and model ID) to LLM calls for better observability. This breaking change affects any custom components that override the invoke_llm method in the following components:
  • CompactLLMCommandGenerator
  • SearchReadyLLMCommandGenerator
  • ContextualResponseRephraser
  • EnterpriseSearchPolicy
  • IntentlessPolicy
  • LLMBasedRouter

Migration Guide

If you have custom components that override invoke_llm, you need to update the method signature and how you call the LLM:

Creating LLMInput

When calling invoke_llm, you now need to create an LLMInput object that includes both the prompt and metadata:
The get_llm_tracing_metadata() method is available in all LLM-based components and returns a dictionary with session ID, tags, and custom metadata.

Changes to Pattern Clarification

We modified the pattern_clarification to handle empty clarification options. Here is a comparison between the old and new implementations:

Changes to AgentInput and AgentOutput

Migration Impact: These changes enable intermediate message support for sub agents. If you have custom agent implementations, you may need to update your code to handle the new fields. To enable sending intermediate messages from sub agents, we updated the AgentInput and AgentOutput schemas: AgentInput Changes:
  • Added recipient_id: Optional[str] = None field to ensure intermediate messages are sent to the correct recipient
AgentOutput Changes:
  • Changed the events field from Optional[List[SlotSet]] to Optional[List[Event]] to support bot uttered events for intermediate messages sent to users

Changes to Agent Protocol

Migration Impact: If you have custom agent protocol implementations, you need to update the run method signature to accept the optional output_channel parameter. We added an output_channel parameter to the agent protocol’s run method signature to allow sending intermediate messages directly to users via the output channel:

Updated Default Prompts to Support Current Date Time in Prompts

The default prompt templates for all components that support including current date and time information have been updated to include a “Date & Time Context” section. By default, include_date_time is enabled, so prompts will automatically include date and time context unless explicitly disabled. This change affects the following components:
  • CompactLLMCommandGenerator
  • SearchReadyLLMCommandGenerator
  • EnterpriseSearchPolicy
  • MCPOpenAgent (with timezone support)
  • MCPTaskAgent (with timezone support)

What Changed

By default, the prompts now automatically include a “Date & Time Context” section that displays:
  • Current date (formatted as “DD Month, YYYY”)
  • Current time (formatted as “HH:MM:SS” with timezone)
  • Current day of the week
This context is added to help LLMs understand temporal references and provide time-aware responses.

Impact

If you have custom prompt templates that override the default templates, you may want to review them to ensure they are compatible with the new DateTime context format. The DateTime context is conditionally included using Jinja2 template syntax:

Migration Steps

  1. Review your custom prompt templates (if any) to ensure they work with the new DateTime context format. The DateTime context is included by default, so your templates should handle the current_datetime variable.
  2. Test your components to verify the prompts render correctly with the date and time context included.
  3. If you want to disable date/time context, you can set include_date_time: false in your component configuration:
config.yml
If you’re using the default prompt templates, no action is required, the DateTime context will be automatically included by default.

Rasa Pro 3.13 to Rasa Pro 3.14

Dependencies

To avoid any conflicts we strongly recommend using a fresh environment when installing Rasa >=3.14.0.
The default pip package for rasa-pro now supports Python versions 3.12 and 3.13, and drops support for Python version 3.9. The package will exclude the following dependency categories:
  1. nlu - All dependencies required to run NLU/coexistence bots, including: transformers, tensorflow (and related packages: tensorflow-text, tensorflow-hub, tensorflow-gcs-filesystem, tensorflow-metal, tf-keras), spacy, sentencepiece, skops, mitie, jieba, sklearn-crfsuite.
  2. channels - All dependencies required to connect to channel connectors, including: fbmessenger, twilio, webexteamssdk, mattermostwrapper, rocketchat_API, aiogram, slack-sdk, cvg-python-sdk. Note: The following channels are NOT included in the channels extra: browser_audio, studio_chat, socketIO, and rest (used by inspector for text and voice).
Optional dependency categories are available to install the relevant packages. Use pip install rasa-pro[nlu] if you have an agent with NLU components. Similarly use pip install rasa-pro[channels] if you have an agent making use of channel connectors. Docker images will continue to have the same dependencies as previously, except for the additional packages mcp and a2a-sdk which now form part of the core dependencies. Important: tensorflow and its related dependencies are only supported for "python_version < '3.12'", so components requiring TensorFlow are not available for Python ≥ 3.12. These components are: DIETClassifier, TEDPolicy, UnexpecTEDIntentPolicy, ResponseSelector, ConveRTFeaturizer, and LanguageModelFeaturizer.

Pattern Continue Interrupted

We modified the pattern_continue_interrupted to ask for confirmation before returning to an interrupted flow. Here is an example conversation comparing the old and new implementations:
Rationale for this change:
  1. Improved UX: Immediately returning to interrupted flows often creates an unnatural conversational experience.
  2. Error Correction: Sometimes the command generator incorrectly identifies a cancellation + start flow as a digression. This change allows users to guide the assistant in correcting these mistakes.
  3. Agent Integration: Sub agents sometimes don’t have a reliable way to signal completion. When these agents are wrapped in flows and a digression occurs, we need user input to determine if the agent’s task is complete.
Here is the comparison between the old and the new pattern_continue_interrupted.

Command Generator

Prompt Template

No Action Required: If you don’t use sub agents, your prompt templates remain unchanged. Migration Required: When sub agents are used, Rasa automatically switches to new default prompts that include agent support. If you have customized prompt templates for the CompactLLMCommandGenerator or SearchReadyLLMCommandGenerator, you must update your custom prompts to include the new agent-related commands and functionality. Prompt Templates of the CompactLLMCommandGenerator
The prompt template for the gpt-4o-2024-11-20 model with agent support is as follows:
Prompt Templates of the SearchReadyLLMCommandGenerator
The prompt template for the gpt-4o-2024-11-20 model with agent support is as follows:

Template Rendering

We updated the render_template method to include sub agent information. If you customized the rendering method, add the new sub agent information to your implementation. The key changes to the function are highlighted below.

LLM Clients

We updated the signature of the completion and acompletion functions in our LLMClient protocol to support LLM calls with tools:
The **kwargs are passed through to the underlying LiteLLM completion functions. Migration Required: If you have modified any existing LLM clients or implemented custom clients, update your completion and acompletion methods to match the new signature. Here are a code snippets of the updated implementations in _BaseLiteLLMClient:

Add tool_calls to LLMResponse

We added a tool_calls field to the LLMResponse class to capture tool calls from LLM responses. The _format_response function was updated to extract tool calls from the LiteLLM response. Migration Impact: If you have custom code that processes LLMResponse objects, you may need to handle the new tool_calls field.

Command

Migration Impact: The changes mentioned below improve conversation flow handling and agent state management. No action required unless you have custom command implementations.

StartFlow Command

We updated the run_command_on_tracker method to handle StartFlow commands when users are in pattern_continue_interrupted state, ensuring smooth conversation flow by cleaning up the pattern. We also added proper agent state management to handle agent interruptions. Flow Resumption: Previously, StartFlow commands for flows already on the stack (but not active) were ignored. This behavior was updated to resume the flow instead.

Cancel Command

We updated the run_command_on_tracker method to properly handle agent cancellation when flows are canceled, ensuring active agent stack frames are removed and agents are properly canceled.

Clarify Command

We updated the run_command_on_tracker method to properly signal agent interruption when clarification is needed.

ChitChat Command

We updated the run_command_on_tracker method to properly signal agent interruption when handling chitchat.

KnowledgeAnswer Command

We updated the run_command_on_tracker method to properly signal agent interruption when handling knowledge requests.

Tracing for Jaeger

We updated the port configuration for Jaeger tracing collection. Migration Required: Update your Jaeger configuration to use the new port settings. Updated Docker Command:
Updated Configuration: Update your endpoints.yml file with the new port configuration:
The Jaeger UI is now accessible at http://localhost:16686/search.

Rasa Pro 3.12 to Rasa Pro 3.13

LLM Judge Model Change in E2E Testing

Starting with Rasa Pro v3.13.x, the default model for the LLM Judge in E2E tests has changed from gpt-4o-mini to gpt-4.1-mini, see Generative Response LLM Judge Configuration. The new model may produce lower scores for the generative_response_is_relevant and generative_response_is_grounded assertions, which can cause previously passing responses to be incorrectly marked as failures (false negatives). Action Required:
  • Lower the thresholds for generative_response_is_relevant and generative_response_is_grounded in your E2E test configuration to reduce the risk of false negatives.
  • Alternatively, if you prefer not to lower the thresholds, configure the LLM Judge to use a more performant model (note: this may increase costs). For details on configuring the LLM Judge, see the E2E testing documentation.

Rasa Pro 3.11 to Rasa Pro 3.12

Custom LLM-based Command Generators

In order to improve slot filling in CALM and allow all types of command generators to issue commands at every conversation turn, we have made the following changes which you should consider to benefit from the new CALM slot filling improvements:
  • added a new method _check_commands_overlap to the base class CommandGenerator. This method checks if the commands issued by the current command generator overlap with the commands issued by other command generators. This method returns the final deduplicated commands. This method is called by the predict_commands method of the CommandGenerator children classes.
  • added two new methods _check_start_flow_command_overlap and _filter_slot_commands to the base class CommandGenerator that will raise NotImplementedError if not implemented by the child class. These methods are already implemented by the LLMBasedCommandGenerator and NLUCommandAdapter classes to uphold the prioritization system of the commands.
  • added a new method _get_prior_commands to the base class CommandGenerator. This method returns a list of commands that have been issued by other command generators prior to the one currently running. This method is called by the predict_commands method of any command generators that inherit from the CommandGenerator class. This prior commands can be either returned in case of an empty tracker or flows, or included to the newly issued commands. For example:
  • added a new method _should_skip_llm_call to the LLMBasedCommandGenerator. This method returns True only if minimize_num_calls is set to True and either prior commands contain a StartFlow command or a SetSlot command for the slot that is requested by an active collect flow step. This method is called by the predict_commands method of the LLMBasedCommandGenerator children classes. If the method returns True, the LLM call is skipped and the method returns the prior commands.
  • moved the _check_commands_against_slot_mappings static method from the CommandGenerator to the LLMBasedCommandGenerator class. This method is used to check if the issued LLM commands are relevant to the slot mappings. The method is called by the predict_commands method of the LLMBasedCommandGenerator children classes.

Migration from SingleStepLLMCommandGenerators to the CompactLLMCommandGenerators

It is recommended to use the new CompactLLMCommandGenerator with optimized prompts for the gpt-4o-2024-11-20 and claude-sonnet-3.5-20240620 models. Using the CompactLLMCommandGenerator can significantly reduce costs - approximately 10 times, according to our tests. If you’ve built a custom command generator that extends SingleStepLLMCommandGenerator, we recommend migrating to the new command generator by inheriting the class from CompactLLMCommandGenerator.

Migration from SingleStepLLMCommandGenerators to the CompactLLMCommandGenerators with the custom commands

If yo’ve built a custom command generator that extends SingleStepLLMCommandGenerator and you’ve defined new commands or overridden Rasa’s default commands, you should:
  • Update the parse_commands method to reflect the changes in the command parsing logic.
  • Update the custom command classes so they are compatible with the latest command interface. For details on updating and implementing custom command classes, please refer to How to customize existing commands section.
In the new implementation, command parsing has been delegated to a dedicated parsing utility method parse_commands which can be imported from rasa.dialogue_understanding.generator.command_parser This method handles the parsing of the predicted LLM output into commands more effectively and flexibly, especially when using customized or newly introduced command types. Here is the new recommended pattern for your command generator’s parse_commands method:

Migration of the custom prompt from SingleStepLLMCommandGenerators to the CompactLLMCommandGenerators

If you’ve customized the default prompt template previously used with the SingleStepLLMCommandGenerator and are now migrating to the CompactLLMCommandGenerator, you must update this template to use the new prompt commands syntax. This updated command syntax is specifically optimized for the capabilities of the new CompactLLMCommandGenerator. For more details on the new prompt, refer to the documentation here

Update to utter_corrected_previous_input default utterance

The text of the default utter_corrected_previous_input utterance has been updated to use a new correction frame context property context.new_slot_values instead of context.corrected_slots.values. The new utterance is:

LLM Judge Config Format Change in E2E Testing

The custom configuration of the LLM Judge used by E2E testing with assertions has been updated to use the llm_judge key which follows the same structure as other generative components in Rasa. This can either use model groups configuration or the individual model configuration option. The llm_judge key can be used in the conftest.yml file as shown below:

action property in custom slot mapping replaced with run_action_every_turn

With the deprecation of the custom slot mapping in favor of the new controlled mapping type, the action property associated with the custom slot mapping has been replaced with the run_action_every_turn property. For this reason, if you prefer not to run these custom actions at every turn, it is recommended you remove the action property from your slot mappings.

Rasa Pro 3.9 to Rasa Pro 3.10

LLM/Embedding Configuration

The LLM and embedding configurations have been updated to use the provider key instead of the type key. These changes apply to all providers, with some examples provided for reference. Cohere
Vertex AI
Hugging Face Hub
llama.cpp The support for loading models directly have been removed. You need to deploy the model to a server and use the server URL to load the model. For instance a llama.cpp server can be run using the following command, ./llama-server -m your_model.gguf --port 8080. For more information on llama.cpp server, refer to the llama.cpp documentation The assistant can be configured as:
vLLM The model can be deployed and served through vLLM==0.6.0. For instance a vLLM server can be run using the following command, vllm serve your_model For more information on vLLM server, refer to the vLLM documentation The assistant can be configured as:
CALM exclusively utilizes the chat completions endpoint of the model server, so it’s essential that the model’s tokenizer includes a chat template. Models lacking a chat template will not be compatible with CALM anymore.
Backward compatibility has been maintained for OpenAI and Azure configurations. For all other providers, ensure the use of the provider key and review the configuration against the documentation.

Disabling the cache

For Rasa Pro versions <= 3.9.x, the correct way to disable the cache was:
Rasa Pro 3.10.0 onwards, this has changed since we rely on LiteLLM to manage caching. To avoid errors, change your configuration to -

Custom Components using an LLM

As of Rasa Pro 3.10, the backend for sending LLM and Embedding API requests has undergone a significant change. The previous LangChain version 0.0.329 has been replaced with LiteLLM. This shift can potentially break custom implementations of components that configure and send API requests to chat completion and embedding endpoints. Specifically, the following components are impacted: If your project contains custom components based on any of the affected components listed above, you will need to verify and possibly refactor your code to ensure compatibility with LiteLLM.

Changes to llm_factory

The llm_factory is used across all components that configure and send API requests to an LLM. Previously, the llm_factory relied on LangChain’s mapping to instantiate LangChain clients. Rasa Pro 3.10 onwards, the llm_factory returns clients that conform to the new LLMClient protocol. This impacts any custom component that was previously relying on LangChain types. If you have overridden components, such as a command generator, you will need to update your code to handle the new return type of LLMClient. This includes adjusting method calls and ensuring compatibility with the new protocol. The following method calls will need to be adjusted if you have overridden them:
  • SingleStepLLMCommandGenerator.invoke_llm
  • MultiStepLLMCommandGenerator.invoke_llm
  • ContextualResponseRephraser.rephrase
  • EnterpriseSearchPolicy.predict_action_probabilities
  • IntentlessPolicy.generate_answer
  • LLMBasedRouter.predict_commands
Here’s an example of how to update your code:

Changes to embedder_factory

The embedder_factory is used across all components that configure and send API requests to an embedding model. Previously, the embedder_factory returned LangChain’s embedding clients of Embeddings type. Rasa Pro 3.10 onwards, the embedder_factory returns clients that conform to the new EmbeddingClient protocol. This change is part of the move to LiteLLM, and it impacts any custom components that were previously relying on LangChain types. If you have overridden components that rely on instantiating clients with embedder_factory you will need to update your code to handle the new return type of EmbeddingClient. This includes adjusting method calls and ensuring compatibility with the new protocol. The following method calls will need to be adjusted if you have overridden them:
  • FlowRetrieval.load
  • FlowRetrieval.populate
  • EnterpriseSearchPolicy.load
  • EnterpriseSearchPolicy.train
  • IntentlessPolicy.load
  • Or if you have overridden the IntentlessPolicy.embedder attribute.
Here’s an example of how to update your code:

Changes to invoke_llm

The previous implementation of invoke_llm method in SingleStepLLMCommandGenerator, MultiStepLLMCommandGenerator, and the deprecated LLMCommandGenerator used llm_factory to instantiate LangChain clients. Since the factory now returns clients that conform to the new LLMClient protocol, any custom overrides of the invoke_llm method will need to be updated to accommodate the new return type. Below you can find the invoke_llm method from Rasa Pro 3.9 and its updated version in Rasa Pro 3.10:

Changes to SingleStepLLMCommandGenerator.predict_commands

For SingleStepLLMCommandGenerator, the predict_commands method now includes a call to self._update_message_parse_data_for_fine_tuning(message, commands, flow_prompt). This function is essential for enabling the fine-tuning recipe. If you have overridden the predict_commands method, you need to manually add this call to ensure proper functionality:

Changes to the default configuration dictionary

The default configurations for the following components have been updated: If you have custom implementations based on the default configurations for any of these components, ensure that your configuration dictionary aligns with the updates shown in the tables below, as the defaults have changed. Default LLM configuration keys have been updated from:
to:
Similarly, default embedding configuration keys have been updated from:
to:
Be sure to update your custom configurations to reflect these changes in order to ensure continued functionality.

Dropped support for Python 3.8

Dropped support for Python 3.8 ahead of Python 3.8 End of Life in October 2024. In Rasa Pro versions 3.10.0, 3.9.11 and 3.8.13, we needed to pin the TensorFlow library version to 2.13.0rc1 in order to remove critical vulnerabilities; this resulted in poor user experience when installing these versions of Rasa Pro with uv pip. Removing support for Python 3.8 will make it possible to upgrade to a stabler version of TensorFlow.

Rasa Pro 3.8 to Rasa Pro 3.9

LLMCommandGenerator

Starting from Rasa Pro 3.9 the former LLMCommandGenerator is replaced by SingleStepLLMCommandGenerator. The LLMCommandGenerator is now deprecated and will be removed in version 4.0.0. The SingleStepLLMCommandGenerator differs from the LLMCommandGenerator in how it handles failures of the invoke_llm method. Specifically, if the invoke_llm method call fails in SingleStepLLMCommandGenerator, it raises a ProviderClientAPIException. In contrast, the LLMCommandGenerator simply returns None when the method call fails.

Slot Mappings

In case you had been using custom slot mapping type for slots set with the prediction of the LLM-based command generator, you need to update your assistant’s slot configuration to use the new from_llm slot mapping type. Note that even if you have written custom slot validation actions (following the validate_<slot_name> convention) for slots set by the LLM-based command generator, you need to update your assistant’s slot configuration to use the new from_llm slot mapping type. For slots that are set only via a custom action e.g. slots set by external sources only, you must add the action name to the slot mapping:

Rasa Pro 3.8.0 to Rasa Pro 3.8.1

Poetry Installation

Starting from Rasa Pro 3.8.1 in the 3.8.x minor series, we have upgraded the version Poetry for managing dependencies in the Rasa Pro Python package to 1.8.2. To install the latest micro versions of Rasa Pro in your project, you must first upgrade Poetry to version 1.8.2:

Rasa Pro 3.7 to 3.8

Starting from 3.8.0, Rasa and Rasa Plus have been merged into a single artifact, named Rasa Pro.

Installation

Following the merge we renamed the resulting python package and Docker image to rasa-pro.

Python package

Rasa Pro python package, for 3.8.0 and onward, is located at:
Name of the package is rasa-pro. Example of how to install the package:
While python package name was changed, the import process remains the same:
For more information on how to install Rasa Pro, please refer to the Python installation guide.

Helm Chart / Docker Image

Rasa Pro docker image, for 3.8.0 and onward, is located at:
Example how to pull the image:
For more information on how to install Rasa Pro Docker image, please refer to the Docker installation guide.

Component Yaml Configuration Changes

Follow the below instructions to update the configuration of Rasa Pro components in the 3.8 version:
  • Audiocodes and Vier CVG channels can be specified in credentials.yml using directly their channel name:

Changes to default behaviour

With Rasa Pro 3.8, we introduced a couple of changes that rectifies the default behaviour of certain components. We believe these changes align better with the principles of CALM. If you are migrating an assistant built with Rasa Pro 3.7, please ensure you have checked if these changes affect your assistant.

Prompt Rendering

Rasa Pro 3.8 introduces a new feature flow-retrieval which ensures that only the flows that are relevant to the conversation context are included in the prompt sent to the LLM in the LLMCommandGenerator. This helps the assistant scale to a higher number of flows and also reduces the LLM costs. This feature is enabled by default and we recommend to use it if the assistant has more than 40 flows. By default, the feature uses embedding models from OpenAI, but if you are using a different provider (for e.g. Azure), please ensure -
  1. An embedding model is configured with the provider.
  2. LLMCommandGenerator has been configured correctly to connect to the embedding provider. For example, see the section on configuration required to connect to Azure OpenAI service
If you wish to disable the feature you can configure the LLMCommandGenerator as:
config.yml

Processing Chitchat

The default behaviour in Rasa Pro 3.7 to handle chitchat utterances was to rely on free form generative responses. This can lead to the assistant sending unwanted responses or responding to out of scope user utterances. The new default behaviour in Rasa Pro 3.8 is to rely on IntentlessPolicy to respond to chitchat utterances using pre-defined responses only. If you were relying on free form generative responses to handle chitchat in Rasa Pro 3.7, you will now see a warning message when you train the same assistant with Rasa Pro 3.8 - ” pattern_chitchat has an action step with action_trigger_chitchat, but IntentlessPolicy is not configured”. This appears because the default definition of pattern_chitchat has been modified in Rasa Pro 3.8 to:
For the assistant to be able to handle chitchat utterances, you have two options:
  1. If you are happy with free-form generative responses for such user utterances, then you can override pattern_chitchat to:
  1. If you want to switch to using pre-defined responses, you should first add IntentlessPolicy to the policies section of the config -
Next, you should add response templates for the pre-defined responses you want the assistant to consider when responding to a chitchat user utterance.

Handling of categorical slots

Rasa Pro versions <= 3.7.8 used to store the value of a categorical slot in the same casing as it was either specified in the user message or predicted by the LLM in a SetSlot command. This wasn’t necessarily same as the casing used in the corresponding possible value defined for that slot in the domain. For e.g, if the categorical slot was defined to have [A, B, C] as the possible values and the prediction was to set it to a then the slot would be set to a. This lead to problems downstream when that slot had to be used in other primitives i.e. flows or custom action. Rasa Pro 3.7.9 fixes this by always storing the slot value in the same casing as defined in the domain. So, in the above example, the slot would now be stored as A instead of a. This ensures that the user is writing business logic for slot comparisons, for e.g. if conditions in flows, using the same casing as defined by them in the domain. If you are migrating from Rasa pro versions <= 3.7.8, please double check your flows and custom actions to make sure none of them break because of this change.

Update default signature of LLM calls

In Rasa Pro >= 3.8 we switched from doing synchronous LLM calls to asynchronous calls. We updated all components that use an LLM, e.g.
  • LLMCommandGenerator
  • ContextualResponseRephraser
  • EnterpriseSearchPolicy
  • IntentlessPolicy
This can potentially break assistants migrating to 3.8 that have sub-classed one of these components in their own custom components. For example, the method predict_commands in the LLMCommandGenerator is now async and needs to await the methods _generate_action_list_using_llm and flow_retrieval.filter_flows as these methods are also async. For more information on asyncio please check their documentation.

Dependency Upgrades

We’ve updated our core dependencies to enhance functionality and performance across our platform.

Spacy 3.7.x

Upgraded from >=3.6 to >=3.7. We have transitioned to using Spacy version 3.7.x to benefit from the latest enhancements in natural language processing. If you’re using any spacy models with your assistant, please update them to Spacy 3.7.x compatible models.

Pydantic 2.x

Upgraded from >=1.10.9,<1.10.10 to ^2.0. Along with the Spacy upgrade, we have moved to Pydantic version 2.x, which necessitates updates to Pydantic models. For assistance with updating your models, please refer to the Pydantic Migration Guide. This ensures compatibility with the latest improvements in data validation and settings management.

Rasa Pro 3.7.9 to Rasa Pro 3.7.10

Poetry Installation

Starting from Rasa Pro 3.7.10 in the 3.7.x minor series, we have upgraded the version Poetry for managing dependencies in the Rasa Pro Python package to 1.8.2. To install Rasa Pro in your project, you must first upgrade Poetry to version 1.8.2:

Rasa Pro 3.7.8 to Rasa Pro 3.7.9

Changes to default behaviour

Handling of categorical slots

Rasa Pro versions <= 3.7.8 used to store the value of a categorical slot in the same casing as it was either specified in the user message or predicted by the LLM in a SetSlot command. This wasn’t necessarily same as the casing used in the corresponding possible value defined for that slot in the domain. For e.g, if the categorical slot was defined to have [A, B, C] as the possible values and the prediction was to set it to a then the slot would be set to a. This lead to problems downstream when that slot had to be used in other primitives i.e. flows or custom action. Rasa Pro 3.7.9 fixes this by always storing the slot value in the same casing as defined in the domain. So, in the above example, the slot would now be stored as A instead of a. This ensures that the user is writing business logic for slot comparisons, for e.g. if conditions in flows, using the same casing as defined by them in the domain. If you are migrating from Rasa pro versions <= 3.7.8, please double check your flows and custom actions to make sure none of them break because of this change.

Rasa 3.6 to Rasa Pro 3.7

Installation

Starting from Rasa 3.7.0, Rasa has moved to a new package registry and Docker registry. You will need to update your package registry to install Rasa 3.7.0 and later versions. If you are a Rasa customer, please reach out to your Rasa account manager or support obtain a license.

Python package

Rasa python package for 3.7.0 has been moved to python package registry.
Name of the package is rasa. Example of how to install the package:
For more information on how to install Rasa Pro, please refer to the Python installation guide.

Helm Chart / Docker Image

Rasa docker image for 3.7.0 is located at:
Example how to pull the image:
For more information on how to install Rasa Pro Docker image, please refer to the Docker installation guide.

Migrating from older versions

For migrating from Rasa Open Source versions, please refer to the migration guide.