OpenAI e tool use agentic: o que mudou na API e por que isso importa

TL;DR

A OpenAI vem consolidando o tool use agentic em torno de Responses API, Agents SDK, Skills e padrões para tarefas de longa duração. Isso importa porque o foco saiu de chamadas pontuais para fluxos com estado, recuperação e coordenação de ferramentas em várias etapas.

Na prática, a mudança favorece quem constrói automações, copilots e assistentes que precisam agir de forma consistente ao longo do tempo. Para times no Brasil, isso pode reduzir retrabalho em fluxos internos que dependem de integrações com documentos, planilhas, CRMs e serviços corporativos já usados no dia a dia.

O que a OpenAI está chamando de fluxo agentic

O recorte mais importante do brief é que a OpenAI posiciona a Responses API como base para trabalhos agentic. A ideia é sair de um padrão centrado em prompt-resposta e chegar a sistemas que conseguem tomar ações com ferramentas hospedadas, manter estado de sessão e coordenar passos múltiplos no mesmo fluxo.

Esse detalhe muda a forma de pensar a aplicação. Em vez de tratar tool calling como um complemento isolado, o design passa a assumir que o agente vai precisar consultar algo, decidir o próximo passo, executar a ação e seguir adiante sem perder contexto.

Responses como fundação do orquestrador

O material recente da OpenAI descreve a Responses API como o ponto de convergência para tool use em fluxos multi-turn. No blog Why we built the Responses API, a própria empresa conecta essa API ao objetivo de construir sistemas com ferramentas hospedadas e suporte mais natural a workflows complexos.

Para quem desenvolve, isso significa menos dependência de soluções ad hoc espalhadas no código e mais clareza sobre onde o estado do trabalho vive. Em agentes de produto, essa separação ajuda a manter rastreabilidade, porque cada etapa pode ser tratada como parte de uma execução maior, não como requisições soltas.

Skills como camada de capacidades plugáveis

Outro ponto recorrente no brief é a abstração de Skills. No post Using skills to accelerate OSS maintenance, a OpenAI mostra Skills como uma forma de empacotar capacidades que o agente pode acionar quando precisa de contexto ou de um comportamento especializado.

O efeito prático é conhecido por quem já montou integrações com ferramentas: o modelo não precisa “saber tudo” de memória. Ele escolhe a skill adequada, consulta a fonte certa e continua o trabalho com menos chance de inventar resposta. Isso é especialmente útil quando a tarefa envolve documentação, repositórios ou rotinas operacionais que mudam com frequência.

MCP e a busca por padronização da integração

O brief também aponta integração com MCP em workflows práticos. Isso é relevante porque o ecossistema de ferramentas para agentes tende a ficar mais útil quando a interface entre modelo e sistema externo fica padronizada. Em vez de criar um conector específico para cada fonte, o time pode reutilizar um protocolo de integração mais consistente.

Na prática diária de engenharia, isso reduz a fricção para conectar o agente a repositórios internos, bases de conhecimento e documentação. O ganho não é só arquitetural; ele aparece também em manutenção, porque um conector padronizado tende a ser mais fácil de testar e substituir do que uma amarração feita caso a caso.

Long-running agents: Shell, compaction e continuidade

O material Shell + Skills + Compaction: Tips for long-running agents that do real work mostra que a OpenAI está pensando em agentes que não terminam em um único turno. O foco aqui é longo prazo: tarefas que continuam, acumulam etapas, produzem artefatos e precisam preservar coerência ao longo do tempo.

Esse cenário é importante porque boa parte dos casos reais não cabe em uma chamada curta. Um agente de suporte interno, por exemplo, pode ler arquivos, revisar um estado de projeto, atualizar documentação e continuar no próximo ciclo sem recomeçar do zero.

Shell para ações concretas

O padrão Shell aparece como a superfície para executar trabalho real no ambiente. Em vez de o modelo apenas descrever o que faria, ele pode acionar comandos, interagir com arquivos e tocar etapas que têm efeito fora da conversa.

Isso aproxima o agente de um assistente operacional. Para engenharia, é a diferença entre obter uma sugestão e entregar uma execução rastreável, algo mais útil quando a tarefa inclui artefatos de software, conteúdo ou manutenção de sistemas.

Compaction para conter o crescimento do contexto

A compaction entra como resposta ao problema de horizonte longo. Em workflows extensos, o contexto cresce, a janela pesa e o custo para manter tudo visível sobe. A proposta é resumir e consolidar o que importa sem perder a continuidade do trabalho.

Na prática, isso melhora duas coisas: custo e legibilidade do estado do agente. Quando o contexto fica mais enxuto e organizado, o sistema tende a errar menos em tarefas longas e o time consegue entender melhor por que uma decisão foi tomada.

O que mudou de “assistente” para “produto agentic”

O comparativo implícito no brief é claro: antes, muita gente montava chat + tool calling como um recurso pontual. Agora, a direção é transformar esse conjunto em produto, com primitives mais estáveis para sessão, ferramentas, execução e observabilidade.

O post From prompts to products: One year of Responses reforça justamente essa transição. A mensagem é que fluxos com ferramentas, multi-etapas e persistência de contexto já aparecem em exemplos de produto, não só em demos.

Multi-agent e coordenação de ferramentas

O repo openai/openai-agents-python aparece no brief como referência para orquestração multi-agent. Isso é útil para separar responsabilidades: um agente coleta informações, outro valida, outro transforma e um quarto consolida o resultado.

Essa divisão costuma ser mais fácil de manter quando a base de orquestração está clara. Em vez de uma lógica monolítica tentando resolver tudo, o sistema ganha papéis mais definidos e cada etapa do fluxo pode ser observada com mais precisão.

Observabilidade e recuperação como parte do design

O lado importante aqui é menos “uso de IA” e mais engenharia de sistema. Quando um agente executa ações, o time precisa saber o que aconteceu, em que ponto houve falha e como recuperar a execução. A arquitetura agentic só faz sentido se houver caminho para auditoria e retomada.

Isso é especialmente relevante em operações corporativas, onde a tarefa não termina na resposta em texto. Há logs, estados intermediários, decisões tomadas e, muitas vezes, impactos em sistemas que precisam ser explicados depois.

Como isso afeta quem constrói no Brasil

No Brasil, o debate fica mais concreto porque muitos times precisam integrar agentes a processos internos já existentes, com orçamento menor e margem baixa para manutenção complexa. Um sistema que reduz retrabalho em documentação, triagem e automação de tarefas pode ter impacto real em squads que operam com recursos limitados.

Além disso, há um ponto regulatório e operacional que pesa aqui: LGPD e governança de dados. Quando o agente consulta documentos, tickets ou CRM, o desenho precisa considerar consentimento, minimização de dados e rastreabilidade do que foi usado na resposta. Isso não é um detalhe cosmético; no contexto brasileiro, é requisito de projeto.

Integração com stacks comuns no mercado local

Grande parte das empresas brasileiras usa ecossistemas já consolidados, como Microsoft 365, Azure, planilhas e bases internas espalhadas. O valor de um fluxo agentic está em reduzir a distância entre esses sistemas e a ação executável, sem exigir uma reescrita completa da operação.

Por isso, o fato de a OpenAI empurrar Responses, Skills e integrações padronizadas conversa bem com a realidade de times que precisam começar pequeno, provar valor e só depois expandir. Para o mercado brasileiro, isso é relevante porque muitas iniciativas de IA nascem em pilotos curtos, com pressão por resultado rápido e custo controlado.

Exemplo de arquitetura mínima para um time de produto

Se você quiser testar essa direção em um projeto interno, a estrutura pode ser bem enxuta: uma camada de entrada, um orquestrador via Responses, uma skill para documentação ou busca, e um mecanismo de persistência do estado da execução. O ponto não é copiar a stack da OpenAI, e sim organizar responsabilidades.

Um recorte útil é este:

1. o usuário pede uma tarefa;
2. o agente identifica se precisa consultar fonte externa;
3. uma skill faz a leitura ou busca;
4. o agente decide o próximo passo;
5. o resultado vai para o sistema alvo com registro do que foi executado.

Esse arranjo funciona bem quando a operação precisa ser auditável. Em um contexto brasileiro de time pequeno, isso evita que a automação vire uma caixa-preta difícil de sustentar depois que o primeiro demo passa.

Conclusão

A direção recente da OpenAI é bastante clara: tool use deixou de ser um recurso lateral e passou a integrar a fundação de produtos agentic. Responses API, Skills, MCP e padrões para long-running agents apontam para uma arquitetura mais organizada para sistemas que executam tarefas reais.

Se você está construindo isso hoje, a forma mais segura de começar é pequena e observável. Abra a documentação oficial da Responses API em developers.openai.com/blog/responses-api e leia a seção sobre tool calling e state-driven workflows para mapear um piloto de 1 hora no seu produto.

Conteúdos da DIO para quem quer aprofundar

• Aceleração Microsoft - Azure AI Agents — 3 dias de mentorias ao vivo para criar, orquestrar e governar agentes de IA integrados ao ecossistema Microsoft.
• Microsoft AI for Tech - OpenAI Services — trilha para integrar serviços da OpenAI no Azure e desenvolver aplicações com GPT e IA em cloud.
• Aceleração: AI Reports com Excel, GPT Agents e Claude Code 2º Semestre — conteúdo prático para criar agentes de IA e automatizar fluxos com ferramentas de produtividade.
• Santander - RAG com ChromaDB, LlamaIndex e Python — trilha voltada a aplicações de IA mais eficientes com persistência de informação e RAG.
• CrewAI Fundamentals — fundamentos de orquestração de agentes em cenários multiagente.
• AI Automation com N8N — automação de fluxos com IA e integrações úteis para processos repetitivos.

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