OpenAI API: agentes multimodais, tools e o que importa agora

TL;DR

O brief desta rodada não confirmou um diff confiável da “última semana” em release notes atomizadas, então o foco precisa ficar no que a documentação oficial sustenta hoje: Agents SDK, Responses API, tool choice, tool search, web search e compaction. Na prática, isso muda como você desenha agentes multimodais: menos roteamento fixo, mais decisão em tempo de execução e mais ênfase em ferramentas como parte central da arquitetura.

O que dá para afirmar com segurança

A documentação oficial da OpenAI descreve um ecossistema em que o uso de ferramentas é nativo na Responses API, com o modelo decidindo quando chamar uma tool ou quando seguir um caminho controlado por você via `tool_choice`.

Esse detalhe parece pequeno, mas altera o desenho de produto. Em vez de tratar integrações como “extras”, você passa a pensar em orquestração por capacidades: busca, execução, navegação e manipulação de arquivos como partes do fluxo principal. A base oficial está em Using tools e em Agents SDK.

Tool use como primitive, não como gambiarra

O brief confirma que o suporte oficial de tools fica ancorado no array `tools` da Responses API. Isso permite conectar funções, buscas e outros recursos sem transformar o prompt em um amontoado de instruções frágeis.

Para quem constrói produto, a consequência é objetiva: você consegue separar melhor intenção, execução e observabilidade. O modelo escolhe a tool quando faz sentido, e o seu código continua responsável por validar entradas, registrar chamadas e lidar com falhas. A referência primária é a guia Using tools.

Tool search resolve um problema prático

Quando o conjunto de capabilities cresce, decidir qual tool usar deixa de ser trivial. A documentação de Tool search descreve descoberta em runtime, inclusive em cenários com MCP e deferred loading.

Isso é útil para agentes que trabalham com um catálogo dinâmico de ações. Em vez de hard-codar uma árvore enorme de if/else, você expõe recursos e deixa o sistema localizar a capacidade adequada no momento certo. Esse padrão também reduz o acoplamento entre o agente e a lista de integrações disponíveis.

Web search entra como ferramenta do fluxo

O guia oficial de Web search mostra que a busca externa pode ser mais uma tool da Responses API. Para cenários multimodais, isso ajuda quando a resposta precisa combinar contexto do diálogo, material recente e dados trazidos pelo próprio usuário.

O ponto importante aqui não é apenas “buscar na web”, e sim trazer recuperação externa para dentro da mesma interface de execução. Isso reduz a distância entre raciocínio e ação: o agente consulta, interpreta e continua o fluxo sem sair da estrutura da API.

Skills, shell e compaction reforçam agentes de longo horizonte

Os posts oficiais sobre skills e shell + skills + compaction tratam esses componentes como primitives para tarefas longas. A ideia é simples: o agente precisa ler, agir, persistir estado e voltar depois sem depender de memória improvisada.

Na prática, isso é relevante para tarefas como analisar arquivos grandes, atualizar projetos e executar passos sequenciais. O ganho está menos em “mais inteligência” e mais em mais previsibilidade operacional. Para times de produto, essa previsibilidade costuma valer mais do que uma demonstração chamativa.

Onde o recorte multimodal realmente pesa

Mesmo sem um diff semanal fechado, o panorama atual aponta para um tipo de agente que mistura texto, recuperação e execução. Nesse cenário, multimodal não é só aceitar imagem ou áudio como entrada; é conseguir encadear percepções e ações dentro do mesmo ciclo.

Se o seu caso envolve screenshot, documento, página web ou áudio transcrito, a pergunta deixa de ser “qual modelo responde isso?” e passa a ser “qual tool, qual estado e qual saída o agente precisa produzir?”. É uma mudança de arquitetura, não só de endpoint.

Menos prompt manual, mais contratos entre componentes

Quando tool use vira base, o prompt deixa de carregar toda a inteligência do sistema. O contrato passa a viver entre o modelo, as tools e a camada de validação. Isso melhora rastreabilidade e ajuda a colocar limites claros em chamadas externas.

Em projetos reais, esse desenho tende a ser mais fácil de auditar. Você consegue ver quando o agente decidiu buscar informação, quando executou uma ação e quando precisou compactar contexto para seguir adiante.

Por que isso importa pro dev brasileiro

No Brasil, a escolha de arquitetura costuma ser condicionada por custo, latência e conformidade. Times que atendem usuários em São Paulo, Recife ou Porto Alegre frequentemente dependem de infraestrutura hospedada fora do país, o que torna latência para regiões como us-east-1 um fator concreto no UX e no custo operacional.

Além disso, a LGPD exige cuidado especial com dados pessoais, consentimento e finalidade. Em agentes multimodais, isso pesa ainda mais porque uma imagem ou um áudio podem carregar dados sensíveis sem parecerem “dados de formulário”. Portanto, tool use e recuperação externa precisam vir acompanhados de classificação de dados, logging mínimo e filtros de saída.

Para muita gente no ecossistema brasileiro, que entra por bootcamps, migração de carreira ou aprendizado autodidata, a parte mais difícil não é chamar um endpoint. É desenhar um fluxo que funcione com orçamento em BRL, manutenção pequena e observabilidade suficiente para não virar caixa-preta.

Como transformar isso em decisão técnica

Se você está avaliando a adoção desses recursos, a decisão prática pode ser feita em três perguntas:

• O agente precisa escolher entre várias ferramentas em tempo de execução?
• Existe necessidade de consulta externa integrada ao fluxo, como web search ou MCP?
• O caso pede tarefas longas, com contexto que vai sendo compactado ao longo do tempo?

Se a resposta for “sim” para ao menos duas delas, você já está no território em que Agents SDK, tool use e compaction fazem diferença de desenho, não só de conveniência.

Conclusão

O recorte mais sólido da documentação atual da OpenAI é este: agentes modernos não dependem só de geração de texto, mas de uma camada explícita de ferramentas, descoberta em runtime e mecanismos para manter trabalho longo viável. Para multimodal, isso significa arquitetar o sistema como uma sequência de percepção, decisão e ação, com cada passo audível e validável.

Se você quiser aplicar isso hoje, pegue um fluxo real do seu produto — por exemplo, triagem de tickets, leitura de screenshots ou consulta de documentação — e redesenhe a primeira versão com uma única tool externa e um critério claro de `tool_choice`. Em menos de 1 hora, leia a seção de tools na documentação oficial da Responses API e adapte um caso simples do seu projeto para esse formato.

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