Build your first agent in just a few minutes with [Rasa Copilot](https://hello.rasa.com/?utm_source=docs&utm_medium=referral&utm_campaign=docs_cta).

On this page

You can customise many aspects of how your assistant project works by modifying the following files: `config.yml`, `endpoints.yml`, and `domain.yml`.

## Configuration File

The `config.yml` file defines how your Rasa assistant processes user messages. It specifies which components, policies, and language settings your assistant will use. Here's the minimal configuration required to run a CALM assistant:

```yaml
recipe: default.v1
language: en

pipeline:
  - name: CompactLLMCommandGenerator

policies:
  - name: FlowPolicy
```

Below are the main parameters you can configure.

### Recipe

- Rasa provides a default graph recipe: `default.v1`. For most projects, the default value is sufficient.
- In case you're running ML experiments or ablation studies and want to add a custom graph recipe, [this guide has you covered](/content/docs/reference/config/components/graph-recipe/index.html).

### Language

- The `language` key sets the primary language your assistant supports. Use a [two-letter ISO 639-1 code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) (e.g., `"en"` for English).
- The `additional_languages` key lists codes of other languages your assistant supports.

👉 [Learn more about language configuration](/content/docs/reference/config/overview/#language/index.html)

### Pipeline

The `pipeline` section lists the components that process the latest user message and produce **commands** for the conversation. The main component in your pipeline is the `LLMCommandGenerator`.

```yaml
  pipeline:
    - name: CompactLLMCommandGenerator
      llm:
        model_group: openai_llm
      flow_retrieval:
        embeddings:
          model_group: openai_embeddings
      user_input:
        max_characters: 420
```

👉 [See the full set of configurable parameters](/content/docs/reference/config/components/llm-command-generators/index.html)

### Policies

The `policies` key lists the dialogue policies your assistant will use to progress the conversation. For CALM, you need at least the `FlowPolicy`. It doesn’t require any additional configuration parameters.

👉 [Learn more about policies](/content/docs/reference/config/policies/overview/index.html)

### Assistant ID

The `assistant_id` key defines the unique identifier of your assistant. This ID is included in every event’s metadata, alongside the model ID. Use a distinct value to help differentiate between multiple deployed assistants.

```yaml
  assistant_id: my_assistant
```

caution

If this required key is missing or still set to the default placeholder, a random assistant ID will be generated and added to your configuration each time you run `rasa train`.

## Endpoints

The `endpoints.yml` file defines how your assistant connects to key services — like where to store conversations, execute custom actions, fetch trained models, or generate responses.

Below are the main parameters you can configure.

### Tracker Store — Where conversations are stored

The `tracker_store` determines where Rasa keeps track of conversations. This is where your assistant remembers past interactions and makes decisions based on conversation context. You can store trackers in a file, a database (like PostgreSQL or MongoDB), or other storage backends.

👉 [How to configure tracker stores](/content/docs/reference/integrations/tracker-stores/index.html)

### Event Broker — Where conversation events are sent

Conversation history is comprised of **events** — every user message, action, or slot update is one. The `event_broker` sends these to other systems (e.g. for monitoring, analytics, or syncing with a data warehouse). It’s especially useful in production setups.

👉 [How to configure event brokers](/content/docs/reference/integrations/event-brokers/index.html)

### Action Endpoint — Where custom code runs

When your assistant needs to do something dynamic — like fetching user data or making an API call — it uses custom actions. The `action_endpoint` tells Rasa where your action server is running so it can call it when needed.

👉 [How to configure action server](/content/docs/reference/integrations/action-server/actions/index.html)

### A2A Server — Expose Rasa as a sub-agent

When an external orchestrator invokes your assistant over the [Agent-to-Agent (A2A) protocol](https://a2a-protocol.org/latest/), add an `a2a_server` block to `endpoints.yml`. Rasa registers A2A JSON-RPC routes on the same port as REST and channel webhooks.

This is the **inverse** of [integrating external agents via A2A](/content/docs/pro/build/integrating-external-agents/index.html), where Rasa is the orchestrator. Here, Rasa is the sub-agent that external systems discover and call.

Requires `start_session_after_expiry: false` in `domain.yml` and `SANIC_WORKERS=1` per replica.

👉 [How to expose Rasa as an A2A sub-agent](/content/docs/pro/build/exposing-rasa-as-a2a-sub-agent/index.html)

👉 [A2A Server configuration reference](/content/docs/reference/integrations/a2a-server/index.html)

### Models — Where trained models live

The `models` section lets you configure remote model storage, such as a cloud bucket or server, where Rasa can automatically fetch the latest trained model at runtime. This is useful for CI/CD workflows where models are trained and uploaded externally.

👉 [How to configure model storage](/content/docs/reference/integrations/model-storage/index.html)

### Model Groups — LLM and embedding models

The `model_groups` section is used to define LLMs and embedding models used by features like retrieval, rephraser, and command generator. You specify provider, type, and settings for each group.

👉 [How to configure model groups](/content/docs/reference/config/components/llm-configuration/#model-groups/index.html)

### Lock Stores — Prevent processing conflicts

The `lock_store` manages conversation-level locks to ensure that only one message processor handles a message at a time. This prevents race conditions when multiple messages for the same user arrive close together — a common scenario in voice assistants or high-traffic setups.

Message processors are tied to Rasa processes, and deployment setup affects the lock store you should use:

- Single Rasa process (typically for development): the in-memory lock store is sufficient.
- Multiple Rasa processes in one pod (i.e. multiple Sanic workers): use the `RedisLockStore` or `ConcurrentRedisLockStore`.
- Multiple Rasa processes across multiple pods: we recommend using the `ConcurrentRedisLockStore`, as described [here](/content/docs/reference/integrations/lock-stores/#description/index.html).

👉 [How to configure lock store](/content/docs/reference/integrations/lock-stores/#custom-lock-store/index.html)

### Vector Stores — Enterprise search and flow retrieval

If your assistant uses Enterprise Search Policy, the `vector_store` allows you to define where the vector embeddings of the source documents are stored. It can also be used to connect to a search API that returns a set of relevant documents given a keyword or a search query.

👉 [How to configure Enterprise Search (RAG)](/content/docs/pro/build/configuring-enterprise-search/index.html)

👉 [How to customize flow retrieval](/content/docs/reference/config/components/llm-command-generators/#customizing-flow-retrieval/index.html)

### NLG Server — External response generator

If you want the assistant’s responses to be generated dynamically by an external system (like an LLM-based server), you can configure an `nlg` endpoint. This allows you to update responses without retraining your model. To use this, the endpoint must point to an HTTP server with a `/nlg` path. For example:

```yaml
nlg:
  url: http://localhost:5055/nlg
```

👉 [How to configure NLG server](/content/docs/reference/integrations/nlg/index.html)

### Contextual Response Rephraser — Rephrase responses with LLMs

Rasa’s built-in rephraser can automatically rewrite your templated responses using an LLM. It preserves intent and facts while making responses sound more natural or varied based on conversation context.

To enable it:

```yaml
nlg:
  type: rephrase
```

👉 [Learn more about the rephraser](/content/docs/reference/primitives/contextual-response-rephraser/index.html)

### Silence Handling — Timeout before triggering fallback

The `silence_timeout` setting controls how long the assistant waits for a response before assuming the user is silent. 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

Default is 7 seconds, but you can override the value:

```yaml
interaction_handling:
  global_silence_timeout: 7
```

👉 [Learn more about silence handling](/content/docs/reference/config/overview/#silence-timeout-handling/index.html)

## Domain

The `domain.yml` file defines the universe your assistant operates in — including its responses, memory (slots), and supported actions.
Example:

```yaml
version: "3.1"

session_config:
  session_expiration_time: 60  # value in minutes, 0 means no timeout
  carry_over_slots_to_new_session: true

responses:
  utter_greeting:
    - text: "Hello! How can I help you today?"

slots:
  user_name:
    type: text
    initial_value: null

actions:
  - action_greet_user
```

### What’s in the Domain

- [Responses](/content/docs/reference/primitives/responses/index.html): Templated messages your assistant can send.
- [Slots](/content/docs/reference/primitives/slots/index.html): Data your assistant stores about the user.
- [Actions](/content/docs/reference/primitives/actions/index.html): Logic or service calls your assistant can perform.
- [Session Configuration](/content/docs/reference/config/domain/#session-configuration/index.html): Controls when conversations reset.

👉 [Learn more about Domain file](/content/docs/reference/config/domain/index.html)