## Overview

By default, **the Robot that answers a conversation is the inbox's Robot**. That covers most cases and
needs no configuration: you connect a Robot to an inbox and it handles everything that arrives there.

But one inbox usually receives very different things. A sales WhatsApp number receives pre-sales
questions, support from existing customers and collections from overdue accounts — three conversations
with different tone, knowledge and tools. You can already route each one to a different **team**. Now
you can route each one to a different **Robot**.

When you set a Robot for a specific conversation, it **replaces** the inbox Robot on that conversation
— it is not added to it. Exactly one Robot answers, always.

## Prerequisites

- Maestro configured on the account (Settings → Maestro).
- At least two Robots, each with its own persona, instructions and tools.
- To switch from an automation, macro or FlowBuilder: administrator permission to edit those rules.

## Step by step

### From the conversation panel

1. Open the conversation and go to the **Maestro** side panel.
2. Click the **AI Robot on this conversation** block. The account's Robots are listed.
3. Pick the Robot. The switch applies from the contact's next message.
4. To undo it, click **Use the inbox default Robot again**. That option appears only when there is
   something to undo.

The block shows the current Robot and, when it was set for that conversation, the **Routed to this
conversation** tag — so you can tell "somebody chose this Robot here" apart from "this is simply the
inbox's Robot".

Directly below it, the **Autonomy mode** card lets an administrator choose Autopilot, Copilot or
Hybrid for this conversation only. The choice is independent from the Robot, persists until reset,
and can be removed with **Use Robot default**.

### From an automation

1. Settings → **Automations** → new rule.
2. Choose the trigger and conditions — for example, *when the conversation is created* **and** *the
   contact belongs to company X*, or *when the `collections` label is added*.
3. Under actions, choose **Set the AI Robot for this conversation** and select the Robot.

The conditions are the same ones every automation has: contact, company and conversation attributes,
labels, custom fields. That is where the flexibility lives — the Robot is decided by the condition you
wrote, not by a fixed rule of the system.

### From a macro

Same action, available in the macro action list. Useful when the decision belongs to the agent: they
open the conversation, recognise a collections case, and run the macro that switches the Robot.

### From the FlowBuilder

The action appears in the **platform action** node. Useful for flows that qualify the contact first and
only then decide which Robot takes over.

### From the API

```http
POST /api/v1/accounts/{account_id}/conversations/{conversation_id}/assignments
Content-Type: application/json

{ "assignee_id": 18, "assignee_type": "AgentBot" }
```

`assignee_id` is the Robot's id. Without `assignee_type`, the endpoint still assigns a **human agent** —
its historical behaviour is unchanged.

### From MCP

The `assign-a-conversation` tool accepts the same fields. It lives in the **Conversation Assignments**
toolset, which is enabled by default in Settings → MCP.

## Settings & options

| What | Where | Effect |
|---|---|---|
| Inbox Robot | Settings → Inboxes | The default for every conversation in it |
| Conversation Robot | Panel / automation / macro / flow / API / MCP | Replaces the default, on that conversation only |
| Back to default | Panel → *Use the inbox default Robot again* | Removes the choice and returns the conversation to the inbox |
| Conversation autonomy | Panel → *Autonomy mode* | Overrides the Robot's mode without changing the Robot |

## Use cases

- **Collections**: when the `overdue` label lands, the conversation moves to the collections Robot, with
  its own tone and tools.
- **Enterprise customer**: conversations from company X go to a Robot with strategic-account
  instructions.
- **Post-sale**: once the sale closes, a flow moves the conversation to the onboarding Robot.
- **Soft escalation**: instead of transferring straight to a human, move to a more specialised Robot
  first.

## Tips, limits & best practices

- **The switch applies from the next message onward.** A reply already being composed finishes with the
  previous Robot — switching mid-turn would be worse, producing a reply that is half of each.
- **The conversation loses its human assignee.** A conversation is handled by a person **or** by a
  Robot, never both. Setting a Robot removes the assigned agent.
- **Auto-assignment does not steal it back.** A conversation held by a Robot does not count as
  "unassigned" for round-robin.
- **A disabled Robot stays in the list**, marked *Off*. That is deliberate: a choice made while it was
  on must remain explicable after somebody turns it off. While disabled, the conversation falls back to
  the inbox Robot.
- **The service sequence starts over.** If the previous Robot had a step sequence, the step the
  conversation was on is discarded and the new Robot starts its own sequence from the beginning. The
  alternative is worse: the new Robot would open mid-script on a script that is not its own, or — more
  likely — the stored step would not exist in its sequence and the conversation would end up with no
  sequence at all, with no error anywhere.
- **Pausing does not depend on a Robot being on this inbox.** Pausing is about the **conversation**:
  while it is active the button is available even when the panel says *No Robot on this inbox*. That
  matters in exactly the case where it is needed most — an inbox that keeps delivering to Maestro with
  no Robot bound. There the panel also shows the warning **"Inbox delivering with no Robot bound"**,
  and the real fix is to tick the inbox in the Robot's inbox list (or remove the bot from the inbox).
- **The conversation history is preserved.** The summary of what the contact already said still
  applies: the new Robot does not re-ask what has already been answered.

## Troubleshooting

**The panel says "No Robot on this inbox" but something is answering.**
That is the divergence the **"Inbox delivering with no Robot bound"** warning describes: the inbox
keeps delivering to Maestro, but no Robot is bound to it. Pause the conversation (the button is
available) and then tick the inbox in the Robot's inbox list — or remove the bot from the inbox in
Settings → Inboxes.

**I switched the Robot and nothing changed.**
Check that the conversation is not paused (the panel shows *Paused*) and that no FlowBuilder flow holds
priority over it. In both cases no Robot answers, whichever one is set.

**The Robot I want is not in the automation list.**
The list holds the account's Robots. If you just created one, reload the automations screen.

**The action ran but the conversation still has the old Robot.**
Check that the chosen Robot has a webhook URL configured. A Robot with no URL receives no messages at
all — which is why the action refuses the switch instead of leaving the conversation without any AI.

**It switched on its own.**
Look for the entry on the conversation timeline: every Robot switch is recorded there, with who did it.
If it names an automation, one of your rules matched its conditions.

### Return the conversation to the Robot

An administrator can use **Resume Robot** while a human agent is assigned if the inbox has an active Maestro binding. The action transfers ownership to the Robot and waits for confirmation. A new human assignment during the operation takes precedence.

If confirmation times out or temporarily fails, refresh the panel and resume again: the same operation and context choice are recovered. Messages accumulated during a human pause still require the explicit backlog processing action; resuming alone does not replay them.

### Reopening without a reply

When a bot-owned conversation reopens, the platform looks for the contact message sequence after the latest public reply. Private notes are not replies to the contact. Recovery preserves original messages and includes text and media.

The Robot must remain enabled and allowed to reply, with no human owner or active pause. Messages before the latest human handback still require explicit backlog processing. Resetting context also excludes messages before the reset boundary.

Automatic recovery is limited to 100 messages from the past seven days and ten history pages. An incomplete sequence is not reported as completed. If the Robot still does not reply, check its binding, autonomy, pauses and verification records; take over the conversation when needed.

### Review messages received during a pause

After a confirmed resume, the **Messages received during pause** notice offers **View retained messages**. A separate window shows the current content of retained public messages, their dates and available attachments. Opening, cancelling or closing the window does not send messages or resume the bot.

Review the list before choosing **Confirm processing**: this action may make the bot reply. If loading fails, use **Try again**. An empty or incomplete list does not allow processing; expired, removed or unidentified messages may be unavailable. Close and reopen the list to refresh it.

Confirmation applies to the displayed set. If new messages or newly eligible retained input change the list, the platform requires a fresh review before processing.

## See also

- [Autonomy and human approval](/hc/ajuda/articles/maestro-brain-autonomia-e-aprovacao-humana-en)
- [Actions per reply and closing](/hc/ajuda/articles/maestro-brain-acoes-por-resposta-e-encerramento-en)