Como os AI Agents Usam Ferramentas (Function Calling Explicado)

Um AI agent usa uma ferramenta por meio do function calling: o modelo lê a tarefa à sua frente, compara essa tarefa com as ferramentas que recebeu e gera uma solicitação estruturada que nomeia a ferramenta e os valores exatos a passar. A sua aplicação, ou o próprio provedor de AI no caso de ferramentas hospedadas, executa essa solicitação em um sistema real e devolve o resultado, que o modelo lê antes de decidir o que fazer em seguida. O function calling é o mecanismo que transforma um modelo de linguagem de algo que só escreve texto em algo que consegue consultar uma agenda, atualizar um registro de CRM ou emitir um reembolso.

Isso já não é um recurso de nicho. A Gartner prevê que 40% das aplicações corporativas terão agents de AI específicos para tarefas até o fim de 2026, contra menos de 5% em 2025, e quase todos esses agents dependem do function calling para fazer qualquer coisa além de gerar uma resposta. Se você está construindo ou comprando um agent, entender como as chamadas de ferramentas realmente funcionam, e onde elas quebram, é a diferença entre um agent realmente útil e um que impressiona em uma demo e desmorona em produção.

De Falar Sobre uma Tarefa a Executá-la

Um modelo sem ferramentas consegue descrever o que deveria acontecer: "Eu recomendaria remarcar para quinta-feira e enviar uma confirmação." Um modelo com ferramentas consegue fazer isso acontecer. Ele chama uma ferramenta de calendário para verificar a disponibilidade de quinta-feira, chama uma ferramenta de mensagens para enviar a confirmação e informa que está feito. Essa é toda a diferença entre um chatbot e um agent, tratada com mais profundidade em como os AI agents funcionam: a percepção alimenta o raciocínio, o raciocínio escolhe uma ferramenta, e a ferramenta é o que de fato altera algo fora do modelo.

O conceito tem nome na literatura de AI: tool use (uso de ferramentas), às vezes chamado de function calling dependendo do fornecedor. Para a definição em linguagem simples e o enquadramento de negócio, o que é tool use cobre esse terreno. Este artigo desce um nível e foca no que importa quando você já está rodando um agent: como uma chamada de ferramenta é construída, como o modelo decide fazer uma, o que acontece quando algo dá errado e como um conjunto crescente de ferramentas é gerenciado sem virar bagunça.

A Anatomia de uma Chamada de Ferramenta

Toda ferramenta que um agent pode usar é definida da mesma forma básica, seja qual for o provedor de AI. Três peças compõem a definição, e o modelo nunca vê mais do que você coloca nessas três, uma estrutura documentada de forma consistente na plataforma de tool use da Anthropic e em todos os outros grandes provedores:

Quando o modelo decide usar uma ferramenta, ele não executa nenhum código por conta própria. Ele gera um objeto estruturado que nomeia a ferramenta e preenche os parâmetros, algo como "chame check_order_status com order_id: 48213." O seu sistema, ou a infraestrutura hospedada do provedor no caso de ferramentas como a busca na web, que rodam do lado do fornecedor, executa essa chamada no sistema de pedidos real e devolve o resultado na mesma conversa. O modelo lê o resultado como informação nova e continua, exatamente como o loop de perceber, raciocinar, agir e observar descreve.

A qualidade da descrição e do schema decide a maior parte do resultado. Uma ferramenta chamada update_record, sem descrição de que tipo de registro ou de quais campos ela aceita, dá ao modelo quase nada com que trabalhar. Uma ferramenta que o modelo pode usar de forma errada porque um parâmetro tem tipagem frouxa, um campo date de texto livre em vez de um formato rígido, é uma ferramenta que mais cedo ou mais tarde será chamada com um valor que ninguém esperava.

Como o Modelo Decide se Vai Chamar uma Ferramenta

A cada turno, o modelo toma uma pequena decisão: este pedido precisa de uma ferramenta, ou ele pode responder com o que já sabe? Uma pergunta sobre a sua política de reembolso pode ser respondida diretamente se o texto da política já estiver no contexto. Uma pergunta sobre o pedido de um cliente específico exige uma ferramenta, porque o modelo não conhece esses dados e nunca conhecerá a menos que os consulte.

Duas coisas moldam essa decisão. Primeiro, o quanto a descrição da ferramenta se encaixa no pedido; uma descrição vaga é ignorada ou mal aplicada. Segundo, como o system prompt ou a configuração do agent orienta o comportamento. Um agent pode ser instruído a sempre consultar uma knowledge base antes de responder, a usar ferramentas apenas quando for explicitamente necessário ou a exigir uma chamada de ferramenta antes de qualquer resposta em determinado cenário. Isso é um ajuste configurável na maioria dos frameworks de agents, e não um comportamento fixo, e é por isso que dois agents construídos sobre o mesmo modelo de base podem agir de forma muito diferente conforme o quão diretamente são instruídos a recorrer a ferramentas.

Esse ponto de decisão é exatamente a parte de "raciocinar" do loop do agent. Como os AI agents funcionam cobre esse ciclo completo com mais profundidade; o momento de seleção de ferramenta descrito aqui é onde o raciocínio vira ação. Para um olhar mais de perto sobre o que acontece do lado do raciocínio antes de uma ferramenta ser chamada, veja como os AI agents raciocinam.

Chamadas Únicas, Sequenciais, Paralelas e Condicionais

Nem toda tarefa precisa de uma única chamada de ferramenta. O trabalho real de um agent geralmente se enquadra em quatro formatos:

O blueprint do AI Meeting Scheduler Agent é um exemplo sequencial limpo: consulta de disponibilidade, depois reserva, depois confirmação, cada etapa dependendo da anterior. O blueprint do AI Research Agent se apoia em chamadas paralelas e sequenciais juntas, consultando várias fontes de uma vez e lendo cada resultado para decidir a próxima busca. O blueprint do AI Support Triage Agent é o caso condicional: a classificação determina se a próxima chamada de ferramenta é uma consulta à knowledge base, uma ação de roteamento ou um escalonamento.

Como São as Ferramentas nos Blueprints de Produção

Descrições abstratas só vão até certo ponto. Veja como os conjuntos de ferramentas realmente se parecem em trabalhos reais.

O AI SDR Agent chama uma ferramenta de pesquisa para puxar dados firmográficos de uma conta-alvo, uma ferramenta de CRM para verificar relacionamentos existentes e registrar o contato, e uma ferramenta de e-mail para enviar a sequência. Três ferramentas, três sistemas distintos, um trabalho coerente.

O AI Invoice AP Agent chama uma ferramenta de extração de documentos para tirar os itens de linha de uma fatura, uma ferramenta de consulta de fornecedores para conferi-la com um pedido de compra e uma ferramenta de ERP para lançar o pagamento aprovado. Cada chamada de ferramenta aqui tem consequências financeiras reais, e é exatamente por isso que uma etapa de aprovação fica entre a extração e o lançamento, em vez de deixar o agent encadear tudo direto.

Repare no padrão: as ferramentas a que um agent tem acesso definem o teto do que ele pode fazer, nada além. Um agent com uma ferramenta de CRM somente leitura consegue consultar registros, mas não alterá-los. Um agent com uma ferramenta com permissão de escrita consegue. Esse limite é uma decisão de design, não um acidente, e geralmente é a primeira coisa que vale revisar quando um agent faz algo que você não esperava.

Quando as Chamadas de Ferramentas Falham: Erros, Novas Tentativas e Limites

As chamadas de ferramentas falham com mais frequência do que as demos sugerem. Os modos de falha comuns:

• Parâmetros errados ou ausentes. O modelo chuta um valor que não recebeu, especialmente em pedidos ambíguos. Um agent bem construído faz uma pergunta de esclarecimento em vez de chutar em qualquer coisa de consequência.
• Erros de permissão. A ferramenta existe, mas as credenciais do agent não permitem aquela ação específica, uma salvaguarda que deve continuar no lugar em vez de ser "corrigida" ampliando o acesso.
• A ferramenta não existe ou foi lembrada errado. Mais comum em conjuntos de ferramentas grandes e mal organizados do que em um conjunto pequeno e bem delimitado.
• Timeouts e quedas. O sistema downstream está lento ou fora do ar, e o agent precisa de um fallback definido em vez de travar ou adivinhar um resultado.

A escala muda esse problema. O próprio guia de function calling da OpenAI recomenda manter pequeno o número de ferramentas disponíveis em um único turno, geralmente abaixo de 20, porque a precisão cai à medida que o modelo precisa distinguir entre mais e mais opções de aparência parecida. Para agents que realmente precisam de uma grande biblioteca de ferramentas, a solução não é socar todas elas em cada prompt. É carregar apenas o subconjunto relevante para a tarefa em questão, para que o modelo escolha em uma lista curta e relevante, e não em uma avassaladora.

A etapa de observar é o que pega a maior parte disso. Um agent bem projetado verifica se uma chamada de ferramenta realmente teve sucesso antes de tratá-la como concluída, tenta de novo em caso de falha transitória e transfere para um humano em vez de adivinhar quando a falha se repete. Um agent que dispara uma chamada de ferramenta e presume que funcionou é a causa raiz mais comum por trás de "a AI disse que enviou o e-mail, mas não enviou".

Function Calling e o Problema da Padronização

Por um tempo, toda integração de ferramenta era trabalho sob medida: um conector específico para o seu CRM, outro para a sua agenda, outro para o seu help desk, cada um quebrando de um jeito um pouco diferente quando a API de base mudava ou você trocava de provedor de AI. O Model Context Protocol resolve isso padronizando como um modelo descobre e chama ferramentas, de modo que uma ferramenta construída uma vez pode funcionar com diferentes provedores de AI, em vez de ser refeita para cada um.

O padrão cresceu rápido. A Anthropic, que originalmente desenvolveu o MCP, relatou mais de 10.000 servidores MCP públicos ativos em dezembro de 2025, contra algumas centenas no lançamento, um ano antes, e o protocolo hoje está por baixo da maioria das grandes plataformas agênticas, e não ao lado delas. Se você está conectando um agent a um conjunto crescente de ferramentas de negócio sem refazer a camada de integração toda vez que troca de modelo, o que é o Model Context Protocol é a referência mais aprofundada, incluindo as considerações de segurança que vêm com a conexão de um conjunto maior de servidores.

Barreiras de Proteção: O Que uma Ferramenta Nunca Deve Poder Fazer Livremente

Nem toda chamada de ferramenta merece a mesma confiança. Uma consulta somente leitura e uma ação que emite reembolsos carregam riscos muito diferentes se o agent errar, e tratá-las de forma idêntica é como um pequeno erro de raciocínio vira um dano financeiro ou ao cliente de verdade.

O padrão que funciona: limitar cada ferramenta à menor permissão que ainda faz o trabalho, exigir uma etapa de aprovação humana para ferramentas financeiras, irreversíveis ou voltadas ao cliente em escala e registrar cada chamada, para que uma ação errada seja rastreável depois, e não um mistério. É a mesma disciplina tratada em barreiras de proteção para AI agents, e é o que separa um agent seguro para deixar rodando de um que tecnicamente funciona até o dia em que deixa de funcionar. O padrão Autonomous Agent aprofunda por que os loops de chamada de ferramentas são a parte de maior risco de qualquer design de agent, já que cada chamada é uma chance de alterar um estado real.

Key Facts

• O function calling funciona por três partes: um nome de ferramenta, uma descrição em linguagem simples e um schema de parâmetros. O modelo nunca executa código por conta própria; ele gera uma solicitação estruturada que o seu sistema executa.
• O modelo decide se vai chamar uma ferramenta comparando o pedido com as descrições das ferramentas e seguindo as instruções recebidas sobre quando recorrer a uma ferramenta e quando responder diretamente.
• As chamadas de ferramentas acontecem em quatro formatos: única, sequencial, paralela e condicional, muitas vezes combinados na execução de um mesmo agent.
• A precisão cai à medida que cresce o número de ferramentas disponíveis. A OpenAI recomenda manter a lista de ferramentas ativas abaixo de cerca de 20 e carregar ferramentas adicionais sob demanda em bibliotecas maiores.
• O Model Context Protocol padroniza a integração de ferramentas entre provedores de AI, e o ecossistema já passou de 10.000 servidores públicos ativos.

Para Onde Ir Agora

O tool use é o que dá mãos a um agent. Combine-o com o lado de raciocínio do loop em como os AI agents raciocinam para ver como um modelo decide qual ferramenta usar e quando parar, e veja como os AI agents funcionam para o loop completo em que essas chamadas de ferramentas se encaixam. Se você está comparando plataformas para construir, o roundup de ferramentas de automação e o guia das melhores ferramentas de automação no-code mostram onde a capacidade de chamar ferramentas aparece nos produtos que você pode comprar hoje.