## 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

1. Go to **Settings → Robôs** and open the Robô.
2. Scroll to **"Where this Robô is used"**.
3. Tick the surfaces it should serve. Each row explains what the surface does and what happens when
   it is left empty.
4. 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.

## See also

- [Autonomy and human approval](/hc/ajuda/articles/maestro-brain-autonomia-e-aprovacao-humana-en)
- [Knowledge base and ontology](/hc/ajuda/articles/maestro-brain-base-de-conhecimento-e-ontologia-en)