Tool Search: Fim do "Carregar Tudo na Memória" nos seus Agentes

Existe um padrão que provavelmente está nos seus sistemas agênticos agora — e que vai envelhecer mal muito rápido.

O padrão é simples: quando o agente inicia uma sessão, você carrega todas as definições de ferramentas disponíveis no prompt. Todas. O agente "vê" todas as tools de uma vez, escolhe quais usar, chama, recebe resultados.

Funciona muito bem quando você tem 10, 15, talvez 20 ferramentas. Mas quando o sistema cresce para 50 tools, 100 tools, ou quando você integra via MCP com vários domínios diferentes — o modelo está processando centenas de tokens de definições de ferramentas que são irrelevantes para a tarefa atual. Você está pagando por isso, esperando pela latência de inferência disso, e competindo com isso pelo espaço do context window que poderia estar sendo usado para dados relevantes.

O GPT-5.4, lançado em março de 2026, introduziu uma resposta formal para esse problema: Tool Search. Em vez de carregar todas as definições, o modelo busca dinamicamente apenas as tools relevantes para o passo atual. É um padrão de retrieval, aplicado ao catálogo de ferramentas.

O que ainda não ficou claro nos anúncios: você não precisa do GPT-5.4 para implementar isso. O padrão arquitetural existe independente do modelo.

Por Que o "Carregar Tudo" Vai Quebrar no Seu Sistema

Deixa eu colocar em números concretos o custo do padrão atual.

Uma definição de tool bem documentada — com nome, descrição detalhada, parâmetros e exemplos — ocupa em média 200-400 tokens. Para um sistema com 50 tools integradas via MCP (nada absurdo para uma plataforma enterprise em 2026), você está injetando 10.000-20.000 tokens só de definições de ferramentas em cada chamada ao modelo.

Com Claude Opus 4.6 ou GPT-5.4 custando na faixa de $15-20 por milhão de tokens de input, isso é $0,15-0,40 por chamada só em definições de tool. Em um sistema com 10.000 chamadas/dia, estamos falando de $1.500-4.000/mês em tokens que não contribuem para a resposta.

Mas o custo financeiro não é o maior problema. O maior problema é a qualidade da resposta. Modelos de linguagem têm algo chamado "lost in the middle" — a tendência de processar melhor informações no início e no final do contexto do que no meio. Quando você injeta 20.000 tokens de definições de tools antes das instruções e dos dados relevantes, você está ativamente prejudicando a qualidade do raciocínio do agente.

E há um terceiro problema: com context windows finitos, cada token gasto em definições de tools irrelevantes é um token que não pode ser usado para histórico de conversa, documentos relevantes, ou o resultado de chamadas de tools anteriores.

O Padrão Tool Search: Como Funciona

O Tool Search é, no fundo, um sistema de retrieval aplicado ao catálogo de ferramentas. A arquitetura tem três componentes:

Tool Registry. Um armazenamento centralizado de todas as definições de tools, com metadata que permite busca semântica. Pode ser um banco de dados vetorial, um índice de busca, ou até um arquivo JSON estruturado para sistemas menores.

Retrieval Semântico. Dado o estado atual do agente — a tarefa, a intenção detectada, o contexto da conversa — o sistema recupera as N tools mais relevantes. A busca pode ser por similaridade vetorial, por tags, por domínio, ou por uma combinação.

Prompt Dinâmico. Apenas as tools recuperadas são injetadas no contexto do agente para aquele passo. O agente processa, decide, executa. Para o próximo passo, se a intenção mudou, uma nova busca recupera tools diferentes.

Tarefa do usuário: "Analise as vendas do Q1 e crie um relatório em PDF"

Step 1 — Detectar intenção: análise de dados
Tool Search: ["get_sales_data", "calculate_metrics", "filter_by_date_range"]
→ Agente executa análise

Step 2 — Detectar intenção: geração de documento
Tool Search: ["create_pdf_report", "format_table", "add_chart"]
→ Agente gera PDF

[Em nenhum momento o agente "viu" tools de e-mail, CRM, deploy, tickets, etc.]

É elegante porque resolve o problema na camada certa. Em vez de forçar o modelo a ignorar tools irrelevantes, você simplesmente não diz a ele que essas tools existem.

Implementando Hoje, Sem Depender do GPT-5.4

O Tool Search do GPT-5.4 é uma implementação específica desse padrão. Mas a arquitetura funciona com qualquer modelo. Aqui está como construir isso agora:

1. Estruture o Tool Registry

interface ToolDefinition {
  name: string;
  description: string;
  parameters: JSONSchema;
  // Metadata para retrieval
  domain: string[];        // ["analytics", "reporting", "data"]
  useCase: string[];       // ["relatórios", "análise de dados", "métricas"]
  embedding?: number[];    // Vetor gerado pela descrição
}

// Exemplo de registry
const toolRegistry: ToolDefinition[] = [
  {
    name: "get_sales_data",
    description: "Busca dados de vendas de um período específico do sistema de CRM",
    parameters: { /* ... */ },
    domain: ["analytics", "sales", "crm"],
    useCase: ["análise de vendas", "relatório de vendas", "dados de performance"]
  },
  {
    name: "send_email",
    description: "Envia um e-mail para um ou múltiplos destinatários",
    parameters: { /* ... */ },
    domain: ["communication", "email"],
    useCase: ["envio de e-mail", "notificação", "comunicação"]
  },
  // ... mais 48 tools
];

2. Implemente o Retrieval

Para sistemas menores, busca por tags/domínio já reduz o problema significativamente:

function retrieveRelevantTools(
  userIntent: string,
  currentStep: string,
  topK: number = 5
): ToolDefinition[] {
  // Opção simples: busca por keywords
  const keywords = extractKeywords(userIntent + " " + currentStep);

  return toolRegistry
    .filter(tool =>
      keywords.some(kw =>
        tool.domain.some(d => d.includes(kw)) ||
        tool.useCase.some(uc => uc.includes(kw))
      )
    )
    .slice(0, topK);
}

// Opção mais poderosa: busca vetorial
async function retrieveRelevantToolsVector(
  userIntent: string,
  topK: number = 5
): Promise<ToolDefinition[]> {
  const intentEmbedding = await embedText(userIntent);

  return toolRegistry
    .map(tool => ({
      tool,
      score: cosineSimilarity(intentEmbedding, tool.embedding)
    }))
    .sort((a, b) => b.score - a.score)
    .slice(0, topK)
    .map(({ tool }) => tool);
}

3. Injete Dinamicamente no Agente

async function runAgentStep(
  userMessage: string,
  conversationHistory: Message[],
  currentTask: string
): Promise<AgentResponse> {

  // Recupera apenas as tools relevantes para esse passo
  const relevantTools = await retrieveRelevantToolsVector(
    `${userMessage} ${currentTask}`,
    topK: 5
  );

  // Constrói o prompt com apenas essas tools
  const response = await llm.call({
    messages: conversationHistory,
    tools: relevantTools.map(toOpenAIToolFormat),
    system: systemPrompt
  });

  return response;
}

A diferença prática: em vez de 50 tools no prompt, o agente processa 5. Para essa tarefa específica, ele não precisa de mais.

Tool Search com MCP: O Próximo Nível

Se você está usando MCP para integrar ferramentas, o Tool Search fica ainda mais interessante — porque você pode combinar o registry local com um MCP server que expõe o catálogo de tools disponíveis:

// Um servidor MCP "tools-registry" que expõe o catálogo
server.tool("search_available_tools", {
  intent: z.string().describe("O que o agente quer fazer"),
  domain: z.string().optional().describe("Domínio específico (analytics, crm, etc.)"),
}, async ({ intent, domain }) => {
  const tools = await retrieveRelevantTools(intent, domain);
  return {
    content: [{
      type: "text",
      text: JSON.stringify(tools.map(t => ({
        name: t.name,
        description: t.description,
        useFor: t.useCase
      })))
    }]
  };
});

Agora o agente pode fazer uma chamada de tool para descobrir quais outras tools existem antes de chamar qualquer coisa. É meta-retrieval — o agente buscando sua própria caixa de ferramentas.

Isso resolve um problema que vai aparecer no seu sistema em breve: como o agente descobre que uma ferramenta existe quando o catálogo é grande demais para ficar todo no contexto?

A Conexão com Context Engineering

Tool Search é, na raiz, uma aplicação de Context Engineering — a disciplina de gerir o que vai e o que não vai no contexto de um agente.

O conceito que ficou famoso com o post do Tobi Lütke sobre os sistemas agênticos da Shopify é simples: o contexto de um agente é um recurso finito e precioso. O trabalho do engenheiro não é "escrever o melhor prompt" — é orquestrar qual informação entra no contexto, em qual momento, em qual nível de detalhe.

Tool Search é Context Engineering aplicado ao catálogo de ferramentas. Da mesma forma que você não joga o banco de dados inteiro no contexto (você busca os registros relevantes), você não joga todas as definições de tools (você busca as relevantes).

O padrão se aplica a tudo que você coloca no contexto:

• Histórico de conversa: compressão e sumarização progressiva em vez de histórico completo
• Documentos: retrieval por relevância em vez de todos os documentos
• Memória de agentes: busca semântica em memória de longo prazo em vez de replay completo
• Definições de tools: Tool Search

Sistemas agênticos de produção em 2026 não são "joga tudo no contexto e reza". São orquestrações cuidadosas de informação, onde cada token no contexto tem uma razão para estar lá.

Quando Implementar Tool Search (e Quando Não Precisa)

Para ser honesto: se você tem menos de 15-20 tools no seu sistema, o Tool Search provavelmente não resolve um problema real ainda. O overhead de implementação não vai se pagar.

O ponto de inflexão é em torno de 30-50 tools, especialmente quando:

• O contexto do agente está frequentemente próximo do limite
• Você observa que o agente confunde ferramentas similares entre si
• Os custos de tokens estão crescendo mais rápido do que o uso
• O sistema integra múltiplos domínios com ferramentas especializadas por domínio

Se você está construindo uma plataforma com integrações extensas via MCP — conectando CRM, ERP, analytics, comunicação, deployment — o Tool Search passa de otimização para requisito arquitetural.

O Que Vem Depois

O Tool Search resolve o problema do catálogo. O próximo problema — que já aparece em sistemas mais avançados — é o Tool Composition: como o agente descobre que pode compor duas ou mais tools para resolver um problema que nenhuma delas resolve individualmente?

Isso é o que os pesquisadores estão chamando de "tool learning" ou "tool synthesis" — agentes que não apenas usam ferramentas, mas entendem como combiná-las. É um passo além do retrieval, em direção a um planejamento mais sofisticado.

Mas esse é tema para outro post. Por enquanto, se você ainda está carregando 50 tools no contexto em cada chamada, você tem trabalho mais imediato a fazer.

Quantas tools você tem no seu sistema agêntico hoje? Se passou de 20, vale medir o percentual de chamadas em que mais da metade das tools disponíveis nunca é invocada. Esse número vai te dizer se Tool Search já deveria estar na sua lista de otimizações.

Principais Aprendizados

• Carregar todas as tools no contexto consome tokens desnecessários, aumenta latência e piora a qualidade do raciocínio do agente
• Tool Search = retrieval semântico aplicado ao catálogo de ferramentas — buscar dinamicamente só as tools relevantes para cada passo
• Você não precisa do GPT-5.4 para implementar isso: tool registry + busca semântica ou por tags + prompt dinâmico funciona com qualquer modelo
• Com MCP, um servidor de registry permite ao agente descobrir suas próprias ferramentas via chamada de tool
• Context Engineering é a disciplina por trás: o contexto é recurso finito, cada token deve ter razão de estar lá
• Vale implementar a partir de ~30-50 tools — abaixo disso, o overhead não compensa

Referências Técnicas

Tool Search e Arquitetura Agêntica

• Top Agentic LLM Models & Frameworks for 2026 — Adaline
• 5 Key Trends Shaping Agentic Development in 2026 — The New Stack
• Top 9 AI Agent Frameworks as of March 2026 — Shakudo

Context Engineering

• LLM-Based Agent Primer Part 2 — SamSena
• Model Context Protocol — Official Docs — Anthropic

Posts Relacionados

• MCP Virou Padrão Aberto da Indústria — Ecossistema MCP
• MCP Security: 38% dos Servidores Sem Autenticação — Segurança em sistemas MCP
• O Déficit de Confiança: Por Que 46% dos Devs Não Confiam na IA — Contexto sobre qualidade em sistemas agênticos

Série: Arquitetura de Sistemas Agênticos

Este post faz parte de uma série sobre padrões de arquitetura para sistemas agênticos em produção.