A demonstração termina bem. O agente encontra o pedido, consulta o andamento e prepara uma resposta que a equipe enviaria sem dificuldade. Então alguém pergunta: “E se a conexão cair logo depois de ele alterar o pedido?”. Por alguns segundos, a conversa deixa de girar em torno do modelo.
Essa pergunta marca uma fronteira mais útil do que o encerramento de uma prova de conceito. Em produção haverá solicitações incompletas, ferramentas indisponíveis e pessoas pedindo coisas que ninguém previu. O CTO precisa entender como o serviço se comportará nessas condições e quem poderá assumir o caso. O projeto está pronto para avançar quando a equipe consegue explicar esse percurso com a mesma clareza com que apresenta a demonstração bem-sucedida.
Qual trabalho você está entregando ao agente?
“Resolver dúvidas de clientes” é um escopo amplo demais. Defina entradas aceitas, fontes disponíveis, ações permitidas e condições de encerramento. Um exemplo mais concreto seria preparar uma resposta sobre um pedido usando apenas registros acessíveis ao usuário solicitante. Acrescente exclusões claras. O agente pode informar sem ter autorização para alterar preços, modificar entregas ou prometer compensações. Esses limites devem aparecer nas ferramentas e permissões, além das instruções.
Determine também quando ele deve parar. Identificador inexistente, dados incompatíveis ou pedido fora do escopo exigem uma resposta controlada. Encaminhar corretamente uma exceção faz parte do serviço; não é apenas uma falha a esconder.
Os casos difíceis também precisam entrar no teste
Reúna exemplos da operação com proteção ou anonimização adequadas. Inclua casos frequentes e situações delicadas: informações incompletas, documentos contraditórios, usuários sem acesso e indisponibilidade temporária de ferramentas. Para cada caso, descreva o resultado esperado e as ações proibidas. Verifique tanto o texto final quanto as alterações feitas nos sistemas. Uma resposta educada não compensa uma atualização incorreta.
As avaliações de agentes discutidas pela Anthropic distinguem tarefas, tentativas e critérios de avaliação. Uma consequência prática é repetir os testes sujeitos a variação, em vez de considerar uma execução favorável como prova suficiente. Reserve exemplos que não sejam usados nos ajustes cotidianos. Caso contrário, o sistema pode melhorar nos testes conhecidos e continuar falhando diante de novas solicitações. Analise erros graves separadamente, sem escondê-los em uma média geral.
Propor uma ação não dá autorização para executá-la
O modelo pode propor uma ação; o sistema ao redor precisa decidir se ela é permitida. Essa fronteira é essencial quando as ferramentas conseguem alterar dados ou enviar comunicações. Utilize identidades de serviço com permissões limitadas. Valide parâmetros conforme as regras de negócio e confira o acesso ao recurso solicitado. Evite ferramentas genéricas que aceitem instruções arbitrárias ou permitam operar sobre qualquer registro.
O conteúdo recuperado de documentos e mensagens deve ser tratado como dado, não como instrução do sistema. Se um arquivo pedir para ignorar políticas ou transmitir informações a outro destino, isso não pode ampliar a autoridade do agente. A aprovação humana também precisa ter significado preciso. Aprovar uma proposta não autoriza todas as suas versões posteriores. Mudanças de destinatário, valor ou condições podem exigir uma nova decisão.
A conexão caiu. O que aconteceu de fato?
Suponha que o agente envie uma alteração a um sistema externo e perca a conexão antes de receber a confirmação. Para ele, houve um erro; no destino, a mudança talvez já tenha sido feita. Acionar uma nova tentativa sem conferir pode repetir uma operação que o cliente solicitou apenas uma vez.
Para sair dessa incerteza, o processo precisa manter um identificador estável da operação e estados reconhecíveis: recebido, validado, aguardando aprovação, executado e encerrado. Guardar uma conversa longa não basta. Quem retomar o caso precisa distinguir o que foi tentado do que está confirmado, consultando o destino antes de repetir uma ação incerta. Quando não houver uma verificação confiável, essa dúvida terá de ser tratada por uma pessoa.
As aprovações também podem perder a validade. Uma proposta autorizada ontem pode ter outro valor ou destinatário hoje. Vincular a aprovação à proposta exata e definir suas condições de validade evita que a recuperação execute uma decisão antiga em um caso que mudou. É um detalhe pouco chamativo na apresentação, mas decisivo para continuar o trabalho com segurança.
Ampliar a autonomia conforme os resultados
Considere um agente hipotético que prepara respostas de suporte. Na primeira etapa, ele trabalha com casos históricos. Na segunda, sugere respostas para solicitações reais, mas uma pessoa revisa todas antes do envio. Uma etapa posterior pode permitir respostas automáticas apenas para categorias delimitadas e verificáveis. As demais continuam supervisionadas. A passagem entre etapas depende dos resultados, não apenas de uma data comercial.
Mantenha um mecanismo para interromper novas ações e uma fila clara para continuar manualmente. Voltar à versão anterior do software não recolhe mensagens enviadas nem desfaz alterações externas. A recuperação precisa abranger os efeitos do sistema. Comece com um grupo limitado de usuários ou casos. Registre a justificativa para cada ampliação e as condições que fariam a operação voltar a uma supervisão mais próxima.
Acompanhar o cliente até o encerramento
Uma execução tecnicamente bem-sucedida pode terminar sem que o cliente receba uma solução. O monitoramento deve acompanhar o percurso completo, da entrada até a confirmação de encerramento. Registre identificador do caso, versão das instruções, modelo utilizado, chamadas de ferramentas, validações e resultado. Evite guardar dados sensíveis sem necessidade. Determine quem pode acessar esses registros e por quanto tempo serão mantidos.
Combine qualidade, tempo de resposta, erros, revisão humana e custo por caso concluído. Acompanhe também a idade das solicitações pendentes. Uma média favorável pode esconder casos abandonados há vários dias. Cada alerta deve ter um responsável e uma ação esperada. Mostrar uma fila crescente em um painel não resolve o problema se ninguém souber quando intervir.
Antes do lançamento, alguém precisa saber como agir se o fornecedor do modelo ficar indisponível, uma ferramenta devolver dados incompletos ou o consumo aumentar. Documente procedimentos curtos e teste sua execução. Defina quem pode parar o serviço, quais situações exigem escalonamento e como comunicar problemas aos usuários. Estabeleça limites de gasto e duração por execução para evitar ciclos caros.
A revisão humana também consome capacidade. Se o piloto encaminha metade dos casos, estime esse trabalho. O agente não aumenta a capacidade total quando transfere mais esforço do que consegue eliminar.
Antes de ampliar o acesso, reúna os responsáveis pelo resultado de negócio e pela operação técnica. Percorra casos concretos: o que o agente pode fazer, como se saiu nas avaliações, quais permissões possui e como uma interrupção seria atendida. Registre as limitações conhecidas e os sinais que exigiriam reduzir a autonomia. Durante um incidente, essas decisões ajudam mais do que uma afirmação genérica de que os testes foram bem.
Após o lançamento, falhas reais podem entrar no conjunto de avaliação, e mudanças de modelo, ferramenta ou política precisam ser verificadas novamente. Ao conversar com a DigitalCube sobre uma prova de conceito, leve também o caso que ainda preocupa a equipe. A pergunta sobre a queda de conexão merece uma resposta antes que um cliente precise fazê-la.