A correção funcionou. O resto do atendimento, nem tanto.
Uma regra comercial mudou. A equipe percebeu que o agente ainda usava a versão antiga. Alguém abriu o prompt, trocou duas frases e publicou.
O caso que motivou a mudança passou. Só que uma exceção deixou de chamar humano, uma resposta antiga continuou no FAQ e o CRM recebeu o mesmo status para duas situações diferentes.
A edição levou dez minutos. Descobrir quais conversas usaram qual regra levou dois dias.
Mudar uma regra de agente em produção exige quatro coisas: versão, casos de teste, publicação gradual e caminho de volta. Sem isso, “ajuste rápido” é apenas incidente com agenda própria.
Resposta curta
Antes de alterar regra, fonte, prompt ou ferramenta:
- descreva qual comportamento precisa mudar;
- guarde a versão atual;
- escreva o antes e o depois em linguagem operacional;
- monte casos que devem mudar;
- acrescente casos vizinhos que devem continuar iguais;
- teste falha de fonte, ferramenta e handoff;
- publique para uma amostra pequena;
- acompanhe resultado, exceção e recontato;
- defina o sinal que interrompe a versão nova;
- mantenha uma forma real de voltar.
O registro de mudança em agente de IA organiza esse trabalho numa página copiável. Para um agente pequeno, uma planilha e duas versões de arquivo já resolvem bastante.
Primeiro descubra o que realmente mudou
“Atualizar o agente” é amplo demais. A mudança costuma morar em uma destas partes:
| Parte | Exemplo | Risco escondido |
|---|---|---|
| regra | novo prazo para cancelamento | exceção antiga deixa de ser reconhecida |
| fonte | política saiu do PDF e foi para sistema | agente consulta conteúdo desatualizado |
| prompt | resposta deve ser mais curta | confirmação importante desaparece |
| ferramenta | nova API de agenda | ação acontece, mas a resposta se perde |
| permissão | agente passa a remarcar | alteração de alto impacto fica sem aprovação |
| handoff | novo gatilho para humano | fila recebe mais casos sem capacidade |
| CRM | novo status ou campo | relatório mistura resultado antigo e novo |
Se a equipe não consegue apontar a parte alterada, ainda não consegue testar a mudança.
Escreva uma frase simples:
Quando o pedido estiver fora do prazo normal, o agente não confirma cancelamento. Ele explica o limite, registra o motivo e passa para a fila responsável com o pedido e a regra consultada.
Essa frase é melhor do que “melhorar tratamento de exceções”. Ela nomeia condição, ação, parada e saída.
Não teste só a frase nova
A documentação de evals da OpenAI trabalha com comportamento desejado, critérios de avaliação e dados de teste representativos. A ideia útil aqui não depende de fornecedor: uma mudança precisa ser comparada contra exemplos concretos.
Monte três grupos.
Casos que devem mudar
São as conversas que provaram a necessidade da alteração.
- política nova;
- exceção recém-aprovada;
- resposta com fonte errada;
- ferramenta que mudou de contrato;
- handoff que acontecia tarde demais.
Casos que devem continuar iguais
São os vizinhos que uma correção apressada costuma quebrar.
- pedido ainda dentro da regra antiga;
- cliente que só quer informação;
- operação em outro canal;
- produto ou região não afetados;
- conversa que já deveria ir para humano.
Casos que tentam quebrar a regra
São as situações ruins que a apresentação pula com certa disciplina.
- fonte ausente;
- dado contraditório;
- ferramenta lenta;
- ação executada com resposta perdida;
- cliente corrige o agente;
- pedido de humano;
- ação de alto impacto sem aprovação;
- fila de destino indisponível.
Se o teste cobre apenas o caso novo, você sabe que a mudança funciona numa conversa. Ainda não sabe o que ela fez com a operação.
Um pacote mínimo de oito testes
Abra o registro de mudança e preencha esta bateria:
| Teste | Resultado esperado |
|---|---|
| caso que motivou a mudança | usa a regra nova e deixa evidência |
| caso comum anterior | preserva o comportamento correto |
| exceção conhecida | para ou chama humano no ponto definido |
| fonte indisponível | não inventa regra nem usa memória como prova |
| ferramenta em timeout | não anuncia resultado nem repete ação incerta |
| pedido de humano | encerra a disputa e faz handoff com contexto |
| fila humana lotada | entra em modo menor sem prometer prazo falso |
| versão anterior restaurada | volta sem perder conversas em andamento |
Rode os testes com identificadores e resultados esperados. “Pareceu melhor” não permite comparar versões.
Versão precisa aparecer na evidência
Guardar o arquivo com nome novo ajuda. Não basta.
Para cada conversa relevante, preserve quando possível:
- identificador da conversa;
- versão do agente;
- versão da regra ou base;
- prompt ou configuração publicada;
- ferramentas chamadas;
- resposta e estado devolvidos;
- decisão de handoff;
- horário da publicação;
- pessoa que aprovou;
- resultado do QA.
Sem esse vínculo, a equipe encontra uma resposta errada e não sabe se aconteceu antes ou depois da correção. A discussão vira arqueologia de Slack, uma ciência que ocupa bastante gente e melhora poucos clientes.
Publicar para todo mundo não é o primeiro teste
Depois de passar no ambiente controlado, libere a menor amostra que ainda representa o trabalho real:
- uma intenção;
- uma fila;
- um turno;
- um canal;
- um grupo pequeno de conversas;
- uma porcentagem do volume.
Acompanhe pelo menos:
- resolução do caso alterado;
- erros nos casos vizinhos;
- handoff e espera humana;
- recontato pelo mesmo motivo;
- falha ou repetição de ferramenta;
- respostas sem fonte;
- reclamação ou correção do cliente.
O NIST AI RMF organiza gestão de risco em governar, mapear, medir e gerir. Para esta rotina, a tradução é direta: alguém aprova, o alcance está descrito, o comportamento é medido e existe uma ação quando o limite estoura.
Fluxo para mudar sem apostar a fila inteira
O caminho de volta vem antes da publicação
Rollback não é apenas “recolocar o prompt antigo”. Pergunte:
- a fonte antiga ainda existe?
- a ferramenta aceita a versão anterior?
- conversas em andamento continuam com qual regra?
- ações feitas pela versão nova podem ser localizadas?
- o CRM distingue os estados?
- a fila humana sabe que a mudança voltou?
- quem pode decidir sem convocar uma reunião inteira?
Uma frase operacional ajuda:
Se duas respostas sem fonte aparecerem na primeira amostra, retirar a versão 14, restaurar a 13, bloquear novas ações do tema e enviar as conversas afetadas para revisão de QA.
O plano de pausa e retomada aprofunda esse caminho para incidentes. O registro de mudança cuida do antes; o plano de pausa cuida do momento em que o limite foi ultrapassado.
A saída humana também muda
Uma regra nova pode aumentar handoff mesmo quando o agente está funcionando corretamente.
Se a política ficou mais restritiva, mais casos chegam para uma pessoa. Se o gatilho mudou, a fila recebe outro tipo de exceção. Se o resumo ganhou um campo novo, o sistema de destino precisa aceitar e mostrar esse campo.
Antes de ampliar, confirme:
- volume esperado de passagens;
- fila e dono;
- contexto entregue;
- prazo que a equipe consegue cumprir;
- mensagem para o cliente;
- critério de prioridade;
- retorno da causa para quem cuida da regra.
Mudar o agente e esquecer a fila humana é uma forma bastante eficiente de transferir o erro de lugar.
Uma planilha basta quando o escopo é pequeno
O caminho simples funciona quando:
- existe um agente ou fluxo estreito;
- poucas pessoas publicam mudanças;
- as versões cabem em arquivos ou configuração registrada;
- uma pessoa consegue revisar a primeira amostra;
- o volume permite localizar conversas manualmente;
- a versão anterior pode ser restaurada rápido;
- a fila humana consegue absorver exceções.
Use o template, guarde antes e depois, rode oito casos e acompanhe uma amostra. Não compre plataforma para compensar a ausência de uma regra escrita.
Onde o caminho manual quebra
A coordenação manual começa a falhar quando:
- várias versões atendem ao mesmo tempo;
- voz, WhatsApp, CRM e ferramentas mudam juntos;
- diferentes times alteram base, prompt e política;
- ninguém sabe qual conversa recebeu qual versão;
- QA não consegue comparar antes e depois;
- a publicação precisa ser gradual por fila ou público;
- uma reversão exige localizar ações já executadas;
- o mesmo erro pode se espalhar em minutos;
- fila humana e modo degradado precisam entrar automaticamente.
Aí o trabalho deixa de ser edição de prompt. Vira operação de mudança: versão, avaliação, autorização, publicação, evidência, pausa e reversão.
É nesse cenário que uma camada de gestão de agentes em produção pode fazer sentido. Antes disso, resolva o básico com o registro de mudança e uma primeira amostra que alguém realmente acompanha.
O teste desta semana
Escolha a última alteração feita em um agente.
Reconstrua o antes e o depois. Separe três conversas que deveriam mudar, três que deveriam continuar iguais e duas que deveriam parar ou ir para humano. Ligue cada resultado a uma versão. Depois simule o sinal de volta.
Se a equipe não consegue dizer qual versão respondeu, ainda não terminou de publicar.
Vídeo
Eu não encontrei um vídeo em português que eu usaria como resposta principal para esta rotina. Há tutoriais de prompt, eval e deploy. O que falta é mostrar uma regra operacional mudando, um caso vizinho quebrando, a publicação limitada e a volta para a versão anterior com conversas reais no meio.
Se bastante gente pedir, este assunto entra na fila de gravação. Não é promessa.