Ferramenta demais também atrapalha: quando o Agente começa a escolher a ação errada

Adicionar novas capacidades a um Agente de IA é tentador. Primeiro ele consulta informações. Depois ganha acesso ao CRM. Em seguida, consegue verificar agenda, criar compromissos, gerar propostas, consultar pagamentos, buscar arquivos, atualizar cadastros e acionar outros sistemas.

Individualmente, cada integração parece tornar o Agente mais capaz. O problema aparece quando todas essas capacidades começam a competir entre si.

Em determinado momento, a dificuldade deixa de ser simplesmente “o Agente consegue executar essa ação?” e passa a ser “o Agente consegue identificar corretamente qual ação deve executar?”.

Um Agente pode ter todas as ferramentas necessárias para resolver uma solicitação e, ainda assim, escolher a ferramenta errada, usar a ferramenta certa com parâmetros incorretos ou fazer várias chamadas desnecessárias antes de chegar ao resultado.

Nesse cenário, adicionar mais uma integração pode piorar a operação em vez de melhorá-la.

O Agente não enxerga ferramentas como um software tradicional

Em um sistema convencional, o programador determina explicitamente qual função será chamada.

Se determinado botão executa `create_payment_link()`, não existe uma decisão sendo tomada naquele momento. O caminho já foi definido no código.

Um Agente funciona de outra maneira.

Ele recebe uma solicitação, interpreta o que precisa ser feito e decide se alguma das ferramentas disponíveis pode ajudá-lo. Na Claude Platform, por exemplo, a documentação da Anthropic explica que Claude decide quando chamar uma ferramenta considerando a solicitação do usuário e a descrição da própria ferramenta.

Isso transforma a definição da ferramenta em parte do ambiente de decisão do Agente.

Se você ainda está separando uma IA que apenas conversa de um sistema capaz de agir, vale entender primeiro por que um Agente IA precisa de ferramentas para resolver problemas de verdade. O passo seguinte é perceber que disponibilizar ferramentas não basta. Elas também precisam ser compreensíveis para o modelo.

Imagine um Agente comercial com acesso a:

• `consultar_cliente`
• `consultar_crm`
• `buscar_oportunidade`
• `atualizar_lead`
• `gerar_proposta`
• `consultar_proposta`
• `gerar_link_pagamento`
• `consultar_pagamento`
• `verificar_agenda`
• `criar_agendamento`
• `consultar_arquivos`
• `buscar_material`

Para quem conhece a arquitetura interna, a diferença entre essas funções pode parecer evidente.

Para o modelo, essas fronteiras precisam estar representadas nos nomes, descrições, parâmetros e resultados.

Se `consultar_cliente`, `consultar_crm` e `buscar_oportunidade` retornarem informações parcialmente semelhantes, o Agente precisa descobrir não apenas que pode consultar dados. Ele precisa entender qual fonte representa o dado correto para aquela situação.

Quanto mais ferramentas semelhantes entram no catálogo, maior fica o espaço de decisão.

Mais capacidades não significam necessariamente melhores resultados

A Anthropic chama atenção explicitamente para esse problema em seu material sobre como desenhar ferramentas para Agentes: mais ferramentas nem sempre produzem resultados melhores.

Um erro comum é simplesmente transformar cada endpoint de uma API em uma ferramenta disponível para o modelo.

Se uma API possui vinte endpoints, isso não significa que um Agente precise enxergar vinte ferramentas.

A arquitetura técnica do sistema e a interface apresentada ao Agente não precisam ser iguais.

Considere um pedido simples:

“Marca uma reunião com o João para semana que vem.”

Internamente, talvez seja necessário:

1. localizar João;

2. identificar seus dados de contato;

3. consultar disponibilidade;

4. comparar horários;

5. criar o evento;

6. adicionar os participantes.

É possível expor cada etapa como uma ferramenta independente.

Mas também é possível oferecer ao Agente uma capacidade de nível mais alto, como `agendar_reuniao`, e executar parte dessa coordenação internamente.

A Anthropic usa um exemplo semelhante ao recomendar a consolidação de operações relacionadas. Em vez de expor ferramentas separadas para listar usuários, listar eventos e criar um evento, pode fazer mais sentido oferecer uma ferramenta orientada ao objetivo de agendar.

O mesmo raciocínio pode ser aplicado a outras operações.

Em vez de:

`buscar_cliente`

`listar_transacoes`

`listar_anotacoes`

uma ferramenta como:

`consultar_contexto_cliente`

pode reunir as informações necessárias para aquela decisão.

Isso reduz a quantidade de etapas intermediárias que o modelo precisa coordenar.

A pergunta deixa de ser “quantas coisas nosso Agente consegue fazer?” e passa a ser “as ferramentas disponíveis representam as decisões que o Agente realmente precisa tomar?”.

O problema fica pior quando as ferramentas se parecem

Quantidade importa, mas a sobreposição pode ser ainda mais problemática.

Duas ferramentas muito diferentes são relativamente fáceis de distinguir.

`verificar_agenda` e `gerar_link_pagamento`, por exemplo, representam intenções bastante distintas.

Agora compare:

`buscar_cliente`

`consultar_cliente`

`buscar_lead`

`consultar_lead`

`consultar_crm`

Mesmo que cada uma possua uma finalidade tecnicamente diferente, o Agente precisa entender essas fronteiras.

A Anthropic relata que ferramentas com funções sobrepostas ou objetivos vagos podem confundir Agentes. Sua recomendação inclui organizar nomes e namespaces de maneira que a separação entre capacidades fique mais evidente.

Um conjunto poderia, por exemplo, ser organizado por serviço:

`crm_buscar_cliente`

`crm_atualizar_cliente`

`agenda_consultar_disponibilidade`

`agenda_criar_evento`

Em outros casos, a divisão pode seguir o recurso ou a intenção operacional.

Não existe um esquema universal de nomenclatura que funcione para qualquer Agente. O ponto é tornar a separação explícita e depois testá-la.

O desenho de uma ferramenta, portanto, envolve mais do que seu código.

Uma boa definição precisa deixar claro o que a ferramenta faz, quando deve ser utilizada, quais dados espera, o que retorna e como se diferencia das alternativas semelhantes.

Se essa distinção é difícil de explicar para uma pessoa nova na equipe, provavelmente também merece revisão antes de ser apresentada ao Agente.

Os parâmetros também fazem parte da decisão

Selecionar a ferramenta correta é apenas metade do trabalho.

Depois disso, o Agente precisa preencher seus parâmetros.

Imagine uma consulta ao CRM com os campos:

`user`

`id`

`type`

`status`

Eles podem ser suficientes para o software que executará a operação, mas deixam várias perguntas para o modelo.

O que `user` representa?

É o cliente, o responsável comercial ou o usuário autenticado?

Qual ID deve ser enviado?

O que `type` diferencia?

Quais valores são aceitos em `status`?

Compare com parâmetros como:

`customer_id`

`opportunity_id`

`pipeline_stage`

A segunda versão reduz parte da interpretação necessária antes da chamada.

A Anthropic recomenda justamente que parâmetros sejam nomeados de forma não ambígua. Também orienta que as descrições expliquem os inputs e outputs esperados.

Para ferramentas mais complexas, a Claude Platform permite fornecer exemplos concretos de inputs válidos.

Isso é útil quando o schema diz o que é estruturalmente permitido, mas não comunica bem quais combinações fazem sentido.

Imagine uma ferramenta para geração de proposta com campos opcionais de desconto, prazo, produto, recorrência e condição de pagamento. Um schema pode validar cada campo individualmente e ainda deixar dúvidas sobre como combiná-los.

Exemplos ajudam a mostrar padrões.

O objetivo não é apenas evitar uma chamada inválida. É diminuir o espaço de interpretação antes da chamada.

Como diagnosticar que o catálogo de ferramentas virou um problema

Esse tipo de falha nem sempre aparece como um erro evidente.

Muitas vezes, o Agente continua funcionando. A operação apenas começa a apresentar comportamentos estranhos.

Um sinal comum é a quantidade de chamadas antes de chegar à ferramenta relevante.

O cliente pergunta sobre uma proposta e o Agente:

1. consulta o CRM;

2. procura arquivos;

3. verifica pagamentos;

4. busca novamente o cliente;

5. finalmente consulta a proposta.

Talvez a resposta final esteja correta. Ainda assim, o caminho indica desperdício e pode revelar dificuldade na seleção.

Outro sinal é a inconsistência.

Solicitações praticamente iguais percorrem caminhos muito diferentes sem uma razão operacional clara.

Também pode ocorrer o uso da ferramenta certa com parâmetros errados, principalmente quando diferentes integrações usam identificadores parecidos.

Há ainda um problema mais silencioso: o Agente encontra uma ferramenta que parece adequada e deixa de considerar outra que representaria melhor a intenção do usuário.

Por isso, avaliar apenas a mensagem final esconde parte do problema.

É útil acompanhar:

• quais ferramentas foram chamadas;
• em qual ordem;
• quantas chamadas foram necessárias;
• quais chamadas falharam;
• quais parâmetros foram enviados;
• quais ferramentas costumam ser utilizadas em sequência;
• onde aparecem chamadas redundantes;
• se solicitações semelhantes produzem estratégias semelhantes.

A Anthropic recomenda acompanhar métricas como número total de chamadas, erros de ferramentas, consumo de tokens e tempo de execução. Também sugere analisar as transcrições completas dos testes.

Muitas chamadas redundantes podem indicar que algumas ferramentas deveriam ser consolidadas. Erros frequentes de parâmetros podem apontar para nomes, descrições ou exemplos insuficientes.

Esse tipo de análise faz parte de uma camada maior de observabilidade de Agentes IA. Quando o Agente erra, saber apenas qual resposta chegou ao cliente não é suficiente. É preciso reconstruir quais decisões e chamadas produziram aquela resposta.

Existe também um custo de contexto

Há outro problema que cresce junto com o catálogo.

O modelo precisa receber informações suficientes para saber quais ferramentas existem e como utilizá-las.

Essas definições consomem contexto.

Em um exemplo publicado pela Anthropic sobre uso avançado de ferramentas, um conjunto de 58 ferramentas distribuídas entre GitHub, Slack, Sentry, Grafana e Splunk consumia aproximadamente 55 mil tokens em definições de ferramentas antes do início da tarefa.

A situação se conecta a um problema mais amplo já discutido no blog: contexto demais também pode atrapalhar um Agente IA. Informações úteis continuam tendo custo quando são carregadas indiscriminadamente.

Mas o tamanho do contexto não é a única questão.

Em grandes catálogos, o modelo também precisa distinguir capacidades parecidas. A própria Anthropic destaca seleção incorreta de ferramentas e parâmetros incorretos como falhas recorrentes quando a biblioteca cresce.

Uma alternativa é não carregar todas as definições para o modelo desde o início.

O Agente pode descobrir ferramentas conforme precisa delas

A Claude Platform possui um mecanismo chamado Tool Search Tool.

A lógica é relativamente simples.

Em vez de apresentar um catálogo enorme ao modelo logo no começo da execução, determinadas ferramentas podem ficar disponíveis para descoberta sob demanda.

O fluxo se aproxima de:

“Descubra primeiro quais ferramentas são relevantes para o problema. Depois escolha entre elas.”

Ferramentas menos frequentes podem ser marcadas para carregamento posterior. Quando Claude identifica que precisa de determinada capacidade, busca no catálogo e recebe as definições correspondentes.

Assim, uma operação conectada a CRM, agenda, arquivos, suporte, pagamentos e dezenas de sistemas não precisa necessariamente manter todas as definições dentro do contexto em cada conversa.

Nos testes divulgados pela Anthropic, a descoberta dinâmica reduziu fortemente o consumo de contexto e melhorou a precisão em avaliações com grandes bibliotecas de ferramentas.

Isso não significa que todo Agente deva implementar busca dinâmica.

A própria documentação atual indica que o uso tradicional tende a ser mais adequado quando existem poucas ferramentas, quando todas são utilizadas com frequência ou quando suas definições são pequenas.

Adicionar uma camada de descoberta a um catálogo com cinco ferramentas claramente diferentes provavelmente criaria complexidade sem resolver um problema real.

O princípio mais útil é outro:

uma capacidade não precisa estar permanentemente diante do Agente apenas porque existe.

Menos decisões pode significar um Agente mais capaz

Existe uma aparente contradição aqui.

Remover, agrupar ou ocultar ferramentas parece reduzir a autonomia do Agente.

Na prática, isso pode melhorar seu desempenho.

Se dez ferramentas representam pequenas variações da mesma intenção, o Agente precisa gastar capacidade distinguindo detalhes da arquitetura interna da empresa.

Talvez essa decisão nem devesse chegar até ele.

Se essas dez operações puderem ser reorganizadas em três capacidades com fronteiras claras, o Agente continua acessando os mesmos sistemas. O que muda é o espaço de decisão.

Isso também não significa transformar tudo em uma ferramenta gigantesca.

Ferramentas genéricas demais criam outra forma de ambiguidade. Uma função chamada `executar_acao`, com dezenas de parâmetros e comportamentos possíveis, apenas desloca o problema.

O objetivo é encontrar divisões que façam sentido para as intenções reais da operação.

Para um Agente comercial, por exemplo, pode ser mais fácil trabalhar com capacidades como:

`consultar_contexto_cliente`

`consultar_disponibilidade`

`agendar_reuniao`

`gerar_proposta`

`consultar_pagamento`

`escalar_para_humano`

do que receber diretamente dezenas de endpoints internos do CRM, ERP, gateway de pagamento e sistema de agenda.

A interface usada internamente pelos sistemas não precisa ser a mesma interface apresentada ao Agente.

Esse cuidado também ajuda a decidir onde a autonomia realmente faz sentido. Há processos em que o modelo precisa interpretar a situação e escolher uma ação. Em outros, um caminho determinístico é mais seguro e simples. Essa fronteira é aprofundada na discussão sobre quando usar um Agente de IA e quando usar um workflow.

Antes de adicionar a próxima integração

Quando um Agente executa poucas funções, aumentar suas capacidades costuma parecer uma evolução óbvia.

Conforme o sistema amadurece, cada nova ferramenta também introduz uma nova possibilidade de decisão.

Antes de integrar mais um CRM, endpoint, banco de dados ou automação, vale verificar:

Essa ferramenta possui uma finalidade claramente diferente das ferramentas existentes?

O Agente consegue identificar quando deve usá-la e quando não deve?

Os nomes e parâmetros deixam pouco espaço para interpretações diferentes?

Duas ou três ferramentas atuais poderiam representar uma única intenção operacional?

Essa capacidade precisa estar disponível em todas as conversas?

Os testes mostram que solicitações parecidas levam consistentemente à ferramenta correta?

É possível observar as chamadas e descobrir quando a seleção começa a falhar?

Dar mais capacidades ao Agente continua sendo parte importante da construção de sistemas úteis. O erro é tratar o número de integrações como medida direta de qualidade.

Um Agente com cinquenta ferramentas mal diferenciadas pode operar pior do que outro com dez ferramentas desenhadas ao redor dos fluxos que realmente importam.

Antes de adicionar a próxima integração, existe um teste simples:

verifique se o Agente consegue distinguir claramente a nova ferramenta das que já possui.

Se essa fronteira ainda não estiver clara, talvez o próximo passo não seja adicionar uma nova capacidade.

Talvez seja melhorar a arquitetura das capacidades que ele já tem.

Fontes

https://www.anthropic.com/engineering/writing-tools-for-agents

https://www.anthropic.com/engineering/advanced-tool-use

https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools

https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview