Overview
A conversation picks its Robô from the inbox: you bind the Robô to that inbox and it answers there. But the account runs an AI model in several other places that are not conversations at all:
- the Brain (the interview that learns your business),
- the agent copilot,
- the rolling summary of long conversations,
- the quality judge,
- the generative dashboards,
- voice calls,
- the knowledge base embeddings.
None of them had any way to know which Robô — and which key — to use. They all fell back to the installation default. The "Where this Robô is used" section, in the Robô's configuration, is where that gets decided: you tick the surfaces it should serve, and each one starts running with its chain, its keys and its persona.
Prerequisites
- At least one Robô created and saved (the section appears only after saving).
Step by step
- Go to Settings → Robôs and open the Robô.
- Scroll to "Where this Robô is used".
- Tick the surfaces it should serve. Each row explains what the surface does and what happens when it is left empty.
- The change saves immediately — you do not need to save the Robô again.
Settings & options
The inbox list is the only door
A Robô answers on an inbox only if that inbox is ticked in the Robô's inbox list. There is no second door: an unticked inbox is real silence — the message arrives, is acknowledged with a technical "ok", and no turn runs.
This changed. An inbox that delivered to Maestro without being ticked used to run an anonymous default configuration — no persona, no instructions, the installation's model. It looked harmless and was not: nothing in the panel said it was happening, and when that anonymous configuration could not answer, the contact received the same technical-issue message for every new message they sent. The behaviour now matches what the screen promises: ticked, it answers; unticked, it does not.
An inbox can end up delivering without being ticked through paths that never touch the Robô form — pairing a hybrid WhatsApp pair, a capability repair, an account import. The platform reconciles that on its own every 15 minutes: an inbox that delivers with no Robô bound has the bot switched off on that inbox (not removed — it stays visible there, off, one click from coming back). While the divergence exists, the conversation panel shows the warning "Inbox delivering with no Robô bound".
The first Brain interview
Every surface in this list is your account's: once a Robô exists, the Brain runs on it — your account, your key.
The exception is the first interview, and it is not a configuration problem: it is the natural order of things, because the interview is what creates your first Robô. In that one moment there is no account Robô to drive the conversation, so it runs on the platform's credentials. The Brain says so in a card at the top of the screen, with a shortcut to create the Robô first if you prefer — but it blocks nothing: demanding a Robô there would trap exactly the people who have none.
The onboarding blueprint (your tailored starting plan) is deliberately absent from this list. It runs while the account is still being created, which makes it a platform stage configured by the installation's operator — not an account setting. Offering it here would be a button that saves cleanly, shows as active, and changes nothing.
Recurring cost
Summary and judge are marked recurring cost. Both run many times (the summary several times per conversation; the judge daily) and both are compression and classification jobs, which a cheap model does well. Pointing an expensive Robô at them works — and costs more than the turns it grades. The choice is yours; the screen only makes sure it is an informed one.
The judge must stay independent
The judge cannot be the same Robô that produces what it grades. An evaluator sharing the writer's persona and instructions does not evaluate the text, it re-derives it. The score keeps looking like a score and stops meaning anything. The platform refuses that combination.
Transcription: how the Robô listens
Just above voice there is a Transcription field. It sets the engine that transcribes incoming audio for this Robô. Leaving it empty uses the installation default.
Choosing a provider only changes the order: the other stays as a fallback if the first fails. A transcription that fails silently costs the contact their message, and no preference is worth that.
Memory: which model produces the embeddings
The Robô you point at Embeddings decides two things, where until recently it decided only one. Its key already paid for every knowledge-base vector; now it also picks which model produces them, in the Memory (embeddings) field of the Robô form. Leave it blank to follow the account's choice, and after it the installation's.
The field lists the curated catalogue, and Browse models beside it opens the live browser: it asks the provider what it offers today, so a model released this week shows up too. The same browser serves transcription, and a row only shows its use button when the field for that modality actually honors the value.
Only that Robô is consulted: there is one knowledge base per account, and it cannot hold two vector spaces at once. The field is stored on other Robôs, but inert.
Changing the model invalidates the vectors already stored. Even between models of the same width the numbers now live in a different vector space, so search degrades until the base is re-indexed. The screen warns you at the moment of choosing; re-index after saving.
A model whose vector width is not this installation's is refused on save, with both numbers in the message. That is not decorative strictness: the column holding the vectors is fixed-width, so a differently-sized model would save cleanly, look active, and then be discarded in silence at use time. Refusing is the only way you get to find out.
Use cases
- An account with its own OpenAI key points the Brain, copilot and dashboards at its main Robô — and starts spending its own quota instead of the installation's.
- A cheap Robô just for the judge and the summary: create a second Robô on an inexpensive model and point only those two surfaces at it, leaving the expensive Robô on conversations.
- A dedicated calls Robô, with a more direct persona, answers the phone when no inbox has a Robô bound to it.
Tips, limits & best practices
- Ticking nothing is a valid choice. The Robô keeps handling conversations and the other surfaces follow the installation default — exactly the behavior you had before.
- Switching off does not erase. A switched-off surface still shows which Robô you had chosen, one click from restoring it. Switched off and never chosen land in the same place but mean different things.
- A surface belongs to one Robô at a time. If another already serves it, the row names it, and ticking here moves it over.
Troubleshooting
"The Robô doesn't answer on that inbox, and no error shows." Open the Robô and check whether the inbox is ticked in its inbox list. An unticked inbox is answered by nobody — not even by a default configuration. The conversation panel tells you which case it is: No Robô on this inbox or Robô switched off.
"The Brain says it is running on the platform." Your account has no Robô yet — and this very conversation is what creates the first one. When it ends, the Brain starts using that Robô's model and key. If you would rather create the Robô first, the card itself has the shortcut.
"The Brain says no model is available." That one is different: neither your account nor the installation has a usable provider key, so there is nothing to answer with. Add the account's key under Integrations, or ask the platform operator to configure one.
"The judge will not save." The chosen Robô already serves the account's conversations or another surface. Pick a different one — the independence is what makes the score worth anything.
"Transcription is still on the same engine." The field needs both provider and model: only one of the two reads as unset, so you never end up transcribing on an engine you did not choose.