A "OpenAI Agents API" não é um único produto. É uma família de superfícies para criar agentes, ou seja, modelos que raciocinam, chamam ferramentas e repetem o ciclo até concluir uma tarefa, lançadas em etapas: a Responses API e o Agents SDK de código aberto em março de 2025, o AgentKit em outubro de 2025 e um ambiente de execução gerenciado que roda o ciclo para você. A única coisa que você precisa internalizar antes de construir: um agente é um ciclo, não uma única chamada. É nesse ciclo que moram todo o poder e todas as surpresas.
Se você está escolhendo uma superfície hoje, as duradouras são a Responses API, o Agents SDK e a Agents API gerenciada. O Agent Builder sem código está de saída (some em 30 de novembro de 2026). E se o que você realmente quer é um agente de suporte funcionando, em vez de um ciclo para construir e manter, essa é a troca que a eesel oferece: uma colega pronta para trabalhar com preço mensal fixo a partir de $299 por 500 créditos, sem orquestração para você cuidar.
O que a "OpenAI Agents API" realmente é
Vale desembaraçar isso primeiro, porque a expressão aponta para algumas coisas relacionadas que chegaram em momentos diferentes, e a nomenclatura é realmente confusa.
Tudo começou em março de 2025, quando a OpenAI lançou a Responses API e o Agents SDK de código aberto juntos, com as primeiras ferramentas integradas. A Responses API é a peça básica: um superconjunto do Chat Completions pelo qual os modelos geram respostas e a superfície em que toda ferramenta hospedada se conecta. Ela também é a futura substituta da antiga Assistants API. O Agents SDK é a camada de orquestração sobre ela, cuidando do ciclo do agente, das transferências entre agentes e das barreiras de proteção dentro da sua própria aplicação.
Depois, em outubro de 2025, veio o AgentKit, um conjunto de ferramentas para quem não queria escrever o ciclo à mão: o Agent Builder (uma tela de arrastar e soltar), o Connector Registry, o ChatKit (uma interface de chat incorporável) e o Evals ampliado. Mais recentemente, a OpenAI adicionou um ambiente de execução Agents API totalmente gerenciado que roda o ciclo para você no seu próprio arnês do Codex, com compactação de contexto e orquestração multiagente embutidas.
Eu desenvolvo as integrações da eesel, então já construí esse mesmo ciclo à mão mais de uma vez, e o modelo mental que mais ajuda é este: nada disso é mágica. Um agente é um modelo a quem você deu uma tarefa, um conjunto de ferramentas e permissão para continuar se chamando até terminar. Todo o resto, o SDK, o ambiente gerenciado, a tela visual, é uma resposta diferente para uma pergunta: quem executa esse ciclo, e onde?
Como o ciclo do agente realmente funciona
Este é o conceito mais importante e o que faz tropeçar toda equipe nova. Uma chamada de API comum é uma requisição e uma resposta. Um agente é um ciclo delas.
Você dá uma tarefa ao agente. O modelo raciocina sobre ela, decide que precisa de informação e chama uma ferramenta (uma busca na web, uma consulta a um banco de dados, uma função que você escreveu). A ferramenta devolve um resultado, esse resultado volta para o contexto do modelo e o modelo raciocina de novo com a nova informação. Se terminou, responde. Se não, chama outra ferramenta. E assim por diante até a tarefa ser concluída ou um limite interromper.
O diagrama de execução da própria OpenAI deixa concreta a versão multiagente: um agente de triagem chama POST /v1/responses, passa por uma barreira de proteção e então transfere para um agente de CRM, que chama o modelo de novo e aciona uma ferramenta. Isso já são várias chamadas de modelo para uma única tarefa.
O que surpreende as pessoas é o crescimento do contexto. Cada resultado de ferramenta se acumula no prompt da chamada seguinte, então o ciclo não só multiplica as chamadas, como infla o tamanho de todas as posteriores. Um desenvolvedor descreveu a realidade com mais franqueza que qualquer página de documentação:
"I was spending $200/day running agents with tool calls. The problem: tools return huge JSON (search results, DB queries, file listings). Each response bloats context. By turn 10, you're paying for 100k+ tokens on every LLM call."
Isso não é um aviso para assustar, é aquilo em torno do qual você deve projetar. O ciclo é o seu poder (é o que permite a um agente encadear pesquisa, decisões e ações) e a sua principal alavanca. Ciclos mais curtos, saídas de ferramenta mais enxutas e tentativas limitadas são quase tudo que separa um agente barato de um caro. Os melhores agentes de IA são aqueles em que alguém pensou bastante em quão poucas voltas cada tarefa realmente precisa.
Os quatro ambientes de execução: escolha onde o ciclo roda
Quando você aceita que um agente é um ciclo, a próxima decisão é onde ele roda. A OpenAI agora oferece quatro ambientes de execução, e eles diferem principalmente em quanto do ciclo é seu.
- Agents API roda o ciclo para você em um arnês do Codex gerenciado, com compactação automática de contexto, orquestração multiagente e um sandbox hospedado opcional. A opção que menos exige de você, e a compactação realmente ajuda a manter o ciclo enxuto.
- Agents SDK roda o ciclo dentro da sua própria aplicação. Você cuida de implantação, armazenamento e aprovações; o runner cuida do ciclo e das transferências. É onde a maioria das equipes que querem controle real acaba.
- Responses API é construir a partir da peça básica: você chama o modelo diretamente e monta sua própria orquestração e histórico. Controle máximo, responsabilidade máxima.
- ChatKit é o front-end de chat incorporado que você coloca no seu produto, apoiado em qualquer um dos anteriores que faça o trabalho de verdade.
Nenhum deles muda o que o modelo ou as ferramentas fazem. Eles mudam quem é responsável por disparar o ciclo, que é a decisão que molda toda a sua arquitetura. Se você quer que o agente seja o seu produto, o SDK ou a Responses API dão o controle. Se quer um agente dentro de um app existente sem hospedar um runner, a Agents API gerenciada é o atalho.
As ferramentas hospedadas que um agente pode usar
Um agente só é tão útil quanto as ferramentas que consegue chamar. Além das suas próprias funções, a OpenAI oferece um conjunto de ferramentas integradas que se conectam direto à Responses API:
- Web search permite ao agente buscar informação ao vivo na internet, com um parâmetro
return_token_budgetque limita quantos tokens de resultado voltam ao modelo. Útil, porque resultados de busca são exatamente o tipo de saída volumosa que infla um ciclo. - File search faz recuperação sobre seus próprios documentos em um armazenamento de vetores, construído sobre embeddings. É assim que você dá ao agente a sua base de conhecimento, e dá para limitar o número de resultados recuperados para manter o contexto enxuto.
- Code Interpreter executa Python em um contêiner isolado, para análise de dados, manipulação de arquivos e contas que o modelo não deveria fazer de cabeça.
- Computer use permite ao agente operar um navegador ou desktop. Para os modelos mais novos, o caminho recomendado pela OpenAI é um ciclo de execução de código em que o modelo escreve um script que o seu próprio sandbox executa, em vez de uma ação hospedada dedicada.
As ferramentas são o que transforma um chatbot em um agente, e escolhê-las bem é metade do trabalho de design. Um agente de suporte que consegue pesquisar a sua central de ajuda e ler o histórico de pedidos faz algo que um simples bot de FAQ nunca faria. Cada chamada de ferramenta também é uma volta do ciclo, então a regra prática é dar ao agente exatamente as ferramentas de que o trabalho precisa e nenhuma a mais.
AgentKit e o que está sendo encerrado
Se escrever o ciclo à mão parece muito, o AgentKit foi a resposta da OpenAI: uma camada visual para montar agentes sem código. O Agent Builder é sua tela de arrastar e soltar, e vale uma olhada porque deixa visível o formato multiagente.
Esse fluxo (início, uma barreira contra jailbreak, um agente de classificação, um if/else que encaminha para um agente de devolução, retenção ou informação, e então uma barreira contra alucinação antes da resposta) é um bom retrato do que um fluxo de suporte real precisa. Cada nó que diz "agente" é pelo menos mais um POST /v1/responses.
Aqui está o porém, e ele importa se você está escolhendo uma superfície hoje. A OpenAI está encerrando o Agent Builder e o Evals, e a partir de 30 de novembro de 2026 eles não estarão mais disponíveis. Na documentação eles já aparecem sob o título "Legacy APIs", e a OpenAI agora orienta você ao Agents SDK focado em código ou aos Workspace Agents no ChatGPT.
Então construa sobre as superfícies duradouras: a Responses API, o Agents SDK, o ambiente da Agents API gerenciada, o ChatKit e o Connector Registry. Trate a tela visual como uma boa forma de prototipar e entender o formato, não como aquilo em que você compromete a produção. A boa notícia é que as próprias camadas não têm taxa separada; a OpenAI é explícita de que as ferramentas do AgentKit estão "included with standard API model pricing", então a escolha é sobre durabilidade, não custo.
Como construir um de verdade
Chega de conceitos. Esta é a sequência que eu seguiria para colocar um primeiro agente no ar, seja qual for o ambiente que você escolher.
- Escolha um modelo. Ajuste ao trabalho, não ao folheto. Um roteador ou classificador simples vai bem em um modelo mais barato como o gpt-5.6-luna; um agente de pesquisa ou raciocínio em várias etapas pede um mais forte. Você pode até misturar modelos em um fluxo multiagente: um pequeno para a triagem, um maior para a etapa difícil.
- Escolha um ambiente de execução. A Agents API gerenciada se quer que a OpenAI execute o ciclo, o Agents SDK se quer executá-lo no seu próprio app com controle total.
- Escreva as instruções e escolha as ferramentas. O prompt do sistema é a descrição do cargo do agente. Depois dê a ele exatamente as ferramentas de que precisa: integradas, como web search e file search, mais suas próprias chamadas de função para tudo específico do seu produto.
- Adicione barreiras de proteção. Barreiras de entrada (verificações de jailbreak e de tema) e de saída (uma checagem de alucinação ou segurança antes de a resposta chegar a um usuário). É a parte que as equipes pulam e depois lamentam.
- Teste antes de ir ao ar. Rode o agente com entradas realistas e observe o ciclo inteiro, não só a resposta final. Ver que um agente deu quatro voltas porque as três primeiras saídas falharam na validação é exatamente o que você quer descobrir antes de um cliente.
- Lance e depois vigie o custo de execução. A unidade que importa é a execução inteira, com tentativas e chamadas de ferramenta incluídas, não o preço de um único token. Instrumente para ver o tamanho do ciclo por tarefa desde o primeiro dia.
Se essa lista soa como um projeto de engenharia de verdade, é porque é. Construir um agente sobre infraestrutura bruta é a decisão certa quando o agente é o seu produto e você quer controle até o token. É a decisão errada quando você só precisa que um trabalho seja feito, como um bom atendimento ao cliente, e não quer ser dono para sempre de um ciclo, de uma bateria de avaliações e de uma pilha de monitoramento.
Quanto custa (a versão curta)
Não existe um único "preço da Agents API". Você soma tokens do modelo a cada volta, cobranças por chamada das ferramentas hospedadas e tempo de contêiner na execução de código, e o tamanho do ciclo é o que realmente mexe na conta. As tarifas dos modelos vão de $0.20 por 1M de tokens no mais barato até $10 por 1M de entrada no topo de linha; web search custa $10 por 1.000 chamadas; file search custa $2.50 por 1.000 chamadas.
Essa é a manchete, mas a conta real está no ciclo, então demos a ela um guia próprio: o detalhamento completo, um exemplo resolvido e um estimador de custo ao vivo estão em preços da OpenAI Agents API. Se você está comparando provedores, nosso artigo OpenAI API vs Anthropic API faz os mesmos números para o Claude.
Experimente a eesel e pule o ciclo por completo
Este é o enquadramento honesto. A OpenAI Agents API é infraestrutura: a matéria-prima com que você monta um agente, mais o ciclo, as avaliações e o monitoramento que você mesmo constrói e mantém. É a escolha certa quando o agente é o seu produto.
A eesel é a outra ponta dessa troca: não é infraestrutura, mas uma colega pronta para trabalhar. Você contrata a colega de suporte com IA, conecta ao seu helpdesk e ela chega já conhecendo a sua empresa pelos seus tickets anteriores e pela central de ajuda. Passamos anos colocando agentes de IA em filas de suporte reais, e é por isso que cada implantação é simulada com os seus tickets históricos antes de responder a um único cliente de verdade. Não há ciclo para você medir, porque o preço é fixo: a partir de $299 por mês por 500 créditos, em que 1 crédito é um ticket ou chat, sem cobrança por quantas chamadas de modelo ou saltos de ferramenta foram necessários para resolver. O ciclo imprevisível é problema nosso, não seu.
E se foi o controle programático que atraiu você na Agents API, a eesel mantém isso. Há uma CLI pública de verdade (@eesel/cli) além de um servidor MCP, webhooks e acesso à rede, então você pode conectar uma integração, editar as instruções permanentes do agente, listar e aprovar ações com humano no ciclo e ler o registro de atividade execução por execução a partir de um terminal ou script. A documentação diz com clareza, "everything on this site can be done from the terminal", e agentes de programação como Claude Code e Cursor podem operá-la diretamente. Você ganha a superfície amigável a agentes sem construir e vigiar o agente em si.
Se você está construindo um agente porque quer ser dono de cada token, a OpenAI Agents API é um lugar realmente bom para isso. Se está construindo porque precisa resolver o atendimento ao cliente, comece um teste gratuito e deixe a colega fazer o trabalho.