OpenAI API e tool use: o que mudou para agentes
TL;DR
A OpenAI reorganizou o tool use para agentes em torno da Responses API, com ferramentas built-in como web search, file search e computer use, além de suporte a integrações remotas via MCP. Em paralelo, o Agents SDK consolidou a orquestração de fluxos single e multi-agent com handoffs e guardrails, reduzindo a necessidade de montar pipelines manuais de chamada de ferramenta, execução e reinjeção de contexto.
Para quem desenvolve, a mudança importa porque desloca a arquitetura do “chat com funções” para uma primitive mais completa de agentes. Na prática, isso afeta como você estrutura integrações, observabilidade e automação, especialmente quando precisa combinar busca na web, documentos internos e ações em interfaces gráficas.
O que mudou no tool use
No material oficial de março de 2025, a OpenAI passou a tratar a Responses API como a base para construir agentes, combinando geração de texto com ferramentas embutidas e um modelo de resposta orientado a itens. A mesma postagem posiciona o Agents SDK como camada de orquestração para workflows com um ou mais agentes.
Isso muda o desenho mental do desenvolvimento. Em vez de montar uma sequência artesanal de prompt, tool call, execução e retorno do resultado, você passa a pensar em uma API que já nasce preparada para esse ciclo, com streaming e acesso direto ao texto final via `response.output_text`.
Responses API como primitive central
A OpenAI descreve a Responses API como a interface unificada para agentic workflows, com ferramentas como web search, file search e computer use disponíveis no próprio fluxo de resposta. A documentação de lançamento também cita melhorias de UX e estado, incluindo design baseado em itens e eventos de streaming mais intuitivos, tudo na mesma página oficial New tools for building agents.
Para o desenvolvedor, o ganho prático é diminuir a cola entre etapas. Isso é útil quando você quer, por exemplo, combinar uma busca externa com consulta a material interno sem precisar manter múltiplos contratos paralelos entre APIs diferentes.
Ferramentas built-in: web search, file search e computer use
Entre as ferramentas built-in destacadas pela OpenAI estão web search, file search e computer use. A proposta é permitir que o agente consulte a web, recupere informação de arquivos e interaja com interfaces de computador dentro do mesmo padrão de execução, conforme descrito em New tools for building agents.
Esse formato é interessante para casos que exigem combinação de fontes. Um agente pode buscar contexto público, cruzar com documentação interna e então executar uma ação orientada por interface visual, sem que você precise desenhar uma camada separada para cada ferramenta.
Computer use e automação de interface
A OpenAI também apresentou o computer use como uma nova ferramenta na Responses API, associada ao modelo de Computer-Using Agent (CUA). Na postagem oficial, a empresa reporta resultados em benchmarks como OSWorld, WebArena e WebVoyager, sempre na mesma fonte primária New tools for building agents.
Na prática, isso abre espaço para automação em sistemas sem API pública ou em fluxos legados com interação visual. É um ponto sensível para times com muitos sistemas internos, incluindo ambientes corporativos usados no Brasil, onde ainda existem portais e backoffs operacionais sem integrações modernas.
O papel do Agents SDK
O Agents SDK aparece como o complemento de orquestração para a Responses API. O repositório oficial descreve o framework como uma base leve para fluxos single e multi-agent, com conceitos como agentes, handoffs, guardrails e sessions.
O valor aqui não é só “rodar um agente”, mas coordenar responsabilidade entre agentes especializados. Para uma equipe técnica, isso facilita desenhar arquiteturas em que um agente faz triagem, outro consulta fontes e um terceiro valida a saída antes de devolver a resposta final.
Handoffs, guardrails e organização do fluxo
Na página oficial da OpenAI sobre novas ferramentas, o Agents SDK é apresentado como evolução do ecossistema experimental anterior, com suporte a handoffs e mecanismos de proteção. Isso é relevante quando um caso de uso pede etapas separadas: um agente pode encaminhar a tarefa a outro, em vez de concentrar toda a lógica em um único prompt gigante fonte.
Para times com requisitos de auditoria ou segurança, guardrails importam bastante. Eles ajudam a separar o que é decisão do modelo e o que precisa de verificação, o que é especialmente útil em cenários com dados sensíveis, como cadastros corporativos ou fluxos cobertos por LGPD.
Integração com MCP remoto
Em uma atualização posterior da Responses API, a OpenAI passou a documentar suporte a remote MCP servers dentro do ecossistema de ferramentas. Essa capacidade aparece na página New tools and features in the Responses API, indicando continuidade no esforço de conectar agentes a sistemas externos de forma mais padronizada.
Isso é útil para organizações que já apostam em um catálogo de serviços internos expostos por padrões compatíveis com MCP. Em vez de criar integrações pontuais para cada sistema, a equipe pode centralizar conectores e deixar o agente consumir essas capacidades de forma mais previsível.
Como pensar a arquitetura na prática
Se você está saindo de um desenho baseado só em chat completions, a principal mudança é separar três camadas: raciocínio, ferramentas e orquestração. A Responses API cobre o ciclo de interação com as ferramentas; o Agents SDK cobre a composição entre agentes; e o seu código passa a focar em regras de negócio, permissões e observabilidade.
Esse recorte reduz acoplamento. Em vez de espalhar lógica de tool use em vários serviços, você tende a concentrar a política de decisão em um lugar mais claro, o que facilita manutenção e testes.
Exemplo de desenho mental de fluxo
Um fluxo típico pode começar com um agente de triagem, seguir para uma busca na web e depois consultar um repositório interno de arquivos. Se houver necessidade de navegação ou preenchimento em sistema legado, o fluxo pode acionar computer use; se a tarefa exigir especialização, o handoff leva a outro agente.
Esse modelo funciona bem para automações de suporte, inteligência comercial e revisão documental. Também ajuda quando você precisa registrar por que uma ferramenta foi acionada, algo importante para governança e para equipes que precisam prestar contas do uso de IA.
Quando isso faz sentido no Brasil
No contexto brasileiro, há um fator concreto que pesa: muitos times ainda operam com sistemas legados, integrações incompletas e requisitos de conformidade ligados à LGPD. Isso torna valioso um agente que consiga combinar busca, documentos internos e interação com sistemas sem exigir uma reescrita total da infraestrutura.
Além disso, o custo em reais e a janela de integração contam. Em muitas empresas brasileiras, especialmente em startups e squads enxutos, o orçamento não permite projetos longos de plataforma; então uma API de agentes com menos cola manual pode encurtar a entrega e reduzir retrabalho.
Implicações para quem constrói no Brasil
Para equipes brasileiras, a discussão não é só técnica; é operacional. Há uma pressão forte para entregar automações que convivam com sistemas estrangeiros, serviços hospedados fora do país e regras locais de proteção de dados, o que obriga a pensar em latência, residência de dados e contratos de acesso desde o início.
Outro ponto é a formação do time. No Brasil, é comum encontrar squads com perfis mistos, incluindo devs que vieram de bootcamps, backend tradicional e dados. Um SDK com conceitos claros de agentes, handoffs e guardrails tende a ser mais fácil de padronizar internamente do que uma coleção de chamadas soltas feitas de forma ad hoc.
Conclusão
A mudança da OpenAI aponta para uma camada de agentes mais integrada, com Responses API como núcleo e Agents SDK como orquestrador. O efeito prático é que tool use deixa de ser um detalhe periférico e vira parte estrutural da aplicação, com impacto direto em desenho de produto, observabilidade e governança.
Se você quer avaliar isso no seu stack, abra a documentação oficial da Responses API e compare com o fluxo atual do seu projeto em uma tarefa real: escolha um caso pequeno, como busca em documentos internos, e teste como ficaria a mesma automação com ferramentas embutidas e um agente de triagem.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
