Maestro AI & Account Brain

What is Maestro AI and the Account Brain

Overview Maestro AI is the artificial intelligence layer of Conversa Labs. It works as a copilot for your team: it suggests replies, drafts messages, runs actions across your modules (CRM, Calendar, Catalog and more) and helps you operate the account faster — always under your confirmation. The Account Brain (Maestro Brain) is your company's knowledge and context base inside the platform. Think of it as a "second brain" or digital twin: it gathers documents, objectives, concepts and relationships from your business into a searchable, traceable model. From that knowledge, Maestro produces answers that cite their source, organizes departments and generates analysis and insights. The relationship between the two is simple: the Brain is the source of truth (what your company is and knows) and Maestro AI is what uses that knowledge to act. The richer the Brain, the better Maestro's suggestions and actions. Prerequisites - A Conversa Labs account with Maestro enabled for your plan/account. - The Account Brain is an optional capability — it may depend on specific enablement for your account. If you can't find it, contact an administrator. - Administrator permission to configure, provision and adjust autonomy. - For voice/dictation features, an up-to-date browser with microphone permission. - Per-account AI keys (optional): under Integrations you connect provider keys (OpenAI, Anthropic, Google, Groq, xAI, DeepSeek, OpenRouter, Cohere, ElevenLabs) used by this account's agents — the Cohere key also keeps the knowledge base indexing as a fallback. - Tavily key (optional): it sits on the same screen but is not a chat provider — no model ever runs on it and it never appears in the robot's model chain. It is the key that unlocks the web search and page reading tools. Step by step 1. Open the Account Brain area from the platform navigation. 2. Run the assisted onboarding (by voice or text) so Maestro understands your business and provisions the basics — see the voice onboarding article. 3. Feed the knowledge corpus with documents, objectives and operational information. 4. Use the generative copilot in conversations to suggest replies and propose actions. 5. Configure departments, autonomy, and review insights and risk analysis. Settings & options - Maestro per channel/inbox: you can control where Maestro acts. - Per-module tools: you enable which actions Maestro may propose/execute (CRM, Calendar, Catalog, etc.). - Autonomy: each department can run at an autonomy level (for example, read-only or with human approval) — nothing destructive happens without confirmation. - Knowledge (corpus): the sources the Brain indexes to answer with source references. - Language: by default the robot speaks the account's language — see the section below. Which language the robot replies in The account's language is the baseline. It is the language set in Settings → Account — the same one that drives the dashboard — and the robot writes in it by default, with nothing for you to configure. Two things change that: 1. The contact writes in another language. If someone clearly writes in Spanish to an account set to Portuguese, the robot answers in Spanish and keeps following the contact for as long as they use that language. This is automatic and needs no setting. 2. You pin a language on the robot. In the robot's form, the Language field defaults to Automatic (account language). Pick a specific language and it applies to that robot, even if the account uses a different one. So the order is: the language picked on the robot → the account's language → the contact can override it by what they write. The same language drives the other surfaces: audio transcription, image and document reading, the conversation summary, copilot suggestions and voice calls. Every language the platform supports is available (not just Portuguese, English and Spanish). Use cases - Speed up support replies with suggestions grounded in company knowledge. - Create CRM deals, schedule appointments and build orders straight from the conversation. - Centralize manuals, policies and objectives so the whole operation answers consistently. - Track risks and opportunities with automatically generated insights. Tips, limits & best practices - Start with onboarding and the corpus: Maestro is only as good as the knowledge it receives. - Keep knowledge up to date — stale information produces outdated suggestions. - Start with conservative autonomy (with approval) and increase as trust grows. - Maestro proposes; the team confirms. Use this to keep quality high. Troubleshooting - I don't see Maestro/the Brain: it may not be enabled for your account or profile — contact an administrator. - Suggestions feel generic: enrich the knowledge corpus and redo onboarding. - Nothing executes: confirm the module tools are enabled and that you have permission. See also - Voice onboarding and assisted setup - Generative copilot: propose, confirm and execute - Departments, risk analysis and insights - Maestro tools per module - DeepSeek as a model provider for your bot - Web search: the bot looking things up on the public internet

Voice onboarding and assisted setup

Overview Voice onboarding is the Maestro Brain assistant that configures your account from a conversation. You describe your business — speaking or typing — and Maestro proposes an initial structure (such as departments and basic settings). You review everything and, once you confirm, the structure is provisioned. The flow always has three moments: briefing (you describe the business), review (you see the proposal) and apply (you confirm and Maestro provisions). Nothing is created without your review. Prerequisites - An account with Maestro enabled and the Account Brain available. - Administrator permission to apply the provisioning. - For voice dictation: an up-to-date browser with microphone permission. If voice isn't available, you can still complete the entire onboarding by text. Step by step 1. Open the Account Brain area and start the assisted setup (onboarding). 2. In the briefing, describe your business: what you do, how you serve customers, which areas/departments exist and what your goals are. You can dictate by voice or type. 3. Let the conversation flow: the assistant asks questions to understand the operation better. 4. Move to the review: Maestro shows the proposal (for example, suggested departments and initial settings). 5. Adjust what you want and click Apply to provision the structure in your account. 6. After applying, keep connecting channels, feeding knowledge and enabling modules. Settings & options - Voice input (dictation): speak instead of typing; handy to describe the business quickly. - Text input: a full alternative if voice isn't available. - Review before apply: the proposal is always presented for your confirmation. - Non-destructive provisioning: Maestro complements what's missing without overwriting what already exists — hand-made agents and settings are preserved. Ready-made templates and niche generation The Studio ships ready-made templates for vertical bots (e-commerce, clinic, real estate, restaurant, education, legal, finance, beauty, automotive, logistics, travel, fitness, professional services and healthcare) already in the account's language. If your segment isn't on the list, describe the niche and Maestro generates a tailored preset in your language — persona, instructions and tools — that you apply and adjust like any other template. Use cases - Quickly set up a new account with a basic department structure. - Standardize the opening of new operations with a few guided questions. - Reuse the assistant to review and complete the structure of an account already in use. Tips, limits & best practices - The clearer your business description, the better the suggestions. - Speak in short, objective sentences when dictating; review the transcribed text before continuing. - Always review before applying — you can adjust everything later. - Onboarding is a starting point: dive deeper into each module in the categories of this Help Center. Troubleshooting - The assistant won't open: confirm Maestro is enabled and that you have administrator permission. - Voice/dictation doesn't work: check the microphone permission in your browser; use text input as an alternative. - Apply provisioned nothing: review the proposal, check error messages in the assistant and try again. If the account already has agents/structure, Maestro only complements what's missing. See also - What is Maestro AI and the Account Brain - Generative copilot: propose, confirm and execute - Departments, risk analysis and insights

Generative copilot: propose, confirm and execute

Overview The generative copilot is Maestro working alongside you in the conversation. Instead of only suggesting free text, it presents action cards: a message draft ready to send, or an action in a module (create a CRM deal, schedule an appointment, build a Catalog order). The principle is always the same: propose → confirm → execute. Maestro proposes the action, you review and confirm, and only then is it executed. This keeps you in control: nothing happens without your approval. Prerequisites - An account with Maestro enabled. - The per-module tools you want to use (CRM, Calendar, Catalog) must be enabled — see the per-module tools article. - Permission to act on the corresponding module (for example, create deals or schedule). Step by step 1. Open a conversation and trigger the Maestro copilot (the "ask Maestro" area). 2. Ask for what you need in natural language — for example, "reply confirming the time" or "create a deal for this contact". 3. Maestro proposes one or more cards: - Message draft: you can copy it or send it to the reply editor. - Module action: a CRM, Calendar or Catalog card with the suggested data. 4. Review the card content and adjust whatever is needed. 5. Confirm to execute the action (send the message or create the record). 6. Track the result in the card itself (in progress, done or error). Settings & options - Message drafts: always available; they help you write replies quickly. - CRM/Calendar/Catalog actions: appear according to the tools enabled for the account. - Automatic link to the conversation: actions created by the copilot are already associated with the current conversation (the deal/appointment is born linked to the right contact). - Reply editor: drafts can go straight into the reply field, respecting the channel type (plain or rich text). Use cases - Reply faster with a draft consistent with the conversation history. - Turn a conversation into a CRM deal without leaving the screen. - Schedule an appointment from the customer's request. - Build an order with Catalog items during the conversation. Tips, limits & best practices - Be specific in your request: the clearer the goal, the better the proposal. - Always review before confirming — the copilot suggests, but the decision is yours. - Only actions whose tools are enabled appear; if one is missing, enable it in Maestro's settings. - Use drafts as a base and personalize the tone for your customer. Troubleshooting - No action cards appear: confirm the module tools are enabled. - The action doesn't execute: check your permission on the module and whether there's an error message in the card. - The draft doesn't go to the reply: make sure the conversation/channel is selected and try again. See also - What is Maestro AI and the Account Brain - Maestro tools per module - Departments, risk analysis and insights

Departments, risk analysis and insights

Overview The Account Brain organizes Maestro's work into departments — operational areas such as support, sales, risk, finance and knowledge. Each department runs periodic routines over the account's conversations and data and produces two main outputs: risk analysis (signals of problems or attention) and insights (opportunities and recommendations). Each department has an autonomy level. At conservative levels, it only observes and suggests (read-only). At levels with human approval, it proposes actions that wait for your confirmation before any execution. Nothing destructive or final happens automatically without that approval. Prerequisites - An account with Maestro and the Account Brain enabled. - Administrator permission to create/adjust departments and autonomy. - Recommended: complete the onboarding (which already provisions the basic departments) and feed the knowledge corpus for richer analysis. Step by step 1. Open the Account Brain and go to the Departments area. 2. Review the provisioned departments (or create/enable the ones that make sense). 3. Set the autonomy level of each one (for example, read-only or with approval). 4. Let the routines run: Maestro processes conversations periodically. 5. Follow the risk analysis and the insights feed generated by the departments. 6. When there are proposals that require approval, review and confirm (or decline) each one. Settings & options - Departments: areas such as support, sales, risk, finance and knowledge. - Autonomy per department: from the most conservative (observes and suggests) to the most autonomous (executes what was approved). Start conservative and evolve. - Human approval (HITL): proposals wait for your decision before being executed. - Insights and risk: panels that consolidate what Maestro found, with source references when applicable. Use cases - Identify at-risk conversations (dissatisfaction, delays, churn) before they become problems. - Discover sales opportunities and next-action recommendations. - Distribute intelligence across areas, with the right level of automation for each one. - Standardize the operation with routines that run on their own and report what matters. Tips, limits & best practices - Start with conservative autonomy (read-only or with approval) and increase as trust grows. - The richer the knowledge corpus, the more accurate the risks and insights. - Departments may appear empty at first — they populate after the routines run. - Periodically review pending proposals so the queue doesn't pile up. Troubleshooting - Empty departments: confirm they are enabled and wait for the routines; check whether onboarding/ provisioning was applied. - No insights/risk: enrich the knowledge and confirm there are enough conversations to analyze. - Proposals don't execute: at approval levels, they depend on your confirmation — review the pending items. - Every conversation with the same risk score: the score is a weighted sum over six signals, and a signal the account cannot produce enters as zero — indistinguishable, from the account's point of view, from "measured, and it is fine". With no SLA policy and no sentiment enrichment, four of the six drop out, the two that remain saturate within hours, and every conversation older than that lands on the same score. The panel says so when it happens — how many signals carry data and how many subjects tied — and breaks the list's ties by waiting time. To get real ordering back: apply an SLA policy, use conversation priority, or fit the saturation windows to your operation's real pace. See also - What is Maestro AI and the Account Brain - Voice onboarding and assisted setup - Maestro tools per module

Maestro tools per module and how to enable them

Overview Tools are the actions Maestro can propose and execute in each module of the platform. For example: write a message draft, create a CRM deal, schedule an appointment in the Calendar, or build a Catalog order. You control which tools are enabled — so Maestro only offers the actions that make sense for your operation. Enabling a tool has two effects: it starts to appear as an action card in the generative copilot and becomes available to departments with their configured autonomy. Disabled tools simply aren't proposed. Prerequisites - An account with Maestro enabled. - Administrator permission to change the tools and autonomy configuration. - The corresponding module must be active in the account (for example, for CRM tools, CRM must be enabled). Step by step 1. Open the Maestro / Account Brain configuration area. 2. Find the list of tools per module (CRM, Calendar, Catalog, messages and others). 3. Enable the tools your team should use and disable the ones that don't apply. 4. If you want, define where Maestro acts (per channel/inbox). 5. Save the changes and test in the copilot: ask for an action and check that the corresponding card appears. Settings & options - Message tools: drafts and reply suggestions (usually always useful). - CRM tools: create/update deals and records related to the contact. - Company tools: see who works at each company, 360° overview, link the contact to a company and record relationships between people and companies. - Calendar tools: propose and create appointments from the conversation. - Catalog tools: build orders and suggest items during the conversation. - Order (Commerce) tools: read the contact's purchase history and record manual sales in the orders registry. - Campaign tools: follow status and delivery metrics, list recipients and operate the campaign (pause, resume, cancel, retry failures). - Flow tools: start a published flow on the conversation, inspect sessions and unstick/cancel runs. - Sales tools: seller portfolio, leaderboard, goals, unified revenue, commission simulator and order attribution/portfolio transfer (with human approval). - Engagement tools: the lead score (cold/warm/hot) and the event timeline. - Ads tools: the conversation's ad context (CTWA), leads, spend KPIs and CAPI conversions (actions that spend budget require human approval). - Web search tools: search the public internet (web_search) and read a page's text by URL (web_fetch). They sit under the Knowledge base category in the grid — they are knowledge from outside the account, unlike the knowledge base tools, which read your own material. They are read-only, send the contact nothing and depend on a Tavily key; without the key Maestro just carries on with what it already knows. - Scope per channel/inbox: control which inboxes Maestro may act in. - Autonomy (per department): defines whether tools only suggest or execute after approval — see the departments article. Use cases - Release only message drafts for a team still getting to know Maestro. - Enable CRM and Calendar tools for a sales team that creates deals and schedules meetings. - Restrict Maestro to specific channels while you validate the results. Tips, limits & best practices - Enable the essentials first: start with a few tools and expand as adoption grows. - Avoid enabling an excessive number of tools at once — there is a technical limit on tools per agent. If you hit the limit, disable the ones you don't use to free up space. - Pair tools with the right autonomy: powerful tools should start with human approval. - Review the list periodically to reflect the modules actually in use. Troubleshooting - An action doesn't appear in the copilot: confirm the tool is enabled and the module is active. - I can't save the configuration / limit error: you may have exceeded the maximum number of tools — disable some and try again. - Maestro doesn't act on a channel: check the scope per channel/inbox. - The action appears but doesn't execute: check your permission on the module and the autonomy level. See also - What is Maestro AI and the Account Brain - Generative copilot: propose, confirm and execute - Departments, risk analysis and insights - Web search: the bot looking things up on the public internet

Bot autonomy modes and human approval (HITL)

Overview Autonomy defines how much the Bot (Maestro acting inside the conversation) does on its own versus when it asks a person to confirm. You pick the level of trust, and it governs how the Bot behaves in support. There are three modes: - Autopilot — the Bot executes on its own, without waiting for approval. - Copilot — the Bot proposes cards (a message draft or a module action); you review and send. Nothing goes out on its own. - Hybrid (Require approval / HITL) — the Bot acts on its own in day-to-day work, except for sensitive actions, which are held, waiting for your approval. The safety principle is simple: in Hybrid, nothing sensitive or final happens without approval; in Copilot, nothing is sent without you. You decide how much to trust. This concept has analogs elsewhere in the platform: the Brain's departments have their own autonomy level (including an "Ask first" tier), and Follow-ups have AI-draft approval. Both are linked under "See also". Prerequisites - Maestro enabled and a Bot/agent configured on the inbox. - Administrator permission to set the autonomy mode. - An owner (the conversation's assignee or a team) to receive the approval notifications. - The per-module tools you want proposed/parked must be enabled — see the tools article. Step by step 1. In the Bot configuration, choose the autonomy mode: Autopilot, Copilot or Hybrid (Require approval). 2. To change only one conversation, open the Maestro side panel, click the Autonomy mode card and choose another mode. The card says Set for this conversation; use Use Bot default to remove the exception. Only administrators can make this change. 3. In Copilot: the Bot proposes cards (a draft or a module action); you review and send/confirm — nothing goes out on its own (details in the generative copilot article). 4. In Hybrid: for day-to-day actions the Bot acts; when a sensitive action comes up, it is parked — the Bot posts a private note that @mentions the owner (firing the native notification) and creates an approval card with an action id. 5. The owner taps/clicks the Maestro indicator in the conversation header to open the panel; the adjacent shortcuts Pause, Resume, or Take over the service. Pending approvals stay visible in the numbered shield. In the panel, choose Approve or Reject. On Approve, the exact action that was held is re-executed; the note records who approved it. 6. In Autopilot: the Bot executes on its own (sensitive actions are still recorded in the audit trail). 7. Track the result on the card and in the conversation's activity line. Settings & options The three autonomy modes | Mode | Behavior | |------|----------| | Autopilot | Runs on its own; no approval wait. | | Copilot | Proposes; the person reviews and sends. Nothing is sent without you. | | Hybrid (Require approval / HITL) | Runs on its own, except sensitive actions, which are parked for approval. | What counts as a sensitive action in Hybrid (gets parked) - Assign to a team, run a macro, mark the conversation as resolved. - Writes to CRM, Tasks, Calendar (create/edit/reschedule/cancel an appointment) and Payments. - Commerce recovery (a recovery card sent to the customer), cancel a follow-up cadence, enroll into a distribution group and trigger a collaboration round. - Database writes, generate video, contracts (create/send/remind) and delegating to a sub-agent when that delegation is marked as sensitive. What the Bot does freely (even in Hybrid) - Reply to the contact, add labels, internal notes, reactions, generate an image, knowledge-base searches and other read-only lookups. Human-only action - Approving an AI Follow-up draft is always human — the Bot never approves its own draft. This holds in any mode (see the Follow-ups article). The approval card and note - The private note @mentions the owner (or the team) and references the action id, to trigger the platform's native notification. - The approval card sits in the conversation's Maestro panel, with Approve and Reject. - The decision is recorded with who approved — and on approval, the exact parked action is re-executed. Handoff to a human: status, priority and summary When handing a conversation off to a human team, the Bot sets the conversation's status (open, pending, snoozed or resolved) and priority (none, low, medium, high or urgent). Each one can be a fixed value or "Maestro decides": in that mode the Bot itself picks the most suitable value per conversation, at the moment of handoff — a fixed value always prevails over the Bot's choice. The handoff note sent to the agent includes the reason and a conversation summary (generated on the spot when there is no accumulated summary yet), so the person can take over with context. Taken over by a human (the bot stands down, then comes back) When a person replies in the conversation (from the dashboard or the mobile app) or pauses the bot, it stands down on that conversation — it stops replying so it does not talk over the human. This applies to that conversation only; the bot keeps working everywhere else. Two options control the comeback: | Option | What it does | Default | |---|---|---| | Resume automatically after a while | The bot takes the conversation back once the window below passes with no new human reply. | On | | Resume after | The idle window before it returns: 1 hour, 4 hours, 12 hours, 24 hours, 48 hours, 1 week, or Custom (you type the hours). | 24 hours | - With auto-resume off, the bot stays paused on that conversation until a person hands it back — there is no time-based return. - The clock runs from the last human message: if the person replies again, the window restarts. - The minimum accepted window is 1 minute; anything shorter is raised to that floor. - The setting is per bot (it applies to every inbox the bot answers on). Where the mode applies, and the per-department analog - The mode configured on the Bot is the default for every inbox it serves. A conversation may keep a persistent exception; precedence is conversation → Bot. The change starts on the next turn, does not interrupt an in-progress reply, and neither executes nor discards existing approvals. - The Brain's departments have their own autonomy level (including "Ask first") — a separate setting, detailed in the departments article. Use cases - A team new to AI: start on Copilot and review everything before sending. - A trusted operation with guardrails: Hybrid — routine replies on their own, money/data moves waiting for approval. - High volume, low risk: Autopilot for simple touches, or Hybrid for most cases. - Sensitive sub-agent delegation kept under approval in Hybrid. Tips, limits & best practices - Grow trust gradually: Copilot → Hybrid → Autopilot. - Make sure there is an owner (assignee or team) so approval requests don't slip by. - Review pending items often so the flow doesn't pile up. - Approving re-executes the exact parked action — check the data before approving; if something changed, reject and ask again. - Only enabled tools are proposed; keep the more powerful ones starting with approval. Troubleshooting - "The action didn't run": in Hybrid, a sensitive action is held — approve it in the Maestro panel. - "Nobody saw the approval request": check the owner (assignee/team) and the account's notifications. - "The Bot acted on its own on something I wanted to review": it's not on the sensitive list, or the mode is Autopilot — switch to Hybrid. - "I can't approve an AI Follow-up draft through the Bot": draft approval is human by design — see the Follow-ups article. See also - What Maestro AI and the Account Brain are - Generative copilot: propose, confirm and execute - Departments, risk analysis and insights - Maestro tools by module - AI with human approval (human-in-the-loop) in Follow-ups

The Bot fills in and corrects Contact and Company data during the conversation

Overview During a conversation people routinely correct and complete their own details: "actually my email is a different one", "take down my tax ID for the invoice", "I moved to another city". Until now, the Bot could read the whole profile and correct nothing — somebody had to reread the conversation afterwards and retype it into the record. The Bot now writes that data while it talks. There are six capabilities: three for the Contact and three for the Company. | What the Bot fills in | Where | |---|---| | Name, email, phone, external identifier and country | Contact | | Tax ID (CPF/CNPJ) and legal type | Contact | | Main address or billing address | Contact | | Legal name, website, domain, industry, size, lifecycle stage, email, phone, timezone and description | Company | | Tax ID (CNPJ) and legal name | Company | | Company address | Company | Three guarantees hold it together: the Bot only records what the person just told it, the contact is always the one in this conversation (it cannot write onto somebody else's record), and every successful write leaves an audit note in the conversation. Prerequisites - Maestro enabled and a Bot configured on the inbox. - An autonomy level set on the Bot — it decides whether the write runs straight away or waits for approval (see "Settings & options"). - The three Contact capabilities are built in: every Bot already has them, which is why they do not appear in the tool list to be ticked. - The three Company ones are regular tools and must be ticked in the Bot's configuration: crm_org_update, crm_org_set_fiscal and crm_org_set_address. - Also tick crm_list_organizations: that is how the Bot finds out which company to update. Without that lookup it cannot identify the record and writes nothing. - The Companies module must be available on the account. Step by step 1. Open the Bot configuration and confirm the autonomy mode. 2. In the tool list, tick the Company ones (crm_org_update, crm_org_set_fiscal, crm_org_set_address) and the crm_list_organizations lookup. The Contact ones are already on. 3. Save and work normally. When the person gives a detail — "note down my tax ID:…" — the Bot records it on the record. 4. In Hybrid (Require approval) mode the write is held and becomes an approval card in the Maestro panel, with a private note mentioning the assignee. Open it and choose Approve or Reject. In Autopilot it runs straight away. 5. Check the result on the contact profile (or the company record) and the audit note logged in the conversation. Settings & options Contact fields | Field | Expected format | |---|---| | Name | Text | | Email | Email address | | Phone | E.164, with country code (e.g. +5521999999999) | | Identifier | This person's external id in your system | | Country | ISO-3166 alpha-2 (e.g. BR) | | Tax ID | The digits as the person gave them; the type (cpf/cnpj) can be inferred | | Legal type | Individual or company | | Address | Street, number, complement, district, city, state, postal code and country | | Billing address | The same fields, stored separately from the main address | The Bot chooses between the main address and the billing address from the context of the conversation. If the person explicitly says it is the invoicing address, have that said in the conversation — that is what drives the choice. Company fields | Field | Note | |---|---| | Trading name | Commercial name | | Legal name | Registered name | | Domain / Website | acme.com / full URL | | Industry | Sector | | Size | Headcount band (e.g. 11-50) | | Lifecycle stage | E.g. lead, customer | | Email and phone | Phone in E.164 | | Timezone | IANA standard (e.g. America/Sao_Paulo) | | Description | A short description of the company | | Tax ID and legal name | Tax identity, to invoice it or put it on a contract | | Address | Street, number, complement, district, city, state, postal code and country | Autonomy: there is no new switch All six capabilities count as sensitive actions — exactly the same treatment as CRM, Calendar and Payments writes. That means: | Bot mode | What happens to the write | |---|---| | Autopilot | Runs straight away. | | Hybrid (Require approval) | It is held waiting for human approval, in the usual panel. | | Copilot | Nothing goes out without your review. | There is no separate toggle just for contact data: what governs it is the Bot's autonomy level. Use cases - Issuing an invoice: the customer gives the tax ID and address mid-conversation, and the record comes out ready for billing. - Closing a contract: the company's legal name and tax ID recorded on the spot, with nobody retyping them from the history later. - Billing: email and phone corrected the moment the person says they changed — the payment link starts arriving in the right place. - Delivery: a billing address kept separate from the main address. - B2B qualification: the company's industry, size and lifecycle stage filled in from what the contact says, feeding segments and reports. Tips, limits & best practices - A stored document comes back masked — and the Bot refuses to rewrite it. A stored tax ID is returned on read as ***. If the Bot tried to "confirm" that masked value, it would overwrite the real document with a mask. So it refuses and asks the person for the document instead. The Bot only stores a document it has just heard in the conversation. - A partial address is merged, never replaced. If the person gives only the city, the postal code and street already stored stay there. The same holds for every field: anything not said keeps its stored value. An incomplete answer never wipes a record. - The contact is always the one in this conversation. The Bot cannot be pointed at somebody else's record — that is exactly how one customer's document would land on another's profile. - The company, however, is found by lookup. If the account has two similarly named companies, ask the contact for the full name or the tax ID before requesting an update — the write lands on the record the Bot found. - The audit note only appears when the action succeeded. If the write failed, there is no note claiming it was done. - Start on Hybrid. Identity data is sensitive: review a few approvals before moving to Autopilot. Troubleshooting - "The Bot said it noted it down, but the field did not change": the mode is Hybrid and the action is held. Open the Maestro panel in the conversation and approve it. - "The document was not saved": the value sent was masked (read from the record, not given by the person). Ask for the document in the conversation and record it again. - "The Bot does not update the company": the Company tools are not ticked in the Bot configuration, or the crm_list_organizations lookup is missing so it cannot find the record. - "The address came out incomplete": the Bot records only what was said. Ask for the missing parts — they are added to what already exists, wiping nothing. - "It updated the wrong company": there was more than one record with a similar name. Fix it on the company record and, next time, confirm the full name or the tax ID first. - "I want it to stop touching the record": use Copilot (nothing goes out without you) or untick the Company tools. The Contact ones follow the Bot's autonomy level. See also - Bot autonomy modes and human approval (HITL) - Maestro tools per module and how to enable them - Checking what the Bot claims before it is sent - Contact fiscal data and address (tax ID, billing) - Companies and contact linking

Checking what the Bot claims before it is sent

Overview A classic problem with AI support is the Bot saying it did something it did not do: "I've booked you for tomorrow at 2pm", when the calendar refused that slot — or when the calendar was never even called. The customer walks away trusting something that does not exist, and the team only finds out later, when the customer shows up at the door. The platform now runs a final check before the reply is delivered. It works like this: 1. The Bot writes the reply. 2. Before sending, the platform compares what the reply claims with what that turn actually executed (which actions ran, and whether they succeeded). 3. If the reply claims a result that does not hold up, that claim is removed and replaced with a neutral line saying the Bot will confirm and get back. 4. The rest of the message is preserved — the conversation continues normally. Two other things changed alongside it: - Failures of internal actions become a private note in the conversation, so the team can see what broke. - The Bot's content filters now apply to every output — text, audio and buttons — not just the written message. Read the limits section before you tell the team about this. It does not make the Bot infallible. It can still be wrong; what the platform does is take down the claim that does not hold up. Prerequisites - Maestro enabled and a Bot configured on the inbox handling the conversation. - The per-module tools the Bot uses (calendar, tasks, payments, catalog, contact records…) must be enabled — their result is the reference the check compares against. - Administrator permission to review the Bot configuration and the content filters. - Someone responsible for the conversation (assigned agent or team) to receive and act on the private note. - There is no switch to flip: the check is automatic and runs on every Bot reply. Step by step The check happens on its own. The steps below are for you to observe and validate that it is working in your operation. 1. Open a conversation handled by the Bot that involves a concrete action (booking, charging, creating a task, registering an order). 2. Read the message delivered to the customer. If the Bot tried to claim a result that did not happen, in its place you will see a line saying it will confirm and get back — instead of "done". 3. Open the conversation's private notes. Failures of internal actions are recorded there, with an indication of what did not work. 4. Fix the cause. It is usually one of these: a disabled tool, a credential/integration that is down, a required piece of data missing (time, amount, document), or a module rule blocking the operation. 5. Redo the action manually if the customer is waiting, and reply confirming it. 6. If the same point keeps failing, adjust the Bot's instructions or enable/fix the corresponding tool. Settings & options | What | Where it lives | Note | |---|---|---| | Reply check | Automatic | Always on, for every Bot reply. Nothing to configure | | Replacement line | Automatic | Neutral "I'll confirm and get back to you" text, in place of the removed claim | | Failure private note | Conversation private notes | Never delivered to the customer | | Bot content filters | Bot configuration | Now applied to text, audio and buttons | | Autonomy mode | Bot configuration | Complementary: defines what needs human approval before it happens | About the private note: it is internal by nature. Customers never see private notes on any channel — not on WhatsApp, not by email, not in the website chat. It shows up only for your team, inside the conversation. About the content filters: if you configured the Bot to avoid certain terms, promises or formats, that rule is now applied to the audio reply and to button/list options as well. Before, a button option could slip past a filter that only covered text. Use cases - Calendar: the Bot tries to book, the slot is already taken, and the reply would claim "booked". The claim goes away, the follow-up line takes its place, and the team gets the private note to reschedule. - Payment: the charge was not created because of a missing tax detail. The customer does not get a "link sent" that never arrived; they get a note saying confirmation is coming. - Task / human handover: the Bot would say "I've escalated you to a specialist", but the handover failed. Without the check, nobody would know — with it, there is a trail in the conversation. - Catalog / order: the item could not be added. Better an "I'll confirm" than a ghost order. - Auditing: when reviewing conversations, failure private notes show where automation breaks most often. Tips, limits & best practices This is the most important part of the article. Set expectations with your team using exactly these terms — promising more than the platform delivers destroys trust at the first exception. The check recognizes the most common shapes of a claim, not all of them. It spots the usual ways of saying "I did it" — "booked", "created", "registered", "sent", "cancelled" and close variations. A sentence written in an unusual, indirect, very long or roundabout way may slip through. It does not stop the Bot from being wrong. The check does not fix reasoning, does not validate real-world information and does not guarantee the answer is correct. It does one thing: it removes the claim of a result that does not hold up against what that turn executed. Do not describe it as "the Bot can no longer make things up". That is not true. The Bot can still state something incorrect and have the sentence go through. Describe it as: "the platform removes the most common claims of a completed action when the action did not happen". Other limits, equally honest: - The check looks at the current turn. A claim made in an earlier reply is not reviewed retroactively. - The reference is what the turn's tools did — not the overall state of the system. If the action happened through another path (an agent did it by hand at the same moment, or a slow process only finished afterwards), the Bot may still be corrected "unnecessarily". - The removal is surgical: the claim goes out, the neutral line comes in. The resulting text can read slightly dry — which is better than a false promise. - The private note does not replace monitoring. It is a trail inside the conversation, not an alert dashboard. - Content filter and reply check are different things: the filter deals with what must not be said; the check deals with what must not be claimed as done. Best practices: - Treat private notes as a work queue: a recorded failure means a customer is waiting. - Actually enable the tools the Bot needs to use. A disabled tool produces exactly the scenario the check corrects — and frustrates the customer all the same. - For sensitive actions (money, cancellation, contact data), combine it with human approval. The check is the last net; approval prevents the problem earlier. - Review failure private notes weekly to find the point that breaks the most. Troubleshooting - "The customer got 'I'll confirm and get back', but the action worked": the action probably completed outside the turn (more slowly, or through another path). Confirm it in the corresponding module and reply to the customer; nothing needs to be undone. - "The Bot claimed something that did not happen and the sentence went through": this is a known limit — the wording fell outside the recognized shapes. Save the excerpt, adjust the Bot's instructions to be more direct at that point and, if possible, turn that step into an action with approval. - "The customer saw an internal remark": a private note is never delivered on any channel. If the customer received the text, it was sent as a normal message, not as a note — review who replied and how. - "The audio said something different from the text": filters now cover audio too. If you find a difference, record the example and review the Bot's instructions and filters. - "A button option I had banned showed up": filters now apply to buttons/lists. Confirm the term is actually in the Bot's filter configuration, and not only in the written instruction. - "I cannot find the private note": confirm you are looking at the right conversation and that your profile can see internal notes on that inbox. See also - Turn verification and holding the reply - Automation triggers about the AI (Maestro) - What Maestro AI and the Account Brain are - Bot autonomy modes and human approval (HITL) - Maestro tools by module - Generative copilot: propose, confirm and execute - Replying, private notes and mentioning teammates

Turn verification and holding the reply

Overview Between the moment the Bot finishes writing and the moment the contact receives the message, there is now a checkpoint. It runs on every delivery path — text, voice, and also the tools that talk to the contact directly — and does two things: 1. It checks the surface of the reply. Leaked internal markup, phrases and personal data blocked in the configuration, the wrong language, unresolved template fields ({contact.name}, [NAME]), a link/phone/price that appears nowhere in what the account has on record nor in what that turn looked up, a near-identical repeat of the previous message, and size caps. 2. It reconciles what the reply claims with what the turn executed. If the message says "I've booked you" and the calendar tool never ran — or ran and failed — the claim does not hold up. When something is caught, the platform has a ladder of reactions, from lightest to heaviest: | Reaction | What happens | |---|---| | Remove the fabricated token | Only the link/phone/price that does not hold up is removed; the rest of the sentence stays. | | Delete the sentence | The unsupported claim is deleted and a neutral line saying it will confirm and get back replaces it. It is deletion, not rewriting. | | Redo once | The Bot redoes the turn with the correction pointed out. Limited to one redo per turn. | | Hold | The reply does not go out. It waits for a person to approve. This is the option you switch on under "Hold the reply" (below). | | Block | Nothing goes out (for example, a human took over the conversation mid-turn, or the message would be an exact duplicate). | Read the limits section before presenting this to your team. This layer does not make the Bot incapable of being wrong. It removes the most common forms of "I already did it" when the doing never happened — and there are ways of writing that get past it. Prerequisites - Maestro enabled and a Bot configured on the inbox. - The per-module tools the Bot uses must be enabled — their execution is the evidence reconciliation compares against. No execution, nothing to compare with. - Account records up to date (products, prices, domains, teams). That is what makes a fabricated link or price recognizable; whatever is not on record tends to be treated as fabricated. - Administrator permission to change the Bot's hold policy. - To hold: somebody on duty to approve. With nobody watching the queue, holding is the same as not replying. Step by step The check is automatic and has no on/off switch. What you configure is the hold. 1. Open the Bot configuration (the Maestro agent) used by the inbox. 2. Find "Hold the reply for human approval". 3. Pick one of the three options (detailed in the next section). The default is Always deliver. 4. As soon as you move away from "Always deliver", the screen shows a highlighted warning: while the reply is held, the contact waits. Read it before saving — that is the real cost of the option. 5. Save. 6. To follow up: a held reply creates a private note on the conversation and enters the approval queue in the Maestro panel, alongside the other approvals. 7. When reviewing you can approve (the reply goes out exactly as it was), edit and send (your version goes out) or reject (nothing is sent; the conversation can optionally be handed off to a human). Settings & options The three hold options | Option | What happens | Honest cost | |---|---|---| | Always deliver (default) | The reply goes straight to the contact. The check still runs and still corrects the text — it just holds nothing. | None. Nobody waits. | | Hold when the reply claims something the turn did not do | Only replies with an unsupported claim are held. Everything else is delivered right away. | The contact waits exactly in the cases that matter — which are also the cases where the reply would have been wrong. | | Hold every reply for human approval | Every reply waits for a person, including "hi, how can I help?". | The contact waits on every message. In practice this is human support with an AI draft. | What "hold" means, without euphemism: while held, the message does not exist on any channel. The contact sees no typing indicator, gets no notice, receives nothing — they see silence until somebody approves. If the hold happens at 7pm and the queue is only checked at 9am, the contact waited all night. That is why the default is Always deliver, and why the warning appears the moment you change the option. Turn holding on when: - somebody is on duty watching the approval queue during the hours the Bot answers; and - the cost of a wrong claim is higher than the cost of the delay (money, health, legal, calendar commitments). If you have nobody on duty, the most balanced combination is usually Always deliver plus the automation trigger Reply claimed an action that never ran alerting a supervisor. The contact does not wait, and someone chases the damage within minutes. What the check hands back to the conversation - The delivered message already comes corrected (sentence deleted, fabricated token removed). - Internal failures become private notes — they never reach the contact. - The automation triggers about the AI let you react automatically (label, assign, alert). See the article under "See also". Use cases - Clinic / provider with a full calendar: "Hold when the reply claims something the turn did not do", with the front desk watching the queue during business hours. The patient never receives an appointment that does not exist; on every other message the reply is immediate. - Billing and payment links: same option. A payment link claimed but never generated is the kind of mistake that produces support tickets, not sales. - 24h operation with no night shift: Always deliver. Holding overnight protects nobody — it turns a rare mistake into guaranteed silence. - New Bot, first week in production: some teams switch Hold every reply on for a few days, with one dedicated person, purely to calibrate tone and instructions. It is expensive and does not scale; use it as a trial period, not as a permanent setting. - Account with lots of branded content (links, prices): keep the records up to date before enabling holds, otherwise you will be manually approving correct replies whose legitimate link simply was not on record. Tips, limits & best practices This is the most important section of the article. Use these words with your team — promising more than the platform delivers costs more than the gap the promise would hide. Do not describe this as "the AI can no longer hallucinate". That is false. The Bot can still assert something wrong, and can still do it in a way that gets past the check. Reconciliation is lexical. It recognizes ways of writing, not meaning. The patterns cover the direct, first-person way of saying something was done ("I've booked", "it's scheduled", "I created", "I sent the link") in Portuguese, English and Spanish. Paraphrase escapes. An indirect sentence, a roundabout one, a very long one, passive voice, or an unusual phrasing gets through reconciliation — including when it asserts exactly the same thing. This is a design choice, not a bug to be fixed later: the false-positive limit is hard. Sentences in the future tense and questions ("can I book you for tomorrow?", "I'll check and confirm") never trigger a claim, because deleting those would break legitimate conversations all the time. The price of that safety is precisely the lower recall. Other limits, equally honest: - Seven families of claim are recognized: booking, record created, document sent, payment link, handoff to a human, price quoted and promised follow-up. Outside those seven, there is no reconciliation at all. - The reference is the current turn, not the state of the system. If the action happened by another route (an agent did it by hand at the same moment, or a slow process finished afterwards), the reply may be corrected "unnecessarily". - Deleting the sentence is not rewriting. What remains can read dry. Better than a false promise, but do not expect elegance. - Fabricated links and prices depend on what the account has on record. A legitimate domain that is not on record may be removed by mistake until you add it — that is an expected false positive, and the fix is to add it. - The check does not validate real-world facts. It does not check whether the information is correct, whether the reasoning makes sense, or whether the policy the Bot quoted exists. It verifies one thing only: whether the reply asserts a result that the turn does not support. - Holding does not fix what got through. If the claim was written in a way reconciliation does not recognize, the "Hold when the reply claims something the turn did not do" option holds nothing — the reply goes out normally. Anyone who wants a total barrier needs "Hold every reply", with the cost that carries. - Redo is limited to once per turn. A turn that was already corrected and fails again is softened or held, not redone indefinitely. Best practices: - Treat failure private notes as a work queue: a logged failure is a contact waiting. - Actually enable the tools the Bot needs. A disabled tool produces exactly the scenario the check corrects — and frustrates the contact just the same. - For sensitive actions, prefer human approval of the action (hybrid autonomy) over holding the reply — it is cheaper, because it prevents the problem before the text exists. - Review weekly where the check acts most. Repetition at the same point almost always means an ambiguous instruction or a broken integration, not "bad AI". Troubleshooting - "The contact got 'I'll confirm and get back to you', but the action worked": the action probably completed outside the turn. Confirm in the module and reply to the contact; nothing needs to be undone. - "The Bot claimed something that did not happen and it got through": known limit — the phrasing fell outside the recognized patterns. Keep the excerpt, make the Bot's instructions more direct at that point, and if the risk is high turn that step into an action with human approval. - "I turned holding on and the contact was left with no reply": that is the documented behavior. While held, the reply does not go out. Check the approval queue; if nobody watches it during those hours, go back to Always deliver. - "The reply came out clipped/dry": the offending sentence was deleted. If it happens often on the same topic, adjust the instructions so the Bot does not promise a result before executing it. - "A legitimate link of ours disappeared from the message": the domain is not on the account's records. Add it and the problem stops. - "The Bot answered in the wrong language and the message did not go out": the check treats a language mismatch as a surface problem. Pin the language in the Bot configuration if your operation is monolingual. - "Where do I see what was held?": on the conversation, via the private note, and in the approval queue of the Maestro panel — the same place as the other approvals. See also - Checking what the Bot claims before it is sent - Automation triggers about the AI (Maestro) - Bot autonomy modes and human approval (HITL) - Maestro tools by module - What Maestro AI and the Account Brain are

Silent bot: working without talking to the contact

Overview The interaction mode answers a single question: does this bot talk to the contact? There are two modes: - Talks to the contact (default) — the bot works as usual: it reads, reasons, uses its tools and replies to the contact on the channel. - Silent — the bot sends the contact nothing. It keeps reading the conversation, reasoning and using the tools you enabled, but everything it produces becomes a private note for the team. A person is the one who answers the customer. Do not confuse this with autonomy. Autonomy is how much the bot decides on its own. Interaction mode is whether what it produces reaches the contact. They are independent: a bot can be silent and still run on autopilot to act behind the scenes. Silent is not "a bot that feels less like talking" — it is structurally unable to send. The contact-facing tools are never handed to the model, and if the model invents one of their names, execution is refused. The lock exists in both places on purpose: a lock only the model respects is not a lock. Prerequisites - Maestro enabled and a configured bot. - Administrator permission to change the bot's configuration. - A human team working the inbox — in silent mode nobody answers the contact until a person does. Step by step 1. Open the bot's configuration. 2. Go to Interaction mode (right below Autonomy). 3. Choose Silent — private notes only. 4. Read the warning that appears: it states exactly what stops happening. 5. Save. From then on, that bot sends the contact nothing. To reverse it, choose Talks to the contact and save — the bot resumes immediately, with every other setting intact. Settings & options | Mode | What the contact receives | Where the bot's output shows up | |------|---------------------------|---------------------------------| | Talks to the contact (default) | The bot's replies, on the channel | In the conversation, as a message | | Silent | Nothing | As a private note for the team | What keeps working in silent mode - Reading the conversation, summary and memory. - Internal tools: CRM, calendar, catalog, knowledge base, database, web search, labelling, creating tasks, recording contact attributes. - Private notes — this is how the bot's work reaches the team. - Autonomy and human approval still govern the actions it performs. What stops happening - No message to the contact, on any channel. - No "typing…" indicator — announcing typing would promise a message that provably cannot arrive. - No read receipts. This is where silent is stricter than Copilot: an observing bot stamping every inbound message as read the moment it lands takes the receipt out of the human agent's hands and manufactures the worst possible reading for a customer — seen, and ignored. Silent vs Copilot Both stop the bot from sending on its own, by different routes: | | Copilot | Silent | |---|---|---| | How the suggestion arrives | A draft card for you to review and send | A private note with what it found | | Does the draft become a message? | Yes, with one click from you | There is no draft to send | | Marks as read | Yes | No | Pick Copilot when you want to speed up the human reply. Pick Silent when you want the bot working alongside a team that owns the conversation. Use cases - Audit and quality — the bot follows conversations and leaves notes about risk, promises made and open items, without ever surfacing to the customer. - Quiet enrichment — it queries the CRM and the knowledge base, records contact attributes and labels the conversation while the human agent talks. - Risk-free pilot — run the bot silent on a real inbox for a few days and read the notes to judge its quality before letting it speak. - Sensitive channel — legal, collections or healthcare, where the answer to the customer is always human but the preparation can be automatic. Tips, limits & best practices - Silent is per bot, not per conversation: it applies to every inbox that bot serves. - If the bot goes silent and nobody is working the inbox, the contact gets no answer at all. Confirm someone is on the other side. - Use silent as a trust ladder: Silent → Copilot → Hybrid → Autopilot. - Tools that act (create a deal, book, charge) keep acting. If you want observation only, review the enabled tools as well. - An unknown value in the field (say, from an API edit) is read as Talks to the contact: if this setting fails, it fails towards continuing to serve. Troubleshooting - "The bot stopped replying out of nowhere" — check the Interaction mode. If it is Silent, that is the expected behaviour. - "Notes appear but the customer receives nothing" — that is exactly silent mode working. Switch to Talks to the contact if you want customer replies. - "The customer says the message was seen and ignored" — in silent mode the bot does not mark as read; check whether the receipt came from an agent's app. - "I asked the bot to send a message and it refused" — in silent mode the sending tools do not exist for it, and execution is refused even if the model tries. - "I want silence in this conversation only" — use Pause the bot on that conversation; the interaction mode covers the whole bot. See also - What Maestro AI and the Account Brain are - Bot autonomy modes and human approval (HITL) - Generative copilot: propose, confirm and execute - Maestro tools by module - Where each bot is used

Web search: the bot looking things up on the public internet

Overview Web search gives the bot two tools for querying the public internet — things it does not know and that do not live in your account: news, market prices, public company data, documentation, anything that changed after the model was trained. | Tool | What it does | |---|---| | web_search | Searches the web and returns ranked results with the title, URL and a snippet of each page. | | web_fetch | Reads the full text of specific pages by URL — after a search when the snippet is not enough, or whenever the bot already has the URL. | Both are read-only and send the contact nothing: they return text to the model, which then decides what (if anything) to say. That is also why they stay available when the bot delegates to a sub-agent. For your account's own content — contacts, deals, catalog, history — the bot has dedicated tools, and the knowledge base holds your material. Web search is for what lives outside. Prerequisites - Maestro enabled and a configured bot. - A Tavily API key available to the bot (see "The key" below). - The web_search and/or web_fetch tools enabled in the bot's tools grid — without them, nothing in this section has any effect. Step by step 1. In the bot's configuration, open the Tools grid and enable Search the web and/or Read a web page (Knowledge category). 2. Scroll to the Web search section. If neither tool is on, a notice tells you nothing there will take effect yet. 3. Adjust Search depth and Results per search. 4. To restrict it, fill in Search only these domains and/or Never these domains. 5. Save. To switch search off entirely, disable both tools in the grid. Your settings are kept for whenever you turn them back on. Settings & options | Option | What it does | Default | |---|---|---| | Search depth | Basic or Advanced. Advanced reads more of each page and matches better, but costs more credits per call. It also applies when web_fetch reads a page. | Basic | | Results per search | A ceiling of 1 to 20. Empty = the tool default (5). | Empty (5) | | Search only these domains | Restricts search to those domains. Empty = the whole web. | Empty | | Never these domains | Always blocks those domains. | Empty | How the two domain lists combine They do not work the same way, and the difference is deliberate: - Search only these domains is a restriction. When you fill it in, the bot's own list is ignored — it cannot search anywhere else, not even if it asks. A restriction the model can widen is not a restriction. - Never these domains is a blocklist. Your domains always apply, and the bot may still add more for a specific query. Type domains separated by commas or newlines. https://, www. and any path after the slash are stripped automatically — Tavily matches hosts, so https://example.com/pricing becomes example.com. What the bot decides (and you do not) - How many results to request for that query: it may ask for fewer than your ceiling, never more. - The topic of the query (general, news or finance) and the time window (past day, week, month or year), decided per question. Neither has a fixed per-bot field today — the default is general, with no time filter. - Which URLs to read with web_fetch — at most 5 per call. The key (Tavily) Search needs a Tavily key. It is looked up in this order: 1. The bot's own key (API keys section, provider tavily). 2. Your account's key, under Integrations. 3. The installation's key, configured by the operator. With none of them, the tools reply that search is not configured and the bot carries on with what it already knows — the conversation does not break. Use cases - Technical support — check a partner's public documentation before advising the customer. - Pre-sales — look up public data about the contact's company to qualify better. - News and prices — answer about something that changed after the model was trained. - Restricted base — put your own site and documentation in Search only these domains: the bot searches only there, like an internal search over public content. Tips, limits & best practices - Every search consumes Tavily credits. Advanced depth and a high result count multiply the spend — start on Basic with the default of 5. - An extra result is also extra context in the turn: 20 results can push the conversation's own information out. - web_fetch reads at most 5 pages per call, and each page's text is truncated to fit the turn. - A URL that could not be read is reported to the bot, not silently dropped — so it does not answer as if it had checked. - The public web is not a source of truth about your operation. For your prices, policies and lead times, use the knowledge base. - Pair it with turn verification if you want to hold replies that claim something the turn did not establish. Troubleshooting - "I configured everything and the bot never searches" — are the web_search/web_fetch tools enabled in the grid? The notice in the section tells you when they are not. - "Search is not configured" — there is no Tavily key at any of the three levels. - "The API key is invalid" — the key exists but was rejected; issue a new one at Tavily. - "The plan limit was reached" — the Tavily account is out of credits. - "Search is rate limited right now" — too many calls in a short window; it retries later. - "It searched a site I did not want" — add the domain to Never these domains, or lock everything down with Search only these domains. - "Results come from another country/language" — make the query more specific in the bot's instructions and restrict by domain. See also - What Maestro AI and the Account Brain are - Maestro tools by module - Knowledge base and ontology - Verifying what the bot claims

DeepSeek as a model provider for your bot

Overview DeepSeek is a language-model provider your bot can use as its main model or as a fallback model, in the same place where you pick OpenAI, Anthropic, Google, Groq and the rest. Access is native: the platform talks straight to api.deepseek.com. That differs from using the same model through OpenRouter — with native access, usage is billed to your DeepSeek account, with your key, with no middleman. | Model | Profile | |---|---| | DeepSeek V4 Pro | The most capable of the family — for reasoning and complex tasks. | | DeepSeek V4 Flash | The fastest and cheapest — for volume and short replies. | Prerequisites - Maestro enabled and a configured bot. - A DeepSeek API key (create one at platform.deepseek.com/api_keys). - Administrator permission to configure keys. Step by step Pick one of the three places for the key — the bot looks them up in this order: 1. This bot only — in the bot's configuration, API keys (per provider) section, DeepSeek row: paste the key and hit Test to confirm before saving. 2. For the whole account — under Settings → Integrations → DeepSeek, enter the key. Every bot in the account can then use it (as long as that bot has account-key usage turned on). 3. For the installation — the operator sets the key in the super admin panel. It applies as a last resort for every account. Once the key is saved: 4. Go back to the bot's configuration and open the Model picker. 5. Choose DeepSeek V4 Pro or DeepSeek V4 Flash as the main model, or add one of them to the fallback chain. 6. Save. Settings & options The key lookup order | Order | Source | When to use it | |---|---|---| | 1st | The bot's own key | A specific bot with separate cost. | | 2nd | The account key (Integrations) | The default for most operations. | | 3rd | The installation key | Set by the operator; covers anyone without their own. | The bot's key always wins. The two global sources only apply if the installation allows it and the bot has that option on — the same rule as every other provider. Live model list With a key configured, the platform reads the model list straight from DeepSeek, so a newly released model shows up without an update. The listing requires the key — there is no anonymous lookup. If the lookup fails, the picker falls back to the curated list above and is never empty. Native vs through OpenRouter The same model may appear twice in the picker: - deepseek:… — native access, billed to your DeepSeek account. - openrouter:deepseek/… — the same model through OpenRouter, billed to your OpenRouter account. This is not a duplicate: they are different routes and different invoices. Pick native if you have a DeepSeek account. Use cases - Cost at volume — DeepSeek V4 Flash on high-volume bots with short replies. - Heavier reasoning — DeepSeek V4 Pro on bots that analyse or decide. - Fallback for another provider — put a DeepSeek model in the chain so service does not stop when the main provider is unavailable or out of credit. Tips, limits & best practices - Test the key in the form before saving. An invalid key shows up immediately. - When building the fallback chain, avoid repeating the same provider back to back: if the outage is account-level (out of credit), the second attempt knocks on the same closed door. Alternate providers. - Usage is billed to your DeepSeek account — watch the balance there. - The key is write-only: once saved, the interface only shows that one exists, never its value. - Switching models does not clear any other bot setting. Troubleshooting - "DeepSeek does not appear in the model picker" — there is no key at any of the three levels, or the bot has global-key usage turned off. - "The key was rejected in the test" — issue a new one at platform.deepseek.com/api_keys and check for a leading or trailing space. - "The model list came back empty" — the DeepSeek lookup failed; the picker shows the curated list and you can still choose normally. - "The bot fell back to another provider constantly" — check the DeepSeek account balance. - "I chose DeepSeek and the charge landed on OpenRouter" — you selected the openrouter:deepseek/… variant; switch to the one starting with deepseek:. See also - What Maestro AI and the Account Brain are - Portable templates: save, duplicate, share and migrate a bot - Maestro tools by module - Where each bot is used

Modelos: save, apply, duplicate, export and import a bot's configuration

Overview A Modelo — the name the screen uses for a saved bot configuration — is a bot's setup stored for reuse: persona, instructions, language model, enabled tools, guardrails, handoff policy, service sequence and everything else you tuned. The library lives in Settings → Bots, just below the bot list — and it shows up even when the account has no bot yet, because importing a Modelo is one of the ways to get your first one. | Action | Where it is | What it does | |---|---|---| | Save as Modelo | in the bot's form | Stores the configuration in this account's library. | | Apply a Modelo | in the bot's form, under Quick-start templates | Brings the stored configuration into the form; you review it and save the bot. | | Duplicate | in the Modelos list | Creates a copy of the Modelo in this account, editable. | | Edit | in the Modelos list | Changes name, vertical and description. It does not touch the stored configuration. | | Delete | in the Modelos list | Removes the Modelo. Bots already created from it keep working. | | Export / Import | in the Modelos list | Produces and reads a .maestro-template.json file another installation can open. | Read this before migrating: a Modelo is not a complete copy of the bot. Two classes of thing are left behind by design — secrets and local references. Whenever something is saved, exported or imported, the What did not travel panel states exactly what was removed or cleared. Never assume "100% imported". Prerequisites - Maestro enabled and at least one configured bot (or a Modelo file to import). - Administrator permission to save, duplicate, edit, delete, export and import. - To import on another installation: administrator access there too. Step by step Save a bot as a Modelo 1. Go to Settings → Bots and open the bot that is already the way you want it. 2. Under Quick-start templates, use Save as Modelo. 3. Fill in Name, and optionally Vertical (optional) and What is this Modelo for? (optional). Name it after the use case, not the client. 4. Confirm with Save Modelo. It appears at the top of the Modelos list. Careful — there are two behaviours, and the dialog tells you which one applies: - The bot is already saved: it stores the configuration the bot is currently running, not unsaved edits on the form. If you just changed something, save the bot first. - The bot does not exist yet: since there is no bot, the configuration on screen is stored as it is. Apply a Modelo to a bot This is the path from Modelo to bot — duplicating creates no bot at all. 1. Open an existing bot, or start creating a new one. 2. Under Quick-start templates, open the Vertical agent picker. Your account's Modelos (and the installation library's) appear in front of the product's ready-made presets. 3. Pick the Modelo and use Apply. The notice tells you how many settings it brought in: applying merges only the fields the Modelo carries — the rest of the form stays as it was. 4. Review the configuration, save the bot, and attach it to the inboxes where it should work. Find, duplicate, edit and delete 1. Use the Search Modelos field to filter by name, description or vertical. Clear search brings the full list back. 2. Duplicate creates a copy of the Modelo in this account, already editable (the notice confirms: "Duplicated as …"). That is how you customise a Shared Modelo, which is read-only. 3. Edit changes Name, Vertical and Description — the stored configuration is not touched. To change the configuration itself, apply the Modelo to a bot, tweak it, and use Save as Modelo again. 4. Delete removes the Modelo from the library. Bots created from it keep working: a Modelo is a starting point, not a link. Export and import between installations 1. On the Modelo, choose Export. The browser downloads a .maestro-template.json file. 2. On the target installation, use Import and pick the file. 3. Read the "What did not travel" panel — it lists, item by item, what was removed or cleared. 4. Reconfigure whatever the panel flagged (keys, teams, knowledge base, media). 5. Apply the Modelo to a bot, review it and save. Settings & options Two scopes: account Modelos and the installation library The list shows both together, and they behave differently on purpose: - Account Modelos — the ones you saved, duplicated or imported. They are editable and can be deleted. - Installation library — they carry the Shared badge and are read-only: they offer no Edit and no Delete. To customise one, use Duplicate: the copy lands in this account, editable, leaving the original untouched. Publishing a Modelo to the whole installation is a platform operator action and has no path in the account panel: the effect crosses every account on the box, and restricting is reversible while unpublishing from the world is not. The "What did not travel" panel It appears after you save, edit, export or import a Modelo, and lists only what could not be carried — references re-matched by name are left out, so the panel stays worth reading. Dismiss closes it. What NEVER travels: secrets Neither the values nor the names. A secret's name is already a map of where the credentials live. These are removed when saving to the library and on export: - The bot's provider keys and the mirror of the account's native keys. - Registered secrets and the list of their names. - Credentials typed literally inside HTTP tools and MCP servers — headers such as Authorization, Cookie, and any field whose name looks like api_key, token, password, secret. - A credential embedded in the URL (https://user:password@host/...). Only the user:password is removed; host, path and query stay so the tool remains reconfigurable. The policy is a denylist: everything travels except what is named as a secret or a local reference. A new field whose name looks like a credential is stripped automatically. That way the possible mistake is "too little travelled", never "a secret travelled". One important and useful exception: a reference in the form {{secret.NAME}} survives — it points at a secret, it is not one. On the other side you just register a secret with that name and the tool works again without rewriting anything. Always use that form in HTTP tools. What does NOT travel: local references team 7 on the target installation points at a team that does not exist — or, worse, at a different team. So every reference is exported as the name it had, re-matched by name on import, and cleared when nothing matches. Nothing is invented: a bot pointing at team 1 just because 1 exists is worse than a bot with no team. | Item | On import | |---|---| | Handoff team | Remapped by name; cleared if no team has that name. | | Sub-agents (delegation) | Remapped by name. | | Knowledge base | Arrives switched off — the ingested content does not travel. Re-ingest, then re-enable. | | Media library assets | Dropped — the URLs point at the source installation's storage. Re-upload on the target. | | Database / cloned voice | The resource does not travel; the capability arrives off and named in the panel. | | Contact attributes | Checked against the ones the target account actually defines. | A capability whose backing resource could not travel arrives disabled on purpose: leaving it on would ship a bot that answers "I checked our knowledge base" against an empty one. The file - Extension .maestro-template.json, carrying a format marker and a version. - A file without the marker is not treated as a Modelo: it is refused, not guessed at. - A version this installation does not know is refused too — never half-read. A half-read Modelo is a bot that looks configured and is not. Use cases - Standardise service — one "Tier 1 support" Modelo applied to several bots. - Try a variant — duplicate the Modelo, apply the copy to a test bot and compare. - Staging → production — configure calmly on staging, export and import. - Agency / multi-client — one Modelo per vertical, exported and imported into each account. - Configuration backup — export before a large change. - Installation migration — carry your bots over without reconfiguring everything by hand. Tips, limits & best practices - Always read the "What did not travel" panel. It is your to-do list on the other side. - After importing, run a real test conversation before putting the bot on live traffic. - Prefer {{secret.NAME}} over pasting the credential: it is the only form that survives the trip. - Name Modelos by use case ("Clinic — booking"), not by client. - Edit does not change behaviour: it only touches the label (name, vertical, description). - Duplicate before experimenting — that way the Modelo that already works stays intact. - A Modelo is a snapshot: changing the bot afterwards does not update the Modelo, and vice versa. Troubleshooting - "I duplicated it and no bot appeared" — duplicating copies the Modelo, it does not create a bot. To get a bot, open the bot's form, apply the Modelo under Vertical agent, save, and attach it to the inboxes. - "This Modelo has no Edit and no Delete" — it comes from the installation (Shared badge) and is read-only. Use Duplicate to get an editable copy in this account. - "A Modelo with this key already exists" — you are importing a file that is already in the library. Duplicate the existing one instead, or rename it before importing again. - "The file was refused on import" — it is not a valid .maestro-template.json, or it was produced by a version this installation cannot read. - "The bot hands off to the wrong team" — no team existed under the same name; the panel marked it cleared. Create the team and select it. - "It says it checked the knowledge base and found nothing" — the base arrives off and empty. Re-ingest the content and enable it. - "The HTTP tools return authentication errors" — credentials do not travel. Register the secrets on the target. - "The media is missing" — the files do not travel; re-upload them in the target's media library. - "I applied the Modelo and not everything changed" — applying merges only the fields the Modelo carries, and the notice shows how many settings came in. The rest stays as the form already had it. See also - What Maestro AI and the Account Brain are - Where each bot is used - Knowledge base and ontology - DeepSeek as a model provider for your bot - Maestro tools by module

Service sequence: steps with an exit criterion the system checks

Overview Until now, a service script could only be written as text in the bot's persona or instructions: "qualify first, then present the proposal, only then close". Text is guidance — a model may follow it or ignore it, and the cheaper, faster models usually ignore it by the third turn. Worse: there was no state saying "this conversation is at the qualification step", so nothing could even notice the drift, let alone correct it. The Service sequence replaces that text with structure: - the service becomes an ordered list of steps; - each step has a goal, the tools it allows and an exit criterion; - the criterion is checked by the platform, in code, against what the turn actually executed — never by asking the bot whether it is done. That inversion is the entire feature. A bot that says "I've already saved your details" without the tool having run advances nothing. It is optional and ships off. A bot that never opens this section behaves exactly as before — same instructions, same tools, same cost. Nothing is added to the conversation. Prerequisites - Maestro enabled and a configured bot. - Administrator permission to edit the bot's configuration. - The tools you want to use in the steps must already be enabled on the bot. A step can only narrow down the tools the bot has — never add to them. - For the Contact fields filled in criterion: the fields you will require must exist on the contact record and be fillable (by a bot tool, by an automation or by the team). Step by step 1. Open the bot's configuration and go to Service sequence. 2. Turn on Follow a sequence of steps. 3. Click Add step and fill in: - Step name — in your own words. The system never translates or rewrites it; the identifier below the name is generated from it. - Goal — goes to the top of the instructions while the step is active. - Tools allowed in this step — pick from the ones the bot already has. - Exit criterion — see the table below. - Turn limit for this step — the safety net (default 8, minimum 1). 4. Repeat for the remaining steps. The order of the list is the order of the service: use move up and move down. Each step leads into the next automatically — you never type the link. 5. Choose After the last step: hand over to a human, mark as resolved, or keep talking with no step. 6. Decide whether to Restrict to the step's tools. 7. Save. On with no steps does not count. The form warns you and asks for at least one step, or for the option to be turned off. Even if it is forced through, a sequence with no steps is inert: the bot works as it always has. Settings & options The four exit criteria | Criterion | The step ends when… | Use it when | |---|---|---| | Tools executed (default) | the chosen tools actually ran in that turn | there is a concrete action that proves the step (booking, charging, recording) | | Contact fields filled in | every field you listed is filled in on the contact | the step exists to collect information | | Only when a human moves it on | nothing automatic advances it — read the limits section | you want a human check mid-service | | After a number of turns | the step's turn limit is reached | there is nothing objective to check (an opening, a greeting) | Details that change the outcome: - Tools executed with an explicit list (the Tools that prove the exit field) requires all the listed tools. - Tools executed without an explicit list accepts any one of the tools allowed in the step — so you do not have to restate the list twice. - A step with no tools and no list is a pacing step: it ends as soon as the turn completes. - Contact fields filled in: if the contact lookup does not happen or fails, the step waits instead of advancing. Advancing on absent evidence is exactly what this feature exists to prevent — and the turn limit still bounds the wait. The turn limit: always present, and always an escalation The limit counts turns (contact messages served), not the model's internal attempts. It exists because "the bot asked me the same thing eight times" is the real problem. When the limit runs out without the criterion being met, the sequence ends there and applies the After the last step policy — as an escalation, not as a completion. The step is not recorded as done, and the next step is not started. After the last step | Option | What happens | |---|---| | Hand over to a human | the conversation is handed over through the same path as the bot's normal handoff: internal note, status and team assignment | | Mark as resolved | the conversation is closed after the reply is delivered — never on top of a message the contact has not received | | Keep talking with no step | the bot carries on serving, now with no step restriction at all | Restrict to the step's tools - On (default): the bot never even receives the other tools. Leaving the step becomes impossible, not merely discouraged. - Off: the step guides through its goal, but does not stop the bot from using any tool it has. Even with the restriction on, a minimum set is never removed: reading the contact and the conversation, and handing over to a human. A step whose author forgot the handoff would produce a conversation that cannot reach a person — worse than the problem the restriction solves. And withholding the contact record makes the model guess facts it could have looked up. What the bot sees of the sequence Only the current step reaches the instructions — never the whole roadmap. A model handed the full map starts narrating it to the contact ("now we move on to the proposal step") or skipping to a step it read about, which is the opposite of following it. The name and the goal reach the bot exactly as you wrote them, in your language, with no translation and no rewriting. Use cases - Sales: Qualification (contact fields) → Proposal (quote tool executed) → Closing (charge created) → hand over to a human. - Triage before a human: a single step, goal "find out the topic and the urgency", exit on contact fields, a 5-turn limit and hand over as the exit policy. - Onboarding: several collection steps, each requiring different contact fields, and mark as resolved at the end. - Human check mid-service: a step with a manual exit and a short turn limit, so the conversation escalates to the team when it gets there (read the limits below before using it). - Support with a fixed procedure: tool restriction on, so the bot cannot create a charge during the diagnosis step. Tips, limits & best practices "Only when a human moves it on" has no advance button. Today nothing advances a manual step automatically, and there is no command in the panel to push it to the next one. In practice it ends in one of two ways: the turn limit runs out and the sequence closes through the exit policy (an escalation), or a person takes over the conversation — at which point the bot has stopped replying anyway. Use this criterion as "stop here and call someone", with a short turn limit and Hand over to a human as the exit policy. Do not use it expecting the conversation to carry on to the next step afterwards. Other limits, equally honest: - A criterion with nothing to check becomes an escalation. If you pick Tools executed with no tools, or Contact fields with no fields, the form warns you: that step would only ever exit on the turn limit — which is an escalation, not a completion. - Only tools already enabled on the bot can enter a step. If the list comes up empty, enable the tools in the Tools section first. - Turning it off does not delete anything. The steps stay saved; the form tells you how many. - The step is durable. It survives a pause, a handoff, a restart and a contact who answers six hours later. A returning contact does not start over. - Editing the sequence while conversations are live has a consequence. If you delete or rename the step a conversation is sitting on, that conversation is released — it finishes unconstrained, as it did before the sequence existed. It is not restarted at step 1, so the contact does not pay for your edit by answering everything again. - The form refuses a sequence that cannot be walked: a step with no name, two steps sharing an identifier, a link pointing at a step that does not exist, or a cycle. - This does not replace reply verification. One stops the bot from advancing without proof; the other stops it from telling the contact something that did not happen. They add up. Best practices: - Start with two or three steps. An eight-step script is easier to get wrong than to follow. - Prefer Tools executed whenever there is a concrete action: it is the hardest criterion to fake. - Write the goal as a task sentence ("find out the segment and the company size"), not as a persona. - Keep the turn limit short on the opening steps and roomier on the ones that depend on the contact answering something slow. - For sensitive actions (money, cancellation, personal data), combine the sequence with human approval. Troubleshooting - "I can't save": the sequence is on with no steps, or there is a step with no name, two sharing an identifier, a broken link or a cycle. The form's message says which one it is. - "The step's tool list is empty": the bot has no tools enabled yet. Enable them in the Tools section and come back. - "The bot won't leave the first step": the criterion is not genuinely being met. Check that the required tool ran (and was not merely mentioned in the reply) and that the required fields are actually filled in on the contact. A disabled tool never runs. - "The conversation was handed over mid-script": some step ran out of turns. That is the escalation working — raise that step's limit or make the criterion easier to meet. - "The bot told the customer the script": it never receives the script, only the current step. If the script text is showing up, it was most likely also written into the instructions or the persona — remove it from there. - "I reordered the steps and an old conversation went odd": live conversations keep the state they already had. If the step they were on is gone, they were released and finish unconstrained. - "I turned the sequence off and the steps disappeared from the screen": they are still saved — the notice tells you how many steps are being kept. See also - Maestro tools by module - Bot autonomy modes and human approval (HITL) - Verifying what the bot claims before sending - Turn verification and holding the reply - Advanced model settings per bot - What Maestro AI and the Account Brain are

Advanced model settings per bot: temperature, Top P, output ceiling and reasoning effort

Overview Every bot already picks a default model and a fallback chain. The Advanced model settings sit one level below that: four knobs that change how the chosen model answers, without changing which model it is. Four fields, all optional: | Field | Range | What it changes | |---|---|---| | Reasoning effort | Inherit / None / Low / Medium / High | how much the model "thinks" before replying, in families that have reasoning | | Temperature | 0 to 2 | higher values make replies more varied; lower values, more predictable | | Top P | above 0 up to 1 | nucleus sampling — usually tuned instead of temperature | | Max output tokens | 1 or more | ceiling on tokens generated per reply | Blank (or "Inherit") keeps the current behavior. A bot that never opens this section stays exactly as it is: the platform only sends a knob to the provider when you chose one. Leaving a field blank is not "zero" — it is "send nothing, use the provider's default". Prerequisites - Maestro enabled and a configured bot. - Administrator permission to edit the bot's configuration. - Knowing which model the bot uses: the knobs only apply where that model's provider accepts them (see the compatibility table below). Step by step 1. Open the bot's configuration. 2. Go to Advanced model settings. 3. Fill in only the fields you want to change. Leave the rest blank. 4. Save. 5. Run a test conversation with that bot and compare the result before applying the same setting to others. Settings & options Temperature and Top P — tune one, not both Both control the same thing along different routes: how much variation a reply may have. The practice the providers themselves recommend is to move one and leave the other blank. Tuning both at once makes the result hard to predict and even harder to compare between two versions of the same bot. As a practical reference: - Low temperature (0 to 0.3): procedures, technical answers, data extraction — anything that should come out the same every time. - Medium temperature (0.4 to 0.6): ordinary support, natural conversation without becoming unpredictable. - High temperature (0.7 or above): creative writing, deliberate message variation. Rarely what you want in customer service. Max output tokens This is a ceiling per reply, not a target. It exists to hold back replies that are too long for the channel (WhatsApp especially) and to cap cost per turn. A ceiling set too low truncates the reply instead of summarizing it — if messages start ending mid-sentence, the ceiling is too tight. Reasoning effort It applies to reasoning-capable models (OpenAI's o-series/gpt-5.x families, DeepSeek and the like). More effort usually means a better answer on hard tasks, more waiting and more cost. This field has a second effect, which is why it exists in the form: choosing a value here also stops the router from forcing an automatic endpoint switch when the model is a reasoning one and has tools bound to it. If you have already decided how the model should reason, the platform honors your decision instead of deciding for you. Where each knob applies — and where it is dropped Each provider spells these parameters differently, and some simply do not have the parameter. The platform translates the value into that provider's correct name and, when the provider does not have it, drops the knob rather than inventing a name the call would reject. | Knob | Where it is dropped | |---|---| | Temperature | on OpenAI reasoning-family models (the family does not accept it) | | Top P | on OpenAI reasoning-family models; on Groq and Cohere, which do not expose the parameter | | Max output tokens | on Cohere | | Reasoning effort | on Anthropic, Google, Cohere, Ollama, xAI and OpenRouter | About the first row: on OpenAI reasoning models, temperature and Top P are dropped together, on purpose. Previously temperature vanished quietly while Top P went on to fail the request — the same panel value behaved two different ways depending on which field you happened to fill in. Dropping is silent. It does not become an error in the conversation nor a warning on this screen. If a knob seems to have no effect, check the table above before looking for a fault. An invalid value: the provider is the one that refuses The platform validates the ranges in the form (temperature 0 to 2, Top P above 0 up to 1, output ceiling 1 or more). Beyond that, whoever decides if a value is acceptable is the model's provider — and any error message you see comes from there, not from the platform. When in doubt, leave it blank. Use cases - Support bot with a fixed procedure: temperature 0.1, so the same question always gets the same answer. - Sales bot: temperature 0.5 to 0.6 — natural conversation without inventing variations every turn. - A bot that only extracts data (recording an order, filling in a record): temperature 0.1 and a low output ceiling; the reply is short by nature. - A bot on a channel with a size limit: an output ceiling so messages do not come out enormous. - A hard task with no rush (analysis, diagnosis): reasoning effort High, accepting more time and more cost. - A reasoning model with tools where you want to control the behavior: set the effort explicitly instead of letting the platform decide. Tips, limits & best practices - Change one field at a time and test. Two knobs at once make it impossible to know which one caused the difference. - Temperature OR Top P. Not both. - Blank is not zero. Clearing the field hands the decision back to the provider; typing 0 is a choice of yours, with a real effect (temperature 0 = as predictable as it gets). - Reasoning effort costs time and money. On WhatsApp support, a high effort can make the reply slow enough for the contact to give up. - These knobs do not change the model. If quality does not improve here, the next step is to change the default model, not to raise the temperature. - The fallback chain still applies. The knobs are applied on top of whichever model actually serves the turn — including a fallback, when the main one fails. - A bot with none of these fields filled in is not a badly configured bot. The provider defaults are good for most conversations. Troubleshooting - "I changed the temperature and nothing changed": the bot's model is an OpenAI reasoning one — in that family temperature and Top P are dropped. Change the model or use reasoning effort. - "I set Top P and it is still the same": besides the case above, Groq and Cohere do not expose that parameter. - "Replies are being cut off mid-sentence": the Max output tokens ceiling is too low. Raise it or leave it blank. - "The provider rejected the call": the value is outside what that model accepts. The message comes from the provider; clear the field and try again. - "The bot got slow": high reasoning effort, or a reasoning model where an ordinary one would do. - "I picked a reasoning effort and the model is not a reasoning one": the knob is dropped. It breaks nothing, it just has no effect. See also - Portable models: one bot, several providers - DeepSeek provider - Service sequence - Turn verification and holding the reply - What Maestro AI and the Account Brain are

Reply formatting: adapt to the channel, or deliver raw markdown

Overview The model always writes in markdown — that is the format it was trained to structure text in. The catch is that every channel understands markdown differently: WhatsApp uses *asterisks* for bold, the web widget renders full markdown, and some channels format nothing at all. Reply formatting decides what happens between what the model wrote and what the contact reads: - Adapt to the channel — translates formatting into the destination channel's dialect. Bold becomes *like this* on WhatsApp, and plain text where there is no support. - Do not format — delivers the raw markdown exactly as the model wrote it. Prerequisites - A Robô already created and configured. - Account administrator access to edit the Robô. Step by step 1. Open Settings → Robôs and edit the Robô. 2. Go to the Delivery section. 3. Under Reply formatting, pick Adapt to the channel or Do not format. 4. Save. The change applies to the next replies; messages already sent are not rewritten. Settings & options | Option | What it does | |---|---| | Adapt to the channel | Converts formatting into what the destination channel understands | | Do not format | Sends the model's markdown untouched | The choice belongs to the Robô, not to the channel: one Robô serving both WhatsApp and the widget adapts for both from a single setting. Use cases - WhatsApp support: use Adapt to the channel. Without it, a markdown **bold** reaches the contact as four literal asterisks in the middle of the sentence. - An integration consuming the reply over the API: use Do not format. The system on the other side usually prefers the original markdown so it can render it its own way. - A channel that already renders markdown: either works; adapting is the safe default. Tips, limits & best practices - When in doubt, Adapt to the channel. It is what the contact expects to see. - Do not format does not mean "plain text": it means markdown intact. If the channel does not render markdown, the contact sees the symbols. - This controls formatting only. It does not change the content, the language or the reply length. Troubleshooting The contact is seeing ** or ## inside the text. The Robô is on Do not format in a channel that does not render markdown. Switch it to Adapt to the channel. The reply arrives with no emphasis at all. The destination channel supports no formatting — the adapt mode falls back to plain text on purpose, because that beats stray symbols. I changed it and nothing happened. The setting applies from the next reply onwards. Also confirm you saved the right Robô if the account has more than one. See also - Advanced model settings - Service sequence

Pagination in custom HTTP tools

Overview A custom HTTP tool lets the Robô call your API. When that API returns lists, it almost always returns them in pages — and without configuring this the Robô reads only the first one and answers with part of the data, unaware that the rest exists. Pagination fixes that. You tell it which kind it is, where the items live in the response, and how many pages to walk. And, optionally, how many items to ask for per page. Prerequisites - A Robô with at least one custom HTTP tool configured. - Knowing how your API paginates: by page number or by cursor. - Account administrator access. Step by step 1. Open Settings → Robôs and edit the Robô. 2. Go to Custom tools and open the tool. 3. Under Pagination, pick the type: No pagination, Page number or Cursor. 4. Fill in the pagination fields (see the table below). 5. Save. Settings & options | Field | What it is for | |---|---| | Type | No pagination, Page number or Cursor | | Page/cursor param | The parameter name your API uses to advance (page, cursor…) | | Items path (array) | Where the result list sits in the response | | Next cursor path | Where the next page's cursor comes back (cursor type only) | | Start page | Which page to begin from | | Max pages | Ceiling on how many pages one call walks | | Page size param | Your API's page-size parameter name (per_page, limit…) | | Items per page | The value sent in that parameter | The last two are optional and travel together: leaving them empty means the parameter is not sent, and the API decides the size. Use cases - An API that defaults to 100 items per page: set per_page = 20. Each page becomes a chunk that fits comfortably in context, and Max pages controls how far to go. - An API that returns everything at once: if it accepts a limit parameter, use it. One huge response eats the model's context and leaves little room for reasoning and for the reply. - A cursor API: fill in Next cursor path; the page size still applies. Tips, limits & best practices - Start modest (10 to 25) and raise it only if answers come back incomplete. - A smaller page size with a larger Max pages usually beats one giant page: the Robô can stop once it has found what it needed. - The parameter must exist in your API. A name it does not know is usually ignored silently — and you are left thinking the setting had no effect. - Leaving it empty is a valid choice when the API's own default is already reasonable. Troubleshooting The Robô answers with partial data. Either pagination is set to No pagination, or Max pages is too low for the volume the query returns. The tool is slow. Every page is one HTTP call. Lower Max pages, or raise items per page to fetch the same volume in fewer round trips. I changed items per page and nothing changed. Confirm the parameter name against your API's docs — per_page, limit, page_size and pageSize are all common, and only one is right. The list comes back empty. The Items path is not pointing at the right array in the response. See also - Advanced model settings - Maestro tools by module

Knowledge base and business map (ontology) of the Brain

Overview The Account Brain has two pieces that work together: - The knowledge base (corpus) is the set of sources that feed the Brain: documents you upload, pages you paste by URL, and the objective/goal you write about your business. Each source is processed and split into indexed pieces (the "chunks"), which Maestro consults to answer with a reference to the origin. - The structure or business map (ontology) is the consultable result of that: a graph of entities (inboxes, teams, AI agents, labels, attributes, macros, channels) and the relations between them, built from the corpus plus the real data in your account. It's the "second brain" — the digital twin — Maestro uses to understand your operation. In short: you feed the knowledge base and the Brain builds the business map from it. The richer the corpus, the better the answers, risks and insights. Prerequisites - An account with Maestro and the Account Brain enabled (the account_brain capability). If you can't find the area, talk to an administrator. - Reading is for any account member: viewing the sources and the business map requires no special permission. - Adding or removing sources is administrator-only — the server re-checks the permission, and the interface hides the upload/delete controls for non-administrators. Step by step Feed the knowledge base In the Knowledge base (corpus) tab, you have three ways to "feed the Brain": 1. Upload a document: drag the file into the upload area (or click to choose) and confirm. The file is stored as an attachment and the Brain fetches and extracts its content, turning it into indexed pieces. 2. Paste a URL: paste a page address and confirm. The Brain fetches the page and extracts the content, just like a document. 3. Write the account objective/goal: describe, in text, your business goal (there's also a voice dictation button to fill it by speaking). The objective is a fixed source: saving it again replaces the previous one instead of duplicating. Manage sources - The list shows each source with its indexed-chunk count, plus a summary at the top with the total number of sources and chunks — the proof the Brain has been fed. - To remove a source, use the delete icon (administrators only) and confirm in the dialog. Removing a source deletes all of its chunks from the index. View the business map (structure/ontology) - Open the Structure (ontology) tab to see the graph of entities and relations built from the corpus and the account's real data. - Click an entity to open the detail panel with its type, the connected relations, and, when present, the sources (origin) of that item. Settings & options - Embeddings provider (administrators): at the top of the knowledge base you choose which provider indexes and searches the account's knowledge (installation default, OpenAI or Cohere). Switching re-indexes every source automatically — wait for processing to finish before judging answer quality. - Three input modes: document, URL, or objective text — pick whatever fits each piece of content. - Objective as a fixed source: re-saving the objective reindexes (replaces); it never piles up duplicates. - Per-source chunk count: shows how much content was actually extracted and indexed. - Fail-safe behavior (cache-first): the business map is cached, so the screen renders even if the engine is momentarily offline — instead of showing an error. - Teaching empty-state: when there's no knowledge yet, the screen invites you to feed the base rather than showing a dead screen. Use cases - Centralize manuals, policies, catalogs and FAQs so Maestro answers consistently. - Record the business objective to guide the copilot's proposals and actions. - Visualize how inboxes, teams, agents and attributes connect — useful to review your account setup. - Build a solid base that improves the risk analysis and insights generated per department. Tips, limits & best practices - The richer and cleaner the corpus, the better: up-to-date, well-written documents produce more accurate risks, insights and analyses. - A clear objective improves the proposals from the copilot and the departments. - Avoid uploading outdated content — old information yields old suggestions. - The business map populates over time: feed sources and wait for processing. - Indexing uses embeddings with automatic provider fallback (e.g. OpenAI → Cohere). Connect a Cohere key under Integrations so the knowledge base keeps indexing even when the primary provider runs out of credits. Troubleshooting - Source with 0 chunks: the extraction found no content — the format may be unsupported, the file may be empty/protected, or the URL may be unreachable. Try another format or re-upload. - Business map (ontology) is empty: the map does NOT come from the sources you upload — it is built from your account's real structure (inboxes, teams, bots, labels, attributes, macros). It is generated when the account is created and refreshed once a day after that. On an account created right after the daily refresh, the map stays empty until the next one. Use Map now, on the empty screen itself, to build it immediately — it takes a few seconds. - "Could not map this account": Maestro could not read your account's structure. This is almost always the account access token Maestro uses; ask an installation administrator to review it and map again. - Action blocked: uploading or removing sources is administrators only. If the controls don't appear (or the action is refused), confirm your role with an administrator. - "Indexing failed" / embeddings unavailable: no embedding provider has a valid key with credits. Check the primary provider's credits (e.g. OpenAI) or connect a Cohere key under Integrations and try again. - Incompatible embedding model while saving a Robot: each installation stores vectors at one fixed width. Pick a model with the same dimension shown on screen — on a 1536 installation, use text-embedding-3-small instead of text-embedding-3-large (3072). After changing a model that has already been used, reindex the knowledge base so old and new vectors are not mixed. See also - What is Maestro AI and the Account Brain - Voice onboarding and assisted setup - Departments, risk analysis and insights

Daily Help Center sync into the bot's knowledge base

Overview There are two different integrations between the Help Center and Maestro. Their names sound alike, but their scope and speed are very different — mixing them up is the most common cause of "I published the article and the bot doesn't know it": | | Per-bot article picker | Daily account-level sync | |---|---|---| | What gets in | only the articles/categories you tick | everything published, across all portals | | Who uses it | that bot only | every bot in the account (shared base) | | When it updates | instantly — on saving the selection and on every edit/publish of the article | once a day, automatically | | Where you set it up | knowledge tab in the bot's configuration | nothing to set up: it is automatic | The first one always worked instantly. The second — the one that takes the whole portal into the account's shared base — had no automatic trigger: it only ran if an installation administrator fired it by hand. From this version on it runs by itself, every day. Each published article becomes a document in the account base under the path help-center/{portal}/{category}/{article} — so the bot answers with the official content and can cite which article the answer came from. Articles with no category land in uncategorized. Prerequisites - An account with Maestro enabled and at least one active bot. The daily sweep skips accounts with no active bot — there would be nobody to hand the knowledge to. - A Help Center portal with articles in the published status. - An embeddings provider with a valid key and credits — this is the same indexing used by the Account Brain's knowledge base. - The sync must be enabled on the installation (a deployment switch under the installation administrator's control). If it is off, no account syncs. Step by step 1. Write and publish your articles in the portal, as usual. Drafts and archived articles do not count. 2. Do nothing else. The sweep runs automatically every day at 05:10 UTC (02:10 in Brasília time). It is not triggered when the service restarts: it waits for the scheduled time. 3. Check it the next day: ask the bot something that only exists in that article. The answer should carry the published content and point to its origin under help-center/…. 4. Need it to count right now, without waiting for the next day? Two ways out: - tick the article (or the whole category) in the bot's knowledge tab — that selection applies immediately and stays in sync on every edit; - or ask an installation administrator to trigger the account sync on demand. Settings & options - Daily cadence, at 05:10 UTC. The odd time is deliberate: Maestro's other automatic routines run on round hours, and the Brain's structure mapping runs 55 minutes earlier — so reading the articles never competes with the previous routine over the same account. - Scope: every portal in the account, every published article. The category becomes a "folder" in the document path. - Indexed content: the article's title plus its body. Subheadings (##, ###) drive how the text is split into passages — each passage carries the section it came from, which improves citations. - Read-only: the sync never edits, publishes, unpublishes or deletes an article. It only reads the portal and writes into the Maestro base. - One run per account, per day: if the previous day's sync is still running when the next one starts, the new one is dropped. There are never two writing to the same base at once. - Atomic replacement: content is indexed before the base is touched, and the swap happens in a single transaction. A failure halfway through never empties what was already indexed. - Error isolation: a broken article, page or portal is counted and the sweep carries on with the rest — one bad item does not sink the whole sync. - Pagination guard: reading each portal is capped and stops on its own when articles start repeating, preventing an endless read. Use cases - Getting the bot to answer with the official published policy, citing the article, instead of a hand-pasted and outdated copy. - Keeping a single source of truth: the team edits the portal, and every bot inherits it. - Accounts with many articles: using the whole portal without ticking item by item. - New bots start out knowing — the base belongs to the account, not to one bot. - Trilingual portals: whatever is published in each language goes into the base. Tips, limits & best practices - Drafts and archived articles do not get in. An article with an empty body is skipped too (and whatever was already indexed is preserved). - Unpublishing does not remove the article from the shared base in the daily sweep: it adds and updates, it does not delete documents for articles that went offline. If a piece of content must disappear from answers immediately, use the per-bot picker (which removes it on unpublish) or ask an administrator to remove that source. - Cost: every run re-indexes the published articles, and indexing costs money per account. That is why the cadence is daily: it is the cheapest steady state that keeps staleness within 24 hours. Running hourly would multiply that cost by 24 to watch content that rarely changes by the hour. - A window of up to 24 hours: urgent changes should go through the per-bot picker, which applies immediately. - A good article makes a good answer: clear titles, well-divided sections and up-to-date content produce better citations. Stale content produces stale answers. Troubleshooting - "I published yesterday and the bot doesn't know it": confirm the article is published, that the account has at least one active bot, and that the embeddings provider has credits. If the article was published after 05:10 UTC, it only gets in on the following sweep. - "Nothing syncs, in any account": the sync is most likely disabled on the installation. Talk to the installation administrator. - "It synced, but the bot doesn't use it": the bot must be allowed to query the knowledge base. Review the tools enabled for it. - "An old article still shows up in answers": that is the limit described above — unpublishing does not delete it from the shared base. Use the per-bot picker or ask for the source removal. - "Could not index" / embeddings unavailable: no embeddings provider has a valid key and credits. Check the primary provider's credits or connect an alternative key under Integrations — same cause (and same fix) as the knowledge base. See also - Knowledge base and business map (ontology) of the Brain - Where each Robô is used: the account's surfaces - Maestro tools per module and how to enable them - What is Maestro AI and the Account Brain

Consultative analytics and generative dashboards in the Brain

Overview The Account Brain offers two ways to read your operation from the data the platform already holds: - Consultative analytics matrix — a tab with real KPIs from the native modules (open conversations, first response time, resolution time, CSAT, MRR, CRM pipeline value, active follow-ups, Catalog orders, and Sales metrics such as goals, attainment, coins and commission), plus series (conversation volume over the last days and distribution by status), each chart carrying a one-line consultative read. - Generative dashboards — you describe in plain language the panel you want, and the Maestro builds a declarative specification (KPI cards, charts, tables and a summary narrative) with the real values overlaid. The matrix is read-only and always available; generative dashboards are yours to create, review, save and organize. Prerequisites - An account with the Account Brain enabled. - Administrator permission to generate, save, reorder and discard dashboards. Any member of the account can view the matrix and the saved dashboards (read-only). - Native modules active and populated so KPIs show real values (for example, Payments for MRR, CRM for the pipeline, Catalog for orders, Sales for goals and commission). Step by step View the analytics (matrix) 1. Open the Account Brain and go to the Analytics tab. 2. Track the KPI cards and the charts (volume and status). 3. Where a matching native report exists, click the KPI to open the report with the detail. 4. If a cached badge appears, the analytics engine was briefly down and the tab showed a native fallback computation — the data is still valid and the tab never breaks. Create a generative dashboard 1. Go to the Dashboards tab. 2. In the generation field, describe in plain language the panel you want (you can also dictate by voice). Example: "show CSAT, MRR and conversation volume for the last two weeks". 3. Click Generate. The Maestro returns a declarative specification with cards and charts, already with the real values of the native KPIs overlaid. Review, save and organize 1. Review the proposal on screen (it is not yet saved). 2. Click Save to keep it — it becomes a native account dashboard, persisted per account. 3. Reorder the widgets (move up/down) to adjust the layout. 4. Saving again updates the existing dashboard; generating without an id creates a new one. 5. To remove one, use discard (with confirmation) — it is a soft-delete. Settings & options - Native KPIs: open conversations, first response time, resolution time, resolutions, CSAT, MRR, pipeline value, active follow-ups, Catalog orders and Sales metrics. Each returns 0 when the module is inactive or has no data yet. - Drill-down: KPIs with a native report link into that report (the rest stay as a plain card). - Declarative filters: chips (for example, period/range) that adjust and regenerate the panel — available to administrators. - Per-account layout: widget order is personalized per account and mirrored into the saved dashboard on save. - Provenance (sources): when the summary is grounded in your knowledge base, source chips appear; clicking one opens the Corpus. - Cache-first behavior: the tab always returns a stable shape; with the engine down it uses the native computation (cached badge). A brand-new account renders zeroed KPIs and empty series — never an error. Use cases - Keep a recurring view of the operation (CSAT, MRR, pipeline) in a saved dashboard. - Quickly build a panel for a specific question ("I want Catalog orders by week"). - Combine period with metrics to compare time windows. - Open the native report straight from a KPI to investigate a number. Tips, limits & best practices - Ask for specific metrics and combine them with filters (e.g. period) for more useful panels. - Use saved dashboards as the team's default view — they persist per account. - The generated specification is only kept after you save; if you regenerate or leave, an unsaved proposal is lost. - KPIs at 0 usually mean an inactive module or no data yet, not an error. Troubleshooting - KPI at 0: the matching module is inactive or there is no data yet (for example, no subscriptions → MRR 0; no CRM deals → pipeline 0). - Action blocked: generate, save, reorder and discard are administrator-only — members have read access. - I lost the generated dashboard: the proposal is not kept until you click Save. - "Cached" badge: the analytics engine was briefly down; the tab used the native fallback computation and stays functional. See also - Departments, risk analysis and insights - Generative copilot: propose, confirm and execute - What the Maestro AI and the Account Brain are

Actions per reply: how much the bot does before answering

Overview Every time the contact writes, the bot composes ONE reply. To compose it, it may need to do things first: look the CRM up, find a product in the catalog, open a deal, attach items, leave a note. Each of those is an action. Actions per reply is the limit on how many actions the bot may chain before it has to answer the contact. It exists so a reply can never get stuck in an endless loop of lookups — the contact would sit in silence while the bot "thinks" forever. The default is 6, which fits most conversations. Prerequisites - Be an administrator of the account. - A bot already created and connected to an inbox. Step by step 1. Go to Settings → Bots and open the bot you want to tune. 2. Scroll to the Conversation & Context block. 3. In Actions per reply, enter the new limit (between 2 and 20). 4. Leave it empty to fall back to the system default. 5. Click Save. It applies from the next message — nothing needs restarting. Settings & options | Value | When to use | |---|---| | Empty (default) | Almost always. Covers support, questions and simple sales. | | 8–12 | Bots that run long processes in one go: read the CRM, open a deal, attach products, leave a note and still reply. | | 2–4 | Very simple bots (FAQ, triage), where chaining many actions is a sign something left the script. | The number of actions actually performed is one less than configured. The last round is reserved for the bot to write the reply — that is what guarantees nobody is left without an answer. Use cases - Consultative sales. The bot reads the history, checks whether a deal is already open, opens one when there isn't, attaches the products mentioned and only then replies. Raising this to 8–10 keeps it from running out mid-process. - Straightforward support. Answering from the Knowledge Base rarely goes past 2–3 actions. Keeping the default is right. Tips, limits & best practices - Raising the limit makes replies slower and more expensive. Each action is one more lookup, and the bot only writes once it is done. Raise it only for a concrete reason. - If the bot runs out of actions before finishing, it does NOT go silent: it replies with what it already gathered and says honestly what it is still handling. It never claims to have done something it did not do. - Whatever was left pending becomes an internal note on the conversation (visible to your team only), listing exactly which actions were not performed. If they still apply, someone does them by hand. - Resolving also ends that turn's outbound delivery. After resolving, Maestro does not send a new sentence to the contact. This prevents automated endpoints from replying to the farewell, reopening the conversation and creating a bot-to-bot loop. The team still sees the native resolve event and an audit note with a human-readable action and reason. - Seeing that note often on the same bot means the limit is tight for what you ask of it — or that its instructions are asking for too many steps per reply. Troubleshooting The bot replied but did not move the card / did not create the deal. Look for the internal note on the conversation. If it lists the action, the budget ran out first. Raise Actions per reply or simplify the bot's instructions. Replies got slower after I raised the limit. Expected: more actions, more time before writing. Go back to the default and raise it gradually. The bot says it "will check" and never comes back. It ran out of actions mid-way. The sentence is honest — it really did not finish. The internal note says what was missing. See also - Bot autonomy modes and human approval (HITL) - Maestro tools by module

Automatic conversation closing by the bot

Overview When the bot finishes helping someone, somebody has to state that the conversation is over. Otherwise it stays open in the queue, taking up room and distorting your reports. Close the conversation when the service ends is the bot setting that handles this. It has three values: - Leave the conversation as it is — the default. Nothing changes. - Mark as resolved — the conversation leaves the queue and counts as resolved. - Mark as pending (human triage) — the conversation leaves automatic handling and waits for a person to look at it. Why this changed Before, whoever wanted this behavior asked for it in the bot's prompt: "when you're done, resolve the conversation". It worked sometimes. The reason is honest: closing was one more action competing for the turn's action budget, and when the limit was reached the action was dropped silently — the bot answered nicely and the conversation stayed open, with no warning at all. Now the platform performs the closing, after the reply has already been delivered to the contact. It doesn't compete for the budget, doesn't depend on the artificial intelligence remembering, and doesn't get lost. Prerequisites - Be an administrator of the account. - A bot already created and connected to an inbox. - A process decision on what "the end" means in your operation: resolved or pending. Step by step 1. Go to Settings → Bots and open the bot you want to adjust. 2. Scroll to the Close the conversation when the service ends field (right above the Conversation & Context block). 3. Pick one of the three values. 4. Click Save. It takes effect from the bot's next reply. Nothing needs restarting, and conversations already open are untouched. Settings & options | Value | What happens | When to use it | |---|---|---| | Leave the conversation as it is (default) | The bot replies and doesn't touch the status. Someone closes it by hand. | When the team wants to review everything before calling it done, or when closing is already handled by an automation of yours. | | Mark as resolved | The conversation leaves the queue and shows up in reports as resolved. | Conversations the bot handles end to end on its own: questions, FAQ, status checks, confirmations. | | Mark as pending (human triage) | The conversation leaves automatic handling and waits for a person. | When the bot does the first part (qualifies, collects data) and someone always has the final word. | Resolved and pending are not the same thing — this is a process choice, not a technical detail. Resolved ends it: out of the queue and counted in resolution, CSAT and handling-time numbers. Pending does not end it: it takes the conversation off autopilot and puts it in the reviewer's queue. If you mark everything as resolved with nobody checking, your reports look great and your operation goes blind. Use cases - FAQ and high-volume questions. The bot answers "what are your hours", "where is my order", "how do I cancel" and nobody else is needed. Resolved keeps the queue clean. - Pre-service and qualification. The bot collects name, need and urgency, but the sales team decides the next step. Pending hands the case over ready for triage without it disappearing from anyone's view. - An operation under audit. New bot, prompt still being tuned, team wanting to read everything it did before trusting it. Leave it as it is until confidence grows. Tips, limits & best practices Three situations where the bot does NOT close, even when configured: 1. The value is "Leave the conversation as it is". It's the default — nobody who never touched it sees any change. 2. The turn delivered nothing to the contact. If the bot never sent a message, there is no completed service to close. Closing a conversation without having spoken to anyone would be worse than leaving it open. 3. The turn ended in a handoff to a human. If the bot just asked for a person, closing the conversation would be the worst possible outcome: whoever was called would find it closed. The handoff destination policy still rules that case — this setting only acts when the turn did not end in a handoff. Honest limit: there is no configurable delay. Closing happens right after the reply. You cannot ask for "close 10 minutes later, if the contact doesn't write again". If the bot closes too early, that is self-healing: as soon as the contact writes again, the conversation reopens on its own and the bot picks the service back up. Nobody is left without an answer because of an early close. Consequence of closing early: the conversation reopens, but the "resolved → reopened → resolved" cycle shows up in the reports. If you see many reopens on the same bot, the signal isn't that closing is broken — it's that this conversation doesn't end where you thought it did. Pending is usually the better choice in those cases. If you use satisfaction surveys (CSAT), ask for the rating together with the last reply, not after it. An already-closed conversation is not the best moment to ask for a score. Troubleshooting I set "Mark as resolved" and the conversation is still open. Check the three situations above, in this order: was the value saved? Did the bot actually send a message on that turn? Did the turn end in a handoff to a human? One of those three explains almost every case. The conversation closes too early, before the contact is done. That's expected when the conversation goes back and forth. It reopens on its own with the next message and the bot continues where it stopped — nothing is lost. If it bothers the team, switch to pending or back to leave it as it is. Resolution numbers jumped after I turned this on. Every automatic close counts. If nobody used to close conversations by hand, the jump is real and expected. Compare periods using the same criteria before drawing conclusions. I can't find the field in the settings. It appears in the bot configuration, for administrators. If you opened the screen through another path or don't have administrator permission, the field isn't available. See also - Actions per reply: how much the bot does before answering - Bot autonomy modes and human approval (HITL)

Where each Robô is used: the account's surfaces

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 - Knowledge base and ontology

AI usage: what your account spent, and where

Overview Every time the platform uses an AI model — the Robot replying to a customer, a dashboard being generated, the onboarding briefing, the quality judge, the copilot, a voice call — that costs money, measured at the moment of the call. The Brain's Usage tab gathers those costs and answers the question that comes up every time the invoice arrives: what did THIS account spend, and on what. The figure is not an estimate. It is the sum of the measurements taken on each call: how many calls, how many tokens went in, how many came out, how many were served from the provider's cache (billed at a discount), and what it cost. Prerequisites - The Brain module must be enabled on the account. - You must be an administrator. This is the only Brain read restricted to administrators, for a simple reason: invoice information is not support information. An agent reading the inbox does not need to read the bill. - The AI service must be reachable. If it is not, the screen shows an error — never a zero. Step by step 1. Open Brain in the sidebar. 2. Go to the Usage tab. 3. Pick the period in the top right: 7, 30 or 90 days. The window IS the question: changing the period reloads the numbers. 4. Read top to bottom: - the four cards summarise the whole period — cost, calls, tokens and cached tokens — and each one carries underneath the average that is usually the next question: cost per day, calls per day, tokens per call and how much of the prompt came from cache (that is the provider's discount: when the percentage drops, the bill rises without the volume moving); - the chart shows spend day by day, with the scale on the left, dates along the bottom, the peak day highlighted and, in the footer, how many days of the period actually had spend — a nearly flat line reading "3 of 90 days with spend" is information, not an empty chart; - the lists below break the same total down by surface, by model and by Robot, each row with its share of the total, its call count and its cost per call; - the Per conversation section lists the most expensive conversations of the period, each with a link that opens the conversation, its cost, how many turns it had and its cost per turn. 5. Use the filter bar at the top to cross the questions: surface, model, Robot and conversation. The filters combine, and they redo the read — they do not hide rows on screen, they change the query. Filtering by one Robot and watching the total drop is the confirmation that this Robot accounts for that share. Amounts below one cent are shown with the decimals they need (for example US$ 0.004933). A model call costs fractions of a cent: rounding to two decimals would print US$ 0.00, which reads as "nothing was measured". Per conversation Until now this screen answered "what did the account spend". Per conversation answers "what did THIS conversation cost" — the question that comes up when one conversation drags on, or when someone wants to know whether a particular case turned out expensive. A conversation's cost includes what it spent outside the reply turn: transcribing the audio the customer sent, the audio the Robot replied with, the voice call. Those used to land in a row that could not be linked back to the conversation that caused them. Sub-agents and delegation. When a Robot delegates to a sub-agent, the sub-agent's tokens are already counted on the caller's turn. The screen shows the delegation so you know it happened, but its cost is not added again — adding it would count the same tokens twice and inflate exactly the number this screen exists to make trustworthy. Unpriced surfaces Not everything that consumes AI has a price table. Audio transcription is billed per second, speech synthesis per character, image and video per unit — and the platform does not have the price table for those. So they show up counted and labelled, measured in their own unit ("3,412 characters synthesized"), and never as US$ 0.00. The distinction is the whole point: US$ 0.00 reads as "this was free". A surface labelled unpriced reads as "this consumed something, and the platform does not know what it cost" — which is the truth. The priced total remains a trustworthy total; it simply is not the whole invoice, and the screen says so instead of letting you add it up wrong. Settings & options There is nothing to configure here: the tab is read-only. What moves the numbers is usage — how many conversations the Robot handles, how many dashboards get generated, whether the quality judge is sampling turns, and which model each Robot uses. To change a Robot's model (and therefore its cost per call), use the Robots screen. To change who grades quality, use the Brain's surface assignment. Use cases - Closing the month. You get the provider's invoice and want to know how much of it is this account. - Finding where the money goes. Almost always the answer is "customer replies" — it is the surface that runs most often. When it is not, that is worth a look: a dashboard generated over and over, or a judge pointed at an expensive model, shows up immediately in the by-surface list. - Comparing Robots. The per-Robot breakdown shows which one consumes most, which usually reflects conversation volume rather than waste — but sometimes reflects an expensive model chosen without need. - Seeing the cache work. Cached tokens are billed at a discount. A high number there means the system prompt is stable and being reused; a sharp drop usually means something in the prompt changed. - Investigating an expensive conversation. The Per conversation section sorts by cost. Opening the most expensive one and checking its turn count separates two different causes: a long conversation (many cheap turns) and a heavy one (few expensive turns, usually a large model or a lot of context). - Finding the cost of voice. Filter by the audio surfaces to see how much transcription and synthesis the account consumed — in seconds and characters, since no dollar price exists for them. Tips, limits & best practices - Values are in US dollars. That is the currency the provider bills in and the measurement was taken in. Converting here would invent an exchange rate the platform never observed. - The by-model breakdown is partial, and the screen says so. Customer replies are measured without recording which model replied, so their cost lands in the total, in the by-surface list and in the daily chart, but not in the by-model list. When that happens, a line states how much of the total the list covers. Adding up only the by-model list and taking it for the whole bill is exactly the mistake that line exists to prevent. - No spend in the period is not an error. If the account genuinely did not use AI, the screen explains that. If the service is down, it shows an error with a retry button. The two situations are different and the screen never swaps one for the other. - The maximum window is 365 days. Longer periods are clamped, not refused. - A day with no spend shows as a day with no spend — not as a gap in the line. Troubleshooting The tab does not appear. The Brain module is disabled on the account, or you are not an administrator. An error shows instead of the numbers. The AI service did not answer. Nothing is rendered as zero on purpose: a made-up figure here would be worse than none. Use Try again; if it persists, it is one for whoever runs the installation. The total does not match the provider's invoice. Two common causes: the invoice covers the whole installation (every account) while this screen covers one account; and the price table used at measurement time may be out of date with the provider. Talk to whoever runs the installation. The by-model list adds up to less than the total. Expected, and the screen warns about it — see "Tips, limits & best practices" above. A surface shows calls but no dollar amount. That is deliberate: transcription, speech synthesis, image and video have no price table in the platform. Their measurement is in their own unit (seconds, characters, units). That is not the same as zero cost, and the label exists precisely so you do not confuse the two. The by-surface and by-conversation totals do not match exactly. A conversation only appears under "Per conversation" if its spend could be linked to it. Account work that belongs to no conversation — a generated dashboard, the onboarding briefing, the daily improvement cycle — counts toward the total and the surfaces, and correctly counts toward no conversation. See also - Analytics and generative dashboards - Advanced model settings

Which Robot handles each conversation

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 Chatwoot action node. Useful for flows that qualify the contact first and only then decide which Robot takes over. From the API 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. See also - Autonomy and human approval - Actions per reply and closing