Skip to main content
integrations.yml is required at the project root. It declares the LLM that drives the agent, the channels customers reach it through, optional MCP tool servers, and any named model groups. The file is copied into the model archive at rasa train, and each section is read from the place that suits what it configures: The agent’s LLM and reference embedder use the same model-group syntax, but have different lifecycles. The LLM group is resolved from the live project at startup. Reference embeddings are resolved from the packaged snapshot because query vectors must match the vectors built at training time.
integrations.yml
That is a complete, working file. Everything else is optional.

llm

Required. Select the model group that drives the agent. Provider, model, credentials, and provider-specific options belong on the selected group. Inline provider, model, or deployment keys under llm fail validation.

Provider examples

provider: openai, azure, and self-hosted have dedicated clients. Any other value is passed through to LiteLLM, so a provider LiteLLM supports works by naming it and its model. OpenAI
integrations.yml
Anthropic
integrations.yml
Google Gemini
integrations.yml
Azure OpenAI. Name the deployment rather than the model, and give the endpoint and API version:
integrations.yml
Self-hosted, OpenAI-compatible. For vLLM, Ollama, TGI, or anything else serving the OpenAI API shape. provider, model, and api_base are all required:
integrations.yml
model is the name your server advertises, and api_base points at the OpenAI-compatible route, usually ending in /v1. Drop api_key_env if the server takes no key.

Secrets

api_key_env names an environment variable and works on every model in a group. Mantle resolves it into the API key before the config reaches the client. ${VAR} expansion happens in the channels: block, which is read with environment variables expanded. llm: and model_groups: are read without expansion, so api_key_env is the mechanism there. Never commit a literal key.

channels

Declares the channels customers reach the agent through.
Each key is a channel name from the built-in channel registry. Values may be: The enabled flag is stripped before the remaining keys are handed to the channel. A non-boolean enabled, or an entry that is neither a mapping nor empty, raises at load.
rest and inspector are the practical minimum: rest is what the evaluation runner talks to, and inspector is required for rasa inspect and for Studio’s Agent Preview. A project with no channels: block registers no channels at all.
Studio’s model service also accepts a top-level inspector: key in a CALM v1 credentials.yml when serving a legacy assistant, so a project ported from CALM v1 keeps working during migration. In a Mantle project, put inspector under channels: here. CALM v1 credentials.yml is not read for a Mantle assistant. ${VAR} references inside channels: are expanded when the file is read, so channel credentials can come from the environment.

Voice channels

A voice channel takes asr: and tts: sub-mappings, and that is where speech recognition and synthesis are configured. Each takes a name: selecting the engine, plus that engine’s own settings:
integrations.yml
Every key besides name goes to that engine, so the available settings are the engine’s own. language_map keys the model and language off the conversation language, which is how both engines take their settings. name also accepts a Python module path, which loads a custom engine implementing from_config_dict.

Deepgram Flux for speech recognition

Flux is the model family to reach for on a live voice agent. It does turn detection inside the ASR rather than inferring it from silence, so the agent takes its turn on the signal the recogniser already has. Naming a flux- model selects it. The engine reads the model name out of language_map and switches to the Flux API on its own, so there is nothing else to declare:
integrations.yml
The two turn-detection knobs are optional: A Flux config takes these two keys and no others. Anything unrecognised fails the load rather than being ignored, so a typo surfaces at startup. The same asr: / tts: shape applies to every voice channel, including jambonz, audiocodes, twilio_media_streams, and genesys. What differs between them is the telephony connection: server_url, and any credentials that provider needs.

model_groups

Required. Named model configurations used by the agent’s LLM and, when configured, the references embedder.
The required llm.model_group selects the orchestrator group. Point agent.yml at an embeddings group by id:
agent.yml
Every model-group reference must name a group declared here. Naming an undeclared group fails validation. Changes to the orchestrator group require a restart; changes to a reference embeddings group require retraining. A group with one model is the usual orchestrator setup. Without a router block, only models[0] is used — extra models are ignored, there is no fallback, and rasa data validate warns. Set router when the group should select among multiple models.

mcp_servers

Optional. A list of named MCP servers a skill can import tools from with mcp/<server-name>:<tool-name> in import_tools. Each entry needs a unique name and a url. Auth, if any, is one of token, api_key, oauth, or module at the top level of that entry. Secrets must use ${ENV_VAR} form — literal secret strings are rejected.
integrations.yml
Use at most one of token, api_key, oauth, or module per server. Omit all four when the server needs no auth. Auth examples are in Auth examples.

Auth examples

integrations.yml
integrations.yml
integrations.yml
integrations.yml

meta_map

Optional. Builds an MCP _meta object on each tool call without exposing those values to the LLM:
integrations.yml
static is a mapping of fixed string key/value pairs always sent in _meta.

How skills use a server

Allowlist only the tools you need in the skill’s import_tools:
skills/check_balance/skill.md
See Import MCP tools for a short walkthrough and skill.md → import_tools for collision and load-failure rules.

Validation

rasa train and rasa data validate check this file:

Tracing (Langfuse)

Mantle projects configure Langfuse under tracing: in integrations.yml.
public_key and private_key must use ${ENV_VAR} references — literal secrets are rejected at validation and apply time. Those references are kept as literal strings when integrations.yml is parsed (they are not expanded like channel credentials). They are resolved when Langfuse configures at CLI startup; if a variable is unset, resolution is best-effort and may leave the literal ${VAR} in the process environment, so tracing is skipped rather than aborting startup. Use rasa data validate to catch invalid shape or key syntax before deploy. Install the monitoring extra (pip install rasa-pro[monitoring]), set LANGFUSE_PUBLIC_KEY and LANGFUSE_SECRET_KEY, then enable the block. Example agents ship it commented out so local defaults stay key-free.

See also

  • agent.yml: identity, persona, prompt tuning