OpenAI tool calling: novidades e instabilidades recentes

TL;DR

O tool calling da OpenAI virou uma peça mais central do fluxo de agentes, especialmente com a Responses API e a integração com tools externas via MCP/Connectors. Isso traz mais flexibilidade, mas também deixa mais visíveis limites práticos de confiabilidade, como paralelismo restrito com built-in tools, strict mode condicionado e comportamento sensível a calls pendentes em cenários Realtime.

O que mudou no ecossistema de tool calling

A mudança mais importante não é só de nome. A OpenAI vem orientando a migração do fluxo antigo para a Responses API, que concentra melhor a experiência de uso de ferramentas em cenários de raciocínio, orquestração e agentes. Na prática, isso empurra o desenvolvedor para um modelo mais declarativo: o modelo decide quando chamar tools, mas a aplicação continua responsável por executar, validar e devolver o resultado com consistência.

Esse redesenho importa porque “function calling” deixou de ser um recurso isolado e passou a ser parte de uma arquitetura maior, em que agentes, governança e conectores trabalham juntos. O guia de Function calling já trata de tópicos como schema de tools, paralelismo e redução de tokens, enquanto o material sobre governança de agentes destaca que a estabilidade do sistema depende tanto do modelo quanto dos guardrails do runtime.

Tool search e carregamento tardio

Uma novidade prática importante é o uso de tool search para não carregar todo o catálogo de funções de uma vez. O guia oficial recomenda esse padrão quando há muitas tools ou schemas grandes, porque isso reduz tokens e adia o carregamento de funções raramente usadas até o momento em que o modelo realmente precisa delas [documentação oficial].

Esse tipo de otimização é especialmente útil em agentes corporativos, onde o catálogo tende a crescer rápido: CRM, sistemas internos, consultas a documentos, bancos vetoriais, automações, e assim por diante. Em vez de tentar entregar tudo ao modelo no primeiro turno, a aplicação faz uma curadoria dinâmica do que realmente precisa estar em jogo.

Paralelismo existe, mas não é universal

Outro ponto relevante é que o paralelismo de function calls tem restrições quando entram built-in tools no caminho. A documentação afirma que parallel function calling is not possible when using built-in tools. Ou seja, se seu agente depende de múltiplas operações em um turno, você não pode assumir que o runtime vai conseguir dispará-las em paralelo em qualquer configuração.

Isso força uma decisão de arquitetura: ou você sequencia as chamadas, ou divide o trabalho em turnos, ou implementa um loop de agente na aplicação. Para times que estão acostumados a tratar o modelo como um simples “chama e responde”, essa é uma mudança importante de mentalidade.

Instabilidades e limitações que aparecem na prática

Quando o assunto é instabilidade, o problema raramente é um “bug único” e mais frequentemente um conjunto de comportamentos intermitentes que parecem aleatórios: tool call duplicada, espera indevida, outputs incompletos ou execução fora de ordem. A documentação oficial não descreve isso como um incidente único, mas deixa claro que há limites operacionais que o time precisa respeitar para não transformar o agente em um sistema frágil.

Um exemplo é o caso de strict mode. O guia aponta que, atualmente, se você usa um modelo fine-tuned e ele chama múltiplas funções no mesmo turno, o strict mode pode ser desabilitado para essas calls. Isso muda bastante o desenho de validação: se você dependia de formato rígido para segurança ou previsibilidade, precisa considerar caminhos alternativos de checagem no seu backend.

Esta seção descreve o estado documentado da plataforma na data do brief. APIs de IA mudam rápido — confira o changelog oficial antes de depender desses comportamentos em produção.

Realtime + MCP: quando a call fica pendente

O caso mais próximo de “instabilidade recente” explicitado nas fontes oficiais está nas notas de Realtime API. O material afirma que, em beta, o modelo não tem async function calling, e que chamadas MCP pendentes sem output podem não ser tratadas bem pelo modelo. Em outras palavras: se a tool demora ou não devolve o formato esperado, o fluxo pode degradar de forma perceptível.

Esse detalhe é importante porque aproxima a confiabilidade do modelo da confiabilidade da infraestrutura ao redor. Em um agente Realtime, não basta o LLM “querer” chamar a tool; é preciso garantir timeout, retorno previsível e estratégia de fallback quando a execução externa falha ou atrasa demais.

MCP/Connectors mudam o ciclo de descoberta

Nas integrações via MCP/Connectors, a OpenAI descreve um comportamento em que, se o item mcp_list_tools já está no contexto, o sistema evita buscar a lista novamente a cada turno. Além disso, com tool search, funções expostas por um MCP server podem ser carregadas de forma tardia. Isso ajuda na eficiência, mas também exige cuidado com estado de sessão e consistência entre turnos.

Na prática, agentes com muitos conectores não devem depender de “redescoberta” constante. Você precisa tratar o contexto como parte da interface de execução, não apenas como histórico textual. Quando esse contexto fica incoerente, o modelo pode tentar agir sobre uma visão desatualizada do catálogo de tools.

Como desenhar um agente mais confiável

Se a sua aplicação depende de tool calling, o objetivo não é só “fazer o modelo chamar uma função”. O objetivo é construir um pipeline que sobreviva a atrasos, retries, schemas em evolução e chamadas múltiplas sem quebrar a experiência do usuário.

Um padrão útil é separar claramente três responsabilidades: o modelo decide, o orquestrador valida, e o executor acessa sistemas externos. Assim, mesmo quando o modelo pede algo fora do esperado, sua aplicação pode normalizar ou recusar a execução sem derrubar o fluxo inteiro.

• Use schemas pequenos e específicos em vez de expor um catálogo gigante de uma vez, alinhando isso com o guidance de tool search.
• Trate cada retorno de tool como uma fronteira de confiabilidade: valide payload, tempo de execução e formato antes de reenviar ao modelo.
• Se houver built-in tools no caminho, não assuma paralelismo automático; desenhe para execução sequencial quando necessário [documentação oficial].
• Em Realtime, implemente timeout e fallback explícitos para calls que podem ficar pendentes, especialmente em integrações MCP [nota oficial].

Exemplo mínimo de orquestração defensiva

Quando o tema envolve execução real, vale pensar em um loop de agente simples no backend: o modelo solicita, o backend executa, o resultado volta, e o próximo turno decide o passo seguinte. Isso reduz a chance de o estado ficar implícito demais.

undefined

Esse tipo de wrapper não resolve tudo, mas já evita que uma falha de integração vire um comportamento opaco do agente. Em ambientes com muitas chamadas, a previsibilidade do executor costuma importar mais do que a “inteligência” do prompt.

Por que isso importa pro dev brasileiro

No Brasil, esse debate pesa por motivos bem concretos. Boa parte das equipes trabalha com orçamento em BRL apertado e com infraestrutura distribuída entre regiões como us-east-1, o que torna custo e latência parte do desenho do agente desde o início. Se cada turno do modelo carrega uma lista enorme de tools, ou se cada call externa vira retrabalho por timeout, a conta chega rápido no fim do mês.

Há também um componente regulatório e operacional: quando o agente toca dados pessoais, o desenvolvedor precisa considerar LGPD desde a coleta até a devolução do resultado. Em times brasileiros, isso costuma significar mais validação local antes de enviar algo para um tool externo, além de cuidado com logs e retenção de contexto.

Outro ponto é o perfil do mercado de engenharia no país. Muitos devs vêm de bootcamps, transição de carreira ou formação autodidata, então o salto de “chamar um endpoint” para “orquestrar um agente com tools, fallback e observabilidade” precisa ser didático e incremental. Nesse cenário, o centro da discussão não é acompanhar moda, e sim construir sistemas que caibam no custo, na governança e na maturidade operacional das equipes daqui.

Conclusão

O tool calling da OpenAI está mais próximo de uma camada de orquestração do que de uma simples funcionalidade de API. A migração para a Responses API, o uso de tool search e as integrações com MCP/Connectors apontam para agentes mais flexíveis, mas também mais sensíveis a detalhes de estado, paralelismo e tempos de resposta.

Se você for aplicar isso em produção, comece pequeno: escolha um fluxo real do seu sistema, limite o número de tools expostas, defina timeout e validação de payload, e meça onde o agente falha antes de aumentar a complexidade. Em até 1 hora, você consegue abrir a documentação oficial de Function calling e adaptar um único fluxo do seu backend para executar com validação explícita de tool e fallback de erro.

Conteúdos da DIO para quem quer aprofundar

• Microsoft AI for Tech - OpenAI Services — Integre serviços da OpenAI no Azure, com foco em aplicações práticas, chatbots e manipulação de texto para soluções cloud e back-end.
• XP Inc. - Cloud com Inteligência Artificial — Trilha para entender e implementar IA generativa na nuvem, com engenharia de prompt, modelos de aprendizado de máquina e projetos para portfólio.
• Nexa - Engenharia de Prompts na AWS com Claude — Jornada curta e prática sobre engenharia de prompts e uso de IA generativa com foco em produtividade e aplicações no dia a dia.
• Formação IA Fundamentals — Formação para começar do zero em IA, cobrindo fundamentos, prompts, automação, assistentes e aplicações reais.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.