Como construir ferramentas confiáveis para agentes de IA

O problema central: agentes que não terminam o trabalho

Ivan Burazin, cofundador e CEO da Daytona, aponta duas frustrações com agentes de IA que usa no dia a dia: os agentes tendem a agir como se fossem ele - inclusive diante da sugestão de dar acesso à conta bancária sob suas credenciais - e eles frequentemente falham em acessar as ferramentas de que precisam. Segundo Burazin, essas falhas de acesso causaram mais problemas em sua experiência do que o próprio modelo. A Daytona fornece sandboxes para execução de código, e a previsão dele é que agentes se tornem os usuários dominantes de ferramentas digitais - o que, na sua definição, inclui no papel de engenheiro de IA quem constrói software para agentes usarem.

A pergunta prática que ele sugere investigar: um agente consegue completar uma tarefa real de cliente pelo seu software, dentro da autoridade e do orçamento de tempo que recebeu?

Identidade e acesso delegado

Traduzir a frustração com identidade em requisito de engenharia significa especificar o que o sistema permitirá, independentemente de como o modelo se descreve. Há várias formas de representar a relação entre usuário e agente: acesso delegado do usuário, identidade de serviço ou combinações - o padrão de troca de tokens OAuth, por exemplo, permite distinguir o sujeito de um token do ator que executa trabalho delegado. Dar ao agente uma conta separada não elimina as decisões de autorização: um usuário pode autorizar um relatório de um projeto sem autorizar exportações do restante da organização, e a integração precisa preservar esse limite mesmo que o modelo peça mais dados.

O agent harness - o runtime que coordena chamadas do modelo e execução de ferramentas - pode carregar contexto e filtrar chamadas, mas os serviços também precisam aplicar autorização. Código de integração confiável pode guardar credenciais e expor apenas operações permitidas, sem colocar segredos no contexto do modelo. Perguntas concretas incluem: qual aplicação age para qual usuário, a quais recursos pode acessar, e como o acesso expira ou é revogado - com registros de auditoria para reconstruir a relação depois.

Essas decisões também pertencem à especificação do produto: se um relatório exige permissão adicional, a equipe precisa decidir se o agente pede aprovação, devolve um resultado parcial rotulado ou para - cada escolha cria uma promessa diferente ao cliente.

Falhas de ferramentas e repetições seguras

Uma falha na fronteira entre plano do agente e o restante do sistema pode ter quatro origens: o modelo escolhe a ferramenta ou argumentos errados, a autorização nega o pedido, o serviço falha no meio da chamada, ou a chamada succeeds e o modelo não sabe o que fazer depois - cada caso pede investigação própria.

O texto ilustra com um agente que solicita a exportação de um dataset e recebe um timeout: o serviço pode ter rejeitado o pedido, iniciado a exportação ou até terminado antes da conexão cair. Repetir a exportação não esclarece qual cenário ocorreu. O contrato de recuperação deve permitir consultar o status da operação e definir quando a repetição é segura. Se o backend suporta requisições idempotentes, o chamador pode reutilizar a mesma chave e parâmetros sob as regras documentadas do serviço - mas o servidor precisa impor o tratamento de duplicatas; adicionar um identificador ao pedido não cria essa garantia por si só, e a janela de validade da chave também importa. Quando o resultado permanece desconhecido, é preciso um caminho definido de reconciliação ou escalonamento.

O que merece testes adicionais com LLMs é como o modelo seleciona a operação e interpreta as evidências retornadas. O trabalho da Anthropic sobre design de ferramentas destaca descrições explícitas, conteúdo de resposta relevante e erros acionáveis. A ferramenta deveria distinguir pedido aceito de exportação concluída, expor verificação do job, explicar se há suporte a repetição e diferenciar falha de permissão de indisponibilidade temporária.

Confiabilidade em execuções repetidas

As falhas que mais surpreendem Burazin ocorrem em tarefas que o agente já completou antes: em testes da Daytona envolvendo concorrência e timing, ele cita nove sucessos seguidos de uma falha - um exemplo de frustração, sem estabelecer taxa de falha medida. Um sucesso anterior prova que o sistema conseguiu completar a tarefa naquele momento; na tentativa seguinte, o modelo pode escolher outra sequência de ações, e o ambiente pode ter mudado (token vencido, dataset diferente, serviço sob carga).

Para investigar, comece com uma tarefa reproduzível e uma definição clara de sucesso: o arquivo esperado contém os dados pedidos, é acessível ao usuário certo e chega dentro do orçamento de tempo - e a avaliação também deve checar acessos não autorizados e operações duplicadas indesejadas. Para comparar implementações de ferramentas, mantenha modelo, instruções, harness e orçamentos fixos, registre as versões e rode cada variante repetidamente de estados iniciais equivalentes, com ambiente resetado entre tentativas; estado residual pode ajudar tentativas posteriores, alerta a orientação da Anthropic sobre avaliações de agentes. Teste também a recuperação deliberadamente, com cenários como resposta perdida após aceite do servidor ou mudança de permissão no meio da tarefa.

A avaliação precisa distinguir completar a tarefa do cliente de seguir o fluxo corretamente: um teste pode passar porque o agente interrompeu uma exportação não autorizada, mesmo sem produzir o relatório. Aprovação necessária deve ser rastreada separadamente de um resgate humano inesperado. Na decisão de produto, considere tempo e custo junto com a conclusão: menos repetições podem significar menos trabalho desperdiçado - ou um agente que desiste mais cedo. Reporte o número de tentativas e as circunstâncias das falhas antes de tratar uma pequena variação na média como melhoria.

O papel do engenheiro que constrói ferramentas para agentes

Burazin enfatiza engenheiros que constroem ferramentas para agentes, porque o trabalho exige entender como modelos usam as interfaces que recebem. Sua previsão de que agentes se tornarão os usuários dominantes de software permanece uma previsão - mas testar um produto existente com um agente não exige aceitar sua escala completa. Uma equipe que mantém um serviço de exportação pode começar com uma tarefa que clientes já delegam, testar se estados de operação mais claros reduzem jobs abandonados ou se um caminho de recuperação documentado reduz intervenção humana desnecessária.

Há um tradeoff: respostas maiores explicam mais, mas consomem contexto adicional e podem obscurecer o campo de que o agente precisa; uma operação estreita simplifica uma tarefa e dificulta outros fluxos. Melhorias precisam se justificar pelas tarefas que o produto deve apoiar.

Burazin avalia que o erro estratégico da Daytona foi hesitar em investir nessa área: "também nos protegemos demais e, por isso, fomos mais lentos do que deveríamos". No fim, as melhorias precisam beneficiar quem entregou a tarefa esperando se ocupar de outra coisa - se o agente precisa de alguém ao teclado explicando cada resultado ambíguo, o produto deixou uma parte substancial do trabalho com o cliente.