Transforme correções da equipe em regras do agente: método de feedback

Um agente de IA confiável melhora quando as correções feitas pela equipe são registradas, revisadas e transformadas em regras escritas ou entradas de memória que o agente lê na próxima vez. O método tem quatro etapas: registrar cada correção com o seu contexto, classificá-la pela causa, promover apenas mudanças aprovadas e testar cada mudança contra casos anteriores antes de ela entrar em operação. Feito assim, uma correção melhora todas as execuções futuras, em vez de ser refeita pela próxima pessoa que perceber o mesmo erro.

Principais pontos

• Uma correção só é útil depois de registrada com a entrada, a saída errada e a saída corrigida.
• Classifique cada correção pela causa antes de mudar qualquer coisa, porque uma informação faltando, uma regra ruim e um resultado de ferramenta com defeito exigem correções diferentes.
• Promova uma correção a regra ou entrada de memória somente depois que um dono nomeado aprovar.
• Teste cada mudança promovida em um conjunto fixo de casos anteriores antes de ela chegar ao trabalho real.
• Mantenha um registro de mudanças para que qualquer pessoa veja o que o agente aprendeu, quando e quem aprovou.

Por que as correções da equipe raramente melhoram o agente

A maioria das correções acontece no calor do momento. Um revisor edita um rascunho, um membro da equipe responde de outro jeito a um cliente, ou alguém cola uma observação em uma janela de chat para explicar o que deu errado. A correção funciona para aquela tarefa, depois fica perdida em uma caixa de entrada, em uma conversa ou na memória de quem a fez. Na semana seguinte, outro colega encontra o mesmo erro, corrige de novo, e o agente não aprende nada que dure.

Há um segundo problema. Uma correção não é automaticamente uma regra. Algumas descrevem uma exceção pontual, como um cliente a quem um gerente prometeu uma data de entrega. Outras refletem uma política que já mudou. Algumas contradizem uma correção feita por outra pessoa no mês anterior. Se toda correção for escrita diretamente nas instruções do agente, o ciclo não melhora o agente. Ele ensina ao agente o que quer que a pessoa mais recente tenha dito.

Referências de governança, como o NIST AI Risk Management Framework, apontam na mesma direção: o risco é gerenciado ao longo de toda a vida de um sistema, não apenas no lançamento. Um ciclo de correções é um lugar prático onde essa ideia vira um hábito diário de operação.

Registre cada correção em um formato que possa ser reutilizado

Uma correção precisa de contexto suficiente para que alguém que não estava na conversa consiga avaliá-la depois. Um registro curto costuma bastar. Ele deve conter:

• A tarefa e a entrada que o agente recebeu, com dados pessoais e confidenciais removidos ou substituídos por um marcador.
• A saída que o agente produziu, citada exatamente, e não parafraseada.
• A saída corrigida, ou a frase ou valor específico que mudou.
• O motivo da mudança, escrito em uma frase por quem fez a correção.
• O nome de quem fez a correção e a data em que ela foi registrada.

Citar a saída exata importa. Uma paráfrase esconde o detalhe que causou o erro, e é exatamente esse detalhe que a regra precisa tratar. Se a sua equipe já mantém registros de execução, esses campos devem se encaixar neles. Para saber quais sinais vale guardar, veja observabilidade de agentes de IA: o que registrar?

Classifique cada correção pela causa antes de mudar qualquer coisa

Muitas correções são aplicadas no lugar errado. Um membro da equipe altera um preço na resposta, e alguém edita o prompt, quando o problema real era que o agente leu uma tabela de preços desatualizada. Faça primeiro uma pergunta: que tipo de falha produziu este erro? Use este guia:

• Se o agente não tinha uma informação, como uma política vigente, o horário de funcionamento de uma filial ou a peça de reposição de um produto, a correção é uma entrada de memória com fonte, dono e data da última verificação.
• Se o agente seguiu uma regra errada, incompleta ou ambígua, a correção é uma mudança na regra.
• Se uma ferramenta devolveu dados desatualizados, parciais ou malformados, ou se a chamada expirou, a correção pertence à integração ou à definição da ferramenta, não ao prompt.
• Se o caso exigia um julgamento que a empresa não quer automatizar, a correção é um limite de aprovação que encaminha esse tipo de caso para uma pessoa.
• Se a correção foi uma exceção pontual, registre-a como nota de exceção e não a generalize.

Use as mesmas categorias em toda a equipe. Um vocabulário comum para falhas torna as tendências visíveis e impede que cada correção pareça um evento único. Para um conjunto mais completo de categorias, veja modos de falha de agentes de IA.

Como promover uma correção a uma regra revisada?

A promoção é uma etapa deliberada, com um dono nomeado. A sequência abaixo funciona para a maioria dos agentes de negócio e pode rodar semanalmente sem atrapalhar o trabalho do dia a dia. Aplique-a a todas as mudanças candidatas:

• Agrupe, a cada semana, as correções registradas pela regra, informação ou ferramenta que elas afetam.
• Espere surgir um padrão antes de redigir uma regra. Duas ou mais correções independentes apontando para a mesma lacuna são um limite razoável para problemas recorrentes. Um erro isolado que causou dano real vai para revisão imediatamente.
• Redija a mudança em linguagem simples: a situação, o comportamento esperado, a exceção e a fonte de qualquer informação.
• Peça que o responsável pelo processo aprove, ajuste ou recuse o rascunho. O responsável é quem responde pelo resultado, nem sempre quem percebeu o erro.
• Reproduza o caso original e um conjunto de casos anteriores parecidos contra a mudança candidata, usando um conjunto de testes fixo e não a lembrança do que funcionava antes. Como montar esse conjunto é tratado em conjunto de avaliação para agente de IA: tarefas de referência versionadas.
• Publique a mudança com uma nota de versão e depois verifique as próximas saídas amostradas para detectar regressões nas áreas afetadas.

No modelo gerenciado da Be Human, esse ciclo faz parte da operação e não é uma tarefa paralela. A primeira contratação define o papel do agente, a memória que ele pode ler e escrever e o limite de aprovação para cada categoria de mudança. Depois, a operação gerenciada revisa as correções em uma cadência definida, mantém o registro de mudanças e os conjuntos de teste atualizados, e encaminha ao responsável nomeado as alterações que afetam permissões ou compromissos com clientes antes da publicação. O cliente continua no controle do que o agente pode aprender.

Escreva regras que o agente consiga seguir e o revisor consiga checar

Uma regra que diz "seja profissional e preciso" não pode ser testada, e o agente não consegue segui-la de forma confiável. Escreva regras como condições e ações. Nomeie a situação, o comportamento exigido, o que fazer quando a situação não se encaixa e onde está a informação que sustenta a regra. Por exemplo:

Quando um cliente pedir reembolso de um pedido feito fora da janela de devolução indicada na entrada de memória da política, não confirme o reembolso. Abra um encaminhamento para o responsável de suporte com o número do pedido, a data da compra e a mensagem do cliente.

Uma regra assim pode ser revisada em segundos. O revisor vê o que a aciona, o que o agente deve fazer e o que contaria como violação. Evite acumular regras conflitantes. Quando uma regra nova tocar em uma existente, leia as duas juntas e diga qual tem precedência. Mantenha credenciais, dados pessoais e números confidenciais fora do texto das regras. Regras descrevem comportamento, e os fatos ficam na memória, com suas fontes.

Mantenha as entradas de memória com fonte, dono e revisão programada

As entradas de memória registram fatos sobre a empresa: política vigente, detalhes de produtos, responsabilidades da equipe e textos aprovados. Cada entrada deve trazer três coisas: a fonte de onde veio, a pessoa que a responde e a data em que foi verificada pela última vez. Sem dono e sem data de verificação, uma entrada de memória vira silenciosamente um boato que o agente repete com confiança.

Revise a memória em um calendário, e não apenas depois de erros. Entradas sobre preços, horários e políticas envelhecem mais depressa. Remova uma entrada quando sua fonte for desativada, e não mantenha a informação antiga ao lado da nova, porque o agente pode ler as duas e misturá-las. Informações desatualizadas estão entre os modos de falha mais lentos de perceber, por isso as verificações programadas importam. Para saber como observar o desgaste gradual, veja degradação de qualidade em agentes de IA ao longo do tempo.

As orientações de engenharia de contexto da Anthropic tratam o contexto de um agente como um recurso limitado, que deve conter apenas o que é útil para a tarefa atual. A mesma disciplina vale para a memória. Um conjunto menor de entradas atuais e bem documentadas é mais fácil de confiar e de revisar do que um arquivo longo de correções antigas que ninguém conferiu.

Cenário ilustrativo: corrigindo um agente de follow-up de orçamentos

Cenário ilustrativo: uma pequena distribuidora usa um agente para redigir e-mails de acompanhamento depois de orçamentos de venda. Uma coordenadora comercial percebe que um rascunho oferece um desconto que já havia sido retirado. Ela corrige o rascunho e registra o caso com o e-mail citado, a linha corrigida e o motivo: o desconto não é mais oferecido.

A equipe classifica o caso primeiro. O agente não tinha uma informação atual, então a correção é uma entrada de memória, e não uma edição de prompt. O responsável por operações comerciais, dono da comunicação de preços, aprova uma entrada de memória informando que o desconto foi retirado. A entrada cita o documento vigente de política de preços e traz a data da verificação. Antes de publicar, a equipe reproduz vários follow-ups anteriores que mencionavam o desconto. Os rascunhos corrigidos deixam o desconto de fora, e um rascunho que pede uma exceção é encaminhado para uma pessoa. A mudança é registrada com sua versão e data.

Na semana seguinte, os follow-ups amostrados são verificados quanto ao mesmo erro, e nenhum aparece. A correção da coordenadora está encerrada. A lição não é sobre um desconto específico. A correção foi resolvida no lugar onde a informação vive, de modo que a próxima pessoa que abrir um rascunho não precise corrigir o mesmo problema de novo.

Se você não tem certeza de qual correção recente da sua equipe deve iniciar esse ciclo, faça o diagnóstico gratuito de IA da Be Human para identificar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Quantas correções devem disparar uma nova regra? Não existe um número universal. Duas ou mais correções independentes apontando para a mesma lacuna são um ponto de partida razoável para problemas recorrentes, enquanto um erro isolado que causou dano real deve ir para revisão imediatamente. Avalie o padrão e suas consequências, e não a quantidade de reclamações.

Quem deve aprovar mudanças nas regras de um agente? O responsável pelo processo que o agente apoia deve aprovar, como o líder comercial para comunicações de orçamento ou o líder de suporte para reembolsos. Essa pessoa responde pelo resultado, então a aprovação não deve ficar com quem apenas percebeu o erro. Mudanças que afetam permissões, acesso a dados ou compromissos com clientes também precisam de revisão de quem governa o sistema.

Toda correção deve ir para a memória do agente? Não. A memória serve para fatos sobre a empresa que continuam válidos em tarefas diferentes. Exceções pontuais, preferências pessoais de um único funcionário e opiniões sobre tom devem ser registradas, mas não armazenadas como memória. Cada entrada de memória que permanecer precisa de fonte, dono e data de revisão.

Como saber se uma mudança de regra melhorou as coisas? Reproduza o caso original que falhou e um conjunto fixo de casos anteriores parecidos antes de publicar e, depois, verifique as saídas reais amostradas na área afetada. Se a mudança corrige o caso mas quebra um comportamento sem relação, reverta e revise. Um registro de mudanças permite ligar uma queda posterior de qualidade à alteração que a causou.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.