Seu primeiro agente de negócio está pronto para os colegas? Valide três tipos de entrega.
Preserve erros críticos, retrabalho e retestes antes de ampliar, reduzir ou redesenhar o piloto.
A demonstração gera um briefing de reunião bem apresentado. Um colega tenta com um documento faltando, e o agente completa a lacuna com uma decisão “confirmada”. A aparência está pronta; a entrega não está confiável.
A equipe pode começar sem um sistema complexo de notas: fixe uma tarefa de baixo risco e confira saídas com entradas completas, incompletas e conflitantes. São três tipos iniciais de caso, não uma comprovação estatística de confiabilidade.
Fixe uma entrega e seus critérios
Escolha um briefing interno a partir de materiais históricos autorizados, cópias anonimizadas e um resultado de referência já aceito. Não teste também CRM, atendimento e relatórios no mesmo piloto. Não autorize mensagens nem gravações em produção.
Os arquivos e a reunião abaixo são fictícios e ilustram a preparação. Não representam testes realizados ou ganhos medidos. No piloto real, use materiais que a equipe possa legitimamente utilizar.
Cartão v1: briefing interno de reunião
Entradas: arquivos nomeados, data, papéis dos participantes, modelo
Saída: brief.md e pendências na pasta desta execução
Obrigatório: data, fontes, decidido/pendente, perguntas da reunião
Proibido: inventar decisões, prometer datas externas,
enviar mensagens, alterar registros de produção
Falha crítica: fato sem fonte, conflito apagado, ação proibida
A supervisão define o aceite antes de ler a saída. Caso contrário, um texto agradável pode reduzir o rigor. A referência não exige frases idênticas; exige os mesmos fatos, evidências e tratamento das pendências.
Três casos com comportamentos diferentes
Crie um diretório de entradas para cada caso, sem respostas de outros testes. “Sempre gerar o documento” não é um critério comum adequado.
| Caso | Entradas | Comportamento esperado |
|---|---|---|
| Completo | Ata aceita, planilha e data concordam | Salvar briefing com fontes dos fatos relevantes |
| Incompleto | Falta só a data da reunião | Apontar a lacuna e perguntar; não adivinhar nem finalizar |
| Conflitante | Ata diz sexta; planilha diz data pendente | Mostrar as duas fontes e pedir uma decisão |
Não peça ao agente para adivinhar qual arquivo manda. Se não houver uma decisão aceita identificável, preservar a divergência é o comportamento certo. Uma parada justificada pode passar no caso incompleto.
Abra o arquivo, não apenas a mensagem “pronto”
Abra uma sessão para cada caso na aba Agent, com a mesma versão do cartão e os caminhos definidos. O workspace mostra ferramentas e artefatos; a declaração no chat não é o próprio resultado.
No Drive, confira datas, decisões, citações, pendências e ações proibidas. Se a falta de data exige interromper a finalização, revise o registro da lacuna; não force um briefing final apenas plausível.
pilot/
task-card-v1.md
cases/complete/ # manifesto e comportamento esperado
cases/missing/ # lacuna e ponto de parada
cases/conflict/ # fontes em desacordo e pergunta
results/v1/ # sessões, arquivos reais e julgamentos
results/v2/ # retestes; sem sobrescrever v1
decision.md # decisão humana e escopo permitido
Registre caso, versão do cartão/Skill, sessão, lista de entradas, caminho da saída, categoria do erro, correções humanas necessárias e revisor. Antes da execução, o campo de resultado fica “não executado”, não “aprovado”. Cronometre quando for necessário; não preencha economia de tempo sem medição.
Uma pessoa executando três casos gera três tentativas, não três usuários. Várias pessoas repetindo o mesmo caso não cobrem todo o negócio. Separe cobertura de entradas, número de pessoas e tentativas.
Falha crítica não desaparece na média
- Falha factual ou de limite: uma confirmação sem fonte, conflito transformado em decisão ou tentativa de ação proibida. Interrompa a expansão e reveja método e permissões.
- Entrega incompleta: havia informação, mas faltam perguntas da reunião ou caminho do artefato. Corrija e teste de novo; uma resposta adicional no chat não corrige silenciosamente o arquivo.
- Defeito de apresentação: fatos e limites passam, mas os títulos não seguem o modelo. Ajuste o formato e verifique se a alteração não introduziu erros de conteúdo.
Se o caso completo passa e o incompleto inventa uma data, o piloto falhou justamente na condição que pede cautela. Duas saídas bonitas não compensam esse problema.
Mude uma regra e preserve o ensaio anterior
Suponha que o agente finalize sem a data. Explicite a parada na v2 e registre a linha alterada. Repita o caso incompleto e o normal: a regra mais rígida não deve bloquear entradas completas autorizadas. Se mudar a escolha de fontes, teste novamente o conflito.
Essa é uma sequência sugerida, não um relato de falha ocorrida ou reparo confirmado. Preserve todas as tentativas, não só a melhor. Se continuar falhando, reduza a tarefa em vez de apenas alongar o prompt.
A pessoa responsável decide entre continuar um piloto limitado, com usuários, entradas e saídas definidos; reduzir o escopo, por exemplo para organizar apenas atas aceitas; ou redesenhar tarefa e evidências. Falhas críticas não resolvidas impedem expansão, por melhor que seja a apresentação.
Perguntas antes de passar aos colegas
Como avaliar sem uma resposta perfeita?
Use fatos verificáveis e uma lista de entrega: datas, fontes, pendências e promessas que não podem ser acrescentadas. A pessoa responsável julga a utilidade dentro desses limites. A referência calibra, não obriga cópia literal.
Três casos aprovados significam erro zero?
Não. Mostram apenas que aquelas tentativas atenderam aos critérios. Novas entradas, públicos ou tarefas de risco maior pedem outros casos e uma decisão separada. Não transforme porcentagens de uma amostra pequena em promessa de confiabilidade.
Qual a diferença para testar o acionamento do Skill?
O teste de acionamento verifica quando o método começa ou para. O aceite da entrega verifica também a sustentação do conteúdo, as correções e o escopo que pode continuar no piloto. Acionar corretamente não garante um documento aceitável.
Aceite uma tarefa histórica antes de agendar trabalho real
No Buda, organize cartão, materiais autorizados e anonimizados, três tipos de caso, resultados e decisão. Se precisar de um método inicial, pesquise e instale um Skill no Marketplace do Buda AI; inspecione passos e condições de parada antes de testar. Instalação não certifica resultados.
Skills definem como; Automations definem quando. Primeiro decida quais entregas a equipe aceita. Agenda e permissão para mensagens reais continuam sendo decisões separadas. Uma demonstração bem-sucedida não as toma por você.