OpenAI Agents API: tool calling no Responses
TL;DR
A OpenAI passou a concentrar o desenvolvimento de agentes em torno do Responses API, com tool calling nativo, tools hospedadas e integração mais direta com o Agents SDK. Na prática, isso reduz a “cola” manual entre chamadas e melhora o caminho para fluxos multi-turn, observabilidade e uso de ferramentas externas.
Para quem constrói produto, a mudança importa porque simplifica a orquestração de ações do modelo sem depender de lógica espalhada no app. O efeito é especialmente relevante em times que precisam conectar APIs internas, MCP e ferramentas próprias sem transformar cada passo em um framework sob medida.
O que muda com o Responses API
O ponto central das novidades recentes é tratar o Responses API como primitive unificado para workflows agentic. Em vez de pensar só em prompt + resposta, a aplicação passa a lidar com um fluxo em que o modelo pode raciocinar, chamar ferramentas e continuar a execução dentro da mesma arquitetura de interação, conforme descrito em New tools for building agents e no balanço de um ano do recurso em From prompts to products: One year of Responses.
Isso é relevante porque o tool calling deixa de ser um detalhe periférico e vira parte do desenho do produto. Em projetos que antes dependiam de orquestração manual entre endpoints, o Responses API reduz a quantidade de “cola” no lado do cliente e facilita lidar com múltiplas ferramentas em sequência.
Tool calling hospedado e tools customizadas
A documentação recente destaca dois caminhos complementares: tools hospedadas pela própria plataforma e tools customizadas, usadas quando a aplicação precisa consultar sistemas ou APIs específicas. O resultado é um modelo que consegue alternar entre ferramentas de forma mais natural, sem o app precisar reconstruir cada etapa do raciocínio do agente, como mostrado em From prompts to products: One year of Responses.
Para o desenvolvedor, o ganho prático aparece quando a tarefa exige combinar fontes diferentes. Um agente pode consultar uma base interna, enriquecer a resposta com uma ferramenta própria e fechar o ciclo sem sair do ecossistema do Responses.
Agents SDK: function tools, Hosted MCP e coordenação
O Agents SDK entra como a camada de abstração para definir ferramentas e conectar superfícies de execução ao agente. A documentação oficial lista function tools, HostedMCPTool e outras primitivas de tool surfaces, criando um caminho mais claro para expor funções, integrar servidores MCP e organizar o estado da execução.
Na prática, isso reduz o atrito entre o código Python/TypeScript do time e a forma como o modelo consome ferramentas. Em vez de manter contratos improvisados, o SDK ajuda a tipar a entrada, validar payloads e estruturar melhor as capacidades expostas ao agente.
Function tools com schema e validação
As function tools permitem transformar funções em ferramentas com schema derivado e validação automática, o que é útil quando a integração precisa ser estável. A documentação do SDK indica esse caminho em openai-agents-python, aproximando a experiência de um contrato bem definido entre aplicação e modelo.
Esse detalhe importa mais do que parece. Em times com múltiplos devs, schema explícito reduz ruído em revisões, facilita testes e evita que mudanças sutis em parâmetros quebrem o comportamento do agente em produção.
Programmatic Tool Calling e o salto de coordenação
Um dos pontos mais interessantes do material recente é o Programmatic Tool Calling. O SDK oficial documenta o recurso em tools.md, descrevendo a possibilidade de o modelo gerar JavaScript para coordenar ferramentas elegíveis antes de consolidar o resultado final no fluxo de Responses.
Isso não é apenas “mais uma chamada de ferramenta”. É uma mudança no nível de coordenação: em vez de um ciclo simples de um tool call por vez, o modelo pode organizar trechos de execução programática para decidir como combinar ferramentas, o que amplia a expressividade do agente dentro das restrições do SDK.
Esta seção descreve uma superfície recente do ecossistema OpenAI. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Compatibilidade e restrições importam
A documentação também é clara sobre o escopo: esse tipo de tool calling avançado depende de modelos compatíveis com Responses. Em outras palavras, não é uma camada genérica que funciona do mesmo jeito em qualquer backend; ela foi desenhada para a arquitetura do Responses API e do Agents SDK, conforme o próprio guia oficial de tools.
Essa limitação precisa entrar na avaliação técnica desde o início. Se o projeto ainda usa um fluxo baseado em Chat Completions, a migração tende a exigir revisão de arquitetura, não só troca de endpoint.
Long-running agents: estado, compaction e execução contínua
Outro vetor forte dos releases recentes é o suporte a agentes que executam trabalho por mais tempo. O texto Shell + Skills + Compaction: Tips for long-running agents that do real work apresenta padrões para manter estado, continuar execuções e lidar com contexto sem estourar a janela de conversa.
O valor disso aparece em cenários reais de produto: automações que leem arquivos, consultam sistemas e precisam de continuidade. Em vez de acoplar a lógica inteira ao front ou a um worker externo, o fluxo do agente passa a ter mais recursos para preservar contexto e concluir tarefas complexas com menos intervenção humana.
Por que compaction faz diferença
Compaction é importante porque agentes longos tendem a acumular histórico rápido. Quando o backend consegue comprimir contexto e preservar apenas o que interessa, a aplicação fica mais robusta para fluxos maiores, evitando perdas de informação e reduzindo a necessidade de recomeçar tarefas do zero.
Para o desenvolvedor, isso significa projetar prompts e tools com mais atenção ao que é persistente e ao que é descartável. Esse tipo de disciplina costuma ser o que separa um protótipo que funciona de uma automação útil no dia a dia.
Por que importa pro dev brasileiro
O contexto brasileiro torna essa mudança ainda mais prática. Em muitas empresas no Brasil, o desenvolvimento precisa conviver com integrações em AWS us-east-1 por custo e disponibilidade regional, além de exigências da LGPD quando dados pessoais entram no loop do agente. Se o fluxo de tool calling é mal desenhado, o risco não é só técnico: é latência maior, custo em dólar e exposição desnecessária de dados.
Há também um fator de mercado local. Times brasileiros costumam trabalhar com budgets mais apertados e com forte mistura de SaaS, ERPs e APIs legadas. Um primitive unificado como o Responses API ajuda a reduzir retrabalho na orquestração e facilita manter governança sobre o que o agente chama, o que é importante quando a operação precisa ser previsível e auditável.
Como avaliar essa stack num projeto real
Se você quer testar a arquitetura agora, comece pelo caminho mais simples: mapeie uma tarefa que hoje exige 2 ou 3 chamadas encadeadas no app e reescreva esse fluxo usando Responses + uma function tool. A documentação de referência está em New tools for building agents e em openai-agents-python/tools.
Depois, compare três coisas: número de chamadas, complexidade da orquestração e clareza do contrato de tool. Se o agente ficar mais simples de operar sem empurrar lógica demais para o cliente, você já tem um sinal útil de que a migração vale aprofundar.
Conclusão
O movimento recente da OpenAI aponta para uma camada mais integrada de agentes, em que Responses API, function tools, Hosted MCP e Programmatic Tool Calling fazem parte do mesmo desenho. Para quem constrói produto, a leitura prática é simples: menos cola no app, mais contratos explícitos e um caminho mais claro para agentes que executam trabalho de verdade.
Se você quer sair do abstrato em menos de 1 hora, abra a documentação oficial do Agents SDK, escolha uma função pequena do seu projeto e modele essa função como tool para comparar o fluxo atual com uma execução via Responses API.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
