integrations.yml as configuration that parses and validates without a runtime
consumer; those are called out below.
Responses and questions
Variant selection by channel or condition. Multiple variants are already parsed; only the first is used today.ask_<memory_entry> hooks for dynamically generated questions, so a skill
can compute the wording of a collect: prompt at runtime.
Integrations
MCP servers.mcp_servers: already validates in integrations.yml, but
there is no resolver. mcp/<server-id>:<tool-name> in import_tools does not
work. Connecting external tool servers is planned.
Knowledge stores. knowledge_stores: (Qdrant, Milvus, external FAISS)
validates but is never queried. Today search_knowledge reads only the local
index built from references/**/*.md.
Per-skill retrieval scoping, so a skill’s own references/ are searched
ahead of, or instead of, the shared index.
Tracker store (Postgres, etc.) for persistent conversation state, and
event broker (Kafka, etc.) for streaming conversation events.
Tool control flow
ToolResult.next is defined but not executed: returning RunTool(...) or
ActivateSkill(...) is currently a no-op. Executing them is planned.
Remote tool hosting
rasa run tools will spin up a dedicated tool server that the runtime
connects to over MCP, letting you host tools separately.