BLOG
O Maia da Make ganhou revisão de planos antes de construir ou alterar cenários, memória de preferências e ajuda para corrigir erros a partir do histórico de execução. A atualização foi anunciada em 30 de outubro de 2026 e está disponível para usuários do Maia, segundo o comunicado oficial. A ferramenta continua em beta público, com condições diferentes para planos pagos e Free.
Para quem atende clientes ou mantém automações de pequenos negócios, a mudança mais útil é poder discutir módulos, conexões e hipóteses antes da construção. Isso cria um ponto de revisão do fluxo, mas não substitui testes nem transforma uma aprovação no chat em garantia de que o atendimento funcionará corretamente.
O que muda no planejamento com o Maia
A novidade amplia a forma de trabalhar com a assistente dentro do construtor de cenários. Além de pedir uma execução diretamente, é possível revisar a proposta primeiro. A atualização também reúne contexto por imagens, compartilhamento de respostas e preferências persistentes, conforme a lista de mudanças.
Em uma aplicação editorial para uma empresa de serviços, a equipe pode pedir um fluxo que receba uma solicitação, confira os campos e encaminhe para revisão. Antes de construir, o responsável compara o plano com o processo real: onde nasce o contato, quais dados são necessários e quem decide o próximo passo. Uma hipótese errada fica mais fácil de perceber nessa etapa do que depois de ativar vários módulos.
Como revisar o plano antes de construir
O caminho documentado é abrir o construtor de cenários, usar o seletor de modo no chat e escolher Plan mode, identificado como Plan first. Depois de descrever o objetivo, confira a proposta e a prévia: Reject rejeita, Revise pede ajustes e Accept and build autoriza a construção. Ao terminar, ainda é necessário salvar o cenário. O procedimento está na introdução oficial ao Maia.
Uma revisão útil não se resume a conferir se os aplicativos certos aparecem. Verifique também o que ocorre quando um campo está vazio, o contato já existe ou uma conexão falha. Esses critérios são decisões do seu processo: inclua-os no pedido e peça uma explicação quando a proposta não deixar o comportamento claro.
| Momento | O que conferir |
|---|---|
| Antes de aceitar o plano | Objetivo, módulos, conexões e hipóteses do fluxo. |
| Depois da construção | Campos, credenciais autorizadas e tratamento de exceções. |
| Antes de ativar | Teste controlado e resultado esperado de cada etapa. |
| Depois de corrigir um erro | Nova execução e conferência do histórico. |
O plano é especialmente interessante para quem contrata a implementação. Ele oferece um material para discutir o que será feito antes de entrar nos detalhes técnicos. Ainda cabe ao responsável validar se a proposta corresponde ao atendimento da empresa e se as conexões utilizadas estão autorizadas.
Corrigir um erro agora parte do histórico do cenário
A documentação mostra a opção Resolve error with Maia no registro de uma execução com erro. Ela abre o construtor com um pedido de ajuda; a assistente consulta a configuração e as execuções anteriores, explica o problema e altera o cenário para tentar resolvê-lo. Depois solicita um teste da correção. Essas ações consomem créditos, conforme o guia de histórico de cenários.
Para usar esse caminho, entre no cenário, abra a aba History, escolha a execução que falhou e localize Resolve error with Maia no topo do registro. O mesmo histórico permite abrir Details e examinar os dados de saída dos módulos. Isso ajuda a comparar a explicação da assistente com o que efetivamente aconteceu na execução.
Ao corrigir um fluxo de cadastro, por exemplo, confira se o erro desapareceu e se o registro resultante está correto. Um cenário terminar sem erro não prova que o cliente foi cadastrado no lugar certo ou que não houve duplicação. Registre o resultado esperado antes de testar e compare a saída com esse critério.
Memória ajuda com preferências, não substitui a configuração
O Maia pode lembrar aplicativos e contas preferidos, estilo de resposta e idioma. É importante diferenciar uma preferência de trabalho da configuração de um cenário. Se um projeto tem uma regra específica de encaminhamento, explique essa regra no contexto do próprio trabalho; não presuma que uma preferência geral descreve toda a lógica necessária.
Como prática de gestão, revise as preferências quando trocar de cliente, conta ou equipe. Uma escolha que fazia sentido em um projeto pode ser inadequada em outro. Para operações com dados de clientes, use exemplos fictícios ao desenhar o fluxo e confira os acessos antes de utilizar registros reais. Isso mantém a revisão centrada no processo que será automatizado.
Quem tem acesso e como funciona a cobrança
Nos planos pagos, o Maia está disponível em beta e o uso consome créditos do mesmo saldo utilizado pelos cenários. A documentação informa uma promoção temporária de 70 mensagens por 30 dias após a primeira interação; depois, as interações passam a consumir créditos. No Free, há teste de 30 dias a partir do cadastro, com 45 mensagens incluídas. As condições podem mudar durante o beta: confira a página de preços do Maia.
O custo por resposta varia conforme a complexidade e os tokens usados. Portanto, acesso em um plano pago não significa uso sem cobrança variável. O consumo por mensagem pode ser consultado no chat e na tabela Credit Usage. Não há, na fonte consultada, um valor fixo universal por cenário corrigido.
A mudança descrita ocorre dentro da Make; não é uma franquia de API de outro fornecedor. Se o cenário usar serviços externos, confira também as condições desses serviços e das conexões escolhidas. Não some assinatura, consumo da assistente e execução da automação como se fossem uma única cobrança invariável.
Como avaliar a atualização no seu negócio
A orientação oficial de boas práticas recomenda descrever o objetivo e os aplicativos, manter pedidos curtos e testar com Run once antes de ativar em produção. É mais fácil conferir um fluxo pequeno e ampliar depois do que aprovar uma automação longa sem conhecer seus resultados intermediários.
Para um pequeno negócio, comece por uma tarefa com entrada e saída claras. Para quem implementa, documente a proposta aprovada, os testes e o consumo observado. A atualização oferece recursos para planejar e investigar, mas a decisão de ativar continua dependendo da validação do processo. Não há promessa documentada de eliminar erros ou de reduzir o custo de toda automação.
