O agente do Postman piorou quando passou a ver cerca de 40 ferramentas. A solução trata a escolha como busca

Dê mais ferramentas a um modelo capaz e ele deveria conseguir fazer mais. O Postman descobriu o contrário a partir de certo ponto: “Nos testes do Postman, os erros de seleção de ferramenta aumentaram quando o conjunto visível passou de aproximadamente 40 ferramentas.”

O detalhe vem de um post de 9 de outubro no AWS Machine Learning Blog, assinado por Srinivas Kini, do time de IA do Postman, e Shubham Gupta, da AWS, que descreve como o Agent Mode roda no Amazon Bedrock dentro de uma plataforma de desenvolvimento com onze anos de produto nas costas. Os erros tinham um padrão reconhecível: chamadas a ferramentas que não existiam, argumentos errados e ferramentas que pareciam certas, mas estavam erradas no contexto.

Cada ferramenta faz parte do prompt

A definição de uma ferramenta é texto que o modelo lê a cada turno: um nome, uma descrição, um schema de parâmetros. Quarenta delas disputam a atenção do modelo, muitas com descrições que se sobrepõem. O modelo não está falhando em raciocinar; está escolhendo num cardápio que ficou longo demais para ser lido com cuidado.

A resposta do Postman foi parar de mostrar o cardápio inteiro. Um agente raiz consulta um banco vetorial de embeddings das ferramentas e, nas palavras do post, “reduz mais de 170 ferramentas a aproximadamente 15 relevantes para a requisição”. Depois entrega essas ferramentas a um subagente com contexto isolado para aquela tarefa, de modo que o modelo vê só o que a tarefa precisa.

1. Pedido do desenvolvedor
2. Agente raiz busca nos embeddings das ferramentas
3. Cerca de 15 de 170+ ferramentas selecionadas
4. Subagente isolado executa a tarefa
5. Aprovação do usuário antes de qualquer mudança de estado

• Ferramentas reduzidas por tarefa: Agente raiz busca nos embeddings das ferramentas · Cerca de 15 de 170+ ferramentas selecionadas · Subagente isolado executa a tarefa

RequisiçãoSeleção e isolamento de contexto

Menos ferramentas, ferramentas melhores

O segundo movimento foi menos glamouroso. Para o API Catalog, o Postman tinha construído várias ferramentas estreitas, cada uma respondendo a um tipo de pergunta. Juntou todas em uma única ferramenta de consulta, que permite ao agente escrever queries com joins e filtros sobre os schemas no ClickHouse. Na prática, o time trocou muitas ferramentas por pergunta por uma interface de dados bem modelada.

Essa troca vale para outros casos. Times que expõem sistemas internos para agentes costumam criar uma ferramenta por endpoint de API, porque é assim que os sistemas estão organizados. Um agente costuma funcionar melhor com menos ferramentas, desenhadas a partir das perguntas que as pessoas fazem, com o modelo de dados fazendo o trabalho. Vimos a mesma economia na API de conhecimento para desenvolvedores do Google: o contexto mais barato é aquele que o agente nunca precisa carregar.

Controles que viajam com a requisição

A arquitetura leva os controles junto. “O Agent Mode exige aprovação do usuário antes de ações que modificam o estado da aplicação”, e as ferramentas têm escopo por tarefa. O Amazon Bedrock Guardrails pode “remover informações pessoais identificáveis antes que cheguem ao modelo”, uma configuração que os administradores enterprise ativam no Agent Mode.

Duas configurações de dados merecem atenção de quem constrói no Bedrock. O Postman definiu retenção de dados como nenhuma nos modelos compatíveis, com o alerta de que “disponibilidade e comportamento dependem do modelo”, então cada modelo precisa ser conferido na documentação atual. E o Agent Mode usa inferência entre regiões, em que a escolha do perfil é uma decisão de residência de dados: perfis geográficos mantêm o roteamento dentro de uma geografia, como Estados Unidos ou União Europeia, enquanto perfis globais acrescentam capacidade em picos, mas não têm fronteira geográfica e só servem para cargas sem exigência de residência.

O que copiar, e o que não copiar

O número de 40 ferramentas é uma observação do Postman sobre a carga e os modelos dele, não uma constante universal. O post não traz números de latência, taxa de erro ou custo, e os “40 milhões de desenvolvedores” do título descrevem o público do Postman, não usuários confirmados do Agent Mode. Leia como uma dissecação de arquitetura, não como um benchmark.

O que se transfere é o método:

• Conte as ferramentas que cada agente enxerga, por tarefa, e acompanhe isso como qualquer outra configuração. Listas de ferramentas crescem em silêncio à medida que os times acrescentam integrações.
• Meça os erros de seleção de ferramenta conforme a lista cresce. Seu limite pode ser 25 ou 60; você só vai saber se medir chamadas à ferramenta errada e a ferramentas inexistentes nos seus evals.
• Selecione as ferramentas antes de o modelo raciocinar, por busca ou por roteamento de tarefa, e isole o contexto de cada subtarefa.
• Mantenha a aprovação de escrita junto da ferramenta, não no prompt, para que ela valha quaisquer que sejam as ferramentas que a busca devolva.

Isso também simplifica a governança. Uma ferramenta que o agente não enxerga numa tarefa é uma ferramenta que ele não pode usar mal naquela tarefa, uma superfície menor e mais testável do que o catálogo completo que o MCP torna tão fácil de conectar.