Skip to main content
You can customise many aspects of how your assistant project works by modifying the following files: config.yml, endpoints.yml, and domain.yml. A minimal configuration for a CALM assistant looks like this:
config.yml
Default ConfigurationFor backwards compatibility, running rasa init will create an NLU-based assistant. To create a CALM assistant with the right config.yml, add the additional --template argument:

Assistant ID

The assistant_id key should be a unique value and allows you to distinguish multiple deployed assistants. This id is added to each event’s metadata, together with the model id. See event brokers for more information. Note that if the config file does not include this required key or the placeholder default value is not replaced, a random assistant name will be generated and added to the configuration every time you run rasa train.

Recipe

The recipe key only needs to be modified if you want to use a custom graph recipe. The vast majority of projects should use the default value "default.v1".

Language

  • The language key sets the primary language your assistant supports. Use a two-letter ISO 639-1 code (e.g., “en” for English).
  • additional_languages key lists codes of other languages your assistant supports.
With these settings, your assistant will default to its primary language but can recognize and respond in all configured languages. You can further translate your assistant’s content. For more details, refer to our Translating Your Assistant guide. Here’s the example for assistant which is using English as default while also supporting Italian, German, and French: config.yml
You can use any valid language or locale-specific code following the BCP 47 standard:
  • Basic language codes: e.g., “en”, “de”, “it”.
  • Locale-specific codes: e.g., “en-US”, “fr-CA”, “de-CH”.
  • Custom language codes: e.g., “x-en-formal”.
Make sure all language codes adhere strictly to this format to avoid unexpected validation errors.
BCP 47 StandardRasa adheres to the BCP 47 standard for language codes. This ensures compatibility with platforms such as Twilio Voice, Genesys Cloud, and Amazon Connect.

Pipeline

The pipeline key lists the components which will be used to process and understand the messages that end users send to your assistant. In a CALM assistant, the output of your components pipeline is a list of commands. The main component in your pipeline is the LLMCommandGenerator. Here is what an example configuration looks like:
config.yml
endpoints.yml
The full set of configurable parameters is listed here. All components which make use of LLMs have common configuration parameters which are listed here

Policies

The policies key lists the dialogue policies your assistant will use to progress the conversation.
config.yml
The FlowPolicy currently doesn’t have an additional configuration parameters.

Silence Timeout Handling

Silence timeouts help your assistant handle situations where the user doesn’t respond. For now, this setting only works with voice-stream channels, such as:
  • Twilio Media Streams
  • Browser Audio
  • Genesys
  • Jambonz Stream
  • Audiocodes Stream
There are two types of timeouts you can configure.

Global Silence Timeout

You can set a default silence timeout across your assistant by adding this to your endpoints.yml:
endpoints.yml
This means the assistant will wait 7 seconds (or your configured value) for a user reply before treating it as silence and triggering fallback logic.

Local (Per-Step) Silence Timeout

You can override the global value for specific Collect steps:
or for a specific channel in that step:
For channels not listed, the timeout set in credentials or global silence timeout of 7 seconds (if not set for a channel in credentials.yml) will be used. This allows you to fine-tune the timing for specific questions. For example, you may want to:
  • Wait longer on more complex or sensitive questions (e.g., “Can you describe your issue?”)
  • Use shorter timeouts for quick prompts (e.g., yes/no questions)
Tailoring silence handling this way improves the conversational experience.

Enabling/Disabling Silence Timeouts

If you want to disable silence detection so it never triggers during a conversation, you can set the timeout to a very high value. For example, to disable it globally:
endpoints.yml
Use this approach if you want to avoid fallback interruptions but still need a valid numeric value for configuration or platform compatibility.
Disabling Silence Timeouts at step levelIf silence timeout is set at the step level, that value has precedence over the global or channel-specific setting. In order to disable silence timeout for a specific step, set it to a very high value (e.g., 70000 seconds) in that step’s configuration.

Customizing the Assistant’s Response to Silence

When the silence timeout is reached, the assistant triggers the pattern_user_silence. You can customize how your assistant responds to silence by modifying this pattern. 👉 Learn more about patterns configuration

Minimum pacing between bot messages (voice streams)

On voice stream channels, Rasa can enforce a minimum gap between consecutive bot audio segments so back-to-back utterances do not sound rushed. When the next bot message is ready, the channel compares the time since the previous message finished playing against a configured minimum. If not enough time has passed, it streams silence for the remaining duration on the same audio path as speech (it does not block the server with a sleep), then plays the next message. This applies to the same class of streaming voice connectors as silence timeout handling.

Regular utterances vs filler

Two types of minimum gaps are used:
  • Between ordinary consecutive bot messages: a shorter default gap (1 second).
  • After a filler message: a longer default gap (2 seconds). Filler messages are short, streamed assistant audio played while longer operations are in progress, for example, brief assistant text sent alongside tool calls from ReAct agents when enabled. A longer pause follows these messages to provide clearer separation before the next substantive response.
If there is no prior bot audio in the turn (for example, the first reply after the user speaks), pacing does not insert a delay ahead of that reply.
These delays are fixed defaults in the voice streaming stack.