2bSolutions • 12 de outubro de 2026 • Engenharia de produto

O problema aparece antes da execução

Imagine um assistente de uma loja com várias funções chamadas “consultar”, “buscar”, “localizar” e “listar”. Todas parecem úteis; cada uma aceita parâmetros diferentes. O cliente faz uma pergunta simples, mas o agente precisa primeiro descobrir qual caminho seguir.

Esse cenário é hipotético. Ele ilustra uma decisão de produto: a interface que oferecemos ao agente merece o mesmo cuidado que a interface oferecida a uma pessoa. Adicionar integrações pode ampliar possibilidades e, ao mesmo tempo, aumentar a ambiguidade.

Em um artigo publicado em 11 de setembro de 2025, a Anthropic recomenda ferramentas com propósitos distintos, nomes claros e retornos relevantes, em vez de apenas transformar cada endpoint existente em uma ferramenta. A recomendação é uma referência de engenharia, não uma promessa de resultado para qualquer aplicação. Fonte: Writing effective tools for agents.

Duas decisões que não devem ser confundidas

A primeira decisão é o que a ferramenta faz. Uma operação de consulta deve explicar o objeto consultado, os filtros aceitos e o significado da resposta. Se duas operações parecem iguais, a documentação precisa tornar a diferença evidente.

A segunda decisão é quando a definição da ferramenta entra no contexto do modelo. No anúncio de 24 de novembro de 2025 sobre uso avançado de ferramentas, a Anthropic apresentou a descoberta sob demanda: o agente pesquisa capacidades e recebe as definições relevantes, em vez de começar com todo o catálogo carregado. A técnica acrescenta uma etapa de busca; portanto, seu valor depende do tamanho e do uso do catálogo. Fonte: Introducing advanced tool use.

A documentação atual do Tool Search descreve carregamento adiado de ferramentas. Antes de implementar, confira nessa documentação a compatibilidade com o modelo e a plataforma usados. Este texto não trata um anúncio de 2025 como lançamento desta semana. Documentação oficial consultada em 12/10/2026.

Uma aplicação prática: consulta de disponibilidade

A proposta abaixo é um exercício de arquitetura, não um relato de implementação ou de desempenho da 2bSolutions.

Considere um assistente que precisa responder se um produto está disponível em uma unidade. Desenhe primeiro o contrato de consulta:

  • Intenção: consultar disponibilidade, sem reservar ou alterar estoque.

  • Entrada: identificador do produto e unidade; se faltarem, a aplicação solicita esclarecimento.

  • Saída: unidade consultada, situação encontrada, horário da informação e indicador de resultado parcial.

  • Ausência: diferencie produto não localizado, indisponibilidade e falha de consulta.

  • Próximo passo: permita uma consulta mais detalhada quando houver necessidade, em vez de devolver todo o catálogo.

Depois, escreva uma descrição curta que deixe explícitos os limites. Um nome como “consultar_disponibilidade_por_unidade” comunica mais intenção que “executar_consulta_v2”. Isso não elimina erros do modelo: torna a integração mais fácil de compreender e testar.

Evite unir consulta e alteração só para economizar uma chamada. Uma ferramenta que pesquisa, reserva e confirma automaticamente pode esconder decisões que deveriam continuar separadas. Descobrir uma ferramenta também não concede permissão para executá-la: a autorização deve continuar sendo verificada pela aplicação.

Como decidir se vale mudar

Comece com uma tarefa estreita e compare duas versões: catálogo atual e catálogo reorganizado. Use os mesmos pedidos de teste, incluindo pedidos incompletos e casos sem resultado. Para isolar o efeito, mantenha modelo, dados e demais configurações iguais.

Observe três perguntas: a ferramenta escolhida corresponde à intenção? A resposta distingue ausência de informação de falha? O fluxo produz alguma alteração que não foi solicitada?

Só depois avalie carregamento sob demanda. Um catálogo pequeno pode não justificar a etapa adicional. Um catálogo grande pode se beneficiar, mas a busca também precisa encontrar a capacidade correta. Compare qualidade, tempo total e custo do fluxo, sem adotar percentuais de testes de fornecedores como previsão para o seu produto.

O próximo passo cabe em uma revisão de contrato

Escolha uma ferramenta que costuma exigir explicação extra. Reescreva nome, propósito, entradas, saídas e erros. Peça a outra pessoa para prever o comportamento apenas pela descrição. Se ela não conseguir, há uma ambiguidade concreta para resolver antes de adicionar mais automação.

O objetivo não é ter o menor número possível de ferramentas. É oferecer um conjunto suficientemente claro para realizar a tarefa certa, com limites visíveis e resultado verificável.